There are a number of reasons why email and other personal productivity tools are used for IT support, for example:
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.
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:
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.
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.
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.
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.
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?
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.
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:
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.
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.