An arrival-window text is not a promise

The board moved. What did the customer hear?

At 7:10 a.m., yesterday’s two-hour removal is still open. Overnight wind changed the hazard, the crew needs another inspection, and the aerial lift is tied up. Pruning visits behind it start sliding.

That is normal tree service scheduling. After a storm, crews may need to check hanging limbs, leaning trees, raised soil, and other hazards before work continues. New York State guidance likewise calls for close inspection of damaged trees.

The customer with a 10–12 window needs warning before it becomes old news—not a firm arrival time.

An updated window is visibility, not certainty.

Myth: Every automated text makes a promise

A promise says, “We will be there at 11:15.” It ties your company to a fixed outcome.

An estimate says, “We expect to arrive between 11:00 and 1:00.” That can be useful, but it still needs room for the work ahead of it to change.

A live update says, “Your place in today’s schedule has moved.” It reports the current position of the job without pretending dispatch controls every minute in the field.

• Promise: a firm time or outcome.
• Estimate: a best current guess.
• Live update: a status based on where the schedule stands now.

That difference matters in tree work. Storm jobs can reveal line hazards, suspended limbs, and equipment needs during assessment. TCIA’s storm-work guidance describes these conditions. False precision is not reassuring when safety decisions remain.

Say: “Today’s schedule has changed. We’ll send an updated arrival window when your visit moves closer.” That is a status update, not an ETA promise.

Myth: A reminder and a live queue update do the same job

They do not. A reminder uses saved appointment details; a live queue update uses the changing schedule. When a removal runs long, the original details are history, not good guidance for the customer’s afternoon.

ServiceTitan’s own documentation separates these patterns: appointment reminders can be set relative to the appointment, while dispatch notifications trigger when a technician is dispatched. Those are different notification events, even if both happen to arrive as a text.

After storm cleanup, a pruning crew may need extra time because the hazard scope exceeds the estimate. A schedule-linked update gives the next customer a current view without suggesting the text rerouted a crew or solved the delay.

Myth: If a text goes out, someone must be handling replies

Sending a message and receiving a reply are separate jobs. This is where tree service dispatch communication gets messy fast.

If your text asks, “Does this still work for you?” customers will answer. Without an inbox owner, the customer may assume a change was handled when it was not.

Two-way texting needs an inbound setup and a person responsible for the next step. AWS documents that two-way SMS must be configured to receive incoming customer messages and send them to a processing destination. Delivery alone is not reply handling. ServiceTitan also treats reply-capable Chat to Text as a separate feature with its own inbox and permissions. Its notification documentation makes that split clear.

Before you send one-way customer texts, ask:

• Can the customer reply to this number?
• If yes, who monitors replies during business hours and after hours?
• Does that person get an alert?
• Who owns a request to change the visit?
• What is the CSR path for a question, cancellation, or exception?

If there is no monitored reply path, say so plainly in the message and give the customer a phone number or other clear route to the CSR team.

Myth: Schedule visibility is the same as rescheduling

A live status update reports movement. Rescheduling changes the appointment record. Those are not neighboring buttons.

A new slot may require a different crew, equipment, route, priority review, and customer consent. It may depend on whether a crane, lift, chip truck, or qualified crew is free. OSHA notes that storm-restoration tree work can require special training, changed-condition job briefings, PPE, aerial devices, and additional safeguards. Those requirements are not calendar decoration.

Keep the flow clean:

1. Detect board movement. An earlier job changes and the schedule shifts.
2. Notify the customer. Send an arrival window update.
3. Make the schedule decision separately. A CSR or dispatcher reviews any request and changes the appointment only after the team decides.

ServiceTitan notes that rescheduling does not automatically create a new booking confirmation—a reminder that notification workflows and appointment changes have separate rules. See the platform documentation.

Put Queue Up in the right-sized box

Do not fill in product boundaries from assumptions. Before you buy or configure Queue Up, have the vendor show the exact trigger, message timing, reply path, and whether the tool can change an appointment record. Treat each answer as a separate capability, not as a bundled promise.

The useful division of labor is still simple: a notification can carry status; a CSR or dispatcher handles the conversation and makes the appointment decision. That leaves people available for the judgment-heavy work—explaining a delay, handling an exception, and approving a real schedule change.

A five-question test for any notification tool

Use this in a vendor demo for any tree service communication software:

1. What triggers the message: a saved appointment or a changing schedule?
2. Does the wording make a promise, give an estimate, or report a status update?
3. Can customers reply, and who monitors that channel?
4. Does the tool show schedule movement, or does it change the appointment record?
5. When something goes sideways, does the CSR, dispatcher, or service manager own the exception?

Match the claim to the tool’s narrow job. Automated arrival updates are valuable when they tell the customer what changed, without pretending they made the hard call for you.