Home › Topics › First Contact Resolution › Raising It

Raising First Contact Resolution Without Cherry-Picking

Thursday, 14:20, at Redbrook Engineering. Marcus, on the first line for eight months, takes a ticket from Elena in the drawing office. She has joined the bridges team and cannot open their shared folder. Marcus can see the folder, can see the group that grants access, and can see that Elena is not in it. He knows exactly what needs to happen. He is not allowed to do it. He writes a polite note, escalates the ticket to the second line, and tells Elena someone will be in touch. The next morning Rafael on the second line adds her to the group, which takes him ninety seconds. Elena, who has by then borrowed a colleague's login to get her work done, replies "thanks" to a ticket she has stopped caring about.

Elena asked once and waited a day for ninety seconds of work that the person she asked could have done on the spot. That is what a low first contact resolution figure looks like from inside one ticket. And raising first contact resolution means removing whatever stopped Marcus finishing. That could be knowledge he did not have, permission he was not given, a tool or a template he was missing, or information the requester did not supply. It does not mean arranging the tickets so that the first line only sees the ones it can finish. That is the cheat this article's title refers to and the last section refuses. This article is part of our First Contact Resolution series. The number itself and its counting rules are in Measuring First Contact Resolution Honestly. This article assumes the count is honest and asks how to move it.

It covers where first contact resolution is lost, in four causes, and knowledge at the first touch. Then come permissions for the first line and the five fixes a first-line technician should be allowed to make. Next come templates, scripts and information, routing that helps and routing that cheats, and what not to do. The article then covers reading the per-person figure for coaching and a worked quarter at a fictional desk. It ends with a short war story and the improvement plan to copy, in that order.

Where First Contact Resolution Is Lost

Every ticket that fails to resolve on first contact fails for one of four reasons, and the first job is to find out which. The first person did not know how to fix it. The first person knew how but was not allowed to. The first person knew how and was allowed to but lacked a tool, a script or a template that would have made it possible in the time available. Or the first person had everything except the information from the requester, and had to ask a question that turned one contact into two. I have never found a fifth reason that was not one of these four wearing a hat.

The way to find out which is to read the escalations and the call-backs, not the successes. Take a month of tickets that were handed off or needed a second contact, and for each one write a single word: knowledge, permission, tool, or information. If the handoff note says "second line please", write to the technician and ask what stopped them. Most will tell you honestly, and the answers cluster fast. A desk that does this for one month knows where its first contact resolution is going, which is more than most desks know after a year of watching the number.

The clustering matters because the four causes have different fixes with different costs, and the cheapest is rarely the one people reach for. Knowledge is fixed with runbooks and takes weeks. Permission is fixed with a decision and takes an afternoon, plus the argument. Tools take a budget or a script. Information is fixed on the request form and in the first reply. At Redbrook, when Jo, the desk lead, did the exercise, a third of the escalations said "permission". The whole desk had been assuming the problem was training.

Knowledge at the First Touch

Knowledge at the first touch means that when a ticket arrives, the steps to fix it are a search away for the person who took it. They are not a question away for someone else. The unit of this is the runbook: a one-page set of steps for one fault that a competent stranger could follow, written by the person who last fixed it. The first twenty to write are the twenty faults that the first line most often hands off with the word "knowledge" beside them. The method for choosing and writing them is in The First Twenty Articles. Nothing in this article improves on that; it only says which twenty.

The runbook has to be where the technician is looking, and the technician has to look. The first is a matter of putting internal articles in the same tool as the tickets, or one click from it. The knowledge base may let an article be visible to agents only, as it does in QuerySolv and in most tools. In that case, the runbook sits beside the public article without the requester seeing the admin steps. The second is a habit: search before you escalate. Habits are built by making the search cheap and by the desk lead asking "did you look?" in a tone that expects the answer to be yes. A runbook nobody opens raises nothing.

Pair every escalation with a capture. When the second line fixes a ticket the first line could not, the resolution note is the draft of the runbook that would have let the first line fix it. The capture habit is to write that draft while the fix is fresh rather than on a documentation day that never comes. Over a quarter the escalations write the runbooks that stop the escalations, which is the only self-funding improvement programme I know of. It still needs someone to insist on it, because escalations are urgent and runbooks are not.

Permissions for the First Line: The Five Fixes

Permission is the cause that costs least to fix and is fixed last. That is because it needs a decision by someone who is not on the desk and who hears "give the first line more rights" as a risk. The honest answer is that it is a risk, a small one. It is managed the same way as every other risk: by naming exactly what is granted, writing down the guardrail, and logging every use. The phrase to know is least privilege, which means a person holds the rights their job needs and no more. Least privilege is an argument for giving the first line the five rights below as much as for withholding the rest. Elena's group membership was within the first line's job. The right to grant it was not, and the gap cost a day.

The table lists the five fixes that a first-line technician at Redbrook is now allowed to make. It includes what each needs and the guardrail that made the decision easy. They are Redbrook's five, worked out from a month of "permission" escalations. Your five will overlap and differ, and the method is the same. Each row is a right that is narrow, logged and reversible, which is the test a cautious manager should apply before signing.

Fix the first line may makeWhat the first line needsThe guardrail
Unlock an account or reset a password for a standard userReset rights over ordinary user accounts, not administrative or service accountsIdentity confirmed and the method noted in the ticket; privileged accounts stay with the second line
Add a user to a standard group or shared mailboxMembership rights over a written list of groups that grant ordinary accessThe list is owned and reviewed; anything off the list is a request needing approval; the addition is noted on the ticket
Fix a printer: clear a stuck queue, reinstall the driver, map the printerRights over print queues and the driver packagesNone beyond logging; the ticket records which printer and what was done
Install software from the approved listThe approved list, the installers, and the right to run them on user devicesThe list has an owner; anything not on it becomes a request, not a refusal
Repair a device's connection: re-enrol a VPN or wireless profile, renew a client certificate, clear cached credentialsThe runbook and the rights to re-enrol a deviceThe runbook says where to stop; a device that fails the runbook twice goes to the second line

Templates, Scripts and Information

The third cause, the missing tool, is usually smaller than it sounds: not a product to buy but a reply to write once or a fix to script once. A template is a reply written in advance for a fault that recurs, with blanks for the specifics. Its job here is to let the first-line technician give a complete fix and a complete explanation in one message. That replaces a quick fix now and an explanation later. The templates a desk needs for its twenty commonest faults are the subject of The Twenty Templates Every Desk Needs. The ones that raise first contact resolution are the ones that end with "this is fixed" rather than "let us know".

A scripted fix is a repair the technician would otherwise do by hand in six steps, wrapped so that it runs in one. The fixes worth scripting are the ones the first line does every week and sometimes gets slightly wrong. The method, and the guardrails that keep a scripted fix from becoming a scripted outage, are in The Ten Fixes You Repeat Every Week. For first contact resolution the point is time: a fix that takes thirty minutes by hand becomes a call-back. The same fix in three minutes happens while the requester is still on the line.

The fourth cause, missing information, is the one the requester can see you working on. If the first reply to a printer ticket is always "which printer?", the request form should ask which printer. If the first reply to an access ticket is always "which folder?", the form should ask for the folder. Every question the first line asks in every third ticket is a field the form is missing. The way to design the form without losing the requesters who fill it in is in A Request Form People Will Finish. (The form will not get everything. It will get the printer.)

Routing That Helps and Routing That Cheats

Routing is how a new ticket reaches the person who works it. There is a version that raises first contact resolution honestly and a version that fakes it. They look alike from a distance. The honest version sends the ticket to the person who can finish it, on the first assignment, before anyone has touched it. It sends the hardware fault to the technician who carries the spares. It sends the finance application error to the technician who knows that application, and the department's own tickets to the department's own queue. The requester still asks once. The first owner still finishes. The number rises because the right person got there first, which is what routing is for. The choices between round-robin, skill-based and claim-based assignment are laid out in Round-Robin vs Skill-Based vs Claiming.

The cheat is the pre-screen. A triager, or a rule, sends every ticket that looks hard to the second line before the first line has seen it. The aim is for the first line only ever to handle tickets it can close in one reply. The first line's figure goes up. The desk's figure does not move. That is because under the counting rules in this series a handoff anywhere breaks the chain. A ticket that started on the second line still had to be finished there. What has changed is that the second line's queue has grown, the first line has stopped learning, and the requester with the "hard" ticket waits as long as before. The test is simple: read the desk-wide figure, never the first-line slice alone. A slice can be arranged. The desk cannot.

Where ownership is claim-based, a technician takes a ticket by claiming it rather than being handed it. In that setup, the honest and the cheating versions become easier to tell apart. That is because every ticket shows who claimed it and whether it changed hands. QuerySolv works this way, as do a number of tools. The effect on this number is that a handoff is a visible act rather than a quiet reassignment. That does not stop a pre-screen. It does make one impossible to deny.

What Not to Do

Do not set a first contact resolution target for the first line alone. Not as a stretch goal, not "just to motivate", not for one quarter. A target on a slice of the desk moves the slice. The ways of moving it are all cheaper than fixing anything: route the hard tickets away, close on the first reply, discourage the reopen. The desk-wide figure, read with its pairs, can carry an expectation; a slice cannot carry a target without bending.

Do not shrink the denominator to flatter the result. Procurement, hardware repairs and approvals cannot be fixed on first contact. The temptation is to take them out so that the desk "is only measured on what it can control". Leave them in the desk-wide figure and read them separately by category, which is what the next article in this series, First Contact Resolution by Category, is for. A desk that excludes its hard tickets has not raised its first contact resolution; it has changed the subject.

Do not reward closing on the first reply. Do not make reopening a ticket awkward for the requester. And do not let "I have sent you an article" count as a fix. Each of these raises the figure for a month and lowers it afterwards, when the reopens arrive and the satisfaction score follows them down. The fifth article in this series is about what that looks like. The only honest way to raise the number is to let the first person finish more tickets. Everything else is a way of counting fewer.

Reading the Per-Person Figure for Coaching

A first contact resolution figure per technician is useful for one thing: finding the cause that is stopping one person. It is useless and harmful for ranking. Two technicians on the same desk get different mixes of tickets, different shifts, and different departments. A difference between them is usually a difference in their queues before it is a difference in them. Read the figure per person for coaching only, and never put it on a wall, in a league table or in an appraisal as a number. The desk that does this will get a higher number and a worse desk, in that order.

Before reading a per-person figure at all, insist on a minimum sample. At Redbrook the rule is forty tickets of a comparable kind in the period, and Jo would rather have sixty. Below that, two unlucky tickets move a person's figure by several points and the conversation that follows is about noise. Above it, the useful question is not "why is your figure low?" but "here are the twelve tickets you handed off last month; what would have let you finish each one?" The answers are the four causes again, for one person. The fix is usually a runbook or a right, not a talk about effort. Marcus's twelve, when Jo read them with him, were eight permission, three knowledge and one that genuinely needed Rafael.

A Worked Quarter at Redbrook Engineering

Here is Redbrook's quarter, invented for this article, with the numbers kept as ranges because the method is the point. Before the work began, the desk-wide figure had sat at a little over a third for three months, around 140 of roughly 420 tickets a month under the counting rules sheet. Jo read one month's handoffs and call-backs, about ninety tickets, and wrote a word beside each. Thirty-one said permission, and twenty-four said knowledge. Eighteen said the device had to be in hand, and seventeen were genuinely second-line work. The permission pile was the biggest and the cheapest, so it went first.

The five rights in the table above took one meeting with the infrastructure lead and a written guardrail per row. The first line had them within the fortnight. The following month the desk-wide figure moved to somewhere between two in five and a little under half, around 180 to 190 of a similar volume. The reopen rate was flat, which is the check that the rise was real. The knowledge pile became the first twenty runbooks, written from the second line's resolution notes over the quarter. The figure moved again, more slowly. Redbrook did not reach any particular number and was not trying to. It was trying to make Elena's ticket take ninety seconds instead of a day, and by the end of the quarter it did.

Remember: first contact resolution rises when the first person who answers can finish more tickets. The only honest ways to do that are knowledge, permission, tools and information at the first touch. Read the desk-wide figure with its pairs; never set a target on the first line alone.

A Short War Story: The Pre-Screen at Bellweather Logistics

At Bellweather Logistics, a service manager called Fatima inherited a first-line target of four in five for first contact resolution. It was set by her predecessor and printed on the team's wall. The triager, who wanted the team to hit it, began routing anything with "server", "VPN" or "application" in the subject straight to the second line unseen. Within two months the first-line figure read a shade over four in five. Meanwhile, the second line's queue had grown by about sixty tickets and its lead had stopped speaking to the triager. One of the pre-screened "hard" tickets, Fatima found when she read the pile, was a user asking how to change the signature in her e-mail application. The desk-wide figure, when she counted it, had fallen slightly, because tickets the first line used to attempt and sometimes finish were now never attempted. The cost was a quarter's backlog on the second line and a first line that had stopped learning anything. A target on a slice moves the slice, and the desk pays for it somewhere you were not looking.

The FCR Improvement Plan

The plan below is one page per quarter, filled in by the desk lead from one month's reading of the handoffs and call-backs. Section A is the reading. Section B picks the cause to attack first, which is nearly always the biggest pile with the cheapest fix. Section C is the change, one or two at most, with an owner and a date. Section D is the check that the rise was honest. It is deliberately short, because an improvement plan with nine actions is a wish list. Fill it in, do the one or two things, recount, and fill in the next one.

FIRST CONTACT RESOLUTION — IMPROVEMENT PLAN, ONE QUARTER
Desk: ______________________   Prepared by: ______________________   Quarter: ____________

A. THE READING (one month of handoffs and call-backs)
   Tickets handed off or needing a second contact in the month ................ ____
   Of these, the first person was stopped by:
      knowledge (did not know how) ............................................ ____
      permission (knew how, not allowed) ...................................... ____
      tool (no template, script or access to the device) ...................... ____
      information (had to ask the requester a question first) ................. ____
      genuinely second-line work .............................................. ____
   Desk-wide figure under the counting rules sheet: ____ of ____ tickets, about ____
   Paired with: reopen rate ______   satisfaction ______

B. THE CAUSE WE ATTACK FIRST
   Cause: ______________   Why first (biggest pile / cheapest fix / both): ______________________
   The ten tickets that show it best: ____ ____ ____ ____ ____ ____ ____ ____ ____ ____

C. THE CHANGE (one or two, no more)
   1. ______________________________________________   Owner: __________   By: __________
      For a permission: the exact right ______________   Guardrail: ______________________
      For knowledge: runbooks to write ____  from which tickets ______________________
      For a tool: template / script / form field ______________________
   2. ______________________________________________   Owner: __________   By: __________

D. THE HONESTY CHECK (next count)
   [ ] Same counting rules sheet, same window, same date rule
   [ ] Denominator unchanged: no category or ticket type removed
   [ ] No routing change that sends tickets past the first line unseen
   [ ] Reopen rate did not rise with the figure
   [ ] Satisfaction did not fall with the figure
   [ ] Per-person figures read for coaching only, above the minimum sample of ____ tickets
   Desk-wide figure after the change: ____ of ____ tickets, about ____

Jo's first plan at Redbrook had one change on it, the five rights, and the honesty check passed on the next count. The second plan had the runbooks. The third, which she has not written yet, will probably be about the device-in-hand pile. That is where the figure stops being a first-line question and becomes a question of how fast a technician can reach a desk. Marcus, who started this article escalating a ninety-second fix, now adds the group membership himself and notes it on the ticket. He has started writing the runbook for the one he still cannot do. That is what raising the number looks like from inside one ticket.

Frequently Asked Questions

The infrastructure lead will not give the first line any extra rights. What now?
Bring the pile, not the argument. Show the month's permission escalations as a list of tickets with the wait each one cost the requester. Propose one right, the narrowest, with its guardrail written out and a review date. A single logged, reversible right granted for a quarter is a much easier yes than "more rights". Once the log shows it was used properly the second right is easier still.
Is skill-based routing a form of cherry-picking?
Not if the ticket goes to the person who will finish it and that person is its first owner. The requester still asks once and one person completes the work, which is exactly what the number is meant to reward. It becomes cherry-picking when tickets are routed past the first line to protect the first line's figure rather than to reach the fixer. The desk-wide count, which treats every handoff the same, shows the difference.
How long before an improvement shows in the number?
A permission change shows in the next full month's count, because the tickets it affects are resolved differently from the day it takes effect. Runbooks show over a quarter, as they are written and found. Form changes show as soon as the new form is live, in fewer first replies that ask a question. Always wait for the reopen window to close before reading any of it, and read the reopen rate alongside.
Should the triager try to fix tickets before assigning them?
Only if the desk's counting rules treat a triager who works a ticket as its first owner, and only if the triager has time. A triager who attempts fixes and runs late on the sort has made the whole desk slower. On most small desks the cleaner arrangement is a triager who sorts and assigns quickly to the person who can finish, and a first line with the knowledge and rights to finish. The number rewards the finish, not the attempt.
We have no second line. Who do we hand off to, and does the number still mean anything?
A desk with no second line still hands off to vendors, application owners and the infrastructure team. It still has call-backs and second contacts. So the number measures the same thing: how much the first person can finish. The four causes apply unchanged. The fixes are the same, with "permission" often meaning rights the infrastructure team holds and could delegate.
Can we show per-technician first contact resolution to the technicians themselves?
Each person can see their own figure with their own handoff list, in a one-to-one, above the minimum sample, framed as "what would have let you finish these". Do not show the team's figures side by side, and do not put any of them on a screen or a wall. The moment the figure is comparative, the cheapest way to improve it is to avoid hard tickets, and the desk will find that way.

From the QuerySolv team: we build self-hosted help desk software for Windows. QuerySolv runs as one Windows service on your own network. It takes requests by web form, e-mail, live chat, social messages and REST API. It is licensed once per installation rather than per agent per month. The free trial runs the full product for 30 days.