Key takeaway
Treat the visit and the customer job as different units. Link returns with evidence, and preserve unresolved or abandoned jobs in the denominator.
One customer problem can create several dispatches
A dispatch count is a record of visits, while a job count is a record of the underlying work. Decide which unit answers the proposed question before merging records. If the question is “what sequence resolved the fault?”, several visits may form one episode. If it is “what happened on each visit?”, flattening the sequence would discard waiting, inspection and failed intervention.
NIST’s work-order example deals with varied descriptions of problems and actions; DOE’s federal O&M guidance treats maintenance within a wider operating program. The visit model here is an editorial adaptation, not a field-service standard published by either agency. It is intended for an internal reconciliation exercise before discussing any real sample.
A completed linkage table
In this hypothetical job J-028, an initial visit diagnoses intermittent drainage trouble. A second visit installs a replacement component but fails the agreed operating check. A third visit corrects a connection and records a passing check. The service manager links all three because the dispatch notes refer to the same original job and symptom. That link is explicit; shared customer identity alone would not be enough.
Add a fourth row for a separate job at the same premises. This makes the main exclusion rule concrete: a repeated location is not necessarily a callback. The illustrative identifiers below describe structure only and are not customer records.
| Visit | Episode link | Visit outcome | Job interpretation |
|---|---|---|---|
| V1: inspect | J-028; original job reference | Diagnosis recorded; no repair | Open episode |
| V2: replace | J-028; callback reference to V1 | Action done; check failed | Not yet resolved |
| V3: reconnect | J-028; continuing symptom | Defined check passed | Resolved under recorded check |
| V4: new request | J-029; different equipment and issue | New work commissioned | Separate episode, despite same site |
Decide which linkage evidence is strong enough
Write a local rule that prioritizes a parent job reference or explicit callback identifier, then use corroborating context. Equipment, symptom and dispatch purpose can help assess a link, but none should automatically override a contradictory job reference. Keep confidence and reviewer attribution with any inferred link. A future reviewer needs to know whether the relationship came from the system or from later analysis.
If the archive lost parent identifiers during a migration, create a separate “relationship uncertain” group. Do not use customer names or addresses as a shortcut for every join. For the example above, removing the callback reference would reduce confidence in connecting V2, even if its date and site appeared plausible. The scope description should disclose that limitation instead of advertising a complete end-to-end workflow.
A no-access visit is not a failed repair
Use two status axes. The visit axis can distinguish inspection, intervention, no access, customer cancellation and documentation missing. The episode axis can distinguish confirmed completion, continuing fault, abandoned work and outcome unknown. The same label “closed” should not silently cover all of them.
For a hypothetical ten-job review, suppose six have a recorded passing check, two await access, one was abandoned and one lacks follow-up. Six of ten, or 60%, have that specific evidence. Excluding the four awkward jobs and calling the archive fully resolved would change the question and hide selection. This percentage describes the invented review set only; it is neither an industry benchmark nor an observed company result.
- Confirm whether “callback” means a continuing issue or simply another appointment.
- Capture customer-declined work without describing it as technician failure.
- Record the period over which follow-up was checked.
- Keep the outcome unknown when confirmation is absent.
End the review with an assignment, not an export
The internal deliverable is a job dictionary, a visit dictionary, linkage rules and a counted set of exceptions. Assign one system owner to confirm the parent reference, one operations lead to review the outcome meaning and one approver to decide the proposed disclosure. Keep private customer correspondence and subcontractor attachments out of the initial description.
Use the inventory tool to describe the category and gaps, then the readiness tool to rank the unresolved decisions. If a potential receiving program asks a precise structural question, a labeled synthetic sequence like J-028 may answer it. A real sample is another event with another scope and approval. Do not fund full archive reconciliation merely because a broad “service data” category appears on a program website.