When a customer leaves, the leased equipment leaves with them. Not intentionally — they just forget. And if your termination workflow doesn’t automatically trigger a returns process the moment the service is ceased, you’ll spend months chasing kit that’s gathering dust in someone’s attic.
It starts the same way every time. A customer calls to cancel. The service is ceased, the line is deprovisioned, the account is closed. Somewhere in a back-office system, a case is marked complete. And somewhere in that customer’s house — tucked behind the television, on a shelf in the hallway, quite possibly in the loft by now — sits a router and two mesh nodes that belong to you.
They didn’t steal it. They meant to send it back. They just never got the box. Or they got the box and it sat on the kitchen worktop for three weeks until someone put it in the recycling by mistake. Or they moved house two months after cancelling and the router went into a removal van and hasn’t been seen since.
For any operator leasing equipment rather than selling it — and the economics of leased hardware are compelling enough that most modern operators go this route — this is not a small problem. A decent mesh router and two satellites costs somewhere between £180 and £350 at hardware cost. Multiply that by the number of terminations you process in a year. Now think about your current recovery rate.
If you’re managing equipment recovery manually — a note on the account, a task for a back-office team, an email that goes out a week after termination if someone remembers — your recovery rate is almost certainly lower than you think it is, and the write-off is showing up somewhere in your accounts as “equipment losses” without anyone having a clear picture of the scale.
Why termination is different from a move
This distinction matters operationally, and it gets glossed over a lot. When a customer moves house, the equipment question is straightforward: they take the kit with them, it gets reconnected at the new address, end of story. The equipment never leaves the customer relationship. You don’t need a recovery workflow because there’s nothing to recover.
Termination is completely different. The customer is leaving. The service is ending. The equipment — which belongs to you, which the customer has been leasing as part of their contract — needs to come back. And the moment the service is ceased is the moment the clock starts on that recovery. Not next week when someone gets around to sending a letter. Not when a back-office team picks up the account in their weekly review. Right now, automatically, as part of the termination workflow.
“The moment the service is ceased is the moment the recovery clock starts. Not next week. Not when someone picks up the account. Right now, automatically.”
The reason this doesn’t happen at most operators isn’t indifference. It’s that the termination workflow and the equipment recovery workflow live in different systems, managed by different teams, with no automated handoff between them. The service is ceased in the provisioning platform. Equipment recovery is a logistics and billing function. Nobody connected them.
What actually happens without automation
The gap between “service ceased” and “returns box dispatched” is where equipment disappears. Here’s the typical sequence at an operator managing this manually.
The termination is processed. The account is marked closed. At some point — maybe the same day, maybe several days later — a back-office team member reviews closed accounts and flags the ones with leased equipment outstanding. They raise a task to send a returns kit. The task goes into a queue. The returns kit is ordered from the logistics provider. It arrives at the customer address. Maybe.
By the time the returns box arrives, it’s been two weeks since the service was ceased. The customer has already half-forgotten they had the equipment. They’ve moved on. The box sits in the hallway. The deadline on the returns label comes and goes. A reminder letter goes out — if anyone notices the box hasn’t been returned. Another few weeks pass.
At some point the equipment is either written off or someone makes a phone call. Either way, it took significant manual effort to get to a bad outcome.
The move-with-termination trap
Watch out for the move scenario that masquerades as a termination. A customer cancels at their current address and simultaneously places a new order at a new address — but your systems process these as a termination and a new install, not a move. The recovery workflow fires, a returns box is sent to the old address that nobody lives at anymore, and the equipment ends up at the sorting office. The new install gets new equipment. You now have two sets of hardware in circulation for one customer relationship. This is a workflow logic problem, not a people problem, and it needs to be handled at the system level.
What the workflow should look like
The right architecture for equipment recovery on termination is a Bridge Server workflow that fires automatically the moment a termination is confirmed — not queued, not batched, not dependent on a human picking up the account. Confirmed termination triggers the workflow. The workflow does the work.
The move-versus-terminate problem in more detail
We mentioned this in passing above, but it deserves more attention because getting it wrong is expensive in both directions.
When a customer moves house, the intended outcome is continuity: same customer, different address, same equipment where possible. The last thing you want is for the recovery workflow to fire and dispatch a returns box to a property the customer has just vacated. Especially because that returned equipment will then need to be checked, cleaned, repackaged, and reallocated — while a new router is being shipped to the new address. You’ve just turned one piece of hardware into four logistics events.
The workflow needs to check, before dispatching anything, whether there’s a pending new install associated with the same customer or account. If there is, the recovery should be suspended and a human flag raised — because the correct handling depends on whether the equipment is moving with the customer, being collected from the old address, or being left for the new occupant (which is a whole separate question if the new occupant is also taking service from you).
This isn’t exotic edge-case logic. It’s a scenario that happens on a significant proportion of your terminations, and handling it wrong generates a disproportionate amount of operational mess.
What gets tracked, and why it matters for the balance sheet
Equipment recovery is fundamentally an asset management problem dressed up as a customer service one. Every router and mesh node in circulation has a book value. The difference between that value and what you write off at year end is a direct function of your recovery rate. Operators who have never measured this properly are often genuinely surprised when they do the first time.
The workflow needs to close the loop back to the asset register. When equipment is returned and received by the logistics provider, that confirmation needs to flow back into the inventory system — serial numbers matched, condition recorded, asset status updated. When equipment is not returned within the deadline and a charge is applied, that also needs to be recorded against the asset.
Without this closed loop, you have no reliable picture of how many devices are currently in circulation, how many have been lost, how many are in transit, and how many are sitting in lofts. The write-offs happen at year end when someone does an audit and the numbers don’t add up.
“Every router in a customer’s loft has a book value. Operators who have never measured their recovery rate are often genuinely surprised when they do the first time.”
The customer experience angle
It’s worth saying something about how this feels from the customer’s perspective, because it’s easy to design a recovery workflow that’s efficient for the operator and genuinely unpleasant to receive.
The customer has just cancelled their service. They may have left for a competitor, which is already a signal that something in the relationship didn’t work. The last thing they need is a poorly timed, impersonal communication that feels like a demand rather than a request. The first communication needs to go out promptly — within a day of termination — be clearly worded, include exactly what needs to be returned and how, and make the returns process as frictionless as possible.
A pre-printed label in a correctly sized box is not a luxury. It’s a basic requirement for a recovery rate worth having. Customers who receive a returns label and have to source their own packaging return their equipment at significantly lower rates than customers who receive a complete returns kit. The cost of the box is trivially small compared to the cost of the hardware it’s supposed to recover.
The follow-up communications, when they’re needed, need to strike a tone that’s firm without being aggressive. The customer did not steal the equipment. They forgot, or they’ve been busy, or the box is still on the worktop. A reminder that feels like a legal threat will generate complaints and, occasionally, a social media post that you’d rather not have to deal with.
The parts of this that keep being done manually
In most operator environments, even ones with reasonably sophisticated OSS platforms, equipment recovery still involves a surprising amount of manual work. The most common gaps we see are these.
The initial trigger. The termination happens in the provisioning system. The returns process happens somewhere else — a logistics platform, a back-office CRM, a spreadsheet. Nobody automated the handoff. Someone checks a queue and raises a task. Sometimes same day. Sometimes not.
The move check. Nobody built the logic to check whether a termination is actually a move. The recovery workflow fires regardless. Equipment gets collected from old addresses that nobody lives at. New equipment is shipped to new addresses. The inventory gets messier with each occurrence.
The tracking loop. Returns are tracked by the logistics provider. Whether those tracking updates flow back into the inventory system — and close the workflow in the OSS — is often left as a manual reconciliation exercise. Someone downloads a report from the courier portal once a week and updates a spreadsheet.
The escalation. When equipment isn’t returned by the deadline, the escalation to billing for the non-return charge should be automatic. In most environments it’s a manual flag that gets raised when someone remembers to check. Which means the charge is often applied late, or not at all.
None of these gaps are technically difficult to close. They’re closed by building the right workflow in Bridge Server, giving it the right integrations, and letting it run. The reason they persist is usually that nobody has made it a priority — the scale of the problem isn’t visible until you measure it, and most operators haven’t measured it.
Starting the measurement
Before you can fix the recovery rate, you need to know what it is. That means pulling three numbers: how many terminations in the last twelve months involved leased equipment, how many pieces of equipment were returned, and how many were written off. The gap between the first number and the second is your problem size.
For most operators who do this exercise for the first time, the number is uncomfortably large. Not because the equipment is being stolen — it almost never is — but because the recovery process is slow, manual, and loses momentum at every handoff. The customer who would have returned the equipment if a box had arrived within three days is much less likely to return it if it arrives three weeks later and they’ve already rearranged the living room.