Action Patterns in Manitou replace traditional call lists and build manual and automatic instructions for alarm processing.
Before Action Patterns
In the early days of alarm monitoring, operators interacted with software by manually receiving signals from receivers, typically displayed on large consoles with limited automation. When an alarm signal came in, the operator would log the event, verify it with a phone call, and dispatch emergency services—all done manually. The software at this time was primarily a tracking tool, assisting operators with maintaining records and facilitating communication, but required constant human oversight and input.
As the software evolved in the 1980s and 1990s, more automation was introduced, allowing operators to manage higher volumes of signals. Instead of manually tracking events, software began to automatically categorize and prioritize alarms, freeing up operators to focus on critical incidents. This still directed users to read and understand written instructions and manually manage any alarm processing.
After Action Patterns
In the late 1990s and early 2000s, and the advent of better communications, the systems became more intuitive, offering guided processes, automated reporting, and direct integration with communication systems, improving the efficiency of human interaction.
Bold's Manitou introduced Action Patterns replacing the Bold THEOS system providing operations with not only who to call and in what order, but full step-by-step instructions for processing alarms. Thus reducing mistakes and ensuring consistent service delivery from alarm operators. These Action patterns also streamline training by providing new hires with clear, repeatable steps, reducing confusion and accelerating their ability to perform tasks independently. This saves onboarding costs for the alarm monitoring operations.
Automations to Action Patterns such as automatic notifications, reduced the number of manual alarm interactions necessary to manually manage and make notifications on non-emergent alarms.
While many operations have continued to maintain comments for alarm processing and operational instructions, Action Patterns allow significant reductions in understanding or interpreting instructions.
Logic Action Patterns
Newer versions of Manitou added programming, verification, and logic action patterns to further improve and ensure that as alarm operations grow the systems and services can grow with them. What would have required an operator to read, verify, and interpret, can now be done with feedback received through technologies, automated instructions, and logic based workflows that reduce waste and increase the effectiveness of the alarm operations.
This image demonstrates the logic flow of Action Patterns.
This flow chart indicates:
- Alarm Arrival - Logic Check of the Account information.
- If UL or Fire system - Alarm Drops to the operator for dispatch and notifications.
- Contact the Responding Authority.
- Contact the Site.
- If Contact is successful:
- Prompt the Operator to determine if additional contacts are required.
- If additional contacts are required -
- Make the Contacts.
- Automatically notify the Dealer of the alarm.
- Close the Alarm.
- If contacts not required:
- Automatically notify the Dealer of the alarm.
- Close the Alarm.
- If Contact unsuccessful:
- Contact Responsibile parties.
- Automatically notify the Dealer of the Alarm.
- Close the Alarm
- If Not UL - Logic to check the current time with the General Schedule (Action Pattern Type).
- If IN the Schedule - The alarm drops to the operator for making contacts.
- Contact Customer - Logic Item to determine if the contact was successful.
- If successful - Prompt to the Operator to determine if the alarm is Actual.
- If Actual - Contact Responding Authority.
- If not successful - Contact the ECV Contact to verify.
- If Contact to ECV is successful
- Prompt operator to confirm if the alarm is Actual or requires Authority dispatch.
- If dispatch required - Dispatch Authority.
- Contact the Responsible Parties
- Automatic notification to the Dealer of the alarm.
- Close the Alarm
- If dispatch Not Required - Prompt if additional Contacts are required.
- If Not Required - Automatically send the Dealer an alarm notification.
- Close the Alarm.
- If dispatch required - Dispatch Authority.
- Prompt operator to confirm if the alarm is Actual or requires Authority dispatch.
- If EVC contact unsuccessful
- Dispatch Authority.
- Contact Responsible Parties
- Automatic Notification to the Dealer of the alarm.
- If Contact to ECV is successful
- If successful - Prompt to the Operator to determine if the alarm is Actual.
- Contact Customer - Logic Item to determine if the contact was successful.
- If Outside the schedule - Automatic suspension of the alarm in the queue (also can be lowered in priority) until the time is inside the schedule.
- Once time is inside the schedule - Logic to verify if the if the alarm restored.
- If Restored - Close the Alarm.
- If Not Restored - Return to IN Schedule steps.
- Once time is inside the schedule - Logic to verify if the if the alarm restored.
- If IN the Schedule - The alarm drops to the operator for making contacts.
- If UL or Fire system - Alarm Drops to the operator for dispatch and notifications.
While the planning and creation of logic action patterns may be more effort intensive, their use creates repeatable, consistent, accurate, and more efficient business operations.