The technician says “done.” Can the office close the job?
A technician can finish a visit while the job still needs a part, an approval or an office review. Define the handoff before building a field service system.
Rootscratch ·
A technician has left the customer site. The office sees “done” in the group chat. Can someone send the invoice? Does a replacement part still need ordering? Will another technician have to go back?
For a field service business, a completed visit can leave several things unresolved. A useful job record tells the office what happened, what remains open and who needs to act next. Before choosing software, agree on the evidence your team needs to close a job.
The rules below are a starting point for repair, installation and maintenance teams. Adapt them to the work you perform and the approvals your customers require.
Give “visit finished” its own meaning
Consider a hypothetical air-conditioning repair. The technician inspects the unit and identifies a faulty part. The part is unavailable, so a return visit is needed. The inspection is finished, but the repair remains open.
If the only available button is “Complete,” the technician must either leave the visit looking unfinished or close work that still needs attention.
Separate the visit outcome from the overall job status. A visit might be completed, interrupted or unable to proceed because the site was inaccessible. The job could still be waiting for a part or customer approval.
A simple set of rules could look like this:
| Record | Example status | What it tells the next person |
|---|---|---|
| Site visit | Finished | The technician has recorded the visit outcome. |
| Repair job | Waiting for part | Work remains open; someone must arrange the part. |
| Office review | Pending | The service report needs checking. |
| Billing | Not reviewed | No one has decided what can be invoiced yet. |
Your team may need fewer states. Keep a status only if it changes a decision, an assigned task or what someone needs to see. Write down who can change it and what information they must provide.
Decide what belongs on the job sheet
A digital job sheet should let the next person understand the visit without calling the technician to reconstruct it.
Start with the existing paper form or service report. For each field, ask who uses the answer and what they do with it. Remove fields that serve no clear purpose; make essential information required at the point when staff can actually supply it.
For a repair visit, the useful record might include:
- The job reference and the particular asset or unit serviced.
- The reported problem, findings and work performed.
- Parts used, including quantities, and any parts still needed.
- Relevant photos or test results, where the work requires them.
- Anything unresolved, with a named next owner.
- Customer acknowledgment, if required, and what was acknowledged.
Prefer a precise note such as “Inspection completed; replacement part requires approval” to an unexplained “done.” For repeat visits, keep each visit's report attached to the same job so staff can follow the history.
Photos should have a defined purpose. Avoid collecting faces, private documents or unrelated areas of a customer's premises when they add nothing to the service record. Decide who can view the evidence and how long the business needs to keep it.
Separate acknowledgment from approval to bill
A customer acknowledging that a technician attended the site may not be approving extra work or accepting an invoice. Give each action a clear label and explain what the person is agreeing to.
If additional work needs approval, record the proposed scope and the decision before treating it as authorized. When acknowledgment cannot be obtained, let the technician record the reason and route the case for review. A required signature field should not encourage someone to invent an acknowledgment just to finish a form.
The office also needs a billing rule. Some jobs may be covered by a maintenance agreement; others may require a quote or review of parts and labor. Agree on the rule for your business before connecting a job status to invoice creation.
Keep corrections traceable. A reviewer should be able to see who changed a report and why, particularly when the change affects approved work or a charge.
Make return visits visible to the dispatcher
“Waiting for part” needs an owner and a next action. Otherwise, the job can remain open without anyone knowing what to do with it.
In the repair example, the office might first need to obtain approval, then confirm the part is available, then contact the customer about another visit. The system should show which step is holding up scheduling.
Link the return visit to the original job. Carry forward the findings and unresolved work so the next technician has the context. Keep new parts usage and visit notes separate enough to review, even when the same person returns.
If scheduling itself is the difficult part, our booking system planning guide covers resource availability and confirmation rules. Here, the priority is making sure an unfinished job reaches the person responsible for arranging the next visit.
Show what the office has actually received
A technician may finish a report where the connection is unreliable. Decide exactly what the mobile system must support: reading assigned jobs, saving notes on the device, attaching photos or submitting a completed report.
Use distinct messages for a record saved on the device and one received by the office. If photos are still uploading, show that too. The technician should be able to tell whether it is safe to leave the screen and what to do if the upload fails.
Ask your developer to demonstrate what happens when:
- A report is saved without a connection and the app is closed.
- Notes arrive, but an attachment fails to upload.
- The technician retries a submission after an uncertain response.
- The office changes the assignment while the technician has an older copy.
Agree on recovery behavior before launch. A retry should not create a second job or duplicate a parts entry. Conflicting changes should remain visible for resolution rather than silently discarding someone's work.
These requirements influence the choice of mobile technology. Our PWA or native app guide explains how to test device and offline requirements before committing to an approach.
Walk one difficult job through the proposed system
Use a real, redacted job as a review exercise before signing off on the workflow. Pick one that needed a return visit, a correction or an exception. Routine work alone will leave important rules untested.
Have a technician and an office reviewer take it through assignment, the site report and the next required action. At the end, check whether they can answer:
- What was completed, and what is still outstanding?
- Has the office received all required evidence?
- Who owns the next step?
- What permits the job to close or move to billing review?
If the answers still depend on a separate chat conversation, identify the missing information or decision and revise the workflow. You may discover that clearer job sheets and status rules solve the immediate problem. A custom system becomes worth discussing when the handoffs, access requirements or connections to other software exceed what your current tools can reasonably support.
Rootscratch's Field Service Management Systems service covers job scheduling, mobile work records, completion evidence and office handoffs. To discuss your process, start a project brief with a short description of one service call and where it becomes difficult to track. Keep customer details and other sensitive information out of the initial inquiry; redacted sample records can be discussed during scoping.