Experience Targets Beside Service Levels
Monday, 14:00, at Northgate Retail. Ingrid runs the desk for forty stores and a head office, and she is presenting the service-level table to the regional managers. It has four priorities, a response and a resolution target for each, all met for the third month running. Hamish, who manages the three largest stores, lets her finish. Then he says what he has been saying in the car park for a year: "You hit the targets. We still never know what's going on. My store managers raise a ticket and then they phone me, because the ticket doesn't talk." Ingrid's table has a column for response time and a column for resolution time. It has no column for whether anyone talked.
An experience target is a written promise about how getting help will feel, stated in plain words. It is measurable from the ticket or the survey, and kept beside the service level rather than in place of it. The service level says how fast: a first response inside an hour, a resolution inside a working day. It is the SLA when it is written down as a service level agreement. The experience target says what happens inside that time: the requester is kept informed, never has to chase, and understands the reply. Some people call a set of these an experience level agreement, by analogy with the service level agreement. The name does not matter and no vendor, institute or framework is needed to write one. This article is part of our Experience Over Metrics series. It sits beside the SLA Design series without redoing any of it. The service level is already designed there, and this article adds the second column.
It covers what the service level says and does not, then the three promises most desks should make. We cover writing a target so that it can be checked, then measuring each target from the ticket. Setting the level from measurement rather than ambition follows, as a worked example. We cover why the targets sit beside the service level and not instead of it, then what to do when the two disagree. Reviewing the targets comes next, then a short war story and the experience target set to copy, in that order.
What the Service Level Says, and Does Not
A service level is a promise about time, made per priority, and measured by a clock the desk controls. It says how long until the first response and how long until the resolution, counted in business hours. It is a good promise. It tells the requester what to expect and the desk what to work on first. When it is missed it tells everyone that something is wrong, which is why the series on what breaches teach exists. If you run QuerySolv, this half is already there: targets per priority on a business-hours schedule, with the response and resolution times in the standard reports. Nothing in this article weakens it.
What the service level does not say is anything about the inside of the time. A priority-two ticket with a one-hour response target is met by an automatic acknowledgement at zero minutes in some tools and by a template reply from "Support" in most. And the clock cannot tell either of those from a named person who read the ticket and gave a time. A resolution target of a working day is met by a fix applied in silence and marked resolved. And the clock cannot tell that from a fix the requester was told about, shown, and asked to confirm. The service level measures the two ends of the ticket. The requester lives in the middle.
Hamish's store managers are describing the middle. Their tickets are answered inside the hour and resolved inside the day. Between those two events they hear nothing, so they phone Hamish, who phones Ingrid. She looks at the ticket and sees that it is inside target. Everyone in that chain is right. The table was asked a question about time and answered it; nobody had asked it a question about silence, because there was no row for one.
The Three Promises Most Desks Should Make
The first promise is kept informed: no open ticket goes longer than a stated interval without a public message from the desk. And every message gives the next time. The interval is set per priority like the service level, shorter for urgent work and longer for the rest. And it is counted in working days from the last message the requester could see. Internal notes do not count, because the requester cannot see them. The promise is not that something will have changed by then. It is that the requester will hear from a person by then, even if the message is "no change, next word Thursday".
The second promise is never had to chase: no requester should have to write to ask what is happening. This is the kept-informed promise seen from the other side. It is stated separately because it is measured differently. Kept informed is measured by the gaps between desk messages. Never had to chase is measured by the requester's messages asking for status. A desk can meet the first and miss the second, if its interval is longer than its requesters' patience, which is how the interval gets tuned. A chase is evidence that the cadence was too slow for that ticket, whatever the sheet says.
The third promise is understood the reply. Every resolving message says what was wrong, what was done and what to try, in words the requester could repeat to a colleague. This is the only one of the three that cannot be fully measured from timestamps. And it is measured instead by reading, ten resolving replies a month, and by the effort question described in Measuring Experience Honestly. A reply that needs translating costs the requester effort after the ticket is closed, which is the worst time to charge them. "Perms corrected on share" is a reply the desk understood. That is not the test.
Three is not a magic number; it is the number of promises a small desk can keep in its head and check in an hour a month. Desks add a fourth later, often "introduced at every handoff" or "asked before every close", once the first three are habit. Start with three. A target set with nine promises is a document, and documents are kept in folders rather than in heads.
Writing an Experience Target
A target is written as one sentence with three parts. Those are the promise in plain words, the trace in the ticket that shows whether it was kept, and the level the desk is aiming at. "Every requester is kept informed: no open ticket goes more than two working days without a public update from the desk that gives the next time; measured as the share of resolved tickets with no such gap; aiming for nine in ten this quarter." The sentence can be read by a store manager, checked by a technician with the ticket list, and argued about at the review. That is the whole job of a target.
Adjectives are the enemy. "Requesters feel supported", "communication is excellent", "updates are timely": each is a sentiment with no trace. So it is met by whoever is describing it and missed by whoever is complaining about it. The review becomes a debate about feelings. Replace every adjective with a count that a stranger could reproduce from the tickets. "Timely" becomes "within two working days"; "supported" becomes "never had to write to ask". "Clear" becomes "ten resolving replies read, and in nine the requester could say what was wrong". If a target has no trace, it is a wish, and the desk will discover at the review that everyone had a different wish.
The wording is agreed with the people who will keep the promise, not announced to them. Ingrid's technicians argued for an hour about whether the kept-informed interval should be one working day or two, and the argument was the point. By the end of it everyone knew what the promise meant and why it was two for most tickets and one for the top priority. A target written by the desk lead alone is kept by the desk lead alone. (The technicians will read it. They will also read the tone it was written in.)
Measuring Each Target From the Ticket
Each of the three promises leaves a trace in the ticket. And the table below says what the trace is, how to count it, and how often. Two of the three are filters over the event history that most tools keep, every message with its author and time; the third is a reading. The counting takes a filter and an hour a month on a small desk, which is roughly what the service-level report takes. It should be done by the same person at the same time so that the two sit together from the start.
| The promise | The trace in the ticket | How to count it | How often | What it cannot see |
|---|---|---|---|---|
| Kept informed | The gap between consecutive public messages from the desk while the ticket was open | For each resolved ticket, the longest gap in working days; count tickets whose longest gap exceeded the interval for their priority | Monthly, on every resolved ticket | Whether the message said anything; a "still working on it" with no next time passes the filter and fails the requester |
| Never had to chase | A message from the requester, while open, asking for status rather than adding information | Count resolved tickets with at least one such message; read a sample to confirm the filter is catching chases and not answers | Monthly, on every resolved ticket | The requester who chased by phone or in the corridor; log those as a note on the ticket so the count sees them |
| Understood the reply | The resolving message, and any reopen or follow-up that begins with "what does this mean" | Read ten resolving messages a month at random; pass if they say what was wrong, what was done and what to try in plain words; add the effort answers and comments | Monthly, ten tickets plus the survey | Whether the requester actually understood; the survey and the follow-up conversation fill that gap, partially |
Note the right-hand column. Every measure has a hole in it, and the honest target set says where. The gap filter cannot read the update; the chase filter cannot hear the telephone; the reading cannot climb inside the requester's head. The holes are smaller than the hole in the service-level table, which cannot see the middle of the ticket at all. They are plugged, partly, by reading a sample and by the survey. A measure with a stated hole is a measurement. A measure that claims to have none is a slide.
Setting the Level From Measurement, Not Ambition
The level in each target is set after the first month of counting, never before. A target set from ambition is broken in its first week. A target set from measurement is a line the desk can see itself approaching. Here is Ingrid's first month, as a worked example from a fictional desk. Of 214 resolved tickets, 71 carried a chase, about one in three. 38 had a gap between public desk messages longer than two working days, about one in six. Of ten resolving replies read, four passed the plain-words test; six were written for a technician. The effort question, in its first month with 39 answers, had 14 saying it took some effort or was hard.
From those counts she set levels for the next two quarters rather than for the month. The chase target goes from one in three to fewer than one in five by the end of the quarter. The target is fewer than one in ten by the end of the one after. Gaps: none longer than the interval by the end of the second quarter, with one in twenty tolerated in the first. Replies: nine of ten passing by the end of the second quarter. The levels are ranges with dates, not points with decimals. And each is a step from where the desk is rather than a destination copied from somewhere else. No industry figure fits every desk. A desk that imports a target from a conference slide has imported a number with no idea what it cost the desk that hit it.
The first month's figures are also the baseline that the report will be compared against. So write them down with their counts and keep them. "Chases fell from 71 of 214 to 29 of 198" is a sentence that survives a sceptical director. "Chases are down" is not. The thinking behind which promises a desk should and should not make, in the service-level sense, is in What to Promise and What Never To. And the same rule applies here: promise what you have measured you can do, and nothing you have only hoped.
Why Beside and Not Instead
The service level and the experience target keep each other honest, and each fails in a known direction without the other. A desk with only a service level becomes fast and cold: the clock is what is measured. So the clock is what is served, and the one-word resolving message and the silent close are its natural products. Hamish's stores are a desk with only a service level. A desk with only experience targets becomes warm and slow. The updates are beautiful, and the requester is never left wondering. And the fix takes a fortnight because nobody is counting the fortnight. "We will keep you informed" becomes a thing the desk does instead of fixing the problem, which the requester notices around the third update.
Together, the two describe a ticket the way the requester describes it. It was fixed in a reasonable time, and I knew what was going on, and I understood what they told me. Neither half is the whole. A desk that reports both, side by side, has a row for Hamish's complaint and a row for the regional director's. When the two rows disagree it has learned something, which is the subject of the next section. A desk that reports only one has a column it cannot be wrong in and a car park full of people who know better.
There is also a practical reason for beside rather than instead. The service level is usually already agreed, written down and reported, and sometimes written into contracts with other departments. The method for the document is in Writing the SLA Document. Replacing it would mean reopening every one of those agreements. Adding a page to it means one review. The experience targets go on the page after the service-level table, with the same owner and the same review date. And the desk-level expectations the requesters are told about, in the sense the managing-expectations series gives that phrase, gain three sentences. Beside is cheaper. It is also more honest, because the two measurements are measuring different things, and pretending one replaces the other is how desks end up measuring neither.
Remember: the service level promises time and the experience target promises the inside of the time: kept informed, never had to chase, understood the reply. Write each target with its trace in the ticket, set the level from the first month's count, and report the two tables on the same page.
When the Two Disagree
Service level met and experience target missed is the commonest disagreement, and it means the desk is fast at the ends and silent in the middle. The tickets inside target with a chase on them are the ones to read. Almost always the failure is at one of the five moments, usually the waiting update, sometimes the handoff. The fix is a habit rather than a resource. This disagreement is good news in disguise: the desk has the capacity, but it is spending it in the wrong place. And the sentence that fixes it takes a minute per ticket.
Service level missed and experience target met is the second shape, and it means the desk is talking to requesters well about tickets it cannot finish. The updates are arriving, nobody is chasing, and the resolution clock is running out anyway. Read the missed tickets for the reason: a part, a vendor, an approval, or simply a queue longer than the people in it can clear. The first three are an honest wait that the experience target is managing as well as it can be managed. The fourth is a capacity problem, and no cadence of updates fixes a capacity problem. The cadence only makes the requester's wait more comfortable, which is worth doing and is not a solution. The experience measure will tell you the desk is overloaded before the service level does. That is because it will be met by technicians writing kind updates about tickets they have no time to touch.
Both missed means stop measuring and fix the queue; nothing about experience is learned from a desk that is drowning, except that it is drowning politely or impolitely. Both met is the aim, and when it arrives, the thing to check is the sample. A desk that meets every target every month has either reached the end of the work or stopped looking in the right places. Read ten tickets from the quiet department, ask Hamish, and watch the ticket volume line for a fall that nobody can explain. Green is a resting state, not a finding.
Reviewing the Targets
Review the experience targets with the service level, on the same quarterly date, with the same people, and change at most one thing. The review asks four questions. Was each level met, with the counts? Which promise was missed most, and at which moment? Is any interval wrong, too short for the desk to keep or too long for the requesters to tolerate, as the chase count will show? And is there a fourth promise the desk is now ready to make? A review that changes three targets at once has reset the baseline three ways and will learn nothing until the quarter after next.
The targets also need defending from a particular kind of improvement: the one that improves the count without improving the ticket. The kept-informed gap can be closed by messages that say nothing. The chase count can be reduced by closing tickets before the requester has time to ask. The plain-words reading can be passed by a template so generic that it applies to every fault and explains none. Each of these will appear within a quarter on a desk that watches the number more closely than the tickets. And each is caught by the same habit. Read ten tickets a month from the requester's side, which is the habit this whole series rests on. Numbers do not keep promises. People do, and the number is how you find out whether they did.
A Short War Story: The Daily Promise at Bluewater Bank
Oscar ran the desk at Bluewater Bank. At a leadership meeting where a director had complained about silent tickets, he made a promise on the spot. From the following Monday every open ticket would receive an update every working day. He had not counted the open tickets, which numbered around a hundred and sixty, or the technicians, who numbered four. On the Monday each of them spent most of the morning writing "no change today" into tickets that had not changed. The requesters read that as the desk reminding them that nothing was happening. By Thursday the technicians had stopped. By the following week the director had been forwarded three "no change today" messages by a requester who found them insulting. At the next leadership meeting the promise was read back to Oscar from the minutes. The cost was a quarter of credibility with the people he most needed to trust the desk. It was a fortnight of technician time spent on updates with no content. It was a set of requesters who had learned that an update from the desk meant nothing had happened. He rewrote the promise after measuring. It set an interval per priority that the desk had kept on most tickets in the previous month. It required a next-time in every message, and a count on the first page of the report. The lesson he gave his team was that a promise made before it is measured is a promise made to the minutes. And the minutes keep it longer than you do.
The Experience Target Set
The sheet below is the page that goes after the service-level table. It holds three promises, each with its trace, its count and its level. It holds a baseline from the first month, a review date, and the holes stated. Fill in the intervals per priority with the ones your desk kept on most tickets last month, not the ones you would like to keep. Fill in the levels as ranges with dates. The last section is the review record, so that a year from now anyone can see when a level moved and why. Keep the sheet with the service-level document, under the same owner, and read them together.
THE EXPERIENCE TARGET SET — ONE PAGE, BESIDE THE SERVICE-LEVEL TABLE
Desk: ______________________ Owner: ______________ Agreed with the team on: ____________
Baseline month: ____________ Review dates: ____________ ____________ ____________
PROMISE 1 — KEPT INFORMED
No open ticket goes more than ____ working days (priority 1: ____, priority 2: ____,
others: ____) without a public message from the desk that gives the next time.
Trace: longest gap between consecutive public desk messages while the ticket was open
Count: resolved tickets whose longest gap exceeded the interval for their priority
Baseline: ____ of ____ Level by ____: fewer than ____ in ____
Hole: the filter cannot read the message; ten are read each month for a next-time
PROMISE 2 — NEVER HAD TO CHASE
No requester has to write, call or walk over to ask what is happening.
Trace: a requester message while open asking for status rather than adding information;
phone and walk-up chases logged as a note on the ticket so they are counted
Count: resolved tickets with at least one chase
Baseline: ____ of ____ Level by ____: fewer than ____ in ____
Hole: the unlogged phone call; technicians log every chase they receive
PROMISE 3 — UNDERSTOOD THE REPLY
Every resolving message says what was wrong, what was done and what to try,
in words the requester could repeat to a colleague.
Trace: the resolving message; reopens or replies that ask what it meant;
the effort question and its comments
Count: ten resolving messages read at random each month; number passing
Baseline: ____ of 10 Level by ____: ____ of 10
Hole: reading cannot confirm understanding; the survey and follow-up calls fill part of it
WHAT WE ARE NOT PROMISING
[ ] that something will have changed by every update
[ ] any level we did not measure first
[ ] anything about tickets outside the desk's scope
REVIEW RECORD
Date ________ Promise ____ Met: yes / no Count ____ of ____ Change made: ______________________
Date ________ Promise ____ Met: yes / no Count ____ of ____ Change made: ______________________
Date ________ Promise ____ Met: yes / no Count ____ of ____ Change made: ______________________
Ingrid's next presentation to the regional managers had two tables on one page. There were the service levels, still met, and three new rows underneath with counts beside them. The first new row read "requester had to chase: 71 of 214 last quarter, 34 of 206 this quarter". Hamish read the row and said "that's the one", which is the only review comment Ingrid has ever written down. The clock had been measured for years. The silence had a number for the first time.
Frequently Asked Questions
Is an experience target the same thing as an experience level agreement?
Should the experience targets replace our service levels?
How long should the kept-informed interval be?
Do internal notes count toward kept informed?
Can these targets be measured in any ticketing tool?
What if the service level is met and the experience target is missed?
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.
