How to cut 'where is my technician?' calls and prove it worked

Short answer

Status calls fall when three things are true: the schedule makes promises it can keep, the customer hears about a change before the window breaks, and exceptions have a named owner. Find which of those failed before you change anything. Then run a 30-day test with the rules written down first, measure status calls per 100 scheduled jobs, and put the guardrails (booking coverage, missed arrivals, escalations) on the same page.

A "where is my technician?" call is not a CSR failure. It is a customer closing an information gap while a visit is still open. The fix is to close the gap earlier.

Step 1: Ask the three-question test on every meaningful miss

When a service call misses its window, a single on-time KPI hides what happened. The question is: was the schedule wrong, was the update missed, or did the job need human judgment?

Start with timestamps, not with who got the complaint. You need the booking time, the promised window, technician status changes, the ETA change, the outbound notice, the inbound call and the resolution. If those records do not exist, the first problem is that the business cannot see what happened.

Schedule quality and communication quality are different controls. A late notice does not repair a bad route. It does keep the customer from spending an afternoon watching the driveway. Uncertainty makes waiting harder, while a proactive explanation and apology can reduce frustration in the moment, though that evidence comes from a healthcare setting rather than home service (PMC).

For schedule variance, compare actual with planned arrival, and report the median, the 80th or 90th percentile and the share outside tolerance. An average can look calm while a few customers lose half a day. A spring replacement that runs 90 minutes when cable damage is involved should not be booked for 45. Field-service records can separate planned from actual, and changing route order may update travel time without moving later start times unless the schedule is recalculated (Microsoft). Do not import a benchmark from another trade. Set a local baseline.

Do not apply automated ETA updates to a schedule that is still wrong. You will send polite, punctual notices about promises dispatch should not have made.

Step 2: Audit the morning phone queue

A two-minute status call is rarely two minutes. The CSR finds the job, checks the route, maybe calls the technician, logs the answer and takes the callback. When those calls crowd the booking queue, the first call of the day becomes a dispatch relay instead of a booked job.

Scope it narrowly:

• Pick the booking-heavy block, such as opening through 10:30 a.m., and compare a normal week with a busy fall week.
• Tag inbound calls: new booking, confirmation, arrival-window check, delay check, queue-position check, on-the-way check, reschedule, other.
• Link each status call to the appointment or job ID and flag customers who called twice about the same visit.
• Track booking outcomes: answered, abandoned, voicemail, booked. If your phone system cannot show abandoned booking calls, mark that gap. You cannot protect capacity you do not count.

Map the trip from booking to arrival and put the actual message beside the actual dispatch data. The gap between them is where repeat calls grow.

Most repeat calls start in a handoff. A common chain: an early repair runs long, the technician does not change status, the next window expires with no update, the customer calls, the CSR relays dispatch's answer, and nothing closes the loop in the customer record, so the customer calls again. The repair delay was unavoidable. The missing timestamp, alert or closed-loop update was not. Inspect the timestamps for booking, confirmation, assignment, route change, status change, revised message, delivery result and first and second inbound call to find where communication stopped moving with the route.

Step 3: Name every trigger and give it one owner

"Dispatch owns it" is shared ownership, which is another name for waiting. Give each trigger one named role, a deadline and a backup. Use your own job titles and put names beside them.

The source event matters as much as the message. If the technician does not mark travel, no system can honestly send an on-the-way text. If dispatch inserts an emergency call, later windows need an explicit check. The service manager should own the decision rule for exceptions, not become the person who sends every update.

Fix the workflow in this order, because buying a tool first is a fine way to make an unclear process happen faster:

1. Add the missing trigger.
2. Name the owner and a backup.
3. Repair the handoff: a timestamped status change, a route-impact check after edits, a closed record after delivery.
4. Improve the message: short, current window or next-update time, a usable reply path.
5. Automate only dependable events. A booking confirmation is a strong candidate. An on-the-way text is only dependable if travel status is.

Step 4: Turn a Monday complaint into one commitment

At the weekly huddle, "the CSRs got hammered with ETA calls again" is a real problem but not yet an outcome. Ask the CSR lead to bring one week of call tracking: the total, the appointment window, the customer's reason, the board event tied to the call and a routine-or-exception label. If a call cannot be tied to a board event, write "unknown." Unknown is a finding.

Then, in eight minutes:

1. Define the miss. "During [period], [number] customers called because they did not receive [expected update] after [board event]." Keep the language neutral: "lacked an update after a known delay," not "dispatch forgot again."
2. Find the failed trigger. The event happened, the right person could see it, an update was sent and the shop can check delivery. No trigger means the standard was never defined. Late board data means the field or dispatch update was late. A missed action means the event was visible but nobody did the customer-facing step.
3. Make one commitment. "[Name] will [action] when [trigger] occurs by [deadline]. Proof: [report, tag, board view or count]." Name people, not departments. Dispatch owns the board event, the CSR owns clean exception tags, the service manager owns field status behavior, and the GM removes one blocker and reviews next Monday.
4. Protect the exception path. Routine: a confirmed window, an en-route text, a known delay with a clear new ETA. Needs judgment: a safety or access problem, an angry customer, uncertain technician timing, a repeat contact after an update. Write the destination and response time next to each.
5. Pick one result and one guardrail. If weekly volume is small, use counts. A move from four calls to two is clearer than a dramatic percentage on almost nothing.

The Lean Enterprise Institute separates process adherence from process performance (LEI). Here, adherence asks whether the update went out after the trigger. Performance asks whether fewer customers had to call.

Step 5: Run a 30-day test

Thirty days gives directional operational evidence, not a durable causal verdict. At day 30, make one local decision: keep, fix or stop.

Rates matter because raw totals follow workload. A shop with 320 jobs and 24 status calls has a different problem than one with 160 jobs and 18. Time-ordered, normalized measures with annotated outside influences are better than a simple before-and-after total (PMC review of run-chart use).

Set the pass conditions before day one

Write the targets, the counting rules and the color bands down first. Do not change call tags or targets halfway because Tuesday looked rough. Set the threshold from your own baseline: if you start at 8.0 status calls per 100 jobs, you might define success as a sustained drop to 6.5 or lower. That number is an example, not an industry benchmark.

• Baseline: 14 to 30 comparable operating days, split into service, install and estimate work. If you only have 14, say so on the scorecard.
• Eligibility: define message-eligible jobs and exclusions before the stable period begins.
• Call tags: one short disposition guide at every phone station, with a sample reviewed in the first three days.
• Context notes: weather, promotions, staffing, outages, holidays and demand spikes.
• Comparison: matching workdays, and a held-out team or area if you can. If not, be modest about what the result proves.

Keep the job number on both the call disposition and the message event, so the GM can inspect an exception instead of debating a dashboard tile.

Run it

• Days 1 to 3: calibrate. Review tagged calls and message records daily and fix training problems now.
• Days 4 to 30: hold the workflow steady. Do not change phone routing, scripts, dispatch policy or the template unless you must, and annotate the date if you do. Keep messages transactional: no offers inside an ETA notice.
• Time sampling: pick two one-hour blocks a week and tally minutes on routine ETA updates, instead of asking CSRs for time sheets.
• Daily: a five-minute data check. Weekly: one owner and GM review.

Read each week in this order: schedule volume and job mix, message coverage and delivery failures, the normalized rate, booking capacity and conversion, then missed arrivals and escalations.

Pass or fail for a two-week pilot

For a booking-capacity pilot in one service area, all five must pass against the baseline week: status calls are a lower share of morning inbound calls, no sampled appointment produces two or more status contacts, every required message meets its deadline, booking abandonment is no higher and no urgent booking call goes to voicemail because a CSR is chasing a status update, and the CSR can see the current promise, delivery and next owner without contacting dispatch. The pass condition is not zero delays. Fall demand will produce delays. It is that delays are handled without manual chasing.

Keep, fix or stop

Write down the decision, the metric owner, the next review date and the one rule you will change.

Step 6: Report it at close without inflating it

If office labor rose without matching route revenue, status calls are a testable place to look. Have the evidence before close.

1. Use a pre-change window that matches the post-change window for weekdays, route count and service mix. A comparable control route or branch is better than a before-and-after alone (GOV.UK guidance on pre-post studies).
2. Give every CSR-reached arrival lookup one reason code, such as technician ETA/status, and keep late service, reschedules and general ETA checks in separate buckets.
3. Record call count, talk time plus after-call work, completed stops and message sent, delivered and failed counts with timestamps. Average handling time includes the work after the conversation (ICMI).
4. Count one customer-job episode once. Transfers do not create new calls, and callbacks get a repeat flag.

Normalize by completed stops. Sample numbers, not a benchmark: 12 ETA calls per 100 stops before and 8 after, and handling time down from 30 to 18 minutes per 100 stops across 500 stops, returns 60 minutes. At a loaded CSR cost of $30 an hour that is $30 of observed labor value.

Use your own loaded cost. The BLS measures employer compensation as wages plus benefits (BLS), which is the right shape. Keep false labor dollars out: hold route volume and service mix steady, split failures from lookups, and note staffing, phone hours, weather and outages. Message logs can show whether notifications line up with calls that reached a CSR. They cannot prove a text prevented a call, so keep the raw telephony and notification records.

Label the result one of three ways: an observed reduction with causal limits, promising, or inconclusive. A close note can stay this plain: ETA/status calls per 100 stops changed from __ to , workload changed by __ hours, labor value was $, delivery was __%, result: __.

Where a tool fits

If manual status work is proven to be the drain, a queue-based text tool can carry the routine updates and keep a job-level message history for audits. Queue Up sends a place in line and an estimated window at the start of the day, updates as the schedule shifts and texts when the technician is on the way. It cannot repair weak route data, skipped technician statuses or unclear ownership. Fix those first, or at the same time. The aim is to return routine update time to booking calls and to the customers who need a person.

For autodialed texts, the FCC says prior consent is required, with different rules for informational and commercial messages, and that recipients can revoke consent by reasonable means (FCC). A valid opt-out stops further automated ETA messages, and the FCC's 2024 order limits an opt-out confirmation to one non-promotional message (Federal Register). Have counsel confirm how this applies to your setup.

The cleanest final question is still the first one: did customers need fewer checks while the service promise held?

Related guides: what to send and when, what a missed arrival costs.