Dispatch: the route is the schedule, and the window is the promise

A workshop sells hours on a ramp. A field service business sells hours minus travel, and the travel is decided by the order somebody put the jobs in that morning. Two schedules with identical work can differ by two billable hours purely on sequencing, and nobody in the van can see which one they are living in.

That makes dispatch a routing problem wearing the costume of a communication problem. Most of what gets sold as dispatch automation is messaging around the edges of a route that is still being built by hand, in a hurry, at seven in the morning.

What we'll cover

• Travel is the cost nobody prices
• The window is a promise about somebody's day
• What the technician needs before leaving
• When a job overruns, everyone behind moves
• Building it with CodeWords
• The emergency that lands mid-route
• Access failures, which are pure loss
• What the office needs back from the van
• Measuring a day honestly
• Making it survive
• Limits worth knowing about
• What to build first
• Frequently asked questions

Travel is the cost nobody prices

Every mile between two jobs is paid for by somebody, and in most small field service businesses it is paid for out of margin because it was never in the quote.

Three things make it worse than it needs to be.

Jobs booked by customer preference rather than geography. A morning slot in one direction and an afternoon slot forty minutes the other way is two customers accommodated and an hour lost.

Urgent work inserted without resequencing. A job dropped into the middle of a route rather than into the right place in it.

No idea what the travel actually was. Very few small operators know their ratio of billable to travelling hours, which means they cannot tell whether a change helped.

Booking by area rather than by preference is the single largest lever here, and it is a scheduling policy rather than software. Offer Tuesday morning to the north side and Tuesday afternoon to the south, and the day builds itself.

The window is a promise about somebody's day

Field service is unusual in that the customer has to be present. An arrival window is not a convenience, it is a claim on somebody's working day, and they have usually taken unpaid time to be there.

Which sets the standard. A four-hour window is tolerable if it is accurate. A two-hour window that slips by three is worse than the four-hour one, because they planned around it.

Three things make windows work.

Quote a window you can actually hit, including travel and the job before it running long.

Narrow it on the day. A text at eight saying "between ten and eleven" turns a morning off into a morning mostly worked, and it is the single most appreciated message in this trade.

Tell them the moment it moves. Not when you know the new time, when you know the old one is wrong. "We are running late, I will confirm a time within the hour" is worth more than silence followed by precision.

What the technician needs before leaving

Dispatch fails most often by omission, and the omissions are predictable.

The address that works, including which entrance, which floor, and the gate code. Rural addresses and flats generate most of the "I cannot find it" calls.

Who will be there, and their number, which is frequently not the person who booked.

Parking. In a city this determines whether a thirty-minute job takes an hour.

What the fault is, in the customer's words, not translated into a job code that loses the detail.

Make and model, and anything needed to work on it. The difference between a first-time fix and a return visit is usually decided here, before anyone leaves.

Whether it is a return visit, and what happened last time. A technician arriving without that context in front of an already annoyed customer is starting three goals down.

When a job overruns, everyone behind moves

The thing that actually breaks a field service day, and most systems handle it as an exception when it is a daily event.

A job running ninety minutes long does not affect one appointment, it affects every appointment after it. Handled by hand, the technician either rings four customers from a driveway or rings none, and the second is what usually happens.

So make the overrun a trigger. When a job is marked as running over, the customers later in the route are told, automatically, with a revised window. The technician does not have to decide who to call or find the time to do it.

Two details that matter. Give the customers furthest down the route the most notice, since they have the most time to use it. And where a job clearly cannot be reached today, say so and rebook rather than moving somebody to six in the evening and hoping.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: what the technician receives before each job, what the customer receives and when, and what happens to the rest of the route when one job runs over.
3. Authorize the connections to wherever jobs are recorded, your calendar, and your WhatsApp Business Platform account.
4. Describe the exceptions: an emergency inserted mid-route, a no-access, a job that needs a second visit, a customer who asked to be phoned.
5. Run it on one technician's route for a fortnight, and record travel time honestly while you do, because that is the number the whole exercise is about.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

The emergency that lands mid-route

Urgent work is the main reason a planned route stops resembling the day that happens, and it needs a rule rather than a judgement made under pressure.

Decide in advance what counts as an emergency for your business, what it costs, and how many planned jobs you are willing to displace for one. Without that, the loudest customer wins and four quiet ones are let down for a job that was not actually urgent.

Where you do displace somebody, the message goes immediately and it offers something: the next slot, a specific time, a choice. A customer bumped with an apology and no alternative is a customer who books elsewhere.

Access failures, which are pure loss

Nobody in, wrong key, no access to the loft, dog in the room. The travel is spent, the slot is gone, and there is nothing to invoice.

Most of it is preventable at booking and confirmation. Ask what access is needed, who will be there, and whether anything has to be moved or turned off first. Say it again the day before, specifically, rather than as a generic reminder.

Then have a policy and state it before the visit rather than after. Whether a failed visit is chargeable is your commercial decision, and a customer told in advance accepts it where one told on the doorstep does not.

What the office needs back from the van

Dispatch is two-directional and the return leg is the one that gets neglected.

Job completed, with what was done. Enough for an invoice without a phone call.

Parts used, so the van stock is right tomorrow.

Whether it is finished. The single most valuable field in field service, and the one most often left ambiguous.

What is needed for the return visit, if there is one, captured while the technician is still standing there.

Photographs where relevant, particularly for anything that may be disputed.

Captured at the door, this takes a minute. Reconstructed in the evening, it takes an hour and is worse.

Measuring a day honestly

Four numbers, and none of them are message statistics.

Billable hours as a share of working hours. The headline figure for the whole business.

Travel time per job, trending.

First-time fix rate, which is where the money is in most repair trades.

Jobs lost to no access, which is pure waste and usually fixable.

Track those for a month and the priorities are obvious. Track messages sent and you will learn nothing about the business.

Making it survive

Check the job state before any customer message, since routes move constantly.

Make the overrun a trigger rather than something a technician remembers to handle.

Ask about access at booking and again the day before, in specifics.

Give the no-access policy to the customer in advance, in writing.

Record travel and first-time fix permanently, not just during a trial.

Limits worth knowing about

Automation cannot shorten a journey. Better sequencing can; messaging cannot.

Some days simply go wrong, and a good system makes that visible sooner rather than preventing it.

Traffic is not predictable enough to quote to the minute, which is why windows exist.

A technician cannot answer a phone in a loft, so anything requiring their input has to be asynchronous.

Tight windows raise the cost of every slip. Promise what the route can carry.

What to build first

The overrun message. When a job is marked as running long, everybody later in the route hears about it with a revised window, without the technician deciding who to ring. It is the most common failure in a field service day and the one that generates the most complaints.

Two habits make the difference. Book by area rather than by preference, since the route is where the unbilled hours go and no message recovers them. And narrow the window on the morning, because a customer who gets their day back after an eight o'clock text remembers it long after they have forgotten what the repair cost.

Frequently asked questions

Why does travel time matter so much in field service?

Because it is paid out of margin and rarely quoted. Two schedules containing identical work can differ by two billable hours purely on the order the jobs were put in.

How should jobs be sequenced?

By geography rather than customer preference. Offering one area a morning and another an afternoon builds the route automatically and removes most of the crossing.

How wide should an arrival window be?

Wide enough to be accurate, then narrowed on the day. A two-hour window that slips by three is worse than an honest four-hour one, because the customer planned around it.

When should a customer be told about a delay?

When you know the old time is wrong, not when you know the new one. "Running late, I will confirm within the hour" beats silence followed by precision.

What should a technician get before leaving?

The address that actually works with entrance and access details, who will be there and their number, parking, the fault in the customer's words, the make and model, and whether it is a return visit.

How should an overrun be handled?

As a trigger. Everyone later in the route is told automatically with a revised window, with the most notice going to those furthest down the day.

How do I handle emergencies without wrecking the route?

Decide in advance what counts, what it costs, and how many planned jobs you will displace. Anyone displaced gets an immediate message offering a specific alternative.

How do I reduce failed visits?

Ask what access is needed at booking and again the day before in specifics, and state the no-access policy in writing beforehand rather than on the doorstep.

What should come back from the van?

What was done, parts used, whether the job is finished, what a return visit needs, and photographs where relevant. Captured at the door it takes a minute.

What should a field service business measure?

Billable hours as a share of working hours, travel per job, first-time fix rate, and jobs lost to no access. Message statistics describe the automation rather than the business.

Related reading

• What to know before the van moves
• Missed calls, and which ones are worth having
• The jobs that are not finished