The Spare workflow is similar to the “temporary” workflow, but involves the exchange of 2 devices instead of one. This workflow also works well with the iiQ Spare Pool app and follows the same process supported by Spare Pool. Please note that Spare Pool is not required.
This workflow is ideal for districts that either use Spare Pool or have adopted a “loaner” program for students who damage their district-issued device throughout the year, and receive their original device after it is repaired (as opposed to keeping the “spare” device for the remainder of the year).
This workflow supports the following process:
The agent initiates the “Spare” workflow from a ticket scenario when:
The student needs to turn in their device for repair
The student needs a Spare device to use until their original device is repaired
The student picks up a Spare device and drops off the damaged device for repair
The agent submits the damaged device for repair
The agent returns the repaired device to the bay for pick-up
The student picks up the repaired device and drops off the Spare device
From the LocknCharge widget located in the lower right-hand corner of the ticket details page, select Spare. An additional setting appears: Reserve bay for all events. This option should be selected if the Agent wishes to lock down the bay used for device pick-up and returns. Leaving this option unchecked, the Agent will have to select a tower and bay when they are ready for the user to return their device. This will determine the timing of the notifications as well as which tower and bay are included in the instructions for device return.
Select Spare workflow and then Start. Next, the users will be prompted to select a tower that they wish to distribute the temporary (loaner) device from. The left side of this widget includes a full list of all of the district’s LocknCharge towers. Use the search bar to search by the tower's name, location, serial # or asset tag.
Each tower listing includes:
Tower online/offline status
the name of the tower
total number of bays for the tower (either 5 or 15)
Total number of bays for each status
Please note that while Agents have the ability to view the contents of towers that are offline, it is not recommended for offline towers to be used in ticketing workflows. If towers are offline, workflows are not accurately reflected in the iiQ ticket interface.
After selecting a tower from the list, the user will then have visibility of each bay in the tower and be prompted to select which bay they would like to use for the ticket they are working on.
The bay status, contents in the bay, and tickets a bay is reserved for will all be displayed within this list view to provide context on how other bays within the tower are currently being utilized.
If an Agent wishes to distribute a device that is already pre-loaded into the bay, they’ll want to choose a bay that has an “Asset Available” status.
If an Agent wishes to distribute a device that they currently have in their possession, but still want to reserve the bay for the ticket they’re working on, they’ll want to select a bay that has an “Available” status and select the device that they’re issuing to the user.
Bays that are already “In Use” or in an “Offline” status will not be able to be selected.
Bay Statuses in iiQ - These statuses are only applicable for working with bays in iiQ, and do not reflect bay statuses from the LocknCharge Cloud portal.
Online - indicates the tower is connected and includes any of the following bay statuses
Available: Bay is online, empty, and ready for use on a ticket.
Ideal for the “return” use case or any workflow when an asset is not pre-loaded into the bay (IE device or item in Agent’s possession prior to initiating workflow)
Asset Available: Bay is online, contains an asset or item, and is ready to be used on a ticket.
Ideal for workflow when bays are preloaded with devices and ready for pick-up
In Use: Bay is online, may or may not contain an asset or item, and is reserved for a ticketing workflow (ticket number & link to view ticket will be included with bay status)
Offline - indicates the bay is offline and not available to manage remotely.
After selecting a bay and ensuring that the asset data entered in this field accurately reflects the device being returned to the requestor, they will then need to toggle the prompt that appears below the asset: “Bay is preloaded with selected asset?”
This option should be selected if the device the Agent is issuing has already been loaded into the bay (either via the tower management interface in iiQ or by physically unlocking the tower and loading the bay).
By enabling this option, an email notification is immediately sent to the requestor of the ticket that contains instructions for picking up the device.
By leaving this option disabled, the system will assume that the asset will need to be loaded and the bay door will need to be closed before proceeding with the workflow, so the email notification will be sent after the next “bay close event.”
Also, have the option to add any item description to the bay from this interface by clicking the Custom description button. Users can input any text values that describe the contents they’re placing in the bay. After entering the description, they’ll want to click the Checkmark icon to save the description. Any text entered into this field will also be used in ticketing notifications that instruct requestors of what they’re picking up. But these can only be sent via initiating a LocknCharge ticketing workflow from the ticket details widget.
Example use cases that this option can be used for include:
Adding chargers to bays for distribution if a student or teacher forgets theirs
Adding other device peripherals to the bay for pick-up
Adding documentation or paperwork that must be signed or notarized to the bay
If the bay still needs to be loaded with the selected device or add a custom item description, the following message will be displayed in the ticket details widget after clicking Confirm.
Once the bay has been accessed to load with the requester’s repaired device, and the bay door is closed, the email notification will be triggered. The following prompt will appear in the ticketing widget.
These notifications can also be referenced in the “emails” tab of the ticket, so Agents and Admins have the ability to see when the email was initiated, who the recipient(s) is (are), and preview a copy of the email notification.
After the exchange event has taken place and the bay door is closed, the assigned Agent will be notified of the exchange and instructed to pick up the damaged device from the bay. After the Agent collects the damaged device, the ticket widget will prompt them to verify the asset exchange in order to ensure that asset data is updated correctly. Please note that the Agent will not be able to progress the workflow without completing this step.
When selecting the option to Verify Exchange, the Agent will be asked to confirm that the correct asset was returned and also indicate if they are leaving the asset inside the bay or removing it for repair. If the Agent doesn’t need the device in their possession in order to troubleshoot (IE can be done remotely), the device can remain in the bay while being serviced to ensure it's connected to the network and charging.
If the Agent selected the option to “Reserve bay for all events” when initiating the workflow, the prompt below will display on the ticket until the repaired device is loaded back into the bay in order to be returned to the requester. By choosing this option, the bay will be locked down for the duration of this ticket’s repair process.
If the Agent did not select the option to “Reserve bay for all events” when initiating the workflow, the prompt below will allow the Agent to complete the “return” phase of the process using any tower and bay that are available. Select Continue and the Agent will choose a tower and bay where the user will pick up their device and return the Spare device to.
After selecting a bay and ensuring that the asset data entered in this field accurately reflects the device being returned to the requestor, they will then need to toggle the prompt that appears below the asset: “Bay is preloaded with selected asset?”
This option should be selected if the device the Agent is issuing has already been loaded into the bay (either via the tower management interface in iiQ or by physically unlocking the tower and loading the bay).
By enabling this option, an email notification is immediately sent to the requestor of the ticket that contains instructions for picking up the device. These instructions are included in a screenshot below.
By leaving this option disabled, the system will assume that the asset will need to be loaded and bay door will need to be closed before proceeding with the workflow, so the email notification will be sent after the next “bay close event.”
If the bay still needs to be loaded with the selected device (or custom item description), the “Waiting for device to be loaded into tower” message will be displayed in the ticket details widget after clicking “Confirm”.
If the bay is pre-loaded with the requester’s repaired device, then the requester will be notified after the bay selection is complete. The instructions included in this notification are below:
Once the requester has picked up their repaired device and returned the Spare device, the Agent will be notified of an exchange event on the ticket and then be prompted to verify the exchange details:
They will first need to verify that the Spare device was returned to the bay so that it can be unassigned.
Then they will need to verify if the device will remain in the tower for the next requester in need of a Spare or if it will be removed. This ensures that the bay status is updated correctly following the completion of the workflow.
An outline of how the ticket, notifications, and asset data are impacted during each step of the “Spare” workflow is included below:
Workflow Step | Ticket | Email Notifications | Asset | Bay Status |
Agent initiates workflow by selecting the Spare workflow & selecting a tower and bay |
|
|
| Updated to “In Use” |
If bay isn’t pre-loaded with asset before initiating workflow, | “Waiting for device to be loaded into tower” widget display |
|
|
|
If bay is preloaded with an asset, these are triggered when the Agent confirms bay being used on the ticket. If bay isn’t preloaded, these are triggered by the next bay close event. | “Pin Email sent to requestor” | (1) Notification sent to end user with instructions for device pickup of spare and drop-off of damaged device |
|
|
Requester accesses bay and closes door | Ticket timeline updated to reflect Spare device pick-up | Notification sent to Agent notifying them of exchange event | (2) Spare asset is assigned to requestor of the ticket | Remains “In Use” Asset in bay is updated to reflect damaged device |
Agent verifies exchange | Ticket timeline updated to reflect verification |
|
|
|
After device is repaired, Agent continues workflow by EITHER: Selecting new tower/bay for return flow OR by loading user’s repaired device + closing bay |
| (1) Email notification with instructions for return of Spare and pick-up of original device are sent to requester after bay close event |
| If new bay selected for return, this bay status is set to “In Use” |
Requester drops off Spare device and picks up repaired device + closes bay door | Agent is prompted to verify exchange Timeline is updated to reflect the return of Spare device | Agent is notified of exchange event |
|
|
Agent opens bay to verify correct Spare was returned and confirm the device was either picked up or left in bay + closes bay door | Widget is updated to prompt Agent to complete verification process |
|
|
|
Agent completes verification steps from ticket modal | Resets to default display |
| (2) Spare is unassigned from requester | Bay status updates to either: “Asset Available” if Spare remains in bay (Agent’s choice during verification) “Available” is Spare is removed from bay during verification |
(1) Email notifications are sent to the “submitted by” requester in the event that the ticket is created on behalf of another user. In the near future, iiQ will add support for sending email notifications to associated parent/guardian accounts of the requester if applicable.
(2) Asset assignment logic varies depending on how many requestors are captured on the ticket. If the ticket is submitted on behalf of a user, the device is assigned to the “on behalf of” requester.
---
Hannah Bailey - Director, Customer Engagement