For obvious reasons, IT Support needs to be reliable. The fact is though, reliability is extremely difficult to achieve without over-resourcing, even if overt managerial effort is involved. And so it’s usually lacking, usually more than is known, something that is evidenced to an extent by service metrics and undesirable day-to-day occurrences, even in organizations with high operational maturity.
Setting the IT service desk scene
Typically, service tickets get chased every day because the wait has been too long. Sizeable backlog is usually present and phone call wait time is often detrimental. It means that beyond the good customer experiences, there are many that are bad.
Then, if you have a resolution service level agreement (SLA) (maximum lead-time) in place, if it’s above 80%, then you’re doing well relative to the industry norm. It means, however, that one in every five customers are not assisted within the period deemed to be acceptable. It seems to me that this is not good by any stretch of the imagination, especially because IT service customers often expect or need attention much faster than the SLA.
More than this though, tickets placed “on-hold” might remain open and abandoned for weeks or months without breaching their SLA. Furthermore, if “first time fix” tickets are not excluded from the analysis (by reason they should be), the lead-time failure rate will actually be much higher.
Then, when a customer chases, is it taken seriously?
The answer will be “yes” if the escalation is a complaint that reaches a manager, but most will only make it as far as the IT service desk. Over the years, I’ve heard commented views from support staff and managers alike such as “they need to wait their turn” or “they’re chasing because they’ve nothing better to do.”
Sure, occasionally this might be the case but without doubt most of the time, if a business colleague makes the effort to chase their support need, it’s because that is their need and therefore it’s of higher priority than most other currently open tickets. Ignored or not handled well, considerable frustration and negative opinion is inevitable, sometimes resulting in the horrible “multi-chase.” Compounding this problem, I’ve never known an IT department to have a process in place that captures its extent. The volume of chased tickets, i.e. the extent of failing to meet needs and expectations, something that would make a great key performance indicator (KPI), simply isn’t known.
But no matter how much better we do, failings will still often occur
Human nature decrees that, from the customer’s point of view, it’ll always take many good service experiences to neutralize the ill feeling of one bad one. It’s a known fact that should be front and center of support team and managerial minds. Teams must do all they can to prioritize according to actual need (not by ticket priority alone) in an effort to perform well across the board, to minimize bad experiences and resulting reputation harm. But even then, failings will still occur because the process underpinning incidents and requests is far too basic to cope with the complexity inherent in IT support.Human nature decrees that, from the customer’s point of view, it’ll always take many good service experiences to neutralize the ill feeling of one bad one. #CX #ITSM Click To Tweet
So, what’s missing? Why is there still this big gap when reason suggests it’s here that improvement efforts should be focused most strongly?
The three necessities of reliability
Without overstaffing and excessive managerial effort, both of which are of course undesirable and usually not possible, achieving reliability comes down to three necessities. Firstly, the need to ensure tickets are progressed in a timely fashion irrespective of their service level target. Secondly, facilitating timeliness, teamwork is necessary, where if one team member isn’t able to take a ticket forward in good time, a colleague will do so whenever possible. Thirdly, motivation to make this happen, largely by teams feeling they own and are in control of service quality.
If a panacea to achieve these transformative elevations can be found, there’s still the issue of phone call wait time and abandonment, however.
Dealing with telephone channel reliability
I find the phone channel quandary a particularly interesting one. We all recognize that allowing all nature of support to be fielded with a phone call will, at least sometimes, be highly detrimental because urgent needs such as AV support or failure to log-on must be dealt with straight away without anything getting in the way. If phone lines are busy though, this doesn’t happen. Failure to make the immediate response channel (phone) always available inevitably causes a steady stream of frustrated, dissatisfied customers.
I’m not sure what’s worse – not being available to provide frictionless service when it’s really needed or, for lower priority cases, failing to provide service in good time (within its SLA), or at all, once a ticket has been raised. Both though are symptoms of too many phone calls, with a service desk unable to spend adequate time progressing ageing workload if they’re frequently on the phone handling non-urgent matters, caught-up in the “here and now.” Either way, it’s certainly bad customer experience all round.
So, for supportability to improve, a fourth necessity is for call volumes to be substantially reduced by purposing your service portal and other digital channels as effectively as possible. Nothing radical in that, but all IT departments really need to take the initiative seriously, not only for the benefit of service customers, but for team morale and job satisfaction as well. I’m certain that even call center staff prefer fewer phone calls, and everyone prefers being on top of their own workload.
Beyond the reasons of supportability and to heal the decimation of appropriate prioritization, organizations should want to reduce phone call volume anyway…
Quite simply, the telephone conversation, like email, is not “digital.” It’s not the modern, efficient, millennial-friendly way of doing things.
IT support and digital transformation
I’m a staunch believer that IT service, which really is at the center of any business and employee experience, shouldn’t be left behind while digital transformation takes hold around them. In fact, there’s a strong argument that digital transformation should start here, so the benefits of modernization are clear for all to feel and see. In doing so, organizational culture might absorb a “digital” mindset quite organically, from the center outwards, and IT will be in the right frame of mind to advise and assist digitalization elsewhere across the enterprise.Is it time to remove the telephone IT support channel? #ITsupport Click To Tweet
As to how far digitalization of IT support can be taken, truly urgent service that necessitates a human touch probably accounts for less than 5% of service tickets, so strategy might aim for 95% digital channel uptake. Indeed, commentary leads us to believe that there are organizations having got this far. With the right approach though, even urgent needs that necessitate support team intervention straight away can be handled appropriately through digital channels, so despite internal IT’s inherent complexity, the aim might be as high as 99%. For sure, depending on an organization’s cultural profile, removing the phone channel altogether will more often be deemed a step too far for some time to come, but many cloud service providers (digital forerunners) don’t have a telephone support channel these days.
Removing the telephone IT support channel?
For this to work in organizations where a service desk is still available to speak to – and this is the really vital bit – service responsiveness, i.e. reliability, experienced in traditional versus digital channels, needs to be balanced and flipped. Employees must know that all nature of support need will always be dealt with appropriately – immediately if necessary – when raised through the service portal or a support app, and there’s no longer a likelihood of needing to chase a response. With this, I think most of us will recognize that like call center staff preferring fewer phone calls, service recipients tend to prefer the simplicity of digital interfaces, where there’s no time and potential frustration involved with waiting for a phone call to be answered, then discussion while the ticket gets logged and first response steps are carried out.
How to get there?
Fortunately, with digitally enabling service tools at our disposal these days, all nature of operational difficulties, shortcomings, constraints, and inefficiencies can be overcome.
With leading tools, practically anything is possible. So, it’s more worthwhile than ever to commit resources to developing, or finding, an improvement strategy that will make a really big difference, before tool selection.It’s more worthwhile than ever to commit resources to developing, or finding, an improvement strategy that will make a really big difference, before tool selection. #ITSM Click To Tweet
Nothing radical in that either, but focus tends to skip what I call “human workload management” (as compared to automated or self-service workload) when really it’s here that should command the greatest focus because it’ll have the biggest impact, for the many reasons I’ve set out.
Then, with an approach developed to form high-functioning service teams, it can be shared to infuse enterprise service management and even external customer services. What a great way for IT to bring forward clear and appreciated business value.
13 potential IT support issues to address
The first step would be to identify everything that isn’t working well, heavily involving individuals who’ve been IT technicians for a long time. Below are thirteen issues that I’ve identified, common to internal IT in most organizations. From there, by unravelling and working out the causes, a new way of working might be designed and a service tool that supports it then chosen. They are:This article shares 13 potential IT support issues to address in your organization. #ITsupport #servicedesk Click To Tweet
- At the service desk level, a resolution SLA is largely ineffectual for guiding service provision and weak for setting end-user expectations. At all levels of support, due to measurement inaccuracy, it’s also invalid in serving its primary purpose, that being to measure the performance of incident management and request fulfillment.
- Aging ticket backlog is often or usually out of control.
- More generally, service teams work in a natural way, but due to time pressures and the onerous nature of doing so, managerial influence on prioritization is inadequate.
- Even if accurately measured, traditional performance metrics serve little purpose; SLAs don’t identify things that can be done to improve service provision.
- Many nuanced operational inefficiencies in how work is carried out go unidentified, substantially limiting the effectiveness of improvement planning.
- New team members in support might make the process and procedural mistakes that go unnoticed, causing inefficiencies, impacting service quality, and potentially causing reputational harm.
- Allocation of tickets to individuals forms a multitude of vulnerable, inefficient silos; teamwork is lacking.
- Service recipient ticket updates are sometimes or often not seen/responded to/answered, causing a poor perception of service and worse still, escalations, and ticket-specific service failure.
- Customer escalations are not handled well or at all, with no process in place to identify them all.
- Tickets are not always updated with journal notes on activity.
- Performance motivation.
- New service desk staff make ticket assignment mistakes, causing frustration across other support tiers when it happens often.
- A weak relationship between the service desk and other support teams.
Each aspect deserves further commentary, so if you’ve found this article interesting, please look out for my future ITSM contributions on ITSM.tools and elsewhere. Personally, I find the first aspect quite fascinating. You can read more on my thoughts surrounding the resolution SLA paradox here.