Day-of job coordination: keep customers, techs, and office aligned

A booked job is a commitment, but it is not yet a coordinated visit. The customer still needs to know what to expect, the technician needs current job context, and the office needs a reliable view of changes in the field. This guide begins after the job is booked. For the preceding workflow, read how Patchment works with Jobber.

Quick answer: Use one post-booking timeline that sends approved routine updates from explicit job events, gives technicians concise route and assignment context, and sends every delay, access issue, or scope change to a named office owner for judgment.

We build Patchment, so this is first-party guidance about how our product approaches that workflow. Automation does not replace the dispatcher. It carries routine context between the customer, technician, and office while exceptions remain human-owned.

One lifecycle, four clear owners

Day-of coordination works when each participant knows both what to do and what not to decide.

• The customer owns access instructions, confirmation that the appointment still works, and a prompt response when the shop asks about a material change. The customer should not have to reconstruct internal scheduling details.
• The technician owns explicit field status messages, accurate problem reports, and the evidence required to close the visit. A technician should report what happened rather than assume the office can infer it.
• The office owns customer promises, schedule tradeoffs, reassignments, pricing or scope decisions, and follow-up that requires judgment. Every exception needs a named person, not a general inbox nobody watches.
• Automation owns approved routine messages, durable event capture, consistent handoffs, and prompts for missing information. It can prepare a decision; it should not quietly make a judgment the shop reserved for a person.

Patchment supports native integrations with Jobber and Housecall Pro. The shop's field-service management system remains the system of record for customers, jobs, schedules, and assignments. Patchment coordinates approved messages and records around that source rather than asking the team to maintain a parallel schedule.

1. Confirm the booking and honor messaging consent

Start the post-booking timeline with a confirmation that restates the business name, service address, appointment window, and a plain-language summary of the requested work. The message should make it easy for the customer to correct a wrong address or say the window no longer works. A correction is an exception for the office, not permission to rewrite the schedule silently.

Send appointment texts only through the shop's approved, consent-aware messaging workflow. A booking does not erase the need to record the customer's messaging choice, identify the sender, and honor help and opt-out requests. The detailed implementation belongs in the guide to SMS consent for field-service booking.

2. Share the assignment and route context

Once the office has assigned the job, the technician needs a compact brief: sequence in the day's work, appointment window, customer display name, service address, problem summary, and access notes. Patchment can send a route summary at the start of the shift and a concise notification when a new assignment is added. The technician can request the current route or the next job when needed.

That context comes from the recorded schedule and assignment, not from silent observation of the technician. It is a job brief, not route optimization. If the ordering changes materially, the update should identify what changed. If a proposed change conflicts with existing work, the current assignment stays intact until the dispatcher reviews and approves a reassignment.

3. Turn an on-my-way reply into an arrival window update

The most useful customer update is tied to something the technician actually did. When the technician replies OMW or “on my way” for the active job, Patchment records the en-route event and can trigger the configured customer message. An ARRIVED reply records arrival. If more than one job could be the target, the workflow asks the technician to identify the job instead of guessing.

The customer message should identify the business, say that the technician is on the way, and repeat the approved arrival window. It should not invent a precise arrival time. Road conditions, parking, and the previous visit can change, so the office should promise only what its policy and current schedule support.

This approach makes the update auditable: the office can see the assignment, the technician's explicit reply, and the resulting customer communication on the job timeline. Patchment does not infer movement from a phone in the background.

4. Route delay, access, and scope-change exceptions to a named human

Field work rarely follows the routine path all day. A technician may report that the customer is not home, the address is wrong, a part is needed, the current visit will run long, another technician is required, or the requested work is broader than the booked description.

Automation can attach the original report to the active job, collect the missing facts, and prepare a clear handoff. Dispatcher judgment decides what happens next. The named office owner chooses whether to contact the customer, move another appointment, approve a reassignment, arrange a return visit, or discuss a scope change. Patchment should not make a new customer promise or change an existing assignment simply because it detected a conflict.

Use a simple exception note with four parts: what changed, which job is affected, what the customer has already been told, and who owns the next action. “Office to review” is not ownership; “Maya will call the customer before the appointment window ends” is.

5. Capture technician evidence and create office visibility

Completion should be based on explicit field evidence. The technician provides the required photo or a documented no-photo reason, a summary of work performed, parts information when relevant, and whether a follow-up or return visit is needed. If something is missing, the workflow asks for that specific item instead of treating the job as complete.

Patchment keeps the source message and associates accepted evidence with the active job. Once the completion record is durable, Patchment records visit_completed locally and moves the job into follow-up. Patchment then attempts to synchronize supported details to the connected field-service system. Provider or field-service completion sync can separately remain pending or require dispatch attention. If that provider sync is pending or needs attention, the completion sync is flagged for dispatch review without undoing the local completion record; customer messaging should still reflect only facts the shop has approved.

6. Send the completion summary and assign human follow-up

After the visit is durably recorded, send the configured completion message. Keep it factual: identify the business and completed visit, acknowledge any next step already approved, and provide the shop's normal way to ask a question. Do not imply that a return visit, price decision, or unresolved repair has been settled when it has not.

If the technician marked follow-up as needed, create a human-owned action with the job context attached. The office decides whether that means a customer call, an estimate, a parts update, a return appointment, or an internal review. The customer receives the approved summary; the dispatcher retains responsibility for the promise that follows it.

A practical day-of operating checklist

Before using this lifecycle with customers, walk one test job through every handoff:

1. Confirm the booking details and the recorded messaging choice.
2. Assign the technician and inspect the route and job brief.
3. Send an on-my-way reply and inspect the customer's arrival-window message.
4. Report a delay, access issue, and scope change; confirm that each reaches the named owner without changing the schedule.
5. Submit incomplete evidence, satisfy the missing-item prompt, and inspect office visibility.
6. Require follow-up and confirm that a person owns the next action before another promise reaches the customer.

Next step

Book a Patchment demo to review your post-booking coordination workflow.