01 / Two outputs
The docket records the visit. The report explains it.
A service docket is the working record completed by the engineer or technician. A customer report is the checked, customer-facing explanation of the same visit.
They may contain much of the same information, but they have different jobs. The docket needs enough detail for the office, the next engineer and any follow-up work. The report should tell the customer why the visit happened, what was done, what the result was and what needs to happen next.
The waste appears when those two documents are treated as separate pieces of work. A paper docket arrives later, photographs are sent separately and somebody in the office types the whole story again.
One useful rule
The customer report should be prepared from the checked service record, not reconstructed from several channels.02 / Site capture
What a useful digital service docket should contain.
Start with the smallest set of fields that identifies the visit, explains the work and makes follow-up clear. The exact fields depend on the trade, customer and contract.
Job number, customer, service address and the existing work-order reference.
Date, engineer or technician, arrival and departure where those times are useful.
The equipment, room, unit, floor or other location the visit concerned.
The reported issue, planned task or inspection request in plain language.
The checks, repair, maintenance or installation actually carried out.
Only the detail needed by the office, customer or future service history.
Working, partially resolved, awaiting parts, further work required or another agreed status.
The next action, its owner and any date or dependency already agreed.
Selected evidence kept with the visit rather than in a separate message thread.
Acknowledgement, signatures, readings, checklists and customer-specific fields may also be needed. Add them because the real process requires them—not because a form builder makes it easy to add more boxes.
03 / Customer output
The customer report should make the outcome obvious.
A customer should not have to decode an engineer’s shorthand or search an email thread to understand whether the issue is resolved.
Customer, site, job reference, visit date and the engineer or team responsible.
A short description of the call-out, planned service or requested work.
A clear summary of what was checked, completed, repaired or replaced.
The condition at the end of the visit and whether the task is complete.
Parts, quotation, return visit or customer action still required.
Include only the photographs, readings or documents that help explain the result.
Do not simply send every internal field.
The customer report is a selected output. Internal notes, cost information, unrelated photographs and anything the customer should not receive stay out of it. A person should review the report before it is sent.
04 / Workflow
A simple docket-to-report workflow.
Pre-fill what the office already knows
Send the job reference, customer, address, scheduled task and known asset to the engineer instead of asking for them again.
Complete the visit record on site
Add the work done, result, follow-up and relevant attachments while the context is fresh.
Review exceptions in the office
Check unclear notes, missing fields and open actions rather than re-keying every line.
Prepare the customer report
Use the approved fields and selected evidence to produce one consistent output.
Approve and send
A named person checks the report, then the final version is sent and retained in the agreed job location.
This is one specific use of the wider job-record workflow: capture context once, keep attachments with it and reuse the checked record downstream.
05 / Worked example
One fictional visit, two useful views.
An engineer attends a fictional office building to investigate a rooftop ventilation unit. No real customer, site or service information is used.
Reactive call-out after the customer reported intermittent operation.
The engineer records the inspection, correction and functional test.
The record states the observed condition at the end of the visit.
No return visit is currently required; the next check remains visible.
The internal docket
The office keeps the job reference, visit times, engineer, detailed work note, attachment names and follow-up status. Those details remain searchable against the job and asset.
The customer report
The customer receives the visit reference, reported issue, work completed, result, follow-up and two selected photographs. The wording follows the approved record, but internal handling notes do not appear.
The handover point
One checked record supplies both views. Nobody has to rebuild the visit from the engineer’s paper docket and phone.06 / Start small
Test one visit type before changing every docket.
Choose a frequent, understandable service visit with a report the office already produces. Use real examples to agree what must be captured and what the customer should see.
- Choose one repeated visit type and one customer-report format.
- Collect three recent dockets, related photos and the reports created from them.
- Mark which information was copied, corrected, chased or added from memory.
- Agree the smallest required field list with an engineer and an office user.
- Separate internal fields from customer-facing fields.
- Run the process on a small number of visits and record the exceptions.
- Measure office handling time and report corrections before expanding it.
Map the record
Use the free service-docket template.
Print the visit record or adapt the CSV headings before choosing or changing software.
Open the templateSee the record move
Try the two-minute example.
Add a fictional record and see how its notes and attachments stay together in the job list.
Try the example07 / Questions
Common questions about digital service dockets.
Is a digital service docket just a PDF form?
It can be, but a useful digital record also keeps its job reference, fields, status and attachments available for search and reuse. A PDF may be one output rather than the only stored version.
Should the engineer write the full customer report?
The engineer should record accurate visit information. The final report can then be prepared from that record and reviewed by the person responsible for customer communication.
Do we need customer signatures?
That depends on the business, customer, contract and type of work. Use acknowledgement or sign-off only where the real process requires it, and define what that sign-off means.
Can our existing field-service software already do this?
Possibly. First check whether it can pre-fill known job information, capture the fields your engineers need, keep attachments with the visit and produce the required report without repeated manual handling. The software comparison guide gives you a practical test.
When is a small custom workflow worth considering?
When the same docket-to-report process causes measurable handling or errors, the required output is clear and existing software cannot fit it without substantial workarounds.
This guide describes a general administrative workflow. It does not define contractual, legal, accounting, safety or regulatory record requirements for a particular service business or customer.