Did arrival texts cut status calls? Prove it before close
Use a simple before-and-after test to see whether technician-arrival notifications reduced status calls and office labor costs before close.
The variance hiding in “just checking” calls
A two-minute arrival-status call is rarely two minutes. The CSR finds the job, checks the route, maybe calls the technician, logs the answer, then takes the callback when the customer wants a firmer time. Those supposedly “quick” calls have excellent survival skills.
Did technician arrival notifications cause the office labor variance, or did something else change? When office labor rises without matching route revenue, customer status calls are a testable place to look. Have the evidence ready before close, not after someone has already named the variance.
Lock the baseline before changing the story
- Use a pre-change window that matches the post-change window for weekdays, route count, and service mix. A before-and-after result cannot rule out other causes by itself, so a comparable control route or branch is better when you have one. Guidance on pre-post studies makes that limitation plain.
- Give every CSR-reached arrival lookup one primary reason code:
technician ETA/status. Do not bury it inside a general service bucket. - Keep late service, reschedules, and general ETA checks in separate buckets. A late technician is a service issue, not proof that the notification failed.
- Record qualifying call count, talk time plus after-call work, completed stops, and notification sent, delivered, failed, and late-log coverage, with timestamps for the notification, scheduled or actual arrival, and inbound call. Report notifications delivered in time separately from missed, late, or post-call notifications; do not attribute calls that occurred before a qualifying notification to its performance. Average handling time includes the work after the conversation, not just the conversation itself. ICMI’s definition is useful here.
- Write the counting rule: one customer-job episode counts once, transfers do not create another call, and callbacks get a repeat-caller flag.
Run the before-and-after math
Use the same number of comparable days after the notification update. Normalize by completed stops, because 40 calls across 400 stops tells a different story than 40 calls across 700.
| Measure | Before | After | What it tells you |
|---|---|---|---|
| ETA/status calls per 100 completed stops | 12 | 8 | Arrival-question rate |
| ETA/status handling minutes per 100 stops | 30 | 18 | Inbound call workload |
| Completed stops | 500 | 500 | Comparable volume check |
| Notification delivery rate | 96% | 97% | Whether texts actually reached customers |
Sample numbers, not a benchmark: if the rate falls from 30 to 18 handling minutes per 100 stops across 500 completed stops, that is 60 minutes returned. At a fully loaded CSR cost of $30 per hour, the observed labor value is $30.
estimated labor value = (baseline minutes per 100 stops − test minutes per 100 stops) ÷ 60 × completed stops ÷ 100 × fully loaded CSR hourly cost
Use your own loaded cost, including benefits, rather than the wage rate alone. The Bureau of Labor Statistics measures employer compensation as wages plus benefits, which is the right shape for this calculation.
Keep false labor dollars out of the close
| Check | Reason |
|---|---|
| Hold route volume and service mix steady | More completed stops create more chances for arrival questions. Show scheduled jobs and route count beside completed stops. |
| Count the customer-job episode once | Transfers, callbacks, and shared queues can turn one question into three call records. |
| Split failures from lookups | A missed arrival, a moved appointment, and a routine “where is my technician?” call need different fixes. |
| Note staffing, phone hours, weather, and outages | Any of these can move inbound call workload without a change in notification performance. |
| Match logs before taking credit | Queue Up can illustrate whether notification logs line up with calls that reached a CSR. It cannot prove a text prevented a call. Keep the raw telephony and notification records. |
That last distinction matters. A notification may have reduced status-call workload, while the time returned to CSRs goes to bookings and customer problems that actually need judgment. That is useful. It is not a license to call every fewer-minute result permanent.
Make the call with a one-line close note
- Observed reduction, with causal limits: comparable volume, strong delivery coverage, a lower status-call rate, and no obvious concurrent change. Report this as an observed result, not proof that notifications caused the labor change; a causal conclusion needs an appropriate comparison or control.
- Promising: the rate fell, but the sample is short or route mix moved. Keep measuring next month.
- Inconclusive: delivery coverage is weak, call reasons were inconsistent, or service trouble changed at the same time.
Keep the baseline. Report the call-rate change, workload hours, labor dollars, and notification coverage together. The close note can stay this plain:
[ETA/status calls per 100 stops changed from __ to __; workload changed by __ hours; labor value was $__; notification delivery was __%; result: observed reduction with causal limits / promising / inconclusive.]