Dispatch Automation

About Dispatch Automation

(Skip to the diagrams)
It’s common to hear people compare the job of a dispatcher to that of a chess player, strategically moving pieces around a board to meet 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.
Dispatch Automation Settings - Beacon Emergency Dispatch Platform

Over the past few years, 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 ready to respond 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 Dispatch Automation settings do.

Understanding how Beacon automates dispatch 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 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 Dispatch Automation 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 all else fails, you can always go back to Chess Master mode in Beacon and just assign responders manually.

*Please note: We are, in no way, advocating for the complete automation of emergency dispatching. We understand very well that calling for a taxi and calling for a 5-car pileup are very different things. In fact, we don’t think that emergency dispatching will every be fully automated — but we definitely think a lot of it can be.

  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 crowdsourcing. It’s a default setting so can be changed 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 less than 10 minutes will be given preference over responders who say their ETA is greater than 10 minutes.
  3. Confirmation Window 1 — The least amount of time in minutes you are willing to wait for responders to reply to an alert from Beacon
  4. Confirmation Window 2 — The most amount of time in minutes you are willing to wait for responders to reply to an alert from Beacon
  5. Custom Incident Labels — Allows Managers to customize the Incident Class, Category and Type labels that appear on the Create Incident page – e.g, “Emergency – Trauma: Motor Vehicle Collision” (see Create Incidents).

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

Using the settings shown in the diagram above, here are three scenarios to describe how Dispatch Automation works 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.

Recommended Posts

Leave a Comment

Retype the CAPTCHA code from the image
Change the CAPTCHA codeSpeak the CAPTCHA code
 

Send us an email to share how you think Beacon can help your service.