ServiceTitan arrival notifications: native alerts, an add-on, or two-way texting

Short answer

Use ServiceTitan's native notifications when events tell the truth: your board is stable, technicians use the status actions consistently and early arrivals are rare. Add a queue-aware layer when the queue tells the truth, meaning the day's order changes enough that a booked window goes stale. Add two-way messaging only when a customer's reply can change the job, and only after someone owns the inbox. In every case, a CSR owns anything that needs a decision, an apology or a new promise.

Three setups that all "send texts"

Trigger
Native ServiceTitan alerts
Configured booking, reminder, dispatch and arrival events
Queue-aware notification layer
Movement in the day's queue
Two-way messaging workflow
A staff send or a customer reply
Refresh after a long job or resequence
Native ServiceTitan alerts
Conditional: verify each alert's re-trigger rule
Queue-aware notification layer
Reliable when the tool watches queue changes
Two-way messaging workflow
Conditional: staff may need to send the update
Audit trail
Native ServiceTitan alerts
Conditional: a manually resent booking confirmation shows in the audit trail, verify the rest
Queue-aware notification layer
Reliable if the layer keeps a shared message log
Two-way messaging workflow
Reliable only if the inbox is tied to the job
Customer replies
Native ServiceTitan alerts
Poor fit unless a separate two-way feature is on and owned
Queue-aware notification layer
Poor fit for a one-way layer
Two-way messaging workflow
Reliable when a named person monitors replies
Operating load
Native ServiceTitan alerts
Low when existing events match the work
Queue-aware notification layer
Low for routine updates, limited to its scope
Two-way messaging workflow
Higher: inbox coverage and response rules are real work

	Native ServiceTitan alerts	Queue-aware notification layer	Two-way messaging workflow
Trigger	Configured booking, reminder, dispatch and arrival events	Movement in the day's queue	A staff send or a customer reply
Refresh after a long job or resequence	Conditional: verify each alert's re-trigger rule	Reliable when the tool watches queue changes	Conditional: staff may need to send the update
Audit trail	Conditional: a manually resent booking confirmation shows in the audit trail, verify the rest	Reliable if the layer keeps a shared message log	Reliable only if the inbox is tied to the job
Customer replies	Poor fit unless a separate two-way feature is on and owned	Poor fit for a one-way layer	Reliable when a named person monitors replies
Operating load	Low when existing events match the work	Low for routine updates, limited to its scope	Higher: inbox coverage and response rules are real work

"Reliable" means the setup fits the condition without a routine manual rescue. "Conditional" means it can fit, but configuration or field behavior decides. "Poor fit" means it does not address the need on its own. This is not a product ranking.

What native ServiceTitan notifications do

ServiceTitan treats confirmation, reminder, dispatch and arrival as separate triggers. Booking confirmation sends when an appointment is first scheduled, reminders are timed before it, dispatch is the on-the-way trigger and arrival follows the technician's Arrive action (ServiceTitan).

Three limits to verify before you rely on them:

A booking confirmation does not fire again after a reschedule. It can be resent manually from the job record, and that send appears in the audit trail (ServiceTitan).
Reminders can be set for 24 hours before the appointment or a specified time the prior day, and same-day bookings made after that window do not get one (ServiceTitan).
The dispatch notice is tied to the first technician dispatched. Extra technicians do not send another while one is working, though a later dispatch after all stop can send again. Tracking needs native GPS, a verified service address, a tracking-URL token in the template and a default outbound SMS number (ServiceTitan).

ServiceTitan can also set the promised arrival window from business hours, job start plus duration, or no window, and operations settings can override customer-notification settings (ServiceTitan). Do not promise a window the board cannot honor.

Ask your ServiceTitan admin which job types and business units are excluded, whether multi-technician limits apply, what starts each notice and exactly what happens after a reschedule.

Best fit: pruning-heavy or maintenance days with predictable job length, customers who mainly need confirmation, reminder and on-the-way notices, and technicians who already use the status actions.

Watch for: a customer window that goes stale when crew order changes but no native trigger fires, an on-the-way text that depends on an action nobody owns during a busy handoff, and tracking promised as universal when GPS, the token and the verified address decide whether a map appears.

When a queue-aware layer fits

A layer fits when the need is informational updates tied to the live order of the day. That is common in removal-heavy tree work, where one job's duration, equipment or access problem pushes several later customers. The question is not "did dispatch happen?" It is "did this customer's place in line change enough that they need a new expectation?"

Queue Up is one example of this model. It texts each customer with a job on the board their place in line and an estimated window at the start of the day, refreshes the window as jobs are completed, added, rescheduled or delayed, alerts affected customers when a technician runs well ahead or behind, and sends an on-the-way text. The CSR can review the log without sending routine updates. It is one-way: it does not handle replies, calls, rerouting or rescheduling, and it does not cover jobs that were not on the day's schedule at the morning send (supabase:tgl-cms.ref_platform.products, slug queue-up).

That limit is healthy when it matches the job. Give customers who call or text another number a path: who takes the message, where it is recorded, and who changes the plan.

When two-way messaging earns the extra work

Two-way messaging pays off when a reply can decide whether the work proceeds. In tree work that is common: a missing gate code, a loose dog, vehicles still in the drop zone, a neighbor objecting to access, or a customer who must approve added scope. These are job inputs, not courtesy replies.

ServiceTitan treats two-way SMS as a separate Chat capability with its own requirements, number and permissions. Replies appear in the Chat inbox only when that feature is enabled and tested, and automated notifications appear in a chat log only after a manual thread exists (ServiceTitan). Do not assume every alert created a staffed conversation.

Before you invite replies, name an inbox owner and a response-time rule, add backup coverage for storm volume and keep the history tied to the customer or job. Otherwise two-way messaging becomes a second system of record that the CSR has to clean up.

Choose by operating condition

Operating condition	Start with	Rule to keep it clean
Stable pruning or maintenance day, few sequence changes	Native notifications	Verify trigger settings and reschedule behavior
Removal-heavy day, equipment dependencies, frequent resequencing	Queue-aware layer	Let the moving queue refresh expectations while dispatch stays the source of truth
Storm response, uncertain access, approvals, frequent exceptions	Two-way workflow	Assign inbox ownership and coverage before inviting replies

A hybrid can be right: native alerts for booking and reminders, a layer for the changing day, two-way for the smaller set of true exceptions. Every hybrid needs rules. Decide the source of truth, which tool sends which message, and how the customer avoids getting two conflicting windows.

Score the options with a five-part scorecard

Rate each option from 0 to 2: 0 missing, 1 partial, manual or unclear, 2 a clear fit shown in a live test. Require a demo, documentation, a sample log or a test job for every score. If early arrivals are your costly failure, double that row. If replies vanishing between shifts is the real mess, double the handoff row.

Criterion	Question	Evidence required
Trigger	What exact status or dispatch action sends the first message, and what happens on re-dispatch?	Test job showing status and send time
Day movement	Can it show queue position, an updated window or an ahead-or-behind warning, and how often does it refresh?	Documentation plus a normal and a delayed test job
Early arrival	Does the customer get useful warning before the technician reaches the door?	A timestamped early-arrival test
Message history	Can a CSR see content, send time, delivery state, the job link and opt-out activity?	A sample log tied to a test job
Office handoff	Where do replies go, and who owns failed sends, complaints and reschedules?	Reply test, failed-send test and a written handoff rule

Use the lowest score on your most expensive failure point as the tie-breaker. A native alert scored only on what your current setup actually sends gets no credit for a board alert alone, and an add-on does not inherit an owner by magic.

Test one bad morning before you commit

Use a safe customer record and run five to ten sample jobs.

Schedule a removal that runs long before the first crew handoff.
Reassign a crew, chipper or lift to cover the delay, and move the next customer's window without a CSR relaying it by hand.
Confirm the customer gets one clear expectation, not the original window plus a contradictory new one.
Fire the on-the-way message at the moment your process truly considers the crew on the way.
Test a delay, a window change, a two-technician re-dispatch, a reassignment, a cancellation, a bad address and GPS turned off.
Reply, send STOP and simulate a failed send. Confirm the owner, the after-hours handling and the opt-out record.
Have the CSR find the full trail in the ticket workflow without searching personal phones or side notes.

The setup passes when it leaves the customer with one expectation, gives one person ownership of exceptions and adds no ritual the crew cannot keep up.

Where the CSR steps in: fact, choice, trust

Run every message through three questions.

Fact. Is this a schedule detail the office already knows to be true and needs no decision? "Your appointment is scheduled for 1:00 to 3:00" is a fact, and so is a final on-the-way text based on real field movement. Automate it.
Choice. Is the customer asking to change timing, routing, price, access or scope? "Can you come after 4?" is not a status update. A CSR checks with dispatch before agreeing.
Trust. Is the customer upset, confused or reacting to a failed promise? "Your technician came while I was gone" needs a person, even if the original notice was accurate.

If it is fact-only, automation can send it. If choice or trust enters, a CSR owns it. ACCA recommends spotting delays from field updates, explaining them, then asking whether the customer wants the later appointment or a reschedule (ACCA).

The exception workflow inside ServiceTitan

Check what was sent. Review message history, send time, the arrival window and schedule changes.
Get the field fact. Ask dispatch whether the technician arrived, left, is delayed or can return. Do not promise a new window yet.
Call with ownership. Explain what happened, apologize when needed and offer only dispatch-confirmed options.
Record the next step in the customer record: the contact, access limits, the apology and the new commitment.
Flag the exception with a named owner and due time.
Close the loop. Update the customer and the job, and make sure dispatch sees the plan. Arrival-window behavior varies by configuration, so confirm your setting (ServiceTitan).

Minimum fields on the job record: the message sent and its time, the original and current window, the confirmed field fact and the customer's access or callback preference, any apology or recovery offered, and the agreed next step with an owner and due time. A reply inbox is not active ownership. It is only a place where a message can wait.

ServiceTitan separates Dispatch Messaging from the Daily Dispatch Board's Notifications view, so confirm that a CSR can reach the customer-message record they need (ServiceTitan).

Consent and records

The FCC says automated texts to wireless numbers need prior consent and that recipients can revoke it by any reasonable means (FCC). CTIA calls for purpose-specific consent, consent and opt-out records and regular testing of messaging controls (CTIA). Write the owner for replies, failed deliveries and opt-outs, with an after-hours fallback, and keep a phone-call fallback for any tracking, SMS or integration failure. Log the trigger, template version, recipient, consent basis, send outcome and any reply or opt-out.

The customer remembers the knock at the door, not the name of the notification setting. Score your native behavior first. If one dispatch event reliably prevents the missed arrivals you have, keep it simple. If customers need warning as the board changes, test the added layer against that exact need.