The Downside of Using Email to Manage IT Support

There are a number of reasons why email and other personal productivity tools are used for IT support, for example:

1. Most IT staff usually have access to email
2. IT staff know how to use email
3. The email technology has already been “paid for” in providing a set of tools for personal productivity reasons

So it’s easy to think of email as being a cheap IT support technology, one that’s easy for IT support people to use. But easy isn’t always best…or even appropriate.

Breaking Down the Issues with Using Email to Manage IT Support

Let’s consider IT support operations – key activity by key activity – in the scenario where we’re part of a group of service desk agents using a communal email inbox to receive and manage end-user incidents and service requests:

Phase 1. Incident Detection and Recording

An end-user email comes in and it’s automatically “recorded” – because it’s sitting there as an entry in the communal inbox. However, does it contain all the required information from the end user? Well, we can’t say, as this will differ by issue or service request type (plus service requests might be mixed in with the far more time-sensitive incidents). We could use an email template to help end users provide the right information though; maybe even something showy that requires different information based on the issue or service request type.

But what do we do if the end user calls by phone, rather than emails? Do we create an email ourselves, add the issue to an Excel spreadsheet, use a post-it note, or record nothing at all? And what about benefiting from the modern penchant for self-service? It’s not just about improving IT efficiency, it’s also about providing contact channels to suit end-user preferences and delivering a better customer experience.

Phase 2. Initial Classification and Support

I guess we could classify an issue, or service request, in an email inbox through the use of folders or tags, but what happens if the initial classification is wrong? The issue can be reclassified but would we know how much service desk 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 urgency and impact-based approach taken?

Also, what about the ease and quality of initial support? Is information related to the task at hand readily available through integrated knowledge management capabilities? 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? So of course we can solve the end user’s issue or service request but only if we have the right knowledge, skills, and experience and our service desk has the absolute minimum of staff churn.

Phase 3. Escalation to a Major Incident Process Where Needed

The reality is that if email is being used to manage IT support then the “process” for major incidents is very likely to be a lot of running around like headless chickens until things are “better again.”

Sadly, this might seem harsh, but using an email inbox and/or manual procedures will not be the quickest route to the required resolution (due to a lack of insight into the root cause, previous resolutions, and ongoing status). 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.

Phase 4. Investigation and Diagnosis

So there was no immediate fix and one or more of our IT support or service desk agents now need to spend time investigating the issue to better understand what needs to be done to rectify things. But what happens here in terms of logging progress and important aspects of our investigations, such as: failed solution attempts, who is currently working on the issue, expected resolution time, and the eventual solution? Of course the email could be updated with all of this information, but will it be? Hard to believe, especially if an issue, once closed, is simply filed away in the “completed” folder with no metrics created, or knowledge captured, to improve resolution of similar issues in the future.

Phase 5. Resolution and Recovery

So the issue is now fixed or, in the case of service requests, the service delivered. The email system can be used to inform the end user, so all is good. Right?

Well, it depends. Is everything that was learned, while resolving the issue, lost as soon as an email is “filed”? Meaning, do the other service desk agents need 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, or 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?

Phase 6. Incident Closure

Probably little to worry about here with email – the issue or service request can be moved into the “completed” folder (plus it can be moved back into the main inbox if the issue or service request needs to be readdressed). That is until we look at the email system’s ability to provide visibility into support operations – with metrics related to throughputs and efficiency, including the number of reopened issues.

Thus transactionally, email can be used for incident management, but there are so many suboptimal elements and inefficiencies, which cost time and money, and can be addressed through the use of a fit-for-purpose help desk or ITSM tool.

But It’s Not Just Issues with the Transactional Elements of Email Handling

There’s also the ongoing monitoring, tracking, and communication of issues/requests to consider. And boy is there a lot to consider here, probably as much as with the previous six bullets combined:

• Does the email system allocate a unique reference to each incident or service request such that an end user or IT team member can quote/find it when needed? And what about providing a suitable audit trail?
• Can the email system calculate the timings between key activities such as email receipt, allocation, resolution, and closure? Thus allowing for the assessment of performance for individual tasks, incident and service request types, individual service desk agents, and the service desk team as a whole? Plus, can those who work on an issue or service request log the time they spend doing so?
• From a management perspective, can incident-related data be used to quantify the adverse effect of IT issues on business operations – a cost of quality and an opportunity to improve things?
• Are service desk agents able to identify issues and service requests that are taking too long to deal with? Even if there are no IT support SLAs to be met, what’s to say that tasks get accidentally delayed or even forgotten about, especially when multiple parties are involved?
• How are issues and requests tracked, not just over time but also from person to person? How is responsibility or accountability assigned – is it the last person to “view” an email or the last person to add a note? Or are emails tagged to individuals or dropped into people-based folders rather than category-based folders?
• Email software lacks “workflow, automation, and alerting” – so how do the individuals with the right skills or authority know that something needs their attention, or how does the system know if an issue has awaited third-party attention for too long? Do people have to regularly check the communal inbox, or has the email system been tweaked to allow for action-request emails (alerts) to be sent? Plus, I’d be willing to bet that such emails, if they exist, don’t automatically get resent (or someone else alerted) if the third party hasn’t done what they need to do in a reasonable time frame.
• Communication-wise, of course emails can be sent to and received from the email system but how are they “organized” and is it easy to separate important emails from trivial ones? Plus, what happens when a telephone call is made or received, or a deskside support agent wants to notify the service desk of what they have discovered or tried as a resolution? What I’m trying to say here is that emails can be used, even if just for collecting notes, but the information within the emails is mostly unstructured and inaccessible at speed.

So How Well Is it All Working?

The last bullet above leads us nicely into another area, and probably the biggest area, of operational and management weakness when using email for the management of IT support – insight and reporting.

With an email system you can probably manually count things such as the number of emails received or closed in a month, and split them between incidents and service requests. You might also be able to attribute them to individuals to ascertain personal “throughputs” (although I’d be worried about people playing the system and quickly jumping on the easiest of issues while avoiding those that take time).

As mentioned earlier, the information or data held within the email system is unstructured and thus difficult to analyze and report on. So accessing insights into: incident and request volume peaks and troughs, average handling times for each incident type, achievement of SLAs, the costs of IT support by category, incident trends for problem management, business unit to business unit comparisons, and other metrics – is either impossible to get or a highly manual and time-consuming activity.

Plus of course the email system will not have a modern reporting capability nor dashboards, nor any form of ability to slice and dice data to identify patterns or other insights such as business intelligence.

Finally, IT Support Is More than Just Service Desk

How does your IT organization manage problems (if they do at all) and changes? Do your monitoring or event management systems integrate with your email system? Can your email system launch automation capabilities to solve issues? I could go on but this blog is already long enough, many would say too long.

My point is merely that using an email system for IT support is really only scratching the surface of support capabilities and missing others espoused by industry best practice such as the ITIL IT service management (ITSM) best practice framework.

So if you’ve read this blog and still think that you can use the corporate email system for IT support, adding to it to get around all of the issues raised, then I’ll pose you one last question – “Would you build your own HR or CRM system?” Unless your answer is oddly “yes” then surely you should be applying the same “buy, not build” logic to invest in fit-for-purpose technology for IT support that’s optimized to business needs (and reliable), maximizes people efficiency through workflow and automation, delivers a better quality service to end users, and provides greater insight into operational performance and improvement opportunities.