Example architecture

A service job, end to end

This is an example architecture, not a client engagement. The operation is composite and the names are generic.

Context

A distributed service operation: customers, dispatch, field teams, assets, parts and billing, across multiple locations and several systems.

Operational constraint

Each boundary is a place where context can be lost. The job does not fail at any one step; it accumulates ambiguity until closeout, where the cost lands as rework and delayed billing.

Customer reports a faultDecides: Service desk
Each boundary is a place where context can be lost. The job does not fail at any one step; it accumulates ambiguity until closeout, where the cost lands as rework and delayed billing.
RequestState it is left in:Logged with the customer's words, not the asset's historyDecides:Service deskSystem of record:CRMFinds out:Immediately
DispatchState it is left in:Assigned on availability, not on what the job needsDecides:DispatcherSystem of record:Scheduling toolFinds out:Same day
TechnicianState it is left in:Arrives without asset history or partsDecides:TechnicianSystem of record:Nothing portableFinds out:On site
FindingState it is left in:Real scope differs from the reported faultDecides:TechnicianSystem of record:Notes and photosFinds out:On site
Quote and approvalState it is left in:Waiting on a decision nobody ownsDecides:Nobody definedSystem of record:EmailFinds out:Days
PartsState it is left in:Ordered against an unconfirmed scopeDecides:Parts deskSystem of record:InventoryFinds out:After approval
CloseoutState it is left in:Billing reconstructs the job from fragmentsDecides:AdministrationSystem of record:ERPFinds out:Weeks

A dashed marker means the handoff has no defined owner and depends on a person carrying the context.

Each boundary is a place where context can be lost. The job does not fail at any one step; it accumulates ambiguity until closeout, where the cost lands as rework and delayed billing.

How to read it

  • The expensive step is not the visit. It is the approval loop that has no owner and no state.
  • Three boundaries depend on a person carrying context that no system holds.
  • Billing is slow because the job was never in one place; administration is reassembling it after the fact.
  • Lifecycle ownership and an approval state with a defined owner fix more here than a new mobile app would.
Example architecture: a service job across a distributed operation | BoRo Studio