Customers swear they never got the on-my-way text

The complaint is always the same sentence and the cause almost never is. Split it three ways before touching any configuration: the message was never generated, because the event that should have created it did not happen; it was generated and delivered but the customer did not recognise it as being from you; or it was delivered so far ahead of the van that it had expired as information by the time it mattered. Each has a different fix, and the sending system reports success in all three.

That last point is what makes this hard. Your platform will show the message as sent, which is a claim about handing it to a provider, not a claim about anybody reading it. The gap between those two is where the whole problem lives.

Trace one job end to end before changing anything

Take 30 jobs across a normal week, including at least 5 from the afternoon of the busiest day, and reconstruct the full chain for each.

1. Record the trigger event: what happened, when, and what caused it — a technician tap, a geofence exit, a dispatcher action, or a scheduled send.
2. Record the send timestamp from your messaging provider, and the difference between it and the trigger. Anything over 60 seconds means the message is queued somewhere you have not looked.
3. Pull the carrier delivery receipt, not the send acknowledgement. They answer different questions: one says the provider accepted it, the other says the handset was reached.
4. Record the actual arrival time from the job record, and compute send-to-arrival. This is the number that tells you whether the message was useful.
5. Record the sender identity the customer saw — the specific number or alphanumeric id — because it varies more than teams expect across job types and branches.

The trigger waits on a tap, and the tap is optional

Most on-my-way messaging is wired to a technician pressing an en-route button. That is a reasonable default and it degrades exactly when it matters most. On a quiet Tuesday the tap happens. On the day with 3 emergency inserts, the technician leaves site late, drives while eating, and taps en route on arrival at the next job — or never, because the app moved the button when the job type changed.

The tell is in the distribution, not the average. Plot the gap between the previous job's completion and the en-route tap: a healthy operation clusters within a few minutes, and a broken one has a fat tail plus a spike at exactly zero, which is the tap being pressed on arrival. Any workflow that depends on a field tap being both present and honest has the same failure profile as a pre-job hazard check that is not tapped through, and the answer is the same: do not make a customer promise depend on a discretionary button.

Better event sources already exist in your data. The dispatch action that assigns and releases the job, the completion of the preceding job, and the movement of the vehicle are all observable without asking anybody to do anything. Which of them is authoritative depends on how assignment is done in the first place, argued in auto-dispatch or dispatcher override.

What a geofence actually promises about a departure

Replacing the tap with a geofence exit is the standard next move, and it is a good one provided nobody treats the geofence as a stopwatch. Platform documentation is unusually candid about the limits, and they are worth reading before the design depends on them.

Read those together and the design follows. A departure event may arrive up to several minutes after the van actually left, so a message reading "leaving now" is already a small lie; write it as "on the way" and let the ETA carry the precision. A 100 to 150 metre radius is larger than many residential sites, so a technician parked on the street may exit the fence while still writing up the job. And in a rural basement with no data, the exit event may simply never arrive — which means the geofence has to be a supplement to a dispatch-side event, never the sole source.

The ETA attached to the message inherits every assumption in your travel model. If planned and actual drive times diverge as the day goes on, the message is punctual and wrong, which annoys customers more than silence. That divergence is its own diagnosis in the drive times are wrong by eleven o'clock, and the deeper reason service routing behaves differently from delivery routing is set out in why service stops break a routing engine.

Delivered, and unrecognisable

A large share of never-received messages were received. They arrived from a number the customer has no reason to trust, next to messages about parcels and prize draws, and were ignored or swiped away. Three things drive this.

• The sender rotates. Messages sent from a pool of numbers, or from a different number per branch, give the customer no thread to recognise. Booking confirmation, reminder and on-my-way should arrive in one conversation from one identity.
• The traffic is unregistered. In the United States, application-to-person messaging on a standard 10-digit long code requires registration under the A2P 10DLC programme; Twilio's US messaging guidelines list registration as a requirement for long codes and note that carriers have begun charging non-compliance fees. Rules differ by country, so confirm the current requirements for each market with your messaging provider rather than assuming your home market's.
• The message looks like marketing. A branded header, a tracking link and an unsubscribe footer are the visual signature of a promotion, and customers filter promotions. An operational message should read like a person wrote it.

There is also a plain data problem underneath: the number on file is a landline, or the mobile belongs to the tenant while the account belongs to the landlord. Any operation with a meaningful share of managed properties should expect a persistent floor of undeliverable messages, and the honest fix is capturing a site contact at booking rather than blaming the channel.

Sent so early that it had expired

The quietest failure is the message that fires when the board is published at 06:45 for a job at 14:00. It is technically an arrival notification and functionally a reminder, and by the time the van is genuinely close the customer has already stopped expecting anything. Complaints from this cause are indistinguishable from non-delivery in a support queue, which is why send-to-arrival belongs in the trace.

A workable rule: the on-my-way message fires on departure from the previous stop with a computed ETA, and no earlier than 45 minutes before predicted arrival. If the ETA moves by more than 30 minutes after sending, that is a slip and it needs a different message with a different tone, which is the discipline in telling the customers who slipped.

What the message may promise is also constrained by what you sold. A named appointment time supports "arriving at 14:20"; a capacity-based arrival window does not, and forcing precise language onto a window creates a promise the board never made. That distinction is the whole of capacity booking or time-slot booking.

A notification the customer cannot act on is not a notification. It is a record that you told them, which is a different product entirely.

A message that survives being read on a locked screen

Most of these messages are read as a preview, glanced at while the customer is doing something else. The whole job of the text is done in the first line, so put the two facts that matter — who is coming and roughly when — before anything else, and leave the branding, the tracking link and the reschedule instructions after them.

Length is a real constraint rather than a stylistic one. A single SMS carries 160 characters in the GSM 7-bit default alphabet, or 70 characters where the content forces UCS-2 encoding, both packed into the same 140 octets; longer messages are split into segments, and concatenation consumes header space so each segment carries fewer characters than a standalone one. One curly apostrophe or emoji can therefore drop your budget from 160 to 70 and split a message that used to fit. Compose against the 7-bit character set on purpose.

Build-wise this is a small, well-bounded piece of work: an event source that does not depend on a tap, a delivery-receipt log, a timing rule and a message under 160 characters — the shape of engagement we describe under MVP and product builds. It sits with the rest of dispatch, scheduling and route sequencing, inside our field service work.

• notifications
• sms
• geofencing
• customer experience