A small HVAC office’s checklist for ServiceTitan schedule updates

The 9:15 delay that moves the whole afternoon

At 9:15 on a warm September morning, one long diagnostic moves three arrival windows. The CSR gets the calls, and the dispatcher rebuilds the afternoon one job at a time.

That is the buying problem: clear HVAC dispatch communication when the schedule changes, without making the CSR guess what a text said or automation the owner of a customer problem. Use this checklist to test the handoffs before you buy.

First, name the three kinds of customer update

Many ServiceTitan-connected tools put “notifications” on the feature list and leave it there. That word covers very different jobs. A booking confirmation is not proof that a customer will hear about a 90-minute diagnostic delay later that day.

ServiceTitan’s documented native customer notifications include booking confirmations, one appointment reminder, dispatched-technician notices, and surveys, with notices recorded in job history. Its reminder is limited to one per appointment, and the documentation does not describe native canceled-job or technician-arrived notices. Read the notification details before treating them as live schedule response.

That distinction keeps a demo honest. Ask which board event causes each message, not whether the vendor “does reminders.”

1. Trace the trigger back to the dispatch board

A useful ServiceTitan schedule update integration starts with a visible change on the board. Do not accept a screen of sample texts as evidence.

1. Ask the vendor to name the exact event that starts an update: a Dispatch Board edit, technician status change, or timed schedule check.
2. Move a 1–3 appointment to 3–5 after a diagnostic runs long. Ask when the new message is calculated and sent.
3. Move another job ahead and check whether affected customers get a fresh estimate. For cancellations, ask whether handling is supported and demonstrate it; do not assume it is.
4. Ask how the tool avoids duplicate or stale texts when the board changes twice in ten minutes.
5. Ask whether the dispatcher can pause, suppress, or correct a message for a sensitive job.

Red flag: “It updates in real time” is not an answer. Get the refresh timing, trigger, and delayed-sync behavior.

If the product relies on ServiceTitan arrival windows, check the setup. Custom windows require Technical Support configuration and administrator setup; once configured, every job receives one. This is separate from internal Dispatch Board timing.

2. Check which jobs and customers qualify

Qualification rules matter as much as the trigger.

Job rules

• Identify qualifying business units, job types, campaigns, tags, and appointment states.
• Test tune-ups, urgent no-cool calls, first and last calls, and jobs with multiple appointments.
• Confirm what happens to a job added at noon and who can exclude a job that needs a human conversation.

Customer rules

• Check missing or invalid mobile numbers, consent and opt-out status, language, time zone, and quiet hours.
• Confirm that the CSR can see why a customer was skipped.

CTIA guidance calls for consent records and honoring opt-outs, including ordinary-language requests. Review the messaging guidance with whoever owns your texting policy.

3. Inspect the message, timing, and customer record

Read the actual HVAC customer text messages in the demo. A schedule-responsive message should say what changed, give the current estimate, and avoid treating an estimate as a guarantee.

Check whether it states queue position or a revised window; limits frequency; and lets a CSR see the sent time, number, content, and delivery state. Confirm dispatchers, CSRs, and managers can access the record and export it for complaints.

Show me in the demo

Send an update, then have a CSR find the outbound SMS log during a mock call. If the record lives in a screen nobody checks, it will not settle the ETA call.

ServiceTitan records its own customer notifications in job history, so compare that record with the connected tool’s record. The native documentation describes the job-history entry.

4. Assign ownership when automation stops

Texts fail, mobile numbers are missing, integrations lag, and carrier filtering happens. Name an owner for each.

ServiceTitan says unregistered SMS/MMS can be blocked, and toll-free messages must be Verified before they can send. Its registration guide lays out the approval prerequisites.

The recovery path should create one visible task assigned to one role, not an unassigned secondary queue.

5. Treat inbound replies as a separate workflow

A text sent is not a conversation handled.

Before launch, establish whether notices are one-way or enter a monitored inbox; who covers that inbox and at what response time; how STOP, wrong-number, reschedule, and cancellation replies are handled; whether replies change the board; and what customers should do to change an appointment.

Never imply that “Reply to reschedule” works unless it reaches a staffed workflow.

6. Use one demo scenario and score the evidence

Run one afternoon scenario: a diagnostic runs long and shifts three jobs. Demonstrate the board event, qualifying and excluded jobs, messages, CSR record, and exception path.

For anything “configurable,” identify who configures it, the timing, CSR training, and the post-launch owner.

Where Queue Up may fit—and where the office still leads

Queue Up may fit a shop that wants one-way ServiceTitan proactive customer updates tied to the changing daily flow. Its current product material describes a start-of-day queue-position and estimated-window text, updates when jobs are completed, added, rescheduled, or delayed, significant ahead-or-behind notices, and an on-the-way text. It also gives the CSR a visible outbound log. Those are the specific Queue Up behaviors to test in your own demo.

Its limits are just as important. Queue Up says it does not handle inbound replies, confirmations or access issues, calls, rerouting, rescheduling, or jobs not scheduled that day. The office still owns those handoffs. Its published material describes customers with a scheduled job that day; confirm any needed job-type, trade, or setup rules directly rather than assuming them.

That is a sensible boundary. The goal is fewer status-chase calls, not a system that quietly takes ownership of a customer who needs a real person. A good choice leaves the CSR with the record, the dispatcher with control of the board, and the customer with an honest next step.