My thoughts exactly. Obviously it must be the op-pickup-time to be a
12.55 second response, it does take humans a few more seconds to
comprehend what they are looking at before blindly dialing the customer.
I also wonder if the events are auto-assigned to the available operators
as they come in, which drastically reduces the "response" time but
doesn't mean the Operator has actually "responded", just his workstation
did. I believe larger monitoring centers with a lot of operators
typically auto-assign events. We don't, all operators see and hear the
pending alarms list as events hit. It's up to the operators to
get-next-available signal. We don't have enough operators to warrant
auto-assigning. If I auto-assigned events it looks like it would
happen, on average, within about 5 seconds (it takes on average less
then 4 seconds from the time the receiver spits out the signal until it
hits an operators screen).
Most often, if I set my alarm off at home, by the time I walk to the
keypad to shut it off and head back to the phone to call the monitoring
center, it's too late, my phone is ringing, they are already calling
me. That's an acceptable response time. As mentioned, there is always
the exception when all operators are busy. Our operators also try to
watch the pending alarms list while handling events, if a high-priority
event comes in (fire, medical, panic) they will typically stop calling
RP's on their current event and grab the high-priority event. It's
amazing how efficiently the system works with a few seasoned operators.
It doesn't matter how fast the system is if the operators are being lazy
or if the dealer puts a ton of special-instruction messages on the
account that the operator must read before they can actually respond to
it. We try to eliminate these types of messages and script it into the
event actions for the operator so they just
"follow-the-yellow-brick-road" as we say. Less interpretation is
required, hence, less mistakes.
>Dear Lucia,
>
[quoted text clipped - 24 lines]
>
>