Let’s talk about an IT service desk “basic” – what to do when the end user doesn’t respond. If I remember my ITIL studies and exams correctly – well, it was over 20 years ago – an incident or service request should only be closed by the end user/customer (not the IT service desk). I understand the logic, as they’re the people best positioned to know if their IT issue has truly been resolved or if their need has been met.
However, not all IT departments have adopted ITIL, and, of those that have, some (I imagine many) will have conveniently decided that waiting for the customer to okay the closure of a ticket adds unnecessary delay and additional activity in what is an already under pressure IT service desk environment.
Dealing with unresponsive end users
But IT service desk ticket closure is something that happens once the incident has been resolved or the service request fulfilled. But what should you do if the end user isn’t responding earlier in the incident or service request lifecycle?
What do you do if the end user is preventing an incident or service request from progressing to meet the agreed service level targets for IT service desk operations? What do you do if the end user not responding is affecting the service desk agent’s and the overall performance targets?
Of course, you could put the ticket on hold, or whatever you call “ticket limbo” locally, but that’s only a temporary measure that neither helps the end user nor the accuracy of an IT service desk’s performance statistics.
So, what should you do if an end user isn’t responding to your IT service desk’s requests for additional information from them?
What would a 1990’s IT help desk have done?
This IT service desk issue was also prevalent with IT help desks. Without a doubt, they would have quickly closed the ticket. They might have sent an email and a reminder to the end user. They might even have called and left a message – firstly to request more information, and secondly to say that the ticket would be closed if a response isn’t received within three days, say. But they wouldn’t have messed about just because ITIL says that only an end user can close a ticket.
The cynical among you might see this as a little optimistic of 1990’s “IT service desk” behavior. I know from my personal 1990’s corporate IT support experiences that, after you called to log an issue, you were lucky to be called back about it within two weeks, and even luckier if someone actually helped you. The IT help desk, especially without a fit-for-purpose IT help desk tool, was often the black hole where your requests for help would go to die.
What does an IT service desk do in 2023?
As you would imagine, and as many an IT service management (ITSM) consultant will tell you, “it depends.” I know that this is my experience. It will differ from organization to organization and IT service desk to IT service desk based on a number of factors, including:
- How the IT service desk, and wider IT organization, perceive end users – from technology users through to valued customers
- How IT service desk service level targets (and agreements) have been set up
- The ability of the IT service desk to physically cater for additional, and some would argue unnecessary, activities just because an end user can’t be bothered to respond in a timely fashion.
So, how should an IT service desk deal with end-user unresponsiveness?
I posted the following IT service desk question to the Back2ITSM Facebook group in 2016 and sought to update the responses in 2021 and now 2023; it’s a far more productive and helpful ITSM forum than any of the LinkedIn groups:
“IT service desk question time … When an end user/customer is unresponsive in respect of a logged incident or service request, what good practices have you seen to either get a response or eventually close the ticket? … timings, comms, approach, etc.”
And received the following, albeit varied, food for thought prior to the 2023 call-out:
James Finister – “There are three elements to consider. First, does your IT service desk actually need a response? In many cases, it makes sense to close a ticket without one, especially if the resolution can be independently verified and a mechanism exists to react to a response if one is finally received. Second, encouraging responses where they are required comes down to a certain amount of social engineering and unobtrusive use of technology. For instance, a pop-up message on an end- user’s screen. Third, the need for unambiguous reporting, which demands good status codes and the use of pivot tables.”
James Gander – “The IT service desk should try three times over three days to contact the user. If there’s no response, resolve it as an appropriate category (such as “Unable to contact user”) and wait. If the end user hasn’t come back within 10 days, say, close the ticket. This is, of course, assuming that you’re sending emails at each status change so they are aware, and leaving voice messages not just trying an IT service desk number and leaving it at that.”
Roy Atkinson agreed with James Gander, with that caveat of the IT service desk needing to use multiple contact methods as voicemail is often ineffective.
Stuart Rance – “Many service providers use a “three attempts and then close the ticket” rule for the IT service desk. They chase up the customer three times, and then close the ticket.”
Darren Hampton – “If we need end-user feedback we clearly state ‘If we do not hear back within a week we’ll consider the matter resolved’ and put the ticket on hold, two days later we send a reminder, and if no response is received as the week is up, we resolve the ticket with a ‘We’ve not had a response so consider the matter resolved. If not, please raise a new ticket via…’ Though we don’t currently have an IT service desk closure code to indicate user non-response and sorely need one.”
John Custy – “I typically recommend IT service desks use more than one channel to communicate where/when you really need a positive response to close the issue, plus some understanding of the business, e.g. more time for sales or in high vacation/holiday periods. If you close the ticket and the customer/end user calls back, then you reopen/open a ticket, and work the issue.”
John Clark – “Have an intermediate status before ‘Closed’ to indicate the last action. For example, requests (or cases) can be Completed, Resolved, or Fulfilled. Incidents can be Resolved. This is a signal to the customer, and those managing performance, that the IT service desk agent believes he/she has fulfilled the request or resolved the incident. Then close them when they are truly closed – that is after the customer confirms, or when the customer doesn’t respond.”
Karen Ferris – “I think the most important aspect – whatever the approach an IT service desk takes to close a ticket due to lack of customer contact, e.g. three times then close – is that it’s clearly agreed with, and communicated to, the customer. That this is the process.”
Gregory Baylis-Hall – “What I’ve done to get around this gray area is to find the compromise sweet spot. On one hand, the IT service desk should have the user’s agreement that all is well again, or their request is fulfilled, and on the other you have the service delivery people saying that it’s affecting their stats. If texting, emailing, calling, instant messaging, and desk-side visits still haven’t yielded a response, to help the stats people I created another status within our ITSM tool – “Awaiting user response.” Then every week we review all the service requests and incidents in this status and chase the users for a response. From the outside (of IT) this is deemed proactive, and I use it as a tool to engage with my business colleagues – and I believe you should use any excuse you can to do that.”
In terms of getting the end user to OK the closure of an IT service desk ticket …
Peter Brooks – “It’s important to consider the value you’re trying to deliver (by chasing the end user). What is the value to the end user of having the ticket closed? Probably zero (the value is in having the issue resolved). What is the value to the IT service desk? The impact on performance statistics, but not much. Then consider how much effort and time you are spending on this.
You then can calculate the cost/value ratio. If the value is, as it usually is, around zero, and the cost is, as it usually is, high, then stop doing it – you’re wasting money. What you really want to know is whether you have resolved the incident. And if you keep the call open, will it cause a major crisis? No.
So, just let end users know, once, that you think you’ve solved their issues. Invite them to contact you if you haven’t. If they’re unhappy, they’ll soon tell the IT service desk”
The 2023 IT service desk insights
Daniel Breston – “Ask why they don’t they respond. Now adjust your IT service desk behavior to their attitude and behavior. I don’t always respond, but that does not mean I am unhappy. You fixed it, and I moved on. I feel you must be busy, so why send you comments? You didn’t fix it; well, if I have not told you this and you don’t know, who is at fault? Really, who is at fault?”
Stephen Cull – “I am surprised how many organizations choose to manually contact users to confirm the closure of tickets, often adopting a “three strike rule” for the IT service desk, the use of these particular words in some cases indicating the contempt the IT organization has for its users, or just maybe how far away the IT team is from understanding its users needs.
The other odd behavior I often see is confusing resolving with closure, often leading to putting tickets on hold, or pending states before being resolved.
My advice to IT service desks on this is, first of all, do you really need to get a response from the user if you know the incident has been fixed or the request successfully delivered? Yes, it’s a good idea for there to be a communication to the user that it’s been fixed or delivered; however, if you know beyond any doubt, what value does it add for the user to confirm this? It’s waste, it is a non-value-adding activity of the user and the IT resource.
Where it is desirable to get a confirmation, does this need to be done manually, or can it be automated? Often technology is available to automate the communication from the IT service desk tool so that when the ticket is resolved, an automated email or even a pop-up message can be sent to the users that they can respond to if they choose. Using automated techniques like this, I would argue, improve the accuracy of the reporting and simple clear workflow. There is no need to put a ticket on hold waiting for user feedback, or any other such user pending state before resolving. The ticket is resolved when it gets resolved; there is no fudging the time, it may get reopened from resolved when it’s not been resolved correctly, and it gets closed following whatever policy you have in place to ensure consistent reporting.
In the other scenario where you’re unable the progress with the ticket because you need information from the user, then waiting states can be useful, and after a period of time and communication that takes into account users going on leave, set in an agreed policy, the ticket should go directly to closed, it should not go to resolved or have a resolution time if it wasn’t actually resolved.”
Phyllis Drucker – “Most of the IT service desk scenarios are covered, but it’s important to distinguish how you handle a resolved issue awaiting closure vs. an unresponsive customer preventing resolution of their incident. I would put the ticket in an ‘awaiting customer’ status for the latter (stop the SLA clock) and use multiple contact methods over 1-2 weeks for the latter. I’m more in favor of notify, wait five days, and auto close for confirmation of a resolved issue. (That may often mean a remote fix or resolved with a tech on the phone).”
Michael Keeling – “A provider needs to accept that responses will not always be provided to the IT service desk; the action to take has to fit the reason the response is needed. If you need a response in order to progress with investigating or progressing resolution, then you must decide how many attempts to obtain it make sense, and how long it is practical to wait. If you do not place limits, you will inevitably build a backlog of unresolved, and often never will be resolved, incidents…because you simply are not going to always get responses. This is mainly in the case of ‘single user’ issues, since those that actually impact the wider business are not going to typically get away with just sitting there; someone is going to be involved. For individuals, well, maybe they solve it themselves, or someone with them does, and they move on. At the practical point, you need to as well.
As to the “Is your incident resolved?” response, again, it’s the single-user issues for which things are now working…and so, they move on. I promote a time period for the IT service desk – and not weeks, but days – in which they can respond if they choose. The rationale for this is that the longer you leave that record sitting, the more likely it is it will be used for something other than the original purpose…a recurrence of an issue (after originally actually being resolved), or worse, a different issue. Both should be a new incident…but won’t be if there is already a record open.”
John Custy – “I think we need to readdress the real challenge, focusing on reducing/eliminating the issues, not just automating the resolution. I see IT service desk automation (in this scenario) as the intermediate step in resolution, not the final step.
As for responding, how does responding provide value to the customer? If I communicated with supply and confirmed the fix, additional communication seems to waste my time and confirm that support groups don’t talk to each other, unless the communication specifically communicates why the additional confirmation is needed.”
So what should your IT service desk do when the end user doesn’t respond? It really does depend. But hopefully, the collective wisdom above will give you some ideas about how to best deal with unresponsive end users, and the impact on IT service desk operations and performance measurement, within your organization.
This IT service desk article was originally written in 2016 and was last updated in 2023.
Further Reading
Stephen Mann
Principal Analyst and Content Director at the ITSM-focused industry analyst firm ITSM.tools. Also an independent IT and IT service management marketing content creator, and a frequent blogger, writer, and presenter on the challenges and opportunities for IT service management professionals.
Previously held positions in IT research and analysis (at IT industry analyst firms Ovum and Forrester and the UK Post Office), IT service management consultancy, enterprise IT service desk and IT service management, IT asset management, innovation and creativity facilitation, project management, finance consultancy, internal audit, and product marketing for a SaaS IT service management technology vendor.
2 Responses
I think the 3-srike rule is pretty prevalent, try to contact the customer on 3 occasions, different times of the day and days of the week to allow for holiday, shift patterns etc and by different medium – chat, phone, email. Then if no response move the incident ticket to resolved – not closed. Give a further 5-7 days before moving to closed – assumes a further email sent when the incident is resolved so the customer has a final chance to reopen. A good article, thanks for posting The Practical Service Manager
Clinck On The Given Link To Read More Such Post.
[email protected]