Incident |
Interface |
Communication process |
Communication |
Outcome |
An incident occurs - security problem, accident, IT alert, exceeding permitted values. Find the possible uses here. | Passing information through the API, e-mail, IoT or manually by user. Find the description of the possibilitie here. | A specific communication procedure is selected for a specific incident type that controls the transfer of information, reaction to responses, escalations and repetitions. Find the description of the communication process here. | Two-way communication with users via the Maatrix mobile application, e-mail, SMS, automatic voice messages. Find information on the mobile application here. | The outcome of the communication process contains important information about incident resolution and is available through the API or the web portal. |
Unmissable acoustic alert |
Comprehensive message |
Choice of possible reactions |
The application rings just like a phone call - keeps ringing until you open the message. | You will not be missing any important information even in crisis and stress situations. | For each message, the application offers possible variants of how to respond to the message. The user response is then comprehensive and assessable in any situation. |
Authorization confirmation |
Remaining reaction time |
Secure connection to server |
The user response may require entering the PIN - you can then rely on the right person to respond to the message. | Very important information about how long to wait for a user response - it then proceeds as if the message was undelivered. | The server connection uses a secure https communication. |
Message distribution |
Possible responses |
Reaction time |
The procedure determines what information to send to what people. | For each message it is possible to prepare response templates so that it is possible to answer quickly and evaluate the answer. | For each message it is possible to set how long to wait for the response. After that the message will be considered undelivered and the further procedure can be decided. |
Response evaluation |
Course of communication |
Event evaluation |
For each message a rule is defined how to handle user responses – is a reaction of a single user sufficient or is a response from all awaited? Is an approval by a single person, a group or an agreement of all called persons required? Evaluation - consensus, choice of the most common answer, the right of veto? | After evaluation of a message it can proceed further. This allows setting up various escalation types; additional instructions can be given to those people who have previously logged in to resolve the event and the like. | The entire communication service ends with information on how the event was resolved, who resolved the event, whether the event was resolved, and so on. |
More info |
WEB panel |
URL link |
Panic button |
|
API |
If the communication service is started by e.g. a dispatcher, he can use the web interface to easily start the service and follow the communication on-line. | The Maatrix service has a URL reference (so-called "short call"), which can be used to start the service. | The communications service can also be started with the SOS (panic) buttons. These can be implemented in software or the service can be connected to a mechanical starter (for example connected through IoT). | If the Maatrix service is started by an application that does not have a Maatrix interface but is able to send notification emails, an e-mail address is created for the Maatrix communication service and the service is then started by an incoming e-mail to this address. | The application developer can make use of an extensive API which can not only set up and start the service using the JSON format, but also inquire about the course and outcome of the communication service. Find the API description here. |