The downside to using email to manage your on call team

There are a number of reasons why email is predominately used to manage an incident. Everyone usually has access to email and the email technology has already been “paid for”. Therefore it’s easy to think of email as being a cheap resource that’s easy for MSPs to use. But easy isn’t always best…or even appropriate.

BREAKING DOWN THE ISSUES WITH USING EMAIL TO MANAGE AN INCIDENT.

Let’s consider an MSP tackling an incident using a communal email inbox to receive and manage end-user incidents and service requests. This flow chart illustrates the workflow of how incidents are regularly handled:

Source (x)

PHASE 1. INCIDENT DETECTION AND RECORDING

This is the first part of the incident lifecycle and if you use email it will probably go something like this. Your client sends you an email. You have a record of this in your inbox. However, does it contain all the required information from the client? Well, we can’t say, as this will differ by issue or service request type. You also have no way of really differentiating between a service request and far more time-sensitive incidents. You could use an email template to help clients provide the right information though; something that resembles a form that requires different information based on the issue or service request type.
But what do you do if the client calls by phone, rather than sending in an email? Do you create an email, add the issue to an Excel spreadsheet, use a post-it note, or record nothing at all?

PHASE 2. INITIAL CLASSIFICATION AND SUPPORT

Classification is not as easy with emails as you have to rely on an email inbox and the use of folders or tags. Even if you manage to come up with a system to classify emails using folders, what happens if the initial classification is wrong? The issue can be reclassified but would we know how much time is wasted on misclassified issues? And what about prioritization? Are issues and requests dealt with on a first-in-first-out (FIFO) basis, with some bias towards “important” end users, or is a more scientific approach taken based on the severity levels of the incident?
Do you have information related to the end user’s IT history and the IT assets they use? And what about information related to service level agreements (SLAs) and the targets for fixes and service request delivery?

PHASE 3. ESCALATION TO A MAJOR INCIDENT PROCESS WHERE NEEDED

Using an email inbox and/or manual procedures will not be the quickest route to the required resolution. Most likely, there will also be insufficient communication to stakeholders, and probably no post-major-incident review to ascertain “what went wrong” and to identify any improvement opportunities. The main problem with escalating the issue via email is that you are not guaranteed an immediate response from the person or process that you emailed to. You also have no way to track the email sent.

PHASE 4. INVESTIGATION AND DIAGNOSIS

Investigation and diagnosis involves the element of collaboration. Many a times you have an email describing an incident that goes out to people in a team. When this is the case it is difficult to assess who is currently working on the issue, expected resolution time, and the eventual solution? You also have no way of logging the progress and important aspects of our investigations

PHASE 5. RESOLUTION AND RECOVERY

If an email containing an incident is not updated to include how the incident is resolved then the next responder at the MSP needs to reinvent the proverbial wheel when a similar issue gets reported in the future. And what about dealing with customer feedback on IT support’s performance? Is that ignored? Of course, knowledge management and customer feedback capabilities can be built and integrated, but surely this is just additional evidence that a fit-for-purpose help desk or service desk tool is so much more than an email system?

TAKE AWAY

The end result is that using email is not an adequate means to manage an incident. While email might seem like the cheapest option, the time spent on creating workarounds to make email an effective means to manage an incident is exorbitant. In time you will notice the cracks in the system and hidden costs will creep up due to miscommunication, lack of clarity and a lack of automation.

Now that we’ve seen how a dysfunctional system based on email works, let’s look at how to set up alerting and incident management the proper way. The following plan detailed in our whitepaper showcases how you can perfect your incident response plan through ConnectWise and critical alerting.