Dispatcher Resources

Using Broadcast Alerts to Automate Dispatching

Emergency Dispatchers are often compared to chess players, strategically moving pieces around to respond to threats. While accurate in spirit, there are a couple problems with this approach:

1. It makes the Dispatcher solely responsible for managing the movements of every Responder, all the time. This is time-consuming.
2. Because it’s time-consuming, it means the more Responders you have, the more Dispatchers you need to manage them. This is resource-intensive.

Over the past decade, we’ve all seen how effective ride-sharing technologies have been in reducing the need for traditional taxi dispatchers, so it’s kind of hard not to ask the same questions about emergency dispatching*:

• What if there was a way to automate dispatch?
• What if there was a way to have as many Responders as you wanted without having to drastically increase the number of Dispatchers at the same time?
• What if there was a way to assign certain Responders, while crowdsourcing the rest to fill in the gaps when needed?

This is what Beacon’s Broadcast Alert settings do.

Understanding how Beacon automates dispatch through Broadcast Alerts can help you to reduce response times, improve efficiency in resource allocation, and scale your coverage area as needed. For example, if you send an alert to 50 Responders, it’s very likely you don’t want all 50 Responders showing up at the scene, so Beacon has to be able to decide which Responders get assigned and which don’t. Beacon also has to be able to make these assignment decisions at random times because Responders may reply to alerts at different times.

Included here below are brief introductions to the Broadcast Alert settings. For some people, the settings may make sense right away. But for those who need more explanation, be sure to click on each of the setting links to get a deeper understanding and see how it all works in practice through easy-to-follow examples and diagrams.

And if automation isn’t what you need, you can always go back to Chess Master mode in Beacon and simply assign Responders manually.

---

1. Maximum Number of Responders (FRs) per Incident — This number puts a default limit on how many Responders can be assigned to each incident when sending Broadcast Alerts. It’s only a default setting so can be changed for each incident through the Create New Incident panel on the dashboard
2. Preferred ETA (Estimated Time of Arrival) — This setting determines which Responders get preference when Beacon is assigning Responders to a new incident. If the Preferred ETA is 10 minutes, all Responders who say they can be on-scene in 10 minutes or less will be given preference over Responders who say their ETA is greater than 10 minutes.
3. Confirmation Window 1 — The minimum amount of time in minutes you are willing to wait for responders to reply to an alert from Beacon
4. Confirmation Window 2 — The maximum amount of time in minutes you are willing to wait for responders to reply to an alert from Beacon
5. Default Dispatch Type — Select which Dispatch Type should be used as the default type when creating new incidents

See below for some quick scenarios demonstrating how these settings work together.

---

Using the settings shown in the diagram below, here are three scenarios to describe how Broadcast Alerts work in practice:

• Settings:
  • Preferred ETA = 10 minutes
  • Confirmation Window 1 = 3 minutes
  • Confirmation Window 2 = 5 minutes
• Scenario A:
  • 12:00pm – The Incident Alert is sent to all Available Responders
  • 12:02pm – Jimmy replies with an ETA of 3 minutes (less than the Preferred ETA of 10 minutes)
  • 12:02pm – Beacon replies to Jimmy saying “Proceed to Location. Please confirm arrival on-scene.”
• Scenario B:
  • 1:00pm – The Incident Alert is sent to all Available Responders
  • 1:01pm – Jimmy replies with an ETA of 11 minutes (greater than the Preferred ETA of 10 minutes)
  • 1:01pm – Beacon replies to Jimmy saying “standby. Please wait 4 minutes”
  • 1:03pm – Confirmation Window1 closes and Beacon replies to Jimmy with its decision: Either “Proceed to Location” or “You’re not needed for this incident“
•  Scenario C:
  • 2:00pm – The Incident Alert is sent to all Responders
  • 2:04pm – Julie replies with an ETA of 15 minutes (more than the Preferred ETA of 10 minutes)
  • 2:04pm – Beacon replies to Julie saying “standby. Please wait 2 minutes”
  • 2:05pm – Confirmation Window2 closes and Beacon replies to Julie with its decision: Either “Proceed to Location” or “You’re not needed for this incident“

Automation for Multiple Responders — Here’s an example of how Dispatch Automation works when multiple responders reply to the same Incident Alert. Please note how Responder 3 is rejected. This has happened because the Maximum Number of Responders (3) is met.