How to audit arrival updates after a schedule change or a storm reroute

Short answer

After a schedule change, check each job whose window moved against a job-linked message record. A job passes only if the latest update matches the current window and shows carrier-confirmed delivery. Anything else becomes an exception with an owner and a due time. When a single job runs long, rebuild its timeline and score five handoffs (schedule accuracy, trigger timing, ownership, exception path, message history), then fix the first one that failed. Before you buy or standardize a workflow, run it through a live reroute and require a record that finance can reconstruct a dispute from.

The goal is not blame. It is that no rescheduled customer's update gets assumed.

The gap 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 slid from 10 to 12 into 1 to 3, the crew knows and the customer may still be watching for the first window. Post-storm work changes fast because hanging limbs, overhead work and downed lines need qualified attention first (Texas A&M Forest Service). Safety can also move the plan: OSHA says line-clearance tree workers must not work in hazardous weather and requires a new job briefing when expected conditions change (OSHA).

An arrival-window text is not a promise. It is a status. The customer with a 10 to 12 window needs warning before it becomes old news, not a firm time the board cannot support.

Audit 1: the five-minute reconciliation

Start with every job whose date, crew order or window changed since the last review point. Do not start with total texts sent. A total cannot show whether a customer's 1 to 3 window replaced the old 10 to 12.

A passing record needs:

The job ID and customer.
The current promised window on the board.
The message time and content, or template version.
The recipient and channel, with contact preference or consent where applicable.
A status: sent, delivered, failed, queued, undelivered or unknown.
A provider message ID or other job-level audit trail.

Memory, chat threads and "called customer" notes do not count unless they name the job, owner, time and outcome.

Statuses are not 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 it (Twilio). Do not call a message "read" unless the provider supplies a supported read signal.

Run it after dispatch finishes 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. That is the promise being tested.
Find the job-linked record. Compare recipient, send time, stated window and latest status.
Check for a second change. If 10 to 12 went out at 8:15 and the job moved to 1 to 3 at 9:00, the earlier message is stale.
Mark Pass only when the latest update matches the current window and shows carrier-confirmed delivery. Otherwise assign an exception code and owner.
Count changed jobs, passes, open exceptions and the age of the oldest one.

Job
1842
Current window
Today, 1 to 3
Message evidence
9:07 text states 1 to 3; delivered
Result
Pass
Job
1851
Current window
Tomorrow, 8 to 10
Message evidence
9:12 text states 8 to 10; queued
Result
Escalate
Job
1860
Current window
Today, 3 to 5
Message evidence
8:40 text states 1 to 3; delivered
Result
Stale window
Job
1873
Current window
Tomorrow, 10 to 12
Message evidence
No job-level record
Result
No record

Job	Current window	Message evidence	Result
1842	Today, 1 to 3	9:07 text states 1 to 3; delivered	Pass
1851	Tomorrow, 8 to 10	9:12 text states 8 to 10; queued	Escalate
1860	Today, 3 to 5	8:40 text states 1 to 3; delivered	Stale window
1873	Tomorrow, 10 to 12	No job-level record	No record

Route exceptions so the CSR is not calling everyone:

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 from the latest board window and review the second-change trigger.
Queued, sent with no final result, or unknown near arrival time	CSR	Escalate by a set cutoff, confirm contact details, use the approved fallback.
Wrong recipient or missing consent	CSR or data owner	Correct the record and choose a policy-safe contact method.
Access issue, call preference or high-risk property detail	CSR	Handle directly and leave a closure note for dispatch.

Every exception needs an owner, a due time and a closure note. 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, late statuses) because each needs a different fix. For texts, honor and track opt-outs. The FCC sets an outer limit of 10 business days to honor a covered revocation (FCC order). The Institute of Internal Auditors asks for documented information that is sufficient, reliable, relevant and useful (IIA). Here, proof has to fit the promise made to one customer.

The standard is plain: no changed job leaves the board without matching evidence or an assigned exception.

Audit 2: rebuild one delayed job

A removal was meant to wrap at 11:30. At noon the climbing crew is still on it, the chip truck is waiting on a disposal run, the next crew order makes no sense and a CSR is answering "are they still coming today?" Nobody was careless. This audit finds the first weak link in the workflow, not a person to blame.

Pick one job from the past two weeks that ran long. Pull timestamps from the board, crew notes, GPS, call log and text record, and mark anything that exists only in memory as unclear.

Moment
Planned finish
Record checked
Board
Moment
First warning
Record checked
Crew note or call
Moment
Overrun confirmed
Record checked
Board or dispatch note
Moment
Board changed
Record checked
Schedule history
Moment
Customer contact
Record checked
Text or call log
Moment
Actual arrival
Record checked
GPS or job record

Moment	Time	What changed	Who knew	Record checked	Customer told
Planned finish				Board
First warning				Crew note or call
Overrun confirmed				Board or dispatch note
Board changed				Schedule history
Customer contact				Text or call log
Actual arrival				GPS or job record

Blank cells are yours to fill in

Circle two gaps: the minutes between field knowledge and office knowledge, and the minutes between office knowledge and the customer notice. Mark the first moment a useful update could have gone out. That is not the moment the new ETA became perfect. A useful update says the crew is delayed, gives a revised window if one is real and names the next update time.

Then score five checks. Green means clear and timely evidence. Yellow means it worked through manual effort or luck. Red means the handoff broke.

Schedule accuracy. Was the duration based on job facts such as access, rigging, haul distance, disposal, permits, weather and equipment? Did complex removals have a buffer rule and a window that allowed normal variation? A narrow window can look precise on the board without making arrival more precise.
Trigger timing. Find the first reliable signal: a longer job, a moved finish, a delayed chip truck, an equipment issue, a board resequence. A warning signal and a confirmed ETA should trigger different actions. A notification setting cannot rescue a late signal. The crew should not manage customer messages from a driveway, but it needs a fast way to signal a changed plan.
Ownership. Assign a primary owner, backup and escalation role for each handoff. Dispatch owns the queue, the revised order and the routine delay notice. The CSR owns replies that need judgment. The crew supplies status facts and does not compose updates.
Exception path. If the customer cannot meet the revised window, confirm whether access can proceed, otherwise reschedule or escalate. If a text gets no reply, follow the call rule before the crew arrives. If the job moves again, replace the old window and state the next update time. For a safety stop, weather hold, breakdown or disposal delay, do not invent an ETA. Give the next update time.
Message history. When dispatch says "we already sent that," where is it? Check for the right job and customer, send time and channel, the exact wording, the sender, delivery result, replies visible to both dispatch and the CSR, the revised window and the next-update promise.

Start with the first red point in the timeline and fix that one. Test one change for a week, tracking notice lead time, inbound ETA calls, missed access, duplicate contacts and manual touches. Repeat the audit and keep the change only if timestamps show earlier notice, clear ownership and a record of what was said.

Audit 3: test any workflow against a live reroute before you standardize it

Run a storm reroute in a sandbox. A September storm can send the aerial-lift crew to a tree on a roof and push routine pruning later or into tomorrow. The workflow has to detect the first change, identify every affected job and update customers accurately without creating more calls. A TCIA storm-response review notes that storm work can involve unsafe conditions, disrupted cell or GPS service and equipment limits while crews still serve other customers (TCIA).

Separate the board from the text. The board is the operational truth, and the customer text is a consequence of a change on it. A standard reminder points back to the original appointment. ServiceTitan's reminders can be set for 24 hours before the appointment or a time the prior day, and same-day bookings made after that window get none (ServiceTitan). Its dispatch and arrival alerts are tied to a technician being assigned or en route (ServiceTitan). Reminder rules are not live schedule-change triggers.

Six tests. Mark a result "yes" only when you see it work against a real job and customer record. Score each pass, partial or fail.

Does a schedule change update the message plan? Pass: the board is the source of truth, and a moved, late or reassigned job is detected, the window is recalculated and a fresh text is sent if needed. Fail: the CSR watches the board and rewrites each update by hand. Do not assume a reschedule creates a new message. ServiceTitan notes that rescheduled bookings do not automatically generate another confirmation (ServiceTitan).
Who owns the on-the-way trigger? Pass: one named owner controls a governed status transition, after the route and crew are real. Fail: "the crew remembers to tap it." A climber or ground worker should not send proof-of-life texts while dealing with falls, struck-by hazards, chainsaws and energized lines (OSHA).
Can one job avoid sending several versions of the truth? Pass: the customer sees one current window per visit even when an estimator, a chip truck and a production crew are involved. Use a stable event key per job and notification type and save its state (pending, sent, delivered, failed) before another send. Retries and distributed events can duplicate messages, which is why AWS recommends idempotency keys and persistent state (AWS).
Are numbers and opt-outs handled before send time? Validate mobile numbers when collected, show the business name and sending number, keep consent and opt-out records on the customer and job, and offer a call or email path. The FCC says autodialed robotexts need prior consent, informational and commercial texts are treated differently, and recipients can opt out by reasonable means (FCC). A non-reply-capable text must disclose that limit and give another way to revoke consent (FCC order). Fail signs: "Reply STOP" on a number that cannot process it, replies into an unmanaged inbox, dispatch chasing failed texts during a reroute.
Can the office see exactly what the customer received? The CSR and dispatcher should open the job and see the same time-stamped history, not a separate inbox. Delivery failures are information, and ServiceTitan distinguishes messages that were sent but not delivered in activity history (ServiceTitan).
Do replies and access problems reach the right person? Every inbound message needs an owner and a deadline. Gate, pet and parking details go to the CSR before the crew departs. A reschedule request goes to the dispatcher or CSR before the window becomes misleading. An urgent same-day conflict goes to the service manager before setup begins. Automation should report the change and route the reply. A person decides whether to hold a crew or rebook.

In a demo, also test trigger coverage by mapping each trigger to the exact schedule field it watches: a booked job, a delayed job, a same-day and a future-date move, a canceled or held job excluded from routine sends, a crew reassignment when the date stays put, equipment-dependent work pushed behind hazard work, a queue refresh that skips unaffected customers, several edits that do not duplicate sends, exclusions by job type or contact, and a manual override. Then reroute: reassign the lift crew to an urgent hazard job, move pruning jobs later, change the order of two, then reroute again after the first update is queued. A workable setup lists every affected job (including the work left behind), bases each update on the revised queue, flags missing or failed contact data for the CSR and does not send an old update after the second reroute.

Result	Meaning	Next move
Pass	Trigger, message record and exception owner are clear	Pilot at normal volume
Partial	One manual handoff or edge case remains	Revise the rule and retest
Fail	Customer timing or ownership breaks	Reject the workflow for now

Treat a crew-side safety step, a stale window, missing opt-out controls and an unowned inbound exception as hard stops. Pilot delayed jobs, reassigned crews, multi-vehicle visits, duplicate events and failed deliveries before calling automated customer notifications standard. A text that arrives on time with the wrong plan is still the wrong text.

Audit 4: the record finance should require

A delayed route turns into a finance question the moment a customer asks for a credit. Hypothetical example: a long inspection pushes four later stops back. At 12:08 the expected arrival changes from 1:00 to 3:00 to 2:30 to 4:30. At 3:18 the customer calls to say nobody told them. A credit, rebook or manager review is a business decision, not an automatic penalty. "The system sent it" is a status update, not an audit trail.

Walk forward from the event that moved the appointment:

Original promise. Retain job, route, technician, customer and service-location IDs.
Trigger. Retain the source: a technician status, a dispatcher edit or a scheduling rule.
Rule and recipient checks. Record the rule and version that required notice, the approved number and channel, and consent and opt-out status. Appointment alerts can be informational, but promotional wording changes the analysis (CTIA).
Message and outcome. Preserve the exact text, template and values, with separate created, queued, sent, delivered, failed and unknown times, plus provider errors, retries and duplicate suppression.
Complaint and review. The CSR and finance need the same history, and a failed send should already show its owner and next action.

Control	Evidence to retain	Finance question
Job and schedule	IDs, original window and revisions	Does this notice belong to this visit, and what changed?
Trigger and recipient	Event source, rule and version, channel, consent basis, opt-out status	Why did it fire, and was the recipient approved?
Message and timing	Exact body, template values, timezone-aware status times	Did it state the right window before the dispute?
Delivery and conversation	Result, errors, retries, replies, staff follow-up	Did it fail or repeat, and who responded?
Access and export	Changes, overrides, retention history, an exportable record	Who altered it, and can finance retrieve it?

NIST's audit guidance calls for records that identify the event, time, location, source, outcome and identity, with protected records and defined retention (NIST SP 800-53). Preserve original content and time order, so a late update cannot overwrite an earlier status (NIST SP 800-171A).

Automation can detect an approved schedule shift, create an approved delay message, send it through an approved channel, flag a failed delivery to a named queue and prevent a duplicate. A person owns the complaint review, the credit decision under company policy, a reroute or rebook that needs judgment, a reply that needs full job context and any unresolved exception. Give failed delivery a named queue and owner, replies an escalation timer, and credits and appointment changes clear authority limits.

Finance's go or no-go test

Run one delayed route from schedule movement through complaint review before launch.

Can you prove the trigger that changed the window?
Can you prove the right person had access to act?
Can you retrieve the exact message and recipient?
Can you distinguish created, sent, delivered, failed and unknown?
Can you link a reply, complaint and override to the same job?
Does each failure and judgment-heavy outcome have a named owner?
Can you export the record, retain it under policy, and sample it after launch and after every rule change?

If any key event cannot be reconstructed, pause approval. Promised time savings do not close a control gap. A complete customer notification record does.

Where a tool fits

If manual relay from a shifting board into customer updates is the weak point, a schedule-driven text tool can carry the routine notices once schedule data and triggers are sound, leaving the CSR to review the log and handle replies. Queue Up sends a place-in-line text and estimated window at the start of the day, refreshes it as jobs are completed, added, rescheduled or delayed, and keeps a log the CSR can review. It is one-way and does not reroute or reschedule (supabase:tgl-cms.ref_platform.products, slug queue-up). It does not fix bad data, late signals or unclear ownership. Run your own live reroute in a sandbox before you rely on any tool, and score what you see.