The 5-stage loaner lifecycle: an operations model
22 May 2026 · 6 min read
Most asset checkout tools think loaners have two states: checked out and returned. That model is fine if you're tracking laptops at a school. It's broken if you're a medical device dealer running a substitution pool.
Between "shipped to customer" and "in pool, ready for next deployment" there are three additional operationally critical states that most software ignores. This post lays out the full model.
Why two states aren't enough
Here's a real conversation I overheard last month at a dealer's service depot:
Operations: "Where's loaner unit #14?"
Tech: "I dropped it at Clínica Dental Lisboa last Thursday."
Operations: "Their machine's back from repair. Should be there by now to swap."
Tech: "Right. They called me yesterday — they have it. I'll go pick up our loaner."
Operations: "When?"
Tech: "Tomorrow probably."
Operations: "OK. Tell me when it's back so I can mark it available."
Tech: "Sure. Need to clean it first too. Take three days."
Three days. Three days where the unit isn't with the customer, isn't returned to the pool, isn't available for another deployment, and your Excel says nothing about where it is. The system shows "deployed" because that's the only non-returned state, but it's misleading. Anyone planning capacity decisions based on that spreadsheet makes wrong calls.
The 5 stages, defined
Stage 1: in_transit_out
The transport box has left your service depot. It's with the courier, en route to the customer. Equipment hasn't been received yet. You can't promise it to anyone else, and the customer can't use it yet.
Trigger: service team marks "dispatched" — typically with a tracking number.
Transition out: customer confirms receipt → at_customer.
Typical duration: few hours to 2 days.
Stage 2: at_customer
Loaner installed at the clinic. Customer is operational. This is the "active deployment" state — what most asset systems call simply "checked out".
Trigger: customer or installer confirms unit working.
Transition out: their original equipment is back from repair, you collect the loaner → in_transit_back.
Typical duration: days to weeks, depending on repair turnaround.
Stage 3: in_transit_back
The transport box is now in the OPPOSITE direction — from the customer back to your service depot. The customer no longer has the unit. Your service depot doesn't have it yet.
Trigger: service tech picks up loaner from customer (often combined with delivering their repaired unit).
Transition out: arrival at depot → cleaning.
Typical duration: hours to 1 day.
Stage 4: cleaning
The loaner is back in your depot but NOT yet available for the next deployment. It's being cleaned, sterilized, inspected for damage, and (if needed) flagged for service. For medical devices this stage is non-negotiable — you cannot ship a used unit without re-processing.
Trigger: unit received at depot.
Transition out: processing complete → closed.
Typical duration: hours to 3 days, depending on device class and your throughput.
Stage 5: closed
Loaner is back in the pool, available for the next deployment. Assignment is finalized. All photos, notes, tracking, and audit entries are sealed.
Trigger: service tech signs off on cleaning + QC.
Transition out: none — this is terminal. Unit appears as "available" until next deploy.
Why this matters operationally
- Accurate capacity planning. You can tell which units are actually deployable now (closed) vs physically with you but not deployable (cleaning) vs deployed (at_customer). Excel collapses these to "out" and you can't plan.
- Cycle time per stage. Where's your bottleneck? In transit? At customer (slow repairs)? Cleaning? Without the 5 stages, you can't tell. With them, you measure each.
- Customer communication. "Your loaner is in cleaning, will be back in pool tomorrow" is more useful than "it's not here yet". The 5-stage model gives you the vocabulary.
- Chain of custody. Each stage transition is timestamped + attributed. For MDR audits this is gold.
- SLAs. If you commit to "loaner deployed within 24h of request" — which stage starts the clock? The 5-stage model lets you define SLAs unambiguously.
Common pitfalls (avoid these)
Pitfall 1: Skipping stages "to save time". "We received it back, but let's mark it closed right away — cleaning is automatic." No. If the unit isn't physically available for redeployment, the data shouldn't say it is. Honesty in stage = honesty in reporting.
Pitfall 2: Manual transition entry. Asking technicians to log into the app and click "mark arrived" creates compliance debt. The transition should be one tap on a mobile flow, or automatic from a tracking webhook.
Pitfall 3: No "needs service" gate before re-deploying. Unit returns with a sticky button. You mark it closed → available. Next day someone deploys it again — broken. You need a flag between cleaning and closed that says "this unit has an open service ticket; do not re-deploy".
How Loaners.app implements this
The five stages live in the schema as a CHECK constraint on the stage column of loaner_assignments. The state machine enforces legal transitions only:
in_transit_out → at_customer → in_transit_back → cleaning → closed
You cannot skip stages. You cannot jump backwards (only the explicit "extend assignment" flow modifies dates). Each transition writes an audit log entry with timestamp + actor.
Each stage has a timestamp column on the assignment row, so cycle time per stage is one SQL query:
avg(arrived_at_customer_at - checked_out_at) -- transit out time avg(loaner_pickup_at - arrived_at_customer_at) -- at_customer time avg(arrived_back_at_service_at - loaner_pickup_at) -- transit back time avg(cleaning_completed_at - arrived_back_at_service_at) -- cleaning time
You see your bottleneck in seconds, not hours of manual spreadsheet analysis.
Start measuring stages
Free trial. Run 5 deployments through the 5-stage flow. Look at the analytics page. You'll know where your operation actually loses time within a week.