How to audit arrival-window updates after a schedule change
Use this quick audit to match rescheduled tree service jobs with sent arrival-window updates, flag exceptions, and limit manual customer calls.
The gap hiding on tomorrow’s board
After a storm reroute, the board can look clean while the customer side is a mess. Hazard work moved up. A pruning job moved from 10–12 to 1–3. The crew knows; the customer may still be watching for the first window.
This is not a full dispatch review. It is a narrow control: for every job whose promised arrival window changed, find matching communication evidence. Post-storm work can change fast because hanging limbs, overhead work, and downed lines need qualified attention first. Texas A&M Forest Service warns against hasty decisions after storm damage.
The goal: no rescheduled customer update gets assumed. It passes, or it becomes an assigned exception.
Set the proof standard before checking jobs
Start with every job whose date, crew order, or arrival window changed since the last review point. Do not start with total texts sent: a total cannot show whether Mrs. Lee’s 1–3 window replaced her old 10–12 window.
A passing record needs
- The job ID and customer name.
- The current promised arrival window on the board.
- The message time and content, or template version.
- The recipient and channel, with contact preference or consent where applicable.
- A visible status:
sent,delivered,failed,queued,undelivered, orunknown. - A provider message ID or other job-level audit trail.
Memory, chat threads, and loose “called customer” notes do not count unless they name the job, owner, time, and outcome.
Status is not all equal. Queued means the provider received the request; sent means a network partner accepted it; delivered reflects carrier confirmation, with handset confirmation where available. Failed means it could not be sent, and undelivered is a negative receipt. Final updates do not arrive in every carrier case, so sent is not proof the customer read the message. The status definitions matter.
Run the five-minute reconciliation
Run this audit after dispatch completes the latest reroute, not while cards are still moving. Freeze the review point so the board and message log reflect the same moment.
- Mark each job whose promised window changed.
- Read the current board window—the promise being tested.
- Find the job-linked communication record. Compare recipient, send time, stated window, and latest status.
- Check for a second change. If 10–12 went out at 8:15 and the job moved to 1–3 at 9:00, the earlier message is stale.
- Mark
Passonly when the latest update matches the current window and has carrier-confirmeddeliveredstatus. Otherwise, assign an exception code and owner. - Count changed jobs, passes, open exceptions, and the oldest exception’s age.
| Job | Current window | Message evidence | Result |
|---|---|---|---|
| 1842 | Today, 1–3 | 9:07 text states 1–3; delivered | Pass |
| 1851 | Tomorrow, 8–10 | 9:12 text states 8–10; queued | Escalate |
| 1860 | Today, 3–5 | 8:40 text states 1–3; delivered | Stale window |
| 1873 | Tomorrow, 10–12 | No job-level message record | No record |
The Institute of Internal Auditors calls for documented information that is sufficient, reliable, relevant, and useful, with record-retention requirements. Its performance standards set that bar. For this control, proof must fit the promise made to one customer.
Route exceptions without sending every job to a CSR
Reserve CSR time for cases that need judgment, a new contact method, or a real conversation.
| Exception | Owner | Next action |
|---|---|---|
| No message record | Dispatcher or system owner | Check the schedule-change trigger and contact data. Send the correct update, or document why it cannot be sent. |
| Failed or undelivered | CSR | Follow up through an approved channel and note the outcome on the job. |
| Wrong or stale window | Dispatcher | Send a corrected update based on the latest board window. Review the second-change trigger. |
Queued, sent with no final result, or unknown near arrival time | CSR | Escalate by the set cutoff time. Confirm contact details, then use the approved fallback. |
| Wrong recipient or missing consent | CSR or data owner | Correct the record and choose a policy-safe contact method. Do not improvise. |
| Access issue, call preference, or high-risk property detail | CSR | Handle directly and leave a closure note for dispatch. |
Every exception needs an owner, due time, and closure note. For text contact records, honor and track opt-out requests. The FCC says covered callers and texters must honor reasonable revocations within no more than 10 business days. Read the FCC order.
Make communication proof part of the board review
Put this control beside crew availability, equipment checks, and priority work. Run it daily and again after a serious reroute.
A one-line scorecard is enough: 18 changed jobs | 15 matched updates | 3 open exceptions | oldest open: 22 minutes. Watch repeat causes—bad numbers, stale templates, missed triggers, or late statuses—because each needs a different fix.
If Queue Up is the message log your office uses, keep the job-linked status record visible. The value is being able to point from a changed job card to the exact update and its outcome.
The standard is plain: no changed job leaves the board without matching evidence or an assigned exception. That protects the CSR from calling everyone and the customer from waiting for a crew on the wrong clock.