Will arrival notifications hold up when the dispatch board changes?

The real test starts when the board moves

A removal runs long. The chip truck is tied up, the afternoon crew gets reassigned, and three customers still expect someone at their property today. This is when tree service arrival notifications either earn their keep or become one more thing for the CSR to explain.

Customers do not get upset because they received too few texts. They get upset because a text promised a window that is no longer real. The goal is fewer routine “where are you?” calls without giving a crew another phone task while it is driving, setting up, or working around hazards.

Audit standard: A notification workflow passes only if it keeps the customer’s timing credible after the dispatch board changes.

Test 1: Does a schedule change update the message plan?

Pass: The dispatch board is the source of truth. When a job moves, runs late, or changes crews, the workflow detects that event, recalculates the arrival window, and decides whether a fresh customer arrival text message is needed.

Fail: The CSR watches the board, spots every change, and rewrites each update by hand. That is not automation. That is a fragile relay race.

Inspect these items:

• The event rule for a moved job, a delayed job, and a reassigned crew.
• How soon the revised window appears after a dispatch board update.
• What happens when the system cannot calculate a credible window.
• Whether a customer gets a new promise only after the new plan is settled.

Do not assume a reschedule creates a new message. For example, ServiceTitan notes that rescheduled bookings do not automatically generate another confirmation. Test the changed plan, not the happy-path schedule.

Test 2: Who owns the on-the-way trigger?

Pass: One named owner controls a governed status transition. It may be the dispatcher changing a job to dispatched, or the system acting on a defined dispatch event. The trigger should happen after the route and crew assignment are real, not when someone hopes they will be.

Fail: “The crew remembers to tap it” is the whole design. A climber, ground worker, or driver should not need to send proof-of-life texts while traveling, staging equipment, or dealing with tree-work hazards. OSHA identifies serious hazards in tree care, including falls, struck-by events, chainsaws, machinery, and energized lines. Keep attention on the work, not the notification button. Those hazards are well documented in OSHA’s tree-care guidance.

Use this compact ownership check:

Status-based triggers are common, but they need governance. ServiceTitan, for instance, ties dispatch and arrival notices to specific technician status actions. Your tree service dispatch standardization should be just as clear.

Test 3: Can one job avoid sending several versions of the truth?

Pass: A customer sees one current arrival window for one visit, even when several people and vehicles are involved. The workflow suppresses repeats caused by reassignment, status retries, or a second crew member.

Fail: The homeowner gets “we’re on the way” from the estimator, then the aerial lift, then the production crew. Texts are easy. Trustworthy timing is the hard part.

Test these tree-service edge cases:

• An estimator arrives before the production crew.
• The chip truck or aerial lift is dispatched separately.
• A crew is reassigned after the first dispatch event.

Use a stable event key for each job and notification type. Save its state as pending, sent, delivered, or failed before allowing another send. This is not fussy engineering for its own sake: retries and distributed events can duplicate messages, which is why AWS recommends idempotency keys, persistent state, and duplicate audits.

Test 4: Are phone numbers and opt-outs handled before send time?

Pass: The office has a valid mobile number, the customer’s preference record, the sending identity, and a non-SMS fallback before the job reaches dispatch. The workflow also handles landlines, shared household numbers, wrong numbers, and numbers that have changed hands.

Fail: The crew or CSR has to repair contact data while a truck is already rolling.

Operating checks

• Validate the number as mobile when it is collected or confirmed.
• Show the business name and sending number clearly.
• Keep the consent and opt-out record attached to the customer and job.
• Process phone-number deactivation data on a regular schedule.
• Offer a call or email path when text messages are not wanted or cannot be delivered.

Compliance notes

Do not label every service update “transactional” and move on. The FCC says autodialed robotexts require prior consent except in emergencies; its consumer guidance distinguishes informational texts from commercial texts, and says recipients can opt out by reasonable means. Read the FCC’s guidance here. Promotional wording can change the analysis.

CTIA’s industry guidance also calls for sender identity, opt-out and customer-care information, opt-in/out records, and recognition of STOP-like ordinary-language opt-outs. Its messaging principles are useful operating guidance, not legal advice. Confirm the rules that apply to your messages, state, carrier, and provider.

Test 5: Can the office see exactly what the customer received?

Pass: The CSR and dispatcher can open the job and see the same time-stamped message history. They can answer a customer without guessing what the system said an hour ago.

Fail: The message sits in a separate inbox, the dispatch record has no link to it, or “delivered” gets treated as proof the customer read it.

Your dispatch communication log needs these fields:

• Job and customer record
• Event that caused the message
• Recipient number and sending number
• Message content and arrival window
• Scheduled, changed, sent, delivered, and failed timestamps
• Suppression, opt-out, or delivery-failure reason

A delivery failure is useful information, not a minor cosmetic error. ServiceTitan’s documentation, for example, distinguishes messages that were sent but not delivered in activity history. That distinction is worth preserving in your own record.

Test 6: Do replies and access problems reach the right person?

Pass: Every inbound message has an owner and a deadline. A note about a locked gate, loose dog, blocked driveway, parking limit, or new timing request reaches the office person who can act before the crew arrives.

Fail: The reply is visible somewhere, but nobody owns it. That is just an unanswered digital sticky note.

Automation should report the change and route the reply. A person should decide whether to hold a crew, alter access instructions, or rebook work. That boundary is the heart of good dispatch exception handling.

Score the workflow before you standardize it

Score each test as pass, partial, or fail. A partial means the normal day works, but the change case depends on memory, a side inbox, or a heroic CSR.

Treat these as hard stops: a crew-side safety step, a stale arrival window, missing opt-out controls, or an unowned inbound exception. Pilot delayed jobs, reassigned crews, multi-vehicle visits, duplicate events, and failed deliveries before calling automated customer notifications standard.

Watch four measures: fewer routine location calls, fewer manual sends, accurate arrival windows, and faster exception response. Those are signs that the CSR has time back for bookings and the exceptions that need judgment.

Product aside: Queue Up

Where the gap is manual CSR translation from a shifting board into customer updates, Queue Up may be positioned internally as a tool to evaluate for that workflow. Confirm its specific notification, scheduling, and exception-handling capabilities with approved product material before making operational commitments. The point is to keep routine updates from consuming the person needed for the weird, important cases.

Standardize only after the scorecard passes. If it does not, revise the workflow. A text that arrives on time with the wrong plan is still the wrong text.