1:1 Phone Call to Ticket Ratio
Hi.
I am a Service Delivery Consultant and have a question about something that I regularly come across in my dealings with Service Desks.
9 out of 10 service desks that I am brought in to 'fix' have a phone call to ticket percentage of between 50% - 60% (i.e. of 100 phone calls received at the Service Desk only 50 - 60 new tickets are generated).
There are a raft of issues that this causes such as giving people an excuse as to why they are not raising tickets, it means that a lot of the first point of contact incidents are not logged, and if we only understand what 50% - 60% of our phone calls relate to then we're unable to put appropriate measures in place to address the other 40% - 50% of phone calls.
What I do is implement a 1:1 phone call to ticket ratio. This means that when a call such as a follow up call is made to the desk an extra ticket is logged and closed with the name of the assignment group being followed up in the description, and the CALL number being followed up in the call title (unfortunately we use HP Service Center and therefore use CALL records - these are Interaction records in later versions of HP Service Manager).
By doing this we always increase our ratio to around 95% of tickets being logged, with 10% - 15% of these being follow up calls. We are then able to go back to each of the resolver teams with a dollar figure (Cost per contact * number of follow up calls generated per team) of them not following up / managing their tickets appropriately. For example, one of our teams we receive 20 follow up calls for each day. Our Cost per Contact is $25 so we can then provide their management with this inormation (i.e. 20 follow up calls * 5 days * $25 per call - this means they cost us $2500 per week, or $10,825 per month, by not keeping on top of their tickets).
I receive a LOT of resistence from people saying that this shouldn't be done, usually the reason is that it is 'manipulating the reporting', or that it is not best practice....
And this is my question... is there a best practice model for this? And, if we aren't going to raise a new ticket for all phone calls then how else do we ensure all appropriate tickets are being logged?
Most people also see logging follow up calls as doubling up our work, but in my opinion it is a truer picture of what the desk are doing.. and of course allows you to identify which teams are costing the desk time & money.
Any thoughts on this would be appreciated..
Thank you!
bwash70
Dear bwash
You may have missed the fact that the ITIL Wizard is satire. Normally I'd leave you to the mercy of the Wizard, but you've put so much effort into the question that I feel we owe you a straight answer.
There's no "official" good practice for ticketing in ITIL. In fact it is distinctly ambiguous about the whole contact vs incident thing.
My short answer is that this is a business process design issue: it is the client's decision what they want recorded and reported.
A longer answer is that I applaud HP for creating a separate entity for interactions. This is as it should be, and many tools don't have it which means they can't report precisely the sort of data that you are referring to. But it only works if there is a separate Incident entity with a many-to-one relationship between Interactions and Requests/Incidents: I assume the HP tool has that. We MUST track Requests and Incidents.
When others object to tracking Interactions I can only assume either (a) they are confusing Interactions with Incidents or (b) they want to hide data. It is never a bad thing to make costs transparent except for those causing the costs.
That's my reply. Anyone else?
Good luck
Skep
Made in New Zealand 
Comments
Interactions, encounters and moments...
bwash, skep
My turf. What I am about to say is from the 2012 USMBOK - and the outside-in thinking.
Interactions come in different guises. They are generally encapsulated in an encounter and not separate 'records'. There are a minimum in a service encounter, including a greet and thank you. Some are critical to the customer perception of quality etc - they are termed moments of truth. These instrument satisfaction levels.
Back to your question in part. Touchpoints is another term for designed interaction points. It is important when designing a support experience and control the cost of support to take all these terms into consideration. As Skep suggests - there is no best practice or golden ratio for contact to tickets of any time. This is inside-out thinking!
What you need to do is to start to design a customer engagement strategy for each service encounter. BTW an encounter is analogous to a service request, and includes automated requests - such as placing an order through a kiosk/app.
Playing the math game of raising the number of calls or reported tickets to lower the average cost per call is plain dumb and meaningless - and more inside-out thinking designed to fail the customer and produce worthless 'finger in the dyke' stats. I agree - stop it!
Wow - we really have a very long way to go and much is thanks to where ITIL 'best practice' and vendor tools have steered us - yuck. Think customer first. Design your service support experience around customer outcomes, experience and satisfaction. Target the elimination of dumb, meaningless interactions that have no value from the customer perspective....
the exact opposite of what I meant
I disagree with all of that. You seem to have read into what I said the exact opposite of what I meant - that's a knack.
The Golden Ratio of contacts to tickets is 1:1. All interactions should be tracked.
From an outside-in perspective, this means we have a history of the contact with the customer, which is an essential aspect of the overall relationship.
From an inside-out perspective we have a record of effort expended and a mechanism of allocating cost. Ian you seem to take a religious position of seeing all "inside" activity as inherently unclean: internal mechanisms and processes have their place and we cannot function without them.
Second-best case is all contacts are recorded but as multiple records of contacts on a single Request/Incident ticket: at least they are still recorded and just maybe we can still extract the information from the database with clever reporting.
The "math game" that bwash was describing is also the opposite of what you said: the resistance is coming from those who want LESS records of calls, which would push the apparent cost-per-call UP, because they either don't want to be exposed as the generators of delay and hence callbacks, or they can't be arsed recording the calls. By properly recording all calls, we can see that the service desk is more efficient as the average cost per call falls and we can see what staff are spending their time on ("inside-out"). We can also identify the groups which are generating the most call-backs, thereby improving that bottleneck and delivering more effective response to the customer; and we can identify customers who call a lot and need better focus ("outside-in" and Lean).
We have no way of knowing from this description whether the interactions are "dumb and meaningless" or productive and caring. Either way we should have a record of them. It may be your turf but sometimes you wander over it in strange directions.
Polish it or fix it?
Quite. Is there a better place than the Service Desk to understanding the profile of customer support needs? And every point under 1:1 reduces the accuracy of that understanding.
Call and ticket stats are at the heart of a performing service desk. Every interaction should be tracked to help build the profile, subject to the normal cost-effort-value checks and balances of course.
As with timesheeting, it's the perception of the effort:value ratio that will cause most resistance. Find the story that answers the 'what's in it for me' questions. Automate as much as possible (ACD systems, ticket templates, self-service). Involve staff in the improvement vision, develop their sense of stakeholding. Introduce competition.
Service desks are the front line of IT service provision, building in the right customer outcomes is of course the basic requirement - but it can't be achieved without addressing the operation, and 'you can't manage what you can't measure'. Try producing a consistent performance without measuring demand and the associated effort. Try doing it without automating tools.