Support Incident Case P1 - P4 Description

This document explains our support incident case priority settings.

Mails to support are directly passed to our support case system, and you will get an automatic message confirming receipt and providing you with a case number.

For clarity, mails sent directly to our support engineers, or in some cases directly to your account managers, but which are themselves requests for support, technical queries, or seeking advice, are on most occasions forwarded to the support case system and are treated as though they are support incidents. Mails sent directly to support engineers or your account manager are outside of our normal SLAs as they are not monitored in the same way as those sent to our support email address.

The activereach support team uses 4 levels of priority (High/Medium/Low/None) when dealing with incidents raised to us and managed by our case system.

Cases are opened automatically at priority 2 and can be adjusted by a support engineer at any point through their life towards resolution.

Priority 1 cases are for severe impact issues within a customer, typically widespread LAN or WAN network failures, or issues significantly hampering normal operation for multiple staff. These cases are escalated within our business so that we have both technical, commercial, and managerial resources focused on minimising the impact to our customer. P1 cases may also have been escalated from a lower priority if they have been unresolved for a prolonged amount of time, fallen out of SLA, or subject to requested escalation by the customer or activereach.

Priority 2 cases are issues that require resolution in a timely manner, and form the vast bulk of the incidents we work on for our customers.

Priority 3 cases are for matters that by their very nature are not of immediate impact to a customer, or where we expect or have been informed that responses from a customer will be delayed.

Priority 4 cases are information only cases or those that we know are for future events. We may also place a case at priority 4 if a customer has a resolved issue but we are working on understanding the root cause.

We have internal metrics and procedures to check individual cases regularly to minimise the time to resolution at all priorities. This includes checks for elapsed time and cases that are without updates against our internal timescales.

At each priority level we have individual case statuses that allow our staff to quickly see whether the case is waiting for input from us or from the customer, or indeed from a 3rd party. Every email from a customer automatically marks the corresponding case as needing attention and moves the case to a specific queue.

We place cases in queues either by specific engineer or by specific team, but additionally every engineer can see cases that have had a response from a customer and that require attention. These are not ‘hidden’ in the queue of an individual engineer. During working hours there is an engineer assigned as the ‘Support Controller’ who ensures all cases are being progressed and handled appropriately.

Each case has the time spent tracked against it and any changes to a case are audit logged.

We publish what we consider to be chargeable cases on our website at

When cases are closed, we check for anomalies in procedural handling automatically, and conduct a follow up post-mortem within the team on a monthly basis to disseminate significant changes to a customer site or future technical handling of matters. Any engineer can mark any case for post-mortem at any point in the life of a case. For cases that require a post-mortem we will feedback to the customer any changes that are required to either prevent the matter from occurring or that might have assisted in the resolution process.