The timely recovery of decommissioned devices is critical to a well-managed mobile environment. Device recovery is not just important to ensure that any residual corporate information is wiped. These decommissioned devices are worth real money with recyclers.

Unfortunately, actually getting devices back can be harder than you’d think. You have to know who has it, which isn’t always straightforward if an employee has been off-boarded. When you do know, you have to make sure that person knows where to send it. Then you have to follow up to make sure it is actually shipped.

In our early days, this was a very time-consuming, manual process. A support tech would create a return label, send it to the user via our ticketing system, then periodically check tracking to see if it was shipped. If it wasn’t, they’d send reminders. This says nothing of the updates needed in our asset tracking system.

As we grew, this process was high on the list of things to automate.

SHIPPING BOT TO THE RESCUE

Repetitive, structured processes like this are made for machines. Our dev team mapped out the process with our service desk leadership and went to work building a bot that could be assigned to a ticket and take over the entire recovery process.

This bot works just like a virtual support tech. If a request includes a device that must be recovered, our service desk attaches the asset to the ticket, assigns the ticket to the shipping bot, then moves on to more important work. In the background, the bot picks up the ticket, constructs a return label, and emails the user with instructions on returning the device or devices.

The bot uses Shippo to integrate into the shipping companies like FedEx or UPS and listens for movement on the tracking number. Rules associated with each client determine how often we remind the user to return the device and when to give up. Templates allow us to tailor the messages to each client’s specific needs.

FEWER ERRORS, BETTER USER EXPERIENCE, AND MORE CONSISTENT DATA

You can imagine that doing a process like this manually is fertile ground for mistakes. Support techs had to manage this queue manually, which meant reminders didn’t always go out on schedule. A tech working through the queue might make a mistake and refer to an iPhone when the device was a Galaxy S10. Sometimes the wrong shipping information was generated. With the bot, these issues almost disappeared.

Even with canned notes in the ticketing system, a tech in a rush might forget to use it and send a reminder that either wasn’t clear or was a little too curt. Sometimes, recovery tickets were closed prematurely, confusing users. As a result, user experience wasn’t always up to our standards. The bot always sticks to the script approved by the client, and users have become accustomed to the messages and know exactly what to do.

Another issue with the manual system was related to its impact on the validity of our asset data. We track client assets to know whether they are deployed, in depot, pending return, or decommissioned. At certain steps in the recovery process, these assets get updated to reflect their status. Humans can get distracted or forget to update those asset statuses, so we found that it introduced errors that cause reporting to be off sometimes. Now, the bot modifies those statuses automatically, ensuring that asset data is more consistent.

MORE IMPORTANTLY, A HAPPIER TEAM

While our clients love these benefits, our team appreciates the bot for other reasons. The manual process was universally derided by our support staff, and can you blame them? It is not fun at all to churn through tickets, tracking shipments, making the same notes over and over. Talk about boring. The more we can offload repetitive tasks like these to machines, the more our support staff can focus on talking to people, digging into more complicated issues, or training. In short, it gives our team more opportunity to hone their skills and lets them drive more value to our client.