If I remember my ITIL* studies and exams correctly – well it was over ten years ago – an incident or service request should only be closed by the end user/customer. I understand the logic, as they’re the people best positioned to know if their IT issue has truly been resolved or their need has been met.
However not all IT shops 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 service desk environment.
Dealing with unresponsive end users
But this is something that happens once the incident has been resolved or the service request fulfilled. 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 progressing to meet the agreed service level targets for 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 is only a temporary measure that neither helps the end user nor accuracy of a service desk’s statistics. So what should you do if an end user isn’t responding to your request for information?
What would a 1990’s IT help desk have done?
Without doubt they would have quickly closed the ticket. They might have sent an email and a reminder. 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 because ITIL says that only an end user can close a ticket.
The cynical amongst you might see this as a little optimistic of 1990’s IT help desk behavior. I know from my personal 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 help desk tool, was often the black hole where your requests for help would go to die.
What do service desks do in 2015?
As you would imagine, and as many an ITSM consultant will tell you, “it depends.” I know that this is my experience. It will differ from organization to organization based on a number of factors, including:
- How the service desk, and wider IT organization, perceive end users – from technology users through to valued customers
- How service desk service level targets (and agreements) have been set up, if at all
- The ability 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 a service desk deal with end user unresponsiveness?
I posted the following to the Back2ITSM Facebook group, it’s far more productive than LinkedIn groups:
“Service (Help) 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:
James Finister – “There are three elements to consider. Firstly, do you 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. Secondly, 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 a user’s screen. Thirdly, the need for unambiguous reporting, which demands good status codes and the use of pivot tables.”
James Gander – “The service desk should try three times over three days to contact the user. If there is no response, resolve it as an appropriate category (such as “Unable to contact user”) and wait. If the 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 a desk number and leaving it at that.” Roy Atkinson agreed with James Gander, with that caveat of 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. They chase up the customer three times, and then close the ticket.”
Darren Hampton – “If we need 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 a closure code to indicate user non-response and sorely need one.”
John Custy – “I typically recommend 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/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 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.”
Kaz Ferris – “I think the most important aspect – whatever the approach taken 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 you 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 a 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 user of having the ticket closed? Probably zero (the value is in having the issue resolved). What is the value to the 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 you 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 you.”
So what should you do? 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 service desk operations and performance measurement, in your organization.
- ITIL is the ITSM best practice framework formerly known as The IT Infrastructure Library
