If you run an HVAC company, plumbing shop, appliance repair business, towing operation, cleaning company, or local delivery service, you already know the phone call. It's 11:40 a.m., the morning schedule is running behind, and a customer calls asking, "The tech said between 12 and 4 — where is he?" The dispatcher pulls up the board, calls the technician, gets voicemail, calls back, relays a vague answer, and returns the customer's call. That single question just consumed fifteen minutes of office time and left the customer only slightly less annoyed than before.
This is exactly the problem technician ETA notifications are designed to solve: automated text messages that tell customers when their technician or crew will arrive, update them if that changes, and confirm when the truck is actually on the way. Done well, they cut inbound "where are you?" calls, reduce no-show-related reschedules, and make your office feel dramatically more professional — without anyone writing a line of code.
In this guide, we'll walk through why these calls happen and what they really cost, what a good notification workflow looks like step by step, how to compute arrival times honestly when traffic happens, how to write messages that set the right expectations, a practical rollout plan, common mistakes, and how to measure whether your notification volume and arrival complaints actually drop.
Why Customers Call to Ask Where the Technician Is
It's tempting to blame customers for being impatient, but the real cause is almost always an information vacuum. People tolerate waiting remarkably well when they know what's happening. They tolerate it terribly when they don't.
The typical field service interaction creates that vacuum in three predictable ways:
- The window is too wide to be useful. "Sometime between 8 a.m. and 12 p.m." gives a customer no idea whether to shower now, run out for groceries, or stand at the window. A four-hour window is a shrug, not an answer.
- Nothing happens between booking and arrival. The customer books Monday for a Thursday appointment, hears nothing for three days, then gets a reminder the night before and silence again until a stranger knocks on the door. Silence reads as "forgotten."
- When things slip, the customer finds out last. A job runs long, traffic snarls, the tech stops for parts — and the office often doesn't know the schedule has slipped until the customer calls to ask. Now the customer is the one delivering the bad news, which is the worst possible dynamic for trust.
There's also a simple anxiety component. For many jobs — a water heater leaking, a car stranded on the shoulder, a furnace out in January — the service call is happening during a stressful moment. Customers in stressful moments seek reassurance, and the fastest reassurance available is picking up the phone. If you don't proactively give them information, they will pull it from you.
What "Where's My Tech?" Calls Actually Cost Your Office
The obvious cost is time. Every status-call involves a receptionist or dispatcher interrupting whatever they were doing, checking the schedule, contacting (or trying to contact) the technician, and calling the customer back. On a busy day, those interruptions stack: ten or fifteen of them scattered across the day can quietly consume hours of coordinated office time, and they tend to arrive in clusters — first thing in the morning when everyone's windows are "8 to 12," and again after lunch.
But the indirect costs are usually bigger than the direct ones:
- Fragmented dispatch attention. Your dispatcher's real job is routing, rescheduling, and solving problems. Every "where's my tech?" ping pulls them out of that work, and interruptions are expensive not because of their duration but because of the refocusing they demand.
- Technician distraction. Many status calls end up forwarded to the tech's phone — while they're under a sink, on a ladder, or driving. That's a safety issue and a focus issue.
- Degraded customer experience before the service even starts. By the time your technician knocks, the customer may already be mildly frustrated. That colors the entire appointment: they're less patient with diagnostics, more price-sensitive, and less likely to leave a positive review.
- Review and reputation risk. Customers who felt ignored in the waiting period routinely mention it in reviews — "they gave a huge window, never called, tech showed up late." The service quality of the repair is often irrelevant if the waiting experience was bad.
- Higher cancel and no-show rates on your side. Customers who wait in information vacuums are more likely to cancel "because nobody showed up" (even when the tech was en route) and to rebook with a competitor who communicated better.
The fix isn't hiring more phone coverage — it's removing the reason the calls happen. That's what a well-built notification workflow does.
What a Good Technician ETA Notification Workflow Looks Like
The goal is a small set of automated messages that answer the customer's questions before they think to ask them. You don't need five or six touches — you need the right three or four, each with a clear job. Here's the anatomy of a solid workflow built around technician ETA notifications:
Step 1: The dispatch trigger
The workflow starts when the job status changes in your scheduling or field service system — for example, when a job moves to "dispatched," "assigned," or "technician en route." The automation should:
- Look up the customer's mobile number and the job details (service type, technician name, scheduled window).
- Check whether the customer has opted into text messages (never skip this — more on it below).
- Pull an estimated travel time from the technician's current location to the customer's address.
This trigger is the backbone. If your scheduling board, dispatch software, or job management tool can mark a job "en route," an automation platform like Automate Anything can listen for that status change and fire everything else automatically. Most modern tools — Jobber, Housecall Pro, ServiceTitan, ServiceM8, Workiz, and similar platforms — expose job statuses that automation tools can connect to.
Step 2: The en-route text with a time window
When the tech actually starts driving, the customer gets a short text: who is coming, what they're coming for, and a realistic arrival estimate. Something like:
"Hi Maria — this is Apex Plumbing. Your technician Dave is on the way for your water heater repair and should arrive between 1:10 and 1:30 p.m. Reply HELP for assistance."
This is the single highest-value message in the whole workflow, because it arrives at the exact moment the customer's mental countdown begins. Note what it includes: the company name (so the text isn't mistaken for spam), the tech's name (humanizes the visit and matters for safety — people want to know who's knocking), and a window narrow enough to act on.
Step 3: The delayed-arrival update
The delayed-arrival message is what separates businesses that communicate from businesses that merely send texts. When the estimate changes — traffic, a prior job running long, a parts stop — the automation sends an honest update:
"Quick update: Dave's previous job ran longer than expected. He's now on the way and should reach you between 1:45 and 2:05 p.m. Sorry for the wait — we appreciate your patience."
The mechanics matter here. The automation should detect when the live arrival estimate drifts beyond the window already communicated (more on the detection logic below) and send the update before the customer notices. A delay text that arrives five minutes after the window has already passed reads as damage control; one that arrives ten minutes early reads as competence.
Step 4: The on-the-way confirmation (for jobs with long lead-ins)
For jobs where the arrival is hours away from the original booking — morning-window jobs, multi-day projects, cleaning crews, deliveries — a "leaving the shop" or "next stop is you" confirmation the day of service closes the last information gap:
"Good morning! Reminder: your carpet cleaning is scheduled today between 12 and 2 p.m. We'll text you when the crew is on the way."
Not every business needs every message. A towing company might only use en-route texts (every job is urgent and dispatched in real time). A cleaning company might lean on day-of reminders plus crew en-route texts. An appliance repair shop benefits from the full sequence. Build the workflow that matches your job rhythm.
Optional: the arrival and follow-up touches
Some teams add a short "your tech has arrived" note (useful for properties where the customer isn't home, like rental management or exterior work) and a post-job follow-up asking for a review or offering the invoice. These are valuable but separate workflows — get the ETA sequence solid first.
How to Compute ETAs Honestly When Traffic Happens
The fastest way to make customers distrust your texts is to send an ETA that's wrong every single time. Here's how to build estimates that hold up in the real world.
Separate travel time from job-completion time
Most "my tech is always late" problems aren't travel problems — they're previous job ran long problems. A realistic ETA pipeline has three parts:
- Remaining work time at the current job. If your techs mark jobs "started" and "complete" in your field software, you can estimate this from job type history (a drain clear typically takes 45 minutes; a furnace diagnostic, an hour). If they don't, this is the single most valuable dispatch habit to build, because it's the input that makes every downstream estimate honest.
- Drive time with live traffic. Routing APIs (Google Maps, Mapbox, and similar services) provide drive-time estimates that account for current conditions. This is dramatically better than a static "it's 20 minutes across town" assumption, especially at rush hour.
- A buffer. Add padding for parking, finding the unit in a complex, getting tools out of the truck, and the hundred small frictions that make real arrival later than map arrival.
Always quote a window, never a minute
"No matter how good your data is, a single minute ('arriving at 1:42') will be wrong roughly half the time. A 20–30 minute window ('between 1:30 and 2:00') will be right almost all the time — and being right is worth far more than being precise. When you compute the ETA, calculate the most likely arrival and then build the window asymmetrically around it: start the window slightly before your best estimate and end it somewhat after. Customers are pleasantly surprised by early arrivals and genuinely frustrated by late ones, so bias the window toward lateness.
Recalculate, don't just schedule
The difference between a naive system and a good one is whether the ETA is a one-time calculation or a continuously refreshed one. A good workflow recalculates when:
- The technician's status changes (job started, job completed, en route).
- The live drive-time estimate shifts materially (for example, an accident adds 25 minutes).
- The communicated window is about to be violated.
In practice, this means your automation should run on a check — for example, every few minutes while a tech is en route, compare the fresh ETA against the last window you sent. If the fresh ETA now falls outside that window, trigger the delayed-arrival update. If it still falls inside, stay quiet. Silence when things are on track is a feature, not a gap: customers who get pinged every ten minutes with "still on the way" stop reading your texts.
Narrowing Wide Windows Without Over-Promising
Four-hour windows are the industry default because they protect the business: they absorb every possible delay. But they push all the waiting pain onto the customer. The art is narrowing windows progressively as uncertainty shrinks — a technique sometimes called "collapsing windows."
Here's how it works in practice:
- At booking (days out): quote the wide window. "Thursday, between 8 a.m. and 12 p.m." This is honest, because days out you genuinely can't know.
- The night before: confirm the window and set expectations for the collapse. "Your appointment is tomorrow between 8 and 12. We'll text you a tighter arrival time in the morning."
- Morning of, once the route is sequenced: narrow it. If your tech's route is now set and the customer is the third stop, you can credibly say "we expect to arrive between 9:30 and 11:30."
- When the prior job completes and the tech goes en route: narrow it fully. "Dave is on the way and should arrive between 10:05 and 10:25."
Each message makes the previous promise more specific, never different. That's the key to avoiding over-promising: you never walk back an earlier commitment, you simply refine it as your information improves. Customers experience this as a system that keeps getting smarter, and each text reduces the odds they'll call.
A few guardrails:
- Never promise the minimum. If the route could get the tech there by 9:30, quote 9:45–10:15. Early beats late, every time.
- Watch your route density. If a tech has five stops and each job's duration is uncertain, later stops inherit all that uncertainty. Collapse windows more conservatively for later stops, and more aggressively for the first stop of the day.
- Be honest about stops without committing times for them. You don't need to tell stop #4 exactly when they'll be served; "your tech is on stop 2 of 4 — we'll text a firmer arrival time soon" is a perfectly good update that keeps them informed without creating a promise you can't keep.
Writing Notification Messages That Set Expectations
The copy in your texts matters as much as the timing logic. Good service-appointment texts share a few characteristics:
1. Identify yourself in the first few words. "Apex Plumbing:" or "Hi Maria, it's Apex Plumbing." Unidentified texts from unfamiliar numbers get deleted or — worse — reported as spam, which can degrade deliverability for your whole number.
2. Lead with the news, not the pleasantries. "Your technician Dave is on the way and should arrive between 1:10 and 1:30" beats "Thank you for choosing Apex! We value your business and wanted to let you know that at this time your technician..." Customers scan texts in two seconds. Front-load the arrival information.
3. Use the technician's first name. It's a small thing with an outsized effect on perceived trustworthiness and safety, especially for customers who are home alone or for elderly clients.
4. Frame delays as updates, not apologies-first. Lead with the new information ("Dave is running about 25 minutes behind") and follow with the brief acknowledgment ("sorry for the wait"). An apology-first text with no new information ("we're sorry for any inconvenience, your technician is still on the way") answers nothing and invites a call.
5. Give a response path. "Reply 1 to confirm, 2 if you need to reschedule" for pre-arrival messages, or "Reply HELP to reach our office" on ETA texts. Two-way capability turns texts into a pressure-release valve: a customer who can text back a question is less likely to call.
6. Keep it short and plain. 300 characters or fewer where possible. No jargon, no emoji walls, no marketing.
7. Handle the "on the way" moment carefully for no-answer jobs. For customers who booked for a time they might not be home (cleanings, deliveries, exterior work), add "If no one's home, Dave will call you" or whatever your actual policy is — so the text also prevents failed-arrival confusion.
One more copy consideration: write templates with plain-language delay reasons where possible. "Heavy traffic on the interstate" or "his earlier repair needed a part swap" is concrete; "unexpected delays" is filler. You can build a small library of common reasons technicians select from in your dispatch app, which feeds honest-sounding, specific texts automatically.
Step-by-Step Rollout Plan
Rolling out technician ETA notifications doesn't have to be a big project. Here's a realistic sequence most field service teams can complete in a few weeks:
Week 1: Audit and instrument.
- Map your current job lifecycle: what statuses exist in your scheduling or field service software (scheduled, dispatched, en route, started, completed)? Which ones does the office set, and which do techs set from the field?
- Check data hygiene: do your customer records have accurate mobile numbers? Are you capturing opt-in consent for texts at booking? Fix the intake first — bad numbers are the most common reason notification projects stumble.
- Ask your technicians how job-duration estimates would work for their work. They'll tell you instantly which job types vary wildly (hint: anything involving older systems or first-time diagnostics) — you'll use this to set buffers per job type.
Week 2: Build the core workflow. 4. In your automation platform, build the trigger: job status changes to "en route" → look up customer mobile, job details, and live drive time → send the en-route text with a computed window. Tools like Automate Anything connect your dispatch software's statuses to messaging and mapping services so this runs without code. 5. Add the delay-detection check: while the job is en route, periodically recompute the ETA and send a delayed-arrival update only if the new estimate falls outside the last communicated window. 6. Write your message templates using the copy principles above. Have someone outside the office read them — if a neutral reader can't tell within two seconds who's texting and what's happening, revise.
Week 3: Pilot. 7. Turn the workflow on for one technician, one service line, or one day of the week. Pick a segment with high call volume so the difference is visible. 8. Brief the technicians so they're not blindsided when customers mention texts, and brief the office so they know what customers will be seeing. 9. Collect every piece of feedback: which texts confused people, which times were wrong, who replied to the texts, and what the office heard on the phone.
Week 4: Refine and expand. 10. Adjust buffers and windows based on pilot accuracy. If early arrivals dominate, shift windows earlier; if lates dominate, widen or shift later. 11. Roll out to all technicians, then layer on optional touches — day-of reminders with window collapse, arrival notifications, or post-job follow-ups. 12. Document the workflow and its templates so new office staff understand what customers receive and when.
Common Mistakes (and How to Avoid Them)
Mistake 1: Sending texts the technician hasn't actually triggered. If the en-route text fires when the dispatcher marks the job en route but the tech is actually finishing lunch, customers learn the texts are fiction within a week. The trigger must reflect reality — have techs tap "en route" from their phones, not have the office guess.
Mistake 2: Only sending good news. A notification system that confirms arrivals but goes silent during delays is worse than nothing, because it trains customers to ignore the texts. The delayed-arrival update is the trust-building message; make sure it actually fires.
Mistake 3: Over-pinging. More than two or three texts per appointment feels like spam. If your automation is updating customers hourly, your windows are probably too wide and your buffers too small — fix the estimates rather than adding messages.
Mistake 4: Texting landlines and stale numbers. Bounce handling matters. Route failed texts back to the office as an exception task ("check this customer's number") rather than letting them vanish silently.
Mistake 5: Skipping consent. In the US, texting customers without consent runs into TCPA rules, and separate rules apply if you ever add marketing messages. Capture opt-in clearly at booking, honor opt-outs (STOP replies) automatically, and keep transactional service texts strictly informational.
Mistake 6: One buffer for all job types. A furnace diagnostic and a full system install do not have the same variance. Set per-job-type duration estimates and buffers, even if rough, instead of applying a flat pad to everything.
Mistake 7: Forgetting the crew case. For cleaning crews, delivery teams, or multi-tech jobs, "your technician Dave" is wrong — it's "your crew" or "your delivery driver." Build separate templates for crew jobs, and assign a crew lead name so the message still humanizes someone.
Mistake 8: Treating the first rollout as final. Your estimates will be wrong for the first two weeks — that's normal and it's the data you need. Teams that abandon after a rough pilot lose the whole benefit; teams that treat week one as calibration end up with systems that are accurate by month two.
Edge Cases Worth Planning For
- Towing and emergency work: every job is "now," so the wide window doesn't exist. Here the workflow collapses to a single, high-frequency en-route text with live updates, and the delay-detection check should run more often. A stranded driver's tolerance for silence is near zero.
- Deliveries with many stops: if your driver serves fifteen stops, per-stop ETAs degrade down the route. Communicate stop position ("you're stop 6 of 12 today") plus a collapsed window for the current leg rather than promising a precise time at the top of the day.
- Customers who aren't home: pair the en-route text with a "we've arrived and no one answered" note plus your policy (call first? leave notice? reschedule fee?). This turns a failed appointment into a documented, fair interaction.
- Multi-day projects: for jobs spanning days (restorations, big installs), send a "today's plan" text each morning with the crew and window, then the en-route text. The daily rhythm replaces the appointment rhythm.
- Techs without smartphones or habits: if your techs won't reliably tap status buttons, a dispatcher-driven trigger is an acceptable fallback — but then train the office that "en route" means now, and audit it.
- The customer replies with a question: your automation should route replies to the office inbox or phone queue with the job context attached, so nobody answers "who is this?" blindly.
A Checklist for Evaluating Your Setup (or a Tool)
Use this to grade your current process or any automation you're considering:
- Trigger based on a real field status change, not a dispatcher's guess
- Live-traffic drive-time calculation, not static distance math
- Windowed ETAs (20–30 minutes when en route), biased toward lateness
- Automatic recalculation while en route, with alerts only when the window breaks
- Delayed-arrival template that leads with new information
- Day-of reminder with progressive window collapse for long-lead appointments
- Templates identifying the company, technician or crew lead, and purpose
- Two-way replies routed to a human with job context
- Opt-in capture, STOP handling, and failed-text exception handling
- Per-job-type duration estimates and buffers
- Separate templates for crews, deliveries, and multi-day jobs
- A pilot period with a defined measurement plan (below)
If your current process fails more than a few of these, a no-code automation platform can close most of the gaps — Automate Anything, for instance, is built to connect your existing dispatch or scheduling software's job statuses to messaging and mapping services without code, and you can browse more workflow guides on the Automate Anything blog.
How to Measure Whether It's Actually Working
The point of this whole exercise is fewer interruptions and happier customers, so measure those directly:
Inbound call metrics:
- Count "where's my tech?" / status-check calls per day (tag them in your phone system or with a simple tally) before and after rollout. This is your headline number.
- Track total inbound call volume per completed job, so growth in job count doesn't mask the improvement.
Complaint and experience metrics:
- Track arrival-related complaints and negative review mentions of waiting, lateness, or communication separately from service-quality complaints. The goal is a visible drop in the communication cluster.
- Ask technicians: are customers calmer at the door? This anecdotal signal shows up fast.
Operational metrics:
- ETA accuracy: what percentage of en-route windows contained the actual arrival? If this sits above roughly 80–85%, your texts build trust; below that, recalibrate buffers.
- Reschedule and same-day-cancel rates attributed to "no one communicated" reasons.
- Delayed-arrival texts sent per 100 jobs — high counts mean chronic under-buffering or route-density problems, not a messaging problem.
Behavioral signals:
- Reply rates and STOP rates. A modest reply rate shows customers read the texts; a rising STOP rate suggests over-pinging.
- Office time: have your dispatcher log interruptions for one week pre-rollout and one week post. It's crude, but the difference is usually obvious.
Give the system four to six weeks to stabilize before judging it. The first two weeks are calibration; the trend that matters starts after your buffers are tuned.
Frequently Asked Questions
Do customers actually want these texts, or is it just noise? Customers overwhelmingly want arrival information for scheduled in-home services. Noise comes from volume, not usefulness — three well-timed, accurate texts per appointment is helpful; six vague ones is spam.
What if we don't have technician GPS tracking? You can still run most of the workflow. Drive-time estimates can start from the prior job's address when the tech marks that job complete, which is nearly as good for single-direction routes. GPS makes continuous recalculation smoother, but status-based triggers get you most of the benefit.
Isn't this just what my field service software already does? Some platforms include basic reminders, but many stop at the day-before appointment reminder and don't handle live en-route windows, delay detection, or reply routing — or they lock those behind configurations you can't customize. A flexible automation layer lets you build exactly the sequence your business needs and change it as you learn.
How narrow should my final en-route window be? Twenty to thirty minutes is the sweet spot for most urban and suburban work. Tighter than fifteen minutes requires very reliable conditions; wider than forty-five minutes starts generating "so when exactly?" calls again.
What about customers who don't text? Always keep a fallback: an automated voice call or a phone call from the office for customers with no mobile number on file or who opt out. The workflow should branch on that automatically rather than leaving those customers in the old silence.
Will technicians resent it? Usually the opposite. Techs hate getting forwarded status calls mid-job more than anyone. Once customers stop calling because the texts answer them, technicians notice within days.
The "where's my technician?" call is one of the most preventable interruptions in field service work. It exists because of an information vacuum, and it disappears when a small set of honest, well-timed technician ETA notifications fills that vacuum before the customer reaches for the phone. Start with the en-route text, add delay detection, narrow your windows progressively, and measure the calls that stop coming in — then build your first automation at https://automateanythingsoftware.com.