How to Automate Laptop Retrieval in Your Offboarding Workflow

ReRoutd Admin — Thu, 29 Oct 2026 22:59:43 +0000

Most offboarding stacks can kill a departing employee’s access in minutes. SSO goes off, the mailbox converts, the license frees up. Then there’s the laptop, which is still sitting on a desk three states away, and the only thing tracking it is someone’s memory.

That’s the gap worth automating. Not because shipping a box is hard, but because the return is the one offboarding step with no owner, no state, and no timestamp. Here’s a workflow that gives it all three, from the HR trigger to a reimaged machine back in the pool.

Treat the return as a state machine, not an email

The mistake most teams make is modeling retrieval as a message: “Hey, can you send the laptop back?” Messages don’t have states. They get read, half-answered, and forgotten.

Model it as a record instead. Every departing device gets one return record, tied to the asset tag and serial, that moves through a fixed set of states. Each state has an owner and an expected duration. When a record sits in one state too long, something fires.

return_record:
  asset_tag: LT-0412
  serial: C02XXXXXXX
  employee_status: terminated   # from HRIS
  states:
    - requested        # kit ordered, owner: IT
    - kit_delivered    # carrier confirms delivery to employee
    - in_transit       # employee dropped it off
    - received         # box arrived at company address
    - checked_in       # serial matched, condition logged
    - reimaged         # ready for reassignment
  escalate_if_stuck_days:
    kit_delivered: 5
    in_transit: 7

The numbers in escalate_if_stuck_days are yours to set. The point is that they exist.

Step 1: The trigger

The workflow starts when HR records a termination date, not when someone remembers to open a ticket. Most HRIS tools can fire a webhook or a scheduled export when an employee’s status or end date changes. Point that at your ticketing system (Jira Service Management, ServiceNow, Freshservice, whatever you run) and have it create one offboarding ticket with subtasks.

One of those subtasks is “Device return,” and it should be created automatically for every asset assigned to that person. Pull the assignment from your MDM or asset inventory, not from the employee’s recollection. People forget the old iPad in the drawer.

If your HRIS can’t send events, a daily scheduled job that diffs end dates against yesterday’s export works fine. Boring is good here.

Step 2: Lock in MDM, don’t wipe yet

On the last day, or the moment access is cut for involuntary exits, send a remote lock from your MDM. Jamf, Intune, Kandji and the rest all support it. A locked laptop is useless to anyone else and still intact for you.

Resist the urge to wipe remotely before the device is back. A wipe before return removes your ability to check the machine, recover files someone forgot to hand over, or confirm it’s the device you think it is. Lock now, wipe on your bench.

Log the lock in the return record with a timestamp. Auditors and security reviews love that line.

Step 3: Confirm the address, then request the kit

The most common reason a return stalls has nothing to do with the employee. It’s a stale address. People move during a notice period, or the HRIS still has the address from their offer letter.

So the kit request step has two parts:

HR confirms the current shipping address with the employee before anything ships.
IT orders the kit to that address.

The second part is where a laptop retrieval service earns its place. Instead of asking the departing employee to find a box, buy tape and front postage, a prepaid kit arrives with packaging sized for the device, a paid return label and a tamper-evident seal. Their only job is to pack it and drop it off at a carrier.

If your retrieval vendor doesn’t offer an API, don’t force it. Keep the order as a ticket subtask with a named owner and paste the tracking reference back into the record. Automation is about state and ownership, not about every step being a webhook.

Step 4: Track states, not a tracking number

A tracking number in one person’s inbox isn’t visibility. What you want is the return record’s state visible to both IT and HR, so nobody has to ask “did that laptop ever come back?” in Slack.

Map carrier and vendor events to your states. Delivery of the kit moves the record to kit_delivered. The first carrier scan on the return leg moves it to in_transit. Delivery to your company address moves it to received.

Then wire the escalation. If a record sits in kit_delivered past your threshold, the ticket pings the manager or HR, not the IT tech who already has thirty other tickets. The person who has the relationship sends the nudge. Many kit services also send automated notifications to the employee, which takes the routine reminders off your plate entirely.

Step 5: Check-in at intake

“Delivered” is not “done.” Plenty of asset records go wrong in the last ten feet, when a box gets signed for and dropped in a closet.

Make check-in a required step that closes the record:

Confirm the seal is intact before opening.
Scan or type the serial and match it against the record.
Note condition and anything that came back with it (charger, dock).
Flag mismatches immediately. A wrong serial is far easier to chase this week than next quarter.

Only a serial match moves the record to checked_in.

Step 6: Wipe, reimage, reassign

Now wipe. Use your MDM’s erase command or your standard reimage process, then re-enroll the device so it’s ready for the next hire. Record the wipe and the reimage as their own timestamps, separate from check-in. That way your records can always answer two different questions: did we get it back, and is it clean?

The whole flow in one table

State	Trigger	Owner	Escalate if stuck
requested	HRIS end date set	IT	Kit not ordered within 1 business day
kit_delivered	Carrier delivery scan	HR	No return scan after your threshold
in_transit	First return-leg scan	IT	No movement after your threshold
received	Delivered to company address	IT	Not checked in within 2 business days
checked_in	Serial matched at intake	IT	n/a
reimaged	Wipe and re-enroll logged	IT	n/a

The thresholds are examples. Pick numbers that fit your team, write them down, and let the ticket enforce them.

Copy-paste checklist

[ ] HRIS end date creates an offboarding ticket automatically
[ ] Ticket creates one “Device return” subtask per assigned asset
[ ] Remote lock sent in MDM and timestamped
[ ] Current shipping address confirmed by HR
[ ] Prepaid kit ordered, sized for the device
[ ] Return record visible to IT and HR
[ ] Escalation goes to the manager or HR, not the help desk
[ ] Seal checked and serial matched at intake
[ ] Wipe and reimage logged as separate steps
[ ] Record closed only after the serial match

Where to start

You don’t need to build all of this at once. The highest-value change is the first one: make the HRIS end date create the device return subtask automatically. That alone turns “who’s chasing that laptop?” into a ticket with an owner.

If you want to skip the box-and-label part, here’s what’s inside a prepaid laptop return kit and how it fits into this flow.

The ReRoutd team

DEV Community: ReRoutd Admin