User Resources

Broadcast Alerts

Using Broadcast Alerts to Automate Dispatching

Skip to the diagrams


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.

Why doesn’t Beacon use GPS to find the Responder that’s closest?

If you’ve ever used Uber or Lyft, you know that these ride-sharing apps use GPS to find the driver that’s closest to you, so it makes sense that Beacon should he able to do that, too, right?

Not exactly.

There are several reasons why Beacon doesn’t use the GPS location of Responders to decide who’s closest:

  1. Not all Responders have smartphones and/or Internet connectivity all the time. If Beacon only relied on GPS locations, then Responders using Beacon via SMS would never get assigned to incidents because Beacon wouldn’t know their location
  2. Beacon doesn’t know your current location unless you have your phone turned on and the Beacon app open in the foreground when the alert is sent out. As soon as you turn the phone off, lock the phone screen, put the app in the background or swipe close it, Android and iOS no longer allow apps to track your location. As a result, once the Beacon mobile app is no longer open and in the foreground, Beacon only knows your last reported location, which may or may not be your current location.
  3. Uber and Lyft drivers do it to get paid, while many Beacon users are volunteers. This makes a big difference: When an Uber or Lyft driver gets assigned to a call, they usually take it because that’s how they make money. If you’re using Broadcast Alerts in Beacon, it’s very likely you’re working with volunteer Responders. And as we all know is the case with volunteers, they often get alerts for emergency incidents that they don’t respond to — even if they’re the closest person to the incident. So, telling the closest Responders to an incident that they’re needed, only to learn that they’re not going to respond, is just a huge waste of time.
  4. Hailing a taxi is a fairly simple transaction; when someone asks for a taxi, they only need one vehicle. Emergency dispatching is very different. For starters, not all emergencies are the same. If someone slips and falls, you may only need one ambulance to respond. But for a motor vehicle collision with multiple victims, you’ll likely need more resources. While it’s possible in theory to automate all of the different response combinations that exist, we’ll be very impressed to see it when it happens. Until then, we’ll rely on Dispatchers to figure out the type of resources they’ll need for each incident, and then let Responders decide if they can or can’t go.

The bottom line is: Don’t be fooled by how “easy” technological solutions look at face value. It may be easy to compare emergency response apps to pizza delivery apps, but in reality, it’s a lot more complicated than that. Anybody who wants to make that comparison has never worked in an emergency service.

  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 image above, 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.

Tags:
Related Articles
Previous
Dispatch Automation
Next
Preferred ETA