What Is Bulldog Dispatch?
The pattern that keeps paging an on-call tech until somebody actually rolls.
Bulldog dispatch is the name for a persistent on-call escalation pattern: when a verified emergency call comes in, the system calls the on-call tech, retries if no answer, escalates to the next tech in the rotation, retries again, and keeps going until somebody accepts the job. The name is the disposition — stubborn, will not let go.
Why one-shot pages fail
The default after-hours dispatch pattern for most small shops is a single text or call to the on-call tech. It works most of the time and fails the times it matters most: the tech’s phone is on silent because their kid is sleeping in the next room, the battery died, the notification got buried, they did not hear it. A single missed page can mean a missed emergency, and a missed emergency at 2 AM is almost always a lost customer. Industry-standard incident response in the software world solved this problem fifteen years ago by treating paging as a retry loop. The trades have been slower to adopt the same pattern.
The anatomy of a working Bulldog loop
Three components define a working implementation:
- The verified emergency. Before paging, the agent must confirm with the caller that this is a true after-hours emergency, not a routine question. Paging the rotation on every call trains the techs to ignore the alerts.
- The on-call rotation. An ordered list of techs with phone numbers and acceptance preferences. Three techs is the standard for small shops — enough redundancy without spreading on-call too thin.
- The retry policy. The time window between attempts (typically 60–90 seconds), the number of cycles before falling back, and the fallback behavior. A common pattern is “3x3”: three techs, three retries each, then fall back to the contractor’s primary number.
The 3x3 pattern, walked through
| Time elapsed | What the system does |
|---|---|
| 0:00 | Verified emergency call ends; Bulldog loop starts. |
| 0:05 | Call tech A. Tech A has 90 seconds to accept. |
| 1:35 | No accept. Call tech B. |
| 3:05 | No accept. Call tech C. |
| 4:35 | No accept. Loop back to tech A. |
| ~13:00 | If no tech has accepted after three full rotations, fall back to the contractor’s primary number with a high-urgency call and SMS. |
Most accepted dispatches happen on the first or second attempt. The retry pattern exists for the cases where the first attempt fails — and in practice, those cases are the ones the contractor remembers, because they are the ones a single-shot system would have lost entirely.
Why “just send a text” is not dispatch
A common contractor setup is “the answering service texts the on-call tech.” That is not dispatch — it is notification. The tech still has to see the text, decide whether to accept, call the customer back, and confirm the dispatch. If any one of those steps fails, the dispatch fails silently. The contractor finds out in the morning when the customer calls back angry, or never finds out, and just notices the revenue is lower than it should be. The voicemail-abandonment problem — around 65% of callers will hang up rather than leave a message — has a sibling on the dispatch side: most one-shot notifications that go unread silently fail.
How to set one up for a small shop
If you want to build this yourself rather than buy it, the minimum viable Bulldog has four parts: a phone number (Twilio works), a small script that maintains the on-call rotation and retry state, a database to log attempts, and a way to confirm acceptance (a one-button SMS reply or a phone keypad accept). Most shops do not have the bandwidth to maintain custom infrastructure for this, which is why dispatchers like Night Watch ship it as a product.
How Night Watch ships it
Night Watch’s Bulldog feature is included in the pilot bundle or available as a $99 add-on to the base service. The default is the 3x3 pattern described above, configurable for shops with different rotation depths or retry preferences. Acceptance is a single button press; acceptance immediately closes the loop and produces a dispatch record on the tech’s phone. Every attempt and every acceptance is logged in the call memo. Pricing.
The takeaway
If your dispatch model depends on a single notification reaching a single phone, you are losing emergencies. The fix is not a better notification system; it is a retry loop. Whether you build it yourself or use a tool, the gap between “we paged the tech” and “a tech accepted the dispatch” is where most of the failed dispatches live.