WhatsApp for field service dispatch: jobs, proof, and photos

A field service business I looked at last year had bought a dispatch system. Every technician had a login. Every job had a ticket number, a route, a status field and a photo upload slot. And every morning, the actual dispatch still happened in a WhatsApp group, because the group is where the technician already was.

That is not a discipline problem. It is a fact about where attention lives. A technician is on a ladder, in a basement, or driving. They will read a chat notification and ignore an app badge. If the job details arrive somewhere they have to remember to open, then the first thing they do at the customer's gate is call the office to ask for the address.

Dispatch fails at the handover, not in the planning

Route planning tools are decent now. The failure is the ten minutes between "this job is assigned" and "the technician is actually moving".

Four things break in that gap:

• The details arrive in a place nobody opens. Address, floor number, gate code, contact name and the slot window all exist — in a system the technician checks twice a day.
• The customer is not told anyone is coming. They booked three days ago and heard nothing since, so they leave. The technician arrives at an empty house and the visit is billed as a failed attempt.
• The technician cannot confirm receipt. No confirmation means dispatch does not know whether the job was seen, so someone calls to check, which is the same phone call the system was meant to prevent.
• Proof arrives late or not at all. The photo lives in a phone gallery, gets forwarded to a group a week later, or never gets attached to the ticket. When the customer disputes the work, there is nothing to open.

None of those need a better route optimiser. They need the message to land in the chat the technician already has open, and to require a one-tap answer.

The four messages that carry most of the load

I have seen teams try to send eleven updates per job. Four do the work.

1. The job assignment. One utility template per job, filled with variables: job reference, customer name, address with landmark, slot window, and what the technician is expected to do. It ends with a reply prompt — accept or flag a problem. That single reply turns "assigned" into "accepted", which is the only status dispatch can actually trust.

2. The customer's arrival window. A separate message to the customer, sent when the job is confirmed for the day rather than when it was booked. Include the window and the technician's name. A customer who knows a name and a two-hour window stays home; a customer who was told "someone will come this week" does not.

3. On the way. Short, sent when the technician leaves the previous job. This is the message that saves the visit, because it converts a vague appointment into a countdown. It also gives the customer a natural moment to say "actually, use the back gate".

4. Completion with proof. The closing message carries the work done, the parts used, and the photo. This is the one that protects revenue, because it is the record you produce six weeks later when the customer says the problem came back.

What makes a proof photo actually count

Most photo policies are unusable because they ask for "a photo of the work". Nobody knows what that means at 6pm on a Friday.

Make it three shots and be specific:

• Wide shot showing the unit in its location, so there is no argument about which machine was serviced.
• Close shot of the part replaced or the reading taken, with the serial number or meter visible where it exists.
• Completion shot of the area left clean, which quietly kills the "they left a mess" dispute before it starts.

Two rules make the difference between an audit trail and a camera roll. The photo must be attached to the job, not sent separately — a photo in a chat with no job reference is unsearchable three months later. And the photo must be requested by the same message that closes the job, so the sequence is one action rather than two habits.

The part nobody warns you about: two audiences, one number

A dispatch flow has two conversations running at once — one with the technician, one with the customer — and they need to stay apart.

That separation is the thing to design first. Mixing them is how a customer ends up in a group chat with three technicians, or a technician receives a customer complaint as if it were a job update. What you want is the business number serving both, with each person's thread scoped to their own jobs: the technician sees the assignment and the address, the customer sees the window and the ETA.

Two platform facts matter here, and neither is optional:

• Templates are approved per category. A job assignment and a "your technician is on the way" notice follow a transaction the person already has with you, so they are utility messages — not marketing. Getting the category wrong is the most common rejection reason I see, and the template approval guide walks through what reviewers actually look for.
• The 24-hour window decides what you can send freely. Once a technician or customer replies, the conversation is open and you can send anything relevant for 24 hours. Outside that, you need an approved template. Dispatch is a good fit for this because assignments and arrival notices are predictable events — they belong in templates anyway. The 24-hour window guide covers the boundary, which is where most first builds break.

What to measure, and what to ignore

Four numbers, tracked per technician and per job type:

• Assignment acknowledgement time. If technicians routinely accept jobs an hour late, the assignment message is not landing.
• First-visit fix rate. The only number that tells you whether the right information reached the right person before they left the depot.
• Avoidable revisits. Split by reason: wrong part, wrong diagnosis, customer not home, incomplete work. Each has a different fix and lumping them hides which one you are solving.
• ETA accuracy. A window you miss by three hours trains customers to stop trusting the message, which puts the phone calls straight back.

Ignore "messages sent". Volume is not a result. A team that sends half as many messages and gets acknowledge-and-close on every job is doing better.

Where this fits

This is not a case for replacing your dispatch system. Keep the system as the record. Put the conversation where the technician and the customer already are, and let the two stay in sync — the assignment out, the acceptance and the proof photo back.

BNex is the WhatsApp Business Platform product I build, and dispatch is one of the workloads it was shaped around: approved templates going out, replies and photos coming back into a shared inbox the office can actually see, instead of one supervisor's phone. The shared inbox guide explains how multiple staff work one business number without stepping on each other, and the pricing guide covers what utility messages cost at your volume.

If your technicians are still asking for addresses by phone, send me one job's worth of messages on WhatsApp and I will tell you which of the four is missing.

Related Reading