Native dispatch alerts vs. an arrival-notification add-on: a scorecard
Score native ServiceTitan alerts and arrival-notification add-ons against the triggers, updates, message history, and office handoffs that matter.
The real cost of an unexpectedly early arrival
It is September. Maintenance calls are filling the board, the noon phone rush has started, and you have ServiceTitan open beside the call queue. A technician reaches a home 25 minutes early. The customer is still at school pickup. The technician waits, the customer calls annoyed, and now you are doing cleanup instead of taking the next booking.
That missed technician arrival is not only a timing problem. It is a communication failure. You may need to apologize, correct the ticket, find a new slot, and make sure the customer does not feel like the office forgot them.
The useful question is not, “Can this send a text?” It is: does your shop need one dispatch event, or communication that keeps up with a changing day?
Set the baseline: what each option is meant to do
Native ServiceTitan alert
A native ServiceTitan on-the-way notification is tied to dispatch. The first technician dispatched sends the notice; additional technicians do not while one is working, though a later dispatch can send another after all stop working. ServiceTitan documents those trigger rules.
Tracking requires native GPS, a verified service address, a tracking-URL template token, and a default outbound SMS number for texts. Review the setup requirements.
Arrival-notification add-on
An add-on may send queue-position, revised-window, or early-route warnings. Ask which event triggers each message and how often it updates; do not score an undefined “real-time” claim.
Keep the boundary clear
Neither notification handles replies, bad appointments, or complaints. ServiceTitan separates Dispatch Messaging from the Daily Dispatch Board’s Notifications view, so confirm that a CSR can access the needed customer-message record. Its Dispatch Board guidance describes the separate views.
Use this five-part scorecard
Rate each option from 0 to 2:
- 0: Missing
- 1: Partial, manual, or unclear
- 2: Clear fit, shown in a live test
If early arrivals are your costly failure point, double that row. If your real mess is customer replies that vanish between shifts, double the handoff row instead. Feature count is a poor referee when one weak point keeps creating callbacks.
| Criterion | Question to ask | Native alerts | Add-on | Evidence required |
|---|---|---|---|---|
| Trigger | What exact status or dispatch action sends the first message? What happens on re-dispatch? | Score the actual dispatch rule, including multi-tech behavior. | Score each defined event, not a broad “automation” claim. | Live demo or test job showing status and send time. |
| Day movement | Can it show queue position, an updated window, or an ahead-or-behind warning? How often does it update? | Score only what your current setup actually sends. | Score only documented refresh rules and thresholds. | Documentation plus a normal and delayed test job. |
| Early arrival | Does the customer get useful warning before the technician reaches the door? | Score the lead time from dispatch to arrival. | Score the warning event and its lead time. | Timestamped early-arrival test. |
| Message history | Can a CSR see content, sent time, delivery state if available, job or customer link, and opt-out activity? | Do not give credit for a board alert alone. | Confirm the record is visible to the CSR. | Sample log tied to a test job. |
| Office handoff | Where do replies go? Who owns failed sends, complaints, reschedules, and ticket notes? | Score the written office process, not the text template. | Same rule. An add-on does not inherit an owner by magic. | Reply test, failed-send test, and written handoff rule. |
Require a live demo, documentation, a sample message log, or a test job for every score.
Also check the promised arrival window. ServiceTitan can use business-hours, job-start-plus-duration, or no window, and operations settings can override customer-notification settings. Review the configuration. Do not promise a window the board cannot honor.
Read the result by workflow, not by feature count
Native-alert fit
Choose native notifications when the board is stable, dispatch habits are dependable, and early arrivals are infrequent. Verify templates, GPS, sending number, and re-dispatch behavior.
Add-on fit
Consider an added layer when the board moves often, windows are wide, or early arrivals create repeat friction. It must provide useful changing-day warnings and a CSR-visible record.
If Queue Up is on your shortlist, have its provider demonstrate triggers, refresh rules, on-the-way behavior, and the CSR-visible message record in your account. Do not score sales claims without verification.
Hybrid fit
Use native on-the-way text for the dispatch event and an added layer for queue or window updates when both solve distinct gaps. A CSR still owns complaints, replies, and booking changes.
Use the lowest score on your most expensive failure point as the tie-breaker.
Run a small test before changing the workflow
Run five to ten sample jobs through the normal workflow, using a safe customer record. Record status-change, send, delivery, and board-update times.
- Test first dispatch and an early arrival; define passing lead time.
- Test a delay, window change, two-tech re-dispatch, and technician reassignment.
- Test cancellation, bad address, and GPS off.
- Reply, send STOP, and simulate a failed send; confirm the owner, after-hours handling, and opt-out record.
- Have a CSR find the full trail in the ticket workflow and mark scorecard rows pass or fail.
The FCC says automated texts to wireless numbers require prior consent, and recipients can revoke consent by any reasonable means. See the FCC’s guidance. CTIA calls for consent and opt-out records and regular messaging-control testing. See its best practices.
Protect the office handoff
Put these operating rules beside the dispatch workflow:
- Name one owner for replies, failed deliveries, and opt-outs during business hours, plus an after-hours fallback.
- State clearly that automated messages do not have booking authority.
- Add a ticket note for every apology, correction, and promised next step after a missed early arrival.
- Set an escalation rule for an early arrival when the customer cannot be reached.
- Keep a fallback for a tracking, SMS, or integration failure: phone call, ticket note, and dispatcher notice.
- Record the trigger, template version, recipient, consent basis, send outcome, reply or opt-out, and exception owner.
This keeps the CSR involved where judgment and a real answer are needed.
Choose the gap you need to close
Score your current native behavior before reviewing add-ons. If one dispatch event reliably prevents the missed-arrival pattern, keep it simple. If customers need warning as the board changes, test the added layer against that exact need.
Choose the option with a clear record and a clean route back to a person. The customer remembers the knock at the door, not the name of the notification setting.