Is the late arrival a routing problem or a communication problem?
Use this operating test to separate bad routes, missed customer updates, and access exceptions before changing your garage door service workflow.

The one-star review starts before the truck is late
A broken-spring call lands at 8:10 a.m. The service manager makes room for it because a customer cannot secure the garage. Fair call.
By 2:30 p.m., one repair ran long, the emergency visit displaced a tune-up, and every promise after lunch has slid. A dispatcher can see the trouble building on the board. A CSR gets the first angry call at 3:07. The owner hears about it at 3:20, when the customer asks why nobody told them.
That one late service arrival can become a one-star review, a tense call, and a quick judgment that dispatch “dropped the ball.” But it may have started with a bad route, a weak job-time estimate, or an access problem that needed a person to decide what happens next.
A single on-time KPI hides all three.
When a service call misses its arrival window, was the schedule wrong, was the customer update missed, or did the job need human judgment?
That is the operating question for garage door service scheduling. Answer it before you change a workflow, buy a tool, or make the dispatcher the safety net for every moving part.
Separate schedule quality from communication quality
Schedule quality is about whether the board can keep the promise it made. Did the job have a realistic duration? Was drive time real? Did the technician have the right skill and parts? Did the order of stops make sense after an urgent call came in?
Communication quality is different. It is about whether the customer got useful notice once the schedule changed. A late notice does not repair a bad route. It does keep the customer from spending an afternoon wondering whether the truck is still coming. Research on waiting shows that uncertainty makes delays harder to tolerate, while a proactive explanation and apology can reduce frustration in the moment, even though that evidence comes from a healthcare setting rather than garage door work (the study explains those limits, too).
Then there are exceptions: a locked commercial site, a tenant who cannot grant access, a safety concern, an approval that has not arrived, or an emergency call that must jump the line. These need judgment, not another automatic text.
| Control | What it covers | First owner |
|---|---|---|
| Schedule quality | Job duration, travel, territory, technician fit, and stop order | Service manager or dispatch lead |
| Arrival window communication | Notice when a recorded customer promise is at risk | CSR or assigned communication owner |
| Exception handling | Access, approvals, safety, and priority conflicts | Named manager with authority to decide |
These controls work together, but they do not have the same measure or fix. A broad on-time rate often makes dispatchers the fallback for bad estimates, missing access notes, and unclear priorities.
The owner’s three-question operating test
Use this test on every meaningful miss, then use it again in the weekly review. Do not start with who got the complaint. Start with timestamps.
You need the booking time, promised arrival window, technician status changes, ETA change, outbound notice, inbound customer call, and final resolution. If those records do not exist, the first problem is not routing or communication. It is that the business cannot see what happened.
| Test question | Evidence to check | Likely cause | First action |
|---|---|---|---|
| Did the board become wrong before the customer promise failed? | Planned versus actual drive time, estimated versus actual work time, route order, technician skill match, emergency insertion | Routing or schedule-model problem | Compare misses by job code, territory, technician, and daypart. Correct the assumption that broke first. |
| Did the office know about the shift before the customer called? | Technician status timestamp, visible ETA change, outbound message timestamp, first inbound status call | Communication-process problem | Set a notification trigger and name the person or system responsible for acting on it. |
| Could a standard update solve it without a decision? | Access notes, approval status, safety issue, customer availability, priority conflict, resolution notes | Human exception | Assign an owner, a response deadline, and an escalation path. |
The first question separates a bad promise from a missed notice. A spring replacement that regularly takes 90 minutes when cable damage is involved should not be booked for 45; neither should a route ignore afternoon traffic or technician fit. Measure actual travel and work time against the plan. Field-service records can separate those values, and changing route order may update travel time without automatically moving later booking start times unless the schedule is recalculated (Microsoft documents that distinction here).
The second question asks whether the office had warning before the customer called; if so, the failure is the trigger or owner. The third prevents false automation: access, safety, approval, and priority conflicts require someone authorized to decide. A miss can involve all three controls, so score each one rather than fixing only the last visible failure.
Read the pattern, not the loudest complaint
One painful day is a story. Several weeks of coded jobs are a pattern.
Start with the patterns that usually create the most avoidable customer friction.
-
Routing pattern. Misses cluster around a job type, territory, technician, daypart, or emergency add-on. Maybe installation estimates are solid, but repair calls involving operators and photo eyes regularly run over. Maybe the late afternoon route across town always absorbs more drive time than the board allows. Break out on-time arrival rate and schedule variance before blaming the person assigning calls.
-
Communication pattern. The board correctly shows the delay, but arrival window communication happens late, inconsistently, or only after a customer calls. Watch the update-before-customer-call rate and repeat status-call volume. If the same CSR always catches problems manually, you have a heroic person, not a control.
-
Exception pattern. The cases are low volume but costly: gate codes are missing, a property manager has not approved work, the customer is not home, or a technician finds a safety issue. These need one root-cause code and a named decision owner. Treating access failures as generic no-shows throws away the clue.
-
Mixed pattern. The schedule begins with bad duration assumptions and ends with missed notices. This is common after an urgent insert, when the first spring call runs long.
Complaint volume is not a staff-performance score. Some customers call quickly, some wait quietly, and some leave a review after the fact. Use complaint calls as evidence, not the whole case file.
For schedule variance, compare actual arrival or completion time with the planned time. Report the median, the 80th or 90th percentile, and the share outside your tolerance. An average can look calm while a handful of customers lose half a day. Scheduling research consistently treats arrival and service duration as variable inputs that require explicit assumptions about capacity, sequence, and priority (this review covers the underlying problem).
Do not import a magic benchmark from another trade. Residential repair, commercial work, installations, emergency security calls, weather, parts, and building access make garage door dispatch its own animal. Set a local baseline first.
Match each diagnosis to the right control
| Diagnosis | Control to install | What good looks like |
|---|---|---|
| Routing problem | Better job codes, duration ranges, territory rules, drive-time inputs, and board sequencing | The promise is based on actual repair and travel patterns, not a shop-wide guess. |
| Communication-process problem | An event-based update when the current schedule moves beyond a set threshold | The customer hears about a credible change before they need to chase the office. |
| Human exception | A named owner, response deadline, and escalation path | Access, approval, safety, and priority decisions stop sitting in a vague queue. |
For the communication control, tie the trigger to the window the customer was given. If the current ETA still fits inside that service call arrival window, do not create noise. If it moves outside the window, send the update or put a CSR on the case. The useful message says what changed, gives the revised expectation when you have one, and tells the customer what happens next. A public repairs charter uses the same plain standard: contractors should advise residents when they will be late and provide a revised ETA (see the charter).
Queue Up fits that second row. It sends predictable customer notifications based on the existing schedule, giving CSRs back time for real exceptions and actual customer care. It does not reroute trucks, reschedule jobs, or replace CSR judgment. That boundary matters.
Do not apply automated ETA updates to a schedule that is still wrong and call it progress. You will simply send polite, punctual notices about promises your garage door dispatch process should not have made.
Put the test into the weekly operating review
Keep the review short, factual, and recurring. The goal is not a meeting about meetings. It is one clear correction per pattern.
-
Pull a small scorecard. Track:
- On-time arrival rate: completed appointments with a recorded promised window that arrived inside that window, divided by all completed appointments with a recorded promised window.
- Schedule variance: for completed appointments with both timestamps, actual arrival or completion minus the corresponding planned arrival or completion.
- Update-before-customer-call rate: at-risk appointments—those whose current ETA moved outside the recorded window—divided into those that received an outbound update timestamped before the first inbound status call or complaint. Keep unreachable customers in the eligible population and code the failed contact attempt separately.
- Repeat status-call rate: appointments with two or more inbound “where is the technician?” contacts, divided by appointments with a recorded promised window.
- Access-related failure rate: scheduled first visits not completed because entry, codes, customer presence, or permission was unavailable, divided by all scheduled first visits. Require one standardized root-cause code; do not count safety, parts, or scheduling failures as access failures.
-
Break the numbers apart. Review job type, territory, technician, weekday, and time of day. Separate residential repair from commercial work and installation.
-
Review five cases. Bring two common misses, one severe miss, and one access exception. Mark the promise, board change, customer update, decision point, and result.
-
Name one manager for each control. A dispatch lead may own duration-code cleanup, a CSR manager update triggers, and a service manager emergency-priority rules.
-
Write a decision log. Capture the pattern, root cause, action, owner, and review date; check it after 30 days.
Use documented roles, authority, status tracking, escalation, and learning after an incident as a governance model. NIST recommends these controls for incident response, not field service, so it is not proof of a dispatch outcome (the guidance is here).
Fix the control that failed
A late arrival is an outcome, not a root cause.
Before changing software or blaming dispatch, score a set of recent misses. Was the customer promise realistic? Did the office know in time? Did the case require a human decision?
Then assign one control owner to each pattern. Scheduling owns a board that can hold up. Customer updates own the notice when it cannot. Exception management owns the calls that no standard message can settle.
That is service operations accountability: evidence first, blame never, and no more asking a dispatcher to patch every crack in the day.