Warning: Surety professional monitoring services may not respond to emergencies

Support
1

This morning we had a security alarm trigger and I am very dissatisfied with the monitoring system response. Full timeline below:

  1. Alarm triggered
  2. Alarm was not dismissed by user within pre-set 20 second window
  3. Becklar monitoring center (contracted by Surety) said that they have their own 20 second window that starts after the user window to be notified of the alarm (that brings us to 40 seconds post alarm triggering)
  4. Becklar monitoring center said they received the alarm at 8:15:49 (after the 20 sec user input window) and it was dismissed at 8:16:12 (43 seconds post alarm trigger), which should have still triggered a response from the monitoring station.
  5. I was told by the first Becklar service rep that they decided not to call because the alarm was dismissed, even though it was outside the dismissal window, and that they wouldn’t call us because there was no landline phone on file (despite us having multiple cell phone numbers and emails on file). What’s the point of having a duress password if the monitoring service will not action an alarm that is dismissed late?
  6. Then a Becklar supervisor said the alarm wasn’t even sent to one of their people for action because “they were probably busy”. She also confirmed that no call would be made unless there was a landline number on file.
  7. So apparently there are multiple hidden policies that resulted in a material failure of the service that we’ve been paying for for years and puts lives at risk. Completely unacceptable.

Additionally, their monitoring station response times need to improve. A prior fire alarm did not trigger a phone call for >6 minutes and they indicated “they were having trouble with dispatching fire”, so I might want to call for fire services myself as well. Ridiculous, unprofessional, and untrustworthy. Don’t put your life in these hands.

2

Thank you for reaching out!

Apologies for the issues. There are some things that Becklar mentioned that are not accurate for our accounts in particular.

The delay on their side that they’re referring to is caused by using the Alarm Response Messenger feature. The delay for that is 90 seconds for accounts not using two-way voice and 30 seconds for accounts using two-way voice. Additionally, by default, an abort for a burglary alarm is accepted at any time while it is still being handled by operators. The reason an operator wasn’t assigned is due to the abort coming in during the chat delay. If a premise number is on file, operators may make a courtesy call to the premise number after an abort, but it will be disregarded if there is no answer.

I’ve applied a change to your account to ensure that alarms are no longer disregarded per abort. I’ve also sent commands to update your panel’s dialer delay to 20 seconds per the email you sent. I’ll follow up with you there regarding additional changes.

For the prior fire alarm, a request was previously made to add special instructions for operators to dispatch immediately on a fire alarm prior to notifying contacts. For the incident on 8/9, the 6+ minute delay was due to operators dispatching the fire department first. The operators began the call to the fire department 18 seconds after the alarm signal was received. The call to the next contact was placed immediately after the call to the fire department was completed. There weren’t any issues during the call to the fire department. The reason it took a little longer than usual for dispatch to be completed is due to the operator needing to wait in the queue for a fire dispatcher to become available, which can happen if the fire department is experiencing a high volume of emergency calls.

There are a lot of errors in what the supervisor told you regarding the procedures. Procedures are programmed in to walk operators through handling the alarm step-by-step and have them make selections as they continue handling the alarm. It isn’t easy to read the raw programming data without training, due to many jumps in the steps, automated checks for various conditions, and multiple possible selections operators make when processing an alarm. That supervisor should’ve advised you to contact us instead, as we have worked directly with Becklar to be able to read the programming correctly, and we have records of special requests for changes.

With such egregious errors in the details provided to you, we have reached out to our Becklar rep to investigate further and get complaints filed against the operators involved. We will also be working with them to ensure your account procedures are set as requested, and we’ll provide you with all the details of how alarm signals are expected to be handled on your account.

This type of incident is not typical and does not meet the high standards that we have for our monitoring partners. We apologize for the inconvenience and are working to resolve this so it does not occur again. We appreciate you bringing this to our attention, and I’ll keep you up to date with the progress as we continue working through this.

3

This is important. Monitoring center operators, and even their supervisors, are not technical support. They get asked difficult questions under pressure in intense situations, and they sometimes make mistakes. But their training is in following the procedure as displayed on the screen, not in doing a post-mortem on what happened during an alarm event, and why.

That’s no excuse for explaining something incorrectly, but the best thing to do when you have a question or concern about our procedures, or are investigating what happened, is to ask our support team.

I’m sorry for the frustrating experience. We’ll do our best to make it up to you.

4

Becklar followed up with me and confirmed that they’ve opened an investigation into this and are looking into what exactly happened. We’ve also opened a complaint, which is being escalated to their Quality Assurance and Operations Management for further review.

I’ll follow up here as we get additional information on the investigation. If you have any other questions in the meantime, please let us know.

5

Becklar has concluded its investigation and found that the operators involved attempted to answer questions outside of the monitoring center’s scope, including ones regarding system programming, panel delays, notification expectations, and account configuration, which should’ve been directed to our team.

Both operators will be receiving documented coaching with a focus on remaining within the monitoring center’s scope, avoiding speculation or presenting assumptions as confirmed facts, clearly distinguishing monitoring activity from panel or account programming, following service instructions used to notify our team for follow-up, and recognizing when continued explanation is creating more confusion and completing a timely handoff instead. While their intentions may have been to help, accuracy and adherence to our instructions must take priority, which will be reinforced through the additional coaching. Becklar’s leadership will follow up to ensure the expectations are understood and applied moving forward.

We appreciate you providing the details and bringing this to our attention. If you have any questions or further issues, please let us know.