Arrival window and on-the-way texts: what to send, when, and who owns the reply

Short answer

Send three kinds of text, each tied to a real event on the dispatch board: an arrival window at booking and on the morning of the job, a revised window the moment the original is at risk, and an on-the-way text after the technician has actually left. Keep the texts one-way and plain. Put a named person on every reply, access problem, reschedule and complaint, because a text that goes out is not a conversation that has been handled.

The rest of this guide covers what each text should say, when it should fire, and where the line sits between automation and people.

Why the customer calls

When a customer asks "When will the technician be here?" they are deciding whether to stay home, leave work or arrange access. A vague answer creates status calls, missed access and a CSR defending a route they cannot see. Research on service waits points the same way: a wait that runs far past an estimate drives dissatisfaction, especially when the business set the estimate (ScienceDirect).

Start from one rule: every customer notice should change what the customer knows or what they need to do next.

Three kinds of message, three different triggers

Do not collapse these into one generic reminder.

Message	What starts it	What it says
Arrival window	Booking, then the morning route being credible	A range, not a time. "Between 10:00 and 12:00." Repair time comes after inspection.
Revised window	The projected arrival leaves the stated window, or crosses your own risk threshold	What changed, the new range, when the next update comes, how to reply or call
On the way	The technician has finished the prior stop and departed	A realistic ETA range, the technician's first name, a callback number, an access reminder

A reminder uses saved appointment details. A live update uses where the job sits in today's schedule now. ServiceTitan documents these as separate events: appointment reminders are timed relative to the appointment, while dispatch notifications fire when a technician is dispatched (ServiceTitan). When a removal or a spring repair runs long, the reminder goes stale and the live update is the one that helps.

An updated window is visibility, not certainty. Estimate language ("we expect to arrive between 11:00 and 1:00") is honest. Promise language ("we'll be there at 11:15") is a future apology with a timestamp.

At booking: set a promise you can keep

The booking call sets the standard for everything after it. Before the call ends:

State the window as a range and separate arrival from job length: "The technician will inspect first, then explain the repair time and any parts."
Name the urgency tier. A trapped vehicle or an unsecured door needs a faster checkpoint and a human call, not a batch text.
Confirm the best number, whether the customer agrees to operational texts, and a backup way to reach them.
Record gate codes, pets, parking limits, tenant or landlord handoffs and who will be on site.
Tell the customer what to do if the timing stops working, and name the next update.

Use a narrow window only when the board can support it. A one-to-three-hour repair and a two-to-six-hour install cannot carry the same static promise. Later jobs in the day get a broader expectation and a firm commitment to update.

Say this	Avoid this
"We have you in a 10:00 to 12:00 arrival window. Repair time comes after the technician inspects the door."	"We'll be there at 10:00."
"If that window changes your plans, reply here or call us."	"Someone should be there all morning."

Before dispatch: confirm only when you have something to add

A morning text earns its place only if it adds information: the current window, a queue position, or a specific time for the next update. "You are on today's schedule" does not help someone deciding whether to leave the house.

Window is stable. Send the current range, the office callback option and any access reminder.
Window moved enough to affect plans. Send the revised range before the original is at risk. Say what changed in plain terms and when the next update comes.
Window is not stable yet. Do not invent an ETA from a moving queue. Say the appointment is still on the route, give the next checkpoint and name who will update them.

During a delay: update when the customer's plan must change

The line for a delay notice is customer impact, not dispatcher discomfort. A five-minute slide inside the stated window needs no text. A missed window does.

Situation	Automated update	Human follow-up
Route shifts but the technician stays inside the window	None	None
Window at risk	Revised range, what changed, next update time, reply option	CSR calls if access is time-sensitive
Window missed	Notice immediately with the best trusted range	CSR calls; service manager owns recovery choices
Emergency job added ahead of a routine call	Revised range before plans are disrupted	CSR checks access
Second change, or no trusted new window	Stop sending guesses	CSR acknowledges the impact, offers choices, gives a firm checkpoint
Trapped vehicle, safety concern, unsecured door	Do not rely on text alone	CSR calls and stays responsible for the next update

Do not promise a technician will finish an earlier job in 20 minutes unless someone on site can support that. A repair can uncover a failed part or a bigger problem. That is normal field work.

On the way: make the last text useful

An on-the-way text is the last notice before a customer opens a gate or brings in a dog. A good one includes:

A realistic range tied to actual departure, such as "about 15 to 25 minutes," not a fixed minute pulled from an unstable map.
The technician's first name and a company callback number.
Identification the customer can check. The CFPB advises people to ask for identification and call the organization independently to verify (CFPB).
A reminder to secure pets and clear the work area, and a reply or call option for a last-minute conflict.

Send it after the technician has committed to the stop and left. A job appearing on today's board is not a departure signal. Drop "soon," "shortly," "in your area" and "almost there" when nobody has left.

What the ServiceTitan on-the-way alert needs

ServiceTitan's dispatch alert sends automatically when a technician is dispatched, if a default outbound SMS number is set. Tracking adds a map, distance and ETA, but it needs native GPS on each technician device, a Tech Tracking URL token in the template and a verified service address. Without a verified address the tracking page shows the technician's name and the destination address instead (ServiceTitan). ServiceTitan says native GPS can be accurate within 3 to 10 meters, against roughly 500 meters from cellular triangulation when GPS is unavailable (ServiceTitan). Non-native devices still receive dispatch notifications but cannot send real-time tracking links.

Before blaming the alert, check the sending number, the customer's mobile number, native GPS and the verified address.

When one more text does not fix the miss

If a crew arrives and the customer has left, the dispatch text may have fired exactly as designed. By dispatch, the customer may already be across town. More alert volume does not create earlier information.

Name the symptom first, then the fix and its owner:

Symptom
No alert, or wrong details
Likely cause
Bad number, template, address or trigger setup
First fix
Audit customer data and notification setup
Owner
CSR or dispatcher
Symptom
Customer needed earlier notice
Likely cause
Dispatch happened after their plans were set
First fix
Send a queue position or window update earlier
Owner
Dispatcher
Symptom
Crew running late
Likely cause
No trigger for a changed ETA
First fix
Revised window or delay update
Owner
Dispatcher
Symptom
Gate, pets, permit or access issue
Likely cause
The customer has to answer a question
First fix
Call or text from an owned inbox and record the answer
Owner
CSR or dispatcher
Symptom
Customer wants another date
Likely cause
A booking-change conversation
First fix
Confirm options and reschedule with a person
Owner
CSR

Symptom	Likely cause	First fix	Owner
No alert, or wrong details	Bad number, template, address or trigger setup	Audit customer data and notification setup	CSR or dispatcher
Customer needed earlier notice	Dispatch happened after their plans were set	Send a queue position or window update earlier	Dispatcher
Crew running late	No trigger for a changed ETA	Revised window or delay update	Dispatcher
Gate, pets, permit or access issue	The customer has to answer a question	Call or text from an owned inbox and record the answer	CSR or dispatcher
Customer wants another date	A booking-change conversation	Confirm options and reschedule with a person	CSR

One-way texts: when they are enough

A one-way arrival text is a notice. It becomes a conversation only when somebody can see a reply, decide what it means and act on it. Do not ask "does this support replies?" Ask "what happens when the customer needs us to do something?"

One-way works for a queue notice, a modest delay with a dependable new window, an on-the-way text and an arrival text. It does not work for a locked gate, a safety concern, a reschedule or a complaint.

Before sending, ask:

Is a reply likely?
Does it need judgment or a decision?
Does it matter within the next hour or two?
What happens if nobody sees it?

Consequence sets the risk, not volume. Delivery is also not confirmed understanding. CTIA notes that business messages can be filtered, delayed or blocked, and delivery is not guaranteed (CTIA).

If replies are not monitored, say so in the message and give a phone number that is. Do not invite customers to text a number nobody watches.

When to add a reply path

Add two-way texting when exceptions stop being exceptional: frequent replies despite no-reply wording, recurring gate, pet or parking issues, timing changes after dispatch, or complaints arriving through personal numbers and voicemail. Do not enable replies just because a provider offers them. Before you do, have a shared inbox with a named owner and a response target, handoff rules, an after-hours policy and a way to close and keep the thread. A reply-capable number without those is worse than an honest one-way number.

ServiceTitan treats two-way SMS as a separate Chat capability with its own enabling requirements, number and permissions, so a dispatch notification is not automatically a monitored channel (ServiceTitan).

What automation handles and what a person owns

Break the work into layers. Automation is good at the first three. The last three need context and authority.

The schedule signal (a window changed)
Text delivery
Message history the office can see
The customer's reply
The dispatch decision
Recovery after a bad experience

Situation	Owner and action
Reply about access, a gate, a tenant or a decision-maker	CSR checks job notes, contacts the right person, updates dispatch
Customer cannot accept the new window	CSR offers approved options or hands to dispatch
Technician needs rerouting	Dispatcher weighs skills, parts and promises already made
Urgency, anger or a repeat delay	Service manager sets the recovery plan and owns any promise on cost or trust
"Is the technician still coming today?"	CSR confirms the current plan instead of guessing from an old text

Use three states so nobody invents the rule mid-shift: text only (routine, no action, low risk), call required (changed promise, access issue, decision needed), and manager review (repeat exception, cancellation risk, added cost). Give each exception a first owner and an escalation owner before the week begins, and set a cutoff so someone decides to hold, resequence or reschedule before a crew spends windshield time.

A recovery call needs an owner, an acknowledgment of the changed expectation, current facts without invented precision, options you can honor, access confirmed aloud and a time for the next update.

Pick the smallest category that closes the gap

"Customer communication" is too broad to buy anything. There are six different jobs, and they overlap in demos:

Category	Solves	Does not solve
Scheduled one-way updates	Routine status from the schedule	Replies, routing, live maps, calls
Manual bulk texts	One event affecting many customers	Per-job queue movement
Two-way SMS	Access details, confirmations, rescheduling talk	Arrival math, routing
Live tracking	Uncertainty after the trip starts	Route quality, earlier delays
Route optimization	A weak plan behind the texts	Customer notices
Voice automation	Repeat status calls	Bad schedule data

Name the failure from last week's call log and choose one category. A shop with poor routing will not text its way out of impossible windows. A shop with sound dispatch does not need live tracking because a demo included a map.

If you are testing a schedule-aware tool, replay a real afternoon: a spring call that runs long, a wrong part, an urgent insert. Ask which exact event starts each message, which jobs count as affected, whether the window refreshes after a second change, and whether the tool stops sending an old estimate after a newer one. A "running late" button that still needs a CSR to find each customer and press send is a manual tool, not a schedule-aware one.

Where Queue Up fits

Queue Up is the one-way option in the first category. At the start of the day each customer with a job on the board gets a text with their place in line and an estimated window. The window updates by text as the schedule shifts, an alert goes out when a technician runs well ahead or behind, and one more text goes out when the technician is on the way. The CSR sees the log. It is text only, it does not handle replies, and it does not reroute or reschedule jobs (supabase:tgl-cms.ref_platform.products, slug queue-up). Pair it with a visible office contact route and an owned exception process.

Consent and opt-out are part of the build

The FCC says consent rules differ for informational and commercial automated texts and that people can opt out by reasonable means (FCC). Its 2024 rule recognizes replies such as STOP, QUIT, END, REVOKE, OPT OUT, CANCEL and UNSUBSCRIBE, and says a sender using a protocol that cannot receive replies must disclose that in each text and offer another way to revoke consent (Federal Register). CTIA recommends telling people who the sender is, the purpose and the opt-out method, and keeping consent records. Keep appointment alerts free of promotions, and have counsel review your program.

One standard for the whole office

Add required booking fields: window, urgency, consent and contact method, access plan, next update point.
Set approved window ranges and who may change them. Keep arrival windows separate from repair-duration estimates.
Write templates with editable fields for timing, technician name, access reminder, callback number and opt-out language.
Automate the repeatable stages only. Keep the CSR and dispatcher on judgment calls.
Spot-check monthly: missed windows, repeat status calls, manual interventions, complaints. Read a few threads, not just totals.

Test the policy with one question: before the technician arrives, does the customer know when to be available, how to prepare, how to verify who is coming and what happens if the timing changes? If not, another automated text will not fix it. The standard needs to.