Metric Gaming and Its Cures: Fix the Incentive, Not the Technician

Monday, 17:40, at Northgate Retail. Sam, who runs the five-person support desk for ninety stores, is looking at the best first-response figure the desk has ever had. Three months ago the regional operations manager set a target: ninety-five tickets in a hundred answered within the hour. The desk has hit it every month since, climbing from about seventy in a hundred to ninety-seven. Sam should be pleased. Instead he is reading ticket 58211, from the manager of the Harbor Street store, about a till that will not print receipts. Created 10:02. First reply 10:04: "Thanks for your ticket, we're looking into this." The next thing that happened on the ticket happened six days later. He opens another. Same reply, two minutes, then silence for four days. The template is called "Ack-1h". It has been used on 240 tickets this quarter. Nobody has cheated. Everyone has hit the target.

Metric gaming is improving a number without improving the thing the number was meant to measure. It is not usually fraud and it is almost never malice. It is people doing exactly what a target told them to do. This is the oldest observation about measurement there is: the moment a measure becomes a target, it stops being a good measure. This article is part of our Helpdesk Metrics That Matter series. It takes each of the six metrics the series tracks, shows how it gets gamed, says why, and gives the cure. Throughout, the cure is aimed at the incentive. The technician who found the shortcut did what the target asked. The target is the problem.

It covers why people game and why it is not a character flaw. Then come the gaming moves one at a time: closing fast, parking tickets forever, splitting and cherry-picking, and steering the survey. Next come the three cures: pairing, sampling and removing the incentive. Then come the conversation to have when you find it, a short war story, and the gaming and cure table to copy.

Why People Game, and Why It Is Not a Character Flaw

People game a metric when the metric has become the thing they are judged on, and the honest route to a good number is slower than a shortcut. That is the whole mechanism. Take a technician with a target of one hour to first reply, a queue of forty tickets, and a template that satisfies the target in two minutes. That technician is not making a moral choice at 10:04 on a Monday. They are clearing the target so they can start the work. The target, which was supposed to measure whether requesters heard from a person, now measures whether a template fired. The number is true. The desk is no faster. The requester at Harbor Street still has a till that will not print.

Gaming follows targets, not metrics. A desk that merely reads its first-response median each month, as one of six numbers, gets a modest amount of gaming. That is because nobody's standing depends on it. A desk that posts the figure per person, sets a threshold, and mentions it in reviews gets a great deal, within weeks. It gets it from its most conscientious people first, because they are the ones who take targets seriously. If you want to know which of your metrics is being gamed, look for the one with a target on it. If you want to know which one will be gamed next, look for the one you are about to put a target on.

This is why the cures in this article do not include "catch the technician". Catching the person who found the shortcut and leaving the target in place produces a quieter shortcut, found by someone else. The cures work on the system. Read the number with its partner so the shortcut shows. Read a sample of real tickets so the number cannot hide behind itself. Take away the reason to game in the first place. I have gamed a metric myself, as a junior technician, by resolving tickets the moment I sent a fix and before anyone confirmed it. That was because resolution time was on a wall and reopens were not. I was quite proud of my resolution time. Nobody measured the reopens, so nobody told me.

Closing Fast: The Early Resolve and the Empty Acknowledgement

The two speed metrics, first response and time to resolution, are gamed by stopping the clock before the work is done. For first response, the move is the acknowledgement template. It is a reply that is sent to the requester, so it counts. It says nothing except that the ticket exists, so it costs nothing. Northgate's "Ack-1h" is the pure form. The number it produces is real, in that a reply did go out within the hour. It is empty, because the requester learned nothing they did not already know from the automatic acknowledgement. The tell is the gap between the first reply and the next thing that happened on the ticket. At Northgate the median gap was two and a half days. The requester had been answered inside an hour and then ignored for a working week, and the metric was delighted.

For time to resolution, the move is the early resolve. The ticket is marked resolved when the fix is sent rather than when it is known to work. Or it is marked resolved while asking the requester to confirm, so that the clock stops on the question rather than the answer. It is the most natural gaming move on any desk, because a technician who has just sent a fix genuinely believes the ticket is done. The status is one click away. The early resolve shows up as reopens and as "any update?" replies arriving on resolved tickets. If the tool creates a new ticket when a requester replies to a resolved one, it shows up as duplicates. Those are tickets from the same requester about the same thing a few days apart. Where a requester's reply reopens a resolved or closed ticket, as it does in QuerySolv and many tools, the early resolve turns into a reopen on its own. In that case, the reopen rate tells the story. Where a reply does not reopen the ticket, the story is in the duplicates, and somebody has to go looking.

The cure for both is the same shape. Pair the speed number with the number that catches the shortcut. Pair first response with satisfaction and with the gap to the next update, and resolution time with the reopen rate. Never show either speed figure without its partner on the same page. Then change what counts. A first response counts when it tells the requester what will happen next and roughly when. A desk can measure that by reading a sample, which the next cure covers. A resolve requires a resolution note that says what was wrong and what was done. Writing that note takes a minute. That is exactly the minute the early resolver was saving. The proper close, with the confirmation that makes "resolved" mean something, is set out in what a proper close looks like. A desk that follows it has made the honest route the fast one.

Pending Forever: Parking Tickets Where the Clock Does Not Look

A waiting status is any status whose meaning is that the next move belongs to someone other than the desk: waiting on the requester, waiting on a supplier, on hold. Tickets in a waiting status are usually excluded from the active queue and often excluded from the resolution clock. They are almost always excluded from whatever number is on the wall. That makes a waiting status the most comfortable place on the desk to put a ticket you do not want to be measured on. The move is to ask the requester a question, any question, and set the ticket to waiting. If they answer, ask another. The ticket is never slow, because the clock is stopped. It is never reopened, because it was never resolved. It is never in anyone's figure, and it is never fixed.

It shows up in the one place most desks do not look: the count of tickets in waiting statuses, and their age. A desk with thirty active tickets and a hundred and sixty waiting ones has not got thirty tickets. It has a hundred and ninety, and the waiting ones are older. The sharper tell is a waiting ticket with no date, because a genuine wait has an answer to "waiting for what, and until when?", and a parked ticket does not. The third tell is a requester reply that landed on a waiting ticket and did not change its status. Some tools change the status and some do not. Test that with a reply from a personal address before trusting any waiting count at all.

The cure is to make the waiting status visible and dated. The backlog metric includes every waiting status in its age bands, measured from creation. So a ticket parked for nine weeks is a nine-week-old ticket on the report and not a well-behaved absence. Every waiting status carries a follow-up date, and a ticket past its date returns to active on its own or in the weekly sweep. The sweep itself, which reads the waiting view oldest first and asks each ticket what it is waiting for, is in the stale ticket sweep. Once waiting time counts towards age and waiting tickets are read weekly, parking a ticket stops being a way of hiding it and becomes a way of being asked about it. That is the opposite incentive and the right one.

Splitting Tickets and Cherry-Picking: Making the Count Lie

The count metrics, tickets created and tickets closed, are gamed by changing what a ticket is. Splitting is the move of turning one request into several tickets. The new starter who needs an account, a laptop and a phone becomes three tickets, each closed quickly, each counted. There are honest reasons to split, chiefly that the three parts go to three different people. The sheet in defining each metric exactly should say when a split is right. The gaming version splits when nothing is going anywhere different. It shows up as clusters of small tickets from the same requester within the same hour, and as a rising created count with a flat number of requesters.

Cherry-picking is the move of choosing which tickets to take so that your own numbers look good. For example, you take the password resets before the printer that has been broken three times. You take the quick question before the ticket from the warehouse with the word "intermittent" in it. Every desk with a shared unassigned queue and per-person numbers has some of it, because claiming the easy ticket is both rational and invisible. It shows up as the oldest unassigned ticket being hard, every time. The age of tickets in the difficult categories grows while the easy categories stay fast. And one technician, usually the most experienced, holds all the tickets nobody else wanted and the worst figures on the desk as a result. The person with the worst numbers on a cherry-picking desk is very often the person doing the most valuable work. A per-person count has no way of knowing that.

The cure for both is to stop counting per person as a score. Team volume in and out is the metric. Per-person counts are for the lead, privately, for balancing and coaching. They are read only above a minimum sample such as twenty resolved tickets in the period, and never ranked or displayed. The reasons are laid out in vanity metrics to ignore. The short version is that a closed count on a wall gets you what it counts and it never counts the hard ticket. Beyond that, use a claiming rule of oldest first. Use a rotation that hands the hardest ticket of the week to someone with the senior technician watching. Add a way of flagging the ticket nobody wants to the lead without inflating its priority. That could be an escalation flag kept separate from priority, a tag, or an internal note addressed to the lead. The point is that the unwanted ticket becomes the lead's business within a day rather than the queue's problem for a month.

Steering the Survey

Satisfaction is gamed by choosing who gets asked and how. The crude move is to send the rating request only to requesters who seem pleased. Or it is to resolve a ticket only once the requester has said thank you, so that the survey goes out on a good note. The subtler move is the resolving reply that says "if you were happy with this, please rate us five", which a surprising number of people will do out of politeness. The subtlest is the technician who, knowing a particular requester is annoyed, hands the ticket to a colleague to resolve. That way, the rating lands on someone else. Or the technician lets it drift to a waiting status, where no survey is ever sent.

It shows up in the response rate and the shape of the ratings rather than in the score. A steered survey has a response rate that moves oddly, higher for some technicians than others with no good reason, or falling overall as fewer tickets reach resolved. The ratings cluster at the top with no comments, because a requester asked to rate five rates five and says nothing, while a requester asked honestly says something. And the comments, which are the only part of a satisfaction survey that tells you what to fix, dry up. A desk whose score rose and whose comment count fell has not got happier requesters. It has got quieter ones.

The cure is to take the choice out of human hands. The rating request goes out with every resolving reply, automatically, to every requester, with the same wording. The technician cannot send it or withhold it. If you run QuerySolv, the rating request goes out with the resolving reply and the results appear in the standard reports, which removes the choosing. In any tool, check who decides whether a survey is sent, and if the answer is the technician, change it. Then never set a per-person satisfaction target. Read the score beside its response rate. Treat a low rating as the beginning of a conversation with the requester and the start of coaching for the technician rather than a mark against them. The methods for both, and for reading around who tends to answer, are in the Measuring Satisfaction series.

The Three Cures: Pair It, Sample It, Remove the Incentive

Pairing is the first cure and the cheapest. Every number that could be improved by a shortcut is read, on the same page and in the same breath, with the number the shortcut damages. Read first response with satisfaction and the gap to the next update, and resolution time with reopens. Read closed count with backlog age, and satisfaction with its response rate. The pairs are the subject of reading metrics together. The rule for gaming is simpler than the full read. A number that improved while its partner got worse did not improve. Northgate's first response fell from hours to minutes while its satisfaction fell from thirty-one good ratings in forty to twenty-two in thirty-eight. The pair said what the number alone could not.

Sampling is the second cure and the one that catches what pairing misses. Once a month, pick ten resolved tickets at random, not the worst ten and not the ones anyone is worried about. Read them: the request, the first reply, the resolve, the note. Use a method that cannot be steered, such as every ticket whose number ends in a seven. A reader can tell within thirty seconds whether the first reply said anything and whether "resolved" was resolved. Ten tickets a month is enough to know whether a figure is honest without being enough to feel like surveillance. Read the five oldest waiting tickets in the same sitting. The complete event history on each ticket is where this reading happens. It is why the sample works: the number can be gamed, but the history of what actually happened on the ticket, and when, cannot be made to say something else.

Removing the incentive is the third cure and the only one that lasts. No target on any single number, ever. If the desk must have targets, they are set on pairs, so that hitting one by damaging the other is a miss. No per-person targets on any of the six, and no per-person figures displayed, ranked or mentioned in reviews. Per-person numbers are for coaching, privately, above a minimum sample. Make the honest route the fast one. Use a first reply template that includes what happens next and when, a resolve that needs a one-line note, and a waiting status that needs a date. And reward what you actually want, which is reopen-free resolutions, hard tickets taken, and the oldest ticket on the desk getting younger. A desk that praises the technician who took the ticket with "intermittent" in it is a desk where the word stops being a deterrent.

• Every speed figure is shown beside its quality partner on the same page.
• Ten resolved tickets chosen at random are read each month, first reply and resolve included.
• The five oldest waiting tickets are read each month and asked what they are waiting for.
• No target sits on a single number; any target sits on a pair.
• No per-person figure is displayed, ranked or raised in a review; per-person reads are for coaching, above a minimum sample.
• Resolving requires a resolution note; a waiting status requires a follow-up date.
• The rating request is sent automatically to every requester, and no technician decides.

The Conversation When You Find It

When the sample turns up a technician whose first replies are all the template and whose resolves are all early, the conversation starts with the target and not the person. That is where the fault is. "I have been reading a sample of tickets and I have noticed the acknowledgement template is going out without a next step on a lot of them. I think the one-hour target did that, and I am changing the target. From next month we read first response alongside the gap to the next update, and the template has a line for when you will come back to them." That is the whole conversation, and it is short, because it accuses nobody of anything they did not do. The technician did what the number asked. The number is being corrected.

Resist the urge to make an example of anyone, even when the shortcut was obvious. An example teaches the team that the game is to not get caught, and the next shortcut is quieter. The exception is deliberate falsification, which is a different thing. Examples include editing timestamps or closing tickets unread in bulk against an explicit instruction. Another is marking tickets resolved for requesters who have said in writing that they are not. That is conduct, it is rare, and it is handled as conduct. Everything short of it is a technician responding to a system, and the system is yours to change.

Tell the team what changed and why, in plain words and in the same week. "We had a target on first response alone, and it got us fast acknowledgements and slower fixes, which is on me. We are reading it with satisfaction and the second-update gap from now on, and the target on the hour is gone." A lead who says this once will find that the team starts bringing gaming to them. That is because they have learned it is a design flaw and not a confession. A lead who never says it will keep finding shortcuts, one at a time, each slightly better hidden than the last.

A Short War Story: The Reopen Target at Meridian Parts

Meridian Parts gave its three-person desk a target of fewer than three reopens in every hundred resolved tickets, after a quarter in which the rate had crept past eight. Within two months the rate was below two. It had fallen because the technicians, led by Jonas, had stopped marking tickets resolved. A fix was sent and the requester was asked to confirm it worked. The ticket was set to waiting on the requester, where it was never resolved, never reopened and never counted. The waiting queue grew from about twenty tickets to a hundred and sixty over the quarter. One of them was from the warehouse, about pick lists printing with the wrong bin locations. It sat in waiting for five weeks after a fix that had not worked. Meanwhile, three pickers checked every list against the screen by hand. The warehouse manager later put the lost time at somewhere between thirty and fifty hours, plus one late delivery to an account that noticed. The desk found it when a new lead added waiting statuses to the backlog age bands and the report produced a number nobody could explain. Meridian dropped the reopen target and read reopens beside resolution time and the waiting count from then on. The rate settled at about five in a hundred, which was true. A target on one number does not remove the problem; it moves it to the number you are not watching.

The Gaming and Cure Table

The table is the template for this article. It has one row per metric, with the gaming move, where it shows up, the partner that catches it and the cure that removes the reason to do it. Pin it where the person who sets targets will see it, because it is written for them rather than for the technicians. Before any target is set on any row, read the row. If the cure column is not already in place, the target will produce the gaming column within a quarter, and it will produce it from your best people first.

Sam retired the "Ack-1h" template on the Tuesday and replaced it with one that had a blank for when the technician would come back. He took the one-hour target off the wall and put first response, satisfaction and the second-update gap on the same page of the monthly report. The first-response figure fell back to about eighty in a hundred within the hour, and the Harbor Street till was fixed on Wednesday. The regional operations manager asked why the number had got worse. Sam said it had got honest, and showed her the three columns, and she did not ask again.

Frequently Asked Questions