Broadcast Alert Settings: Confirmation Windows

About Confirmation Windows

The Confirm Window 1 & 2 settings serve two purposes:

  1. They set Minimum and Maximum time limits on how long Beacon will wait to receive replies to Incident Alerts from Responders
  2. They ensure that Responders who are close to an incident aren’t passed over simply because Responders who are farther away replied to the Incident Alert more quickly

When Dispatchers send out Broadcast Alerts, Responders are asked to self-report their ETA to the Incident Location. But the reality is, you can only wait for so long. This is where Confirmation Windows 1 & 2 come into play.

Using the Settings shown here, fwe’ve included three examples that demonstrate how the Confirmation Windows work in conjunction with the Preferred ETA setting.

(Please note: The Confirmation Window 1 & 2 settings work the same whether you’re responding through the Beacon Mobile App or via SMS.)

Example 1

Confirmation Window 1 = 3 mins
Responder ETA > Preferred ETA

In this scenario, Confirmation Window 1 opens at 12:00, when the Broadcast Alert is sent out, and will stay open for 3 minutes.

The Responder shown here replies to the Broadcast Alert at 12:01, with an ETA that’s greater than the Preferred ETA of 10 minutes, so Beacon asks the Responder to Please standby: 2 minutes.

At 12:03, Confirmation Window 1 closes, so Beacon has to decide if it’s going to assign the Responders or tell them they’re not needed.

Though the Responder can’t see what happened, Beacon tells them they’re not needed — at 12:02 Beacon found another Responder with an ETA of 3 minutes, reaching the maximum number of Responders that Beacon can assign itself to this incident.

Example 2

Confirmation Window 2 = 5 mins
Responder ETA > Preferred ETA

In this scenario, Confirmation Window 1 opens at 12:00, when the Broadcast Alert is sent out, and but then closes 3 minutes later at 12:03. If Confirmation Window 1 closes and Beacon hasn’t met the Assigned Responders maximum limit, Confirmation Window 2 opens.

The Responder shown here replies to the Broadcast Alert at 12:04, with an ETA that’s greater than the Preferred ETA of 10 minutes, so Beacon asks the Responder to Please standby: 1 minutes.

At 12:05, Confirmation Window 2 closes (5 minutes after the Broadcast Alert was first sent out), so Beacon has to make a final decision if it’s going to assign the Responders or tell them they’re not needed.

In this scenario, Beacon tells the Responder to “Confirm En Route” because there were no other Responders with a shorter ETA, and when Confirmation Window 2 closes, Beacon will no longer accept replies.

Example 3

This diagram demonstrates multiple Responders replying to the same incident at different times:

FAQ: Why does the incident stay open after I complete it?

Incidents can be closed in three ways:

  1. All Assigned Responders complete the incident
  2. The Dispatcher cancels the incident manually
  3. Confirmation Window 2 closes and no other Responders are assigned

If you’re using Beacon to run simulations, it’s very likely you’re going to move through the incident very quickly — faster than in real life. This will result in you completing the incident before the Confirmation Windows close, so the incident will stay open until the Confirmation Windows close.

 

To read more Frequently Asked Questions, visit our FAQ page

Summary

In short, the Confirmation Windows, in combination with the Preferred ETA, make sure that:

  1. The closest Responders are always assigned
  2. The farthest Responders are only assigned when there isn’t enough help close by
  3. And neither of them are prematurely dismissed

If you think this could all be done more easily with GPS, we’d argue it’s not as simple as it looks — crowdsourcing the nearest taxi driver is actually a lot easier than crowdsourcing emergency responders (and, as a rule of thumb, it’s not good for our profession to make that comparison).

Recent Posts

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