The Return workflow is essentially the reverse process of the New ticketing workflow. Simply allows Agents to easily send instructions for users to drop-off or return items in a LocknCharge bay. This workflow is ideal for collecting devices or accessories from students or staff members throughout the year on an ad hoc basis. This workflow allows Agents to associate a ticket with an empty bay by indicating the contents they are expecting to be returned, and then sends email notifications to requesters with corresponding instructions for completing the return process.
From the LocknCharge widget located in the lower right-hand corner of the ticket details page select the Return workflow and then Start. 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.
For the Return workflow, users are prompted to select an “Available” bay (IE one that the system recognizes as empty already) and indicate what they are expecting to be returned, either via asset tag or serial number. Another option is to add a custom item description for returns that do not involve an iiQ asset.
To add a custom 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 about 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
After selecting an asset or adding a description, select Confirm. An email notification containing instructions for the return process is sent to the requester. An example of this email notification is included below.
After the requester has returned the item or device following the instructions provided, the Agent is notified of the exchange event via the “Ticket Updated” notification and the ticket timeline is updated to reflect that the bay was accessed.
Agents will need to have “Ticket Updated” notifications enabled in their notification preferences to receive notifications of bay activity on tickets they are assigned.
The Agent will then need to access the bay to verify that the expected device or contents were returned. The Agent will need to check the bay to ensure the following:
The correct device was returned to the bay. This ensures the correct asset record is updated in iiQ after the workflow is complete.
They are either leaving the device in the bay or removing it. This ensures the bay status of the tower is updated accurately following the completion of the workflow.
They are unassigning the owner of the device that was returned. This ensures the device ownership is updated correctly following the completion of the workflow.
Once this verification step has been completed,
The bay status will become either:
“Available”, if the end-user toggled the option to “leave asset in bay” OFF during the verification step.
“Asset Available”, if the end-user toggled the option to “leave asset in bay” ON during the verification step.
The LocknCharge widget available from the ticket details page will default to its default state, and end users are able to initiate another workflow from its original state if needed.
The asset, either left in the bay or removed from the bay, will either:
Be unassigned; if the user confirms the correct asset was returned and chooses to unassign the device.
Remain assigned to the user that returned the device; if the user confirms the correct asset was returned and toggled the option to unassign the owner from the device OFF during the verification step.
After completing the verification step, the workflow is complete and the widget returns to its default state. The asset and bay status is updated according to the Agent’s selection during the verification step.
An outline of how the ticket, notifications, and asset data are impacted during each step of the “Return” workflow is included below:
Workflow Step | Ticket | Email Notifications | Asset | Bay Status |
Agent initiates workflow by selecting a tower, bay, and expected device or item description for return + clicking “Confirm” | Widget updates to reflect return process instructions | (1) Email notification sent to requester that contains instructions for return |
| Updated to “In Use” |
User accesses bay to drop off device or other item + closes bay door | Exchange event logged in ticket timeline | “Ticket Updated” notification sent to Agent notifying them of exchange event |
|
|
Agent accesses bay to verify contents, remove asset or other contents, and closes bay door | Ticketing widget updates to prompt verification step |
|
|
|
Agent completes verification step | Verification logged in ticket timeline as resolution action Ticket widget reverts to default state |
| If applicable, returned asset is unassigned depending on Agent’s selection during verification | Bay status updated to reflect “Available” or “Asset Available” depending on Agent’s selection |
(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.
---
Hannah Bailey - Director, Customer Engagement