Built in
The open loop, captured
Here's the everyday version: a tech goes out to investigate a fault, figures out what's wrong, and the fix needs a part nobody's holding. The visit's done, but the job isn't. That gap — "we still owe this customer a repair" — is exactly what a We Owe is for.
From the service request, you open a We Owe and describe what's still owed: "needs a new air end," say. It carries the customer, the asset, and the branch along with it, and it lands on your open-commitments list so it can't get lost between visits.
Investigate → order → install
That promise usually has a few moving parts, so a We Owe breaks into a checklist of sub-tasks — the natural shape of this kind of work:
- Investigate — confirm the diagnosis and the exact part needed.
- Order the part — get it on the way, note the ETA.
- Install it — schedule the return trip and put it in.
Each step is assignable and checked off on its own, so the person ordering the part and the tech going back out can both see exactly where things stand.
The follow-up visit links back
When the part lands and it's time to go install it, that return trip is its own service request — scheduled and dispatched like any other job. The difference: it's linked back to the We Owe. So the original investigation and the follow-up install read as one connected story, not two unrelated visits to the same customer.
A We Owe can link to more than one service request, which matters when a fix takes two or three trips. The hours and materials from each linked visit roll up onto the We Owe, so the full cost of making good on that promise sits in one place.
Closing the loop
Once the part's in and the customer's running, you mark the We Owe completed and it clears off your open list. Need to pause — backordered part, customer not ready? Defer it with a reason and an optional resume date so it resurfaces on its own instead of relying on memory.