Setting Expectations at the Desk Level Before Anyone Asks

Monday, 07:55, at Wexford Timber. Aoife, who runs the two-person desk, arrives to four tickets that came in overnight. One is from Pete, the yard foreman, at 05:40: "Scanner gun in the yard is dead. Rang the IT number three times. Is anyone even there at six?" Nobody has ever told Pete whether IT is there at six. He inferred that it was from the one morning, two winters ago, when a technician happened to pick up at seven. Another ticket, from accounts at 22:15, asks for a password reset "urgently" and clearly expected someone to see it before morning. A third, from a new starter, asks politely whether it is all right to raise a ticket for something small. Four requesters, four different ideas of what the desk is, and the desk has published none of its own.

Desk-level expectations are the standing promises a desk publishes once, for everyone. They cover when it is open, how to reach it, how quickly a person will reply, what happens to a request raised out of hours, and what counts as urgent. They are set at the level of the desk rather than the ticket, so that every individual ticket starts from a shared understanding instead of from zero. This article is part of our Managing Expectations series. It is about writing those promises down in words a requester can read in a minute, putting them where requesters will see them, and keeping them true.

It covers why expectations get set whether or not you publish them. Next come published response times in plain words; the acknowledgment text. Then come the portal and out-of-hours text; service levels explained for users, with a table. Next come where to publish all of it; keeping the published promise honest. Finally come a short war story and the "what to expect from the desk" page to copy, in that order.

Expectations Are Set Whether You Publish Them or Not

Every requester already has an expectation of the desk, and if the desk did not set it, their last experience did. Pete expects six in the morning because of one answered call two winters ago. Accounts expect an overnight password reset because a technician once did one at nine at night from home as a favour. The new starter expects to be told off for raising a small ticket because that is what happened at their last job. None of these expectations is unreasonable, and none of them is the desk's, and the desk will be judged against all of them. An unpublished expectation is not an absence. It is a different expectation in every head.

The cost shows up as anger that seems to come from nowhere. A requester who believed the desk was staffed at six and rang three times to silence is not being unreasonable when the ticket arrives with an edge to it. They were let down by a promise they believed had been made. The desk, which never made the promise, feels unfairly blamed. Both are right, and the argument that follows is about a document that does not exist. Publish the hours and the response times, and the argument becomes "the page says eight, I needed six". That is a conversation about whether the desk should open earlier, and that is a conversation worth having.

Publishing also protects the desk from its own best days. The technician who answers at seven once, or resets a password at nine at night, has done something generous. Generosity becomes the standard the moment it is repeated twice. A published page says what the desk does every day, which lets the generous act stay generous instead of becoming an obligation nobody agreed to. Pete can be told, kindly, that the desk opens at eight and that the yard has a workaround for a dead scanner until then. That is a better outcome for both of them than a technician who feels obliged to be at a desk at six because they once were.

Published Response Times in Plain Words

A published response time is a promise about when a person will reply, and the plain-words version has to say exactly that. "We respond to all tickets within four working hours" means something to the desk and almost nothing to a requester. They do not know whether "respond" means a human or a machine, or whether "working hours" include their lunch break. They also do not know whether four hours is the usual wait or the worst case. The plain-words version is: "A person from the desk will reply to your ticket within four working hours, and usually within the hour. Working hours are eight to six, Monday to Friday. A ticket raised at five on Friday will be answered by ten on Monday." Nothing in that is new information to the desk. All of it is new information to Pete.

Say the usual and the worst case both, because publishing only the ceiling makes every requester expect the ceiling. If the desk replies to most tickets inside the hour but promises four, a page that says only "within four working hours" tells requesters to settle in for a half-day wait. In that situation, the ones who got a reply in ten minutes will be pleasantly surprised and the ones who waited three hours and fifty minutes will feel the desk cut it fine. "Usually within the hour, always within four" is honest in both directions, and it means the three-hour reply is a kept promise rather than a near miss. Publish the typical, promise the ceiling, and keep the ceiling without fail.

The published response time is the plain-words face of the service-level agreement, and the two must agree without being the same document. The service-level agreement, or SLA, is the desk's formal commitment, by priority, to response and resolution times, written for the people who run the desk and the managers who hold it to account. What it is and how to write one is covered in SLA in Plain Words. The desk-level page is the two-paragraph version for the people who raise tickets, and it must never promise anything the SLA does not. The common mistake is to publish a response promise and a resolution promise as if they were the same kind of thing. The difference, and why the resolution promise is the dangerous one, is in Response vs Resolution Targets. On the public page, promise the response firmly and describe the resolution as an aim.

The Acknowledgment Text

The automatic acknowledgment is the first thing every requester reads from the desk, and most of them are written by nobody. The default text in the tool says that the request has been received and will be dealt with as soon as possible. That answers none of the three questions a requester is actually asking: did a person get it, who has it, and when will I hear. Those three questions, and the four-sentence human reply that answers them, are the subject of What Users Actually Want to Know About Their Ticket. The acknowledgment cannot answer the second, because no person has it yet. But it can answer the first honestly and set up the third, and that is its job.

A good acknowledgment says five things in five short lines. The ticket number, so they can refer to it. That the message was received automatically and has not yet been read by a person, so they do not mistake it for a reply. When a person will reply, as a published promise: "by 11:30 today" if the tool can compute it, or "within four working hours, usually within the hour" if not. How to add information, which is to reply to the same message so it lands on the same ticket. And what to do if the matter is genuinely urgent, with the one route for that and a plain description of what urgent means. "Thank you for contacting the desk; we value your request" is not one of the five. Nobody has ever felt valued by an auto-reply.

The acknowledgment also has to say what it is not. It is not a reply. A requester who reads "we will deal with this as soon as possible" and hears a promise of imminent action will chase in an hour. The acknowledgment is not an answer to "is this urgent enough". A requester who put "URGENT" in the subject line needs to know whether anyone will treat it that way or whether the desk decides. Say it plainly: "The desk sets the priority when a person reads your ticket. If people cannot work, say so in your first line." Write the acknowledgment text once, read it aloud as if you were the yard foreman at 05:40, and then leave it alone for a year. The one improvement most acknowledgments need is to be shorter.

The Portal and the Out-of-Hours Text

The out-of-hours message is the acknowledgment's night shift. It has one job: to tell the requester exactly what will happen to the ticket they have just raised at 22:15. "The desk is open eight to six, Monday to Friday. Your ticket has been logged and a person will read it when the desk opens at 08:00 and reply by 10:00. If this is stopping people from working right now, the on-call number is on the portal front page; please use it only for that." That is honest about the gap, specific about when it closes, and clear about the one exception. The requester from accounts may be disappointed that nobody will reset their password tonight. They will not be surprised at nine the next morning, which is the point.

If there is no out-of-hours cover, say so, without apology and without hiding it in a footer. "There is no out-of-hours support; the desk will see your ticket at 08:00" is a complete and respectable sentence. A desk that publishes it has fewer angry Monday tickets than a desk that implies cover it does not have. If there is cover for genuine emergencies, define emergency in words rather than leaving the requester to decide. In that case, "the warehouse cannot ship, a whole site is offline, or something is unsafe" is a definition; "critical business impact" is a phrase. The definition will be stretched occasionally. It will still be stretched far less often than a blank.

The portal's front page carries the same promises, shortened to a glance: the hours, the response time, the urgent route, and where to look if something is already known to be broken. That last line saves more tickets than any other on the page. A requester who can see "e-mail is slow for everyone this morning, we are on it" does not raise a ticket to tell you. A status line or a small status page for a small organisation is the subject of A Status Page for a Small Organisation. The expectations page only needs to say where it is. Keep the front page to what fits on a phone screen without scrolling. Anyone who wants more can click through to the full page, and nobody raising a ticket at 05:40 wants more.

Service Levels Explained for Users

Requesters do not need the service-level document; they need to know what the desk will treat as urgent, what it will not, and roughly how long each kind of thing takes. The desk-level version is a short table in the requester's terms: what the situation looks like from their chair, examples they will recognise, when a person will reply, and what the desk aims for on the fix. The priority names from the tool can appear in a column so the requester understands what "P2" means when they see it on a ticket. But the rows are described by impact, not by number. Nobody outside the desk has ever cared what a P2 is. They care whether "the whole yard cannot scan" counts.

Be explicit that the desk sets the priority, and say why in one line: because the desk can see every ticket and the requester can see one. Requesters accept this when it is stated and resent it when they discover it, usually by marking something urgent and finding it treated as routine with no explanation. Add the line that lets them influence it honestly: "If people cannot work, say so in your first sentence and say how many." That is the information the desk actually needs to prioritise. Asking for it in advance gets far better first lines than a drop-down labelled "Urgency" ever has. The table below is a starting shape for a desk with three or four levels. The numbers are examples, and yours come from your own service-level agreement, which this table must never contradict.

Where to Publish It

The page lives wherever requesters already look, which means several places carrying the same words rather than one place carrying the perfect version. The portal front page gets the glance version. The acknowledgment gets the response promise and the urgent route. The knowledge base gets the full page, so a search for "hours" or "how long" finds it. The new-starter pack gets a link and the three-line summary, because new starters are the only people who will ever read the whole thing voluntarily. They set their expectations in the first week. If you run QuerySolv, the knowledge base can hold an article that everyone can see, not only the desk. In that case, the expectations page is the first article that belongs there. Wherever it lives, every copy must say the same thing, which means one person owns the words and the others are copies.

Put a short version where the desk is not. A card by the printers, a line in the out-of-office of the shared mailbox, a notice in the yard office next to the scanner charger: the places where a requester is standing when something breaks and the desk is the last thing on their mind. Pete would have read "IT desk: 08:00 to 18:00, Monday to Friday; out of hours, see the portal" on a card by the charger and known at 05:40 that nobody was there. That is less comforting than a technician but far more useful than three unanswered calls. The yard does not have a portal. It has a wall, and walls are where expectations are set for people who do not sit at desks.

Where the desk is split into departments with their own mailbox, their own form and their own service levels, as QuerySolv allows, each department publishes its own version of the page with its own hours and promises. In that setup, the portal front page says which department handles what. A facilities team that works seven to four and an IT desk that works eight to six should not share one "what to expect" page, because one of them will be lying on it. The split is also the place to say which door leads where. That way, a yard scanner goes to IT and a broken yard light goes to facilities without the requester having to guess. Many doors, one queue each, and a page on every door saying what is behind it.

Keeping the Published Promise Honest

A published promise is only worth having if the desk measures itself against it. The measure is simple: once a month, count the tickets whose first human reply came later than the page promised. Most tools report the time to first response; filter it against the published ceiling and read the number. If it is a handful, the page is true. If it is a tenth of the tickets, the page is a wish, and a requester who read it has been told something that was not so. The number is more useful than the average, because the average hides the Friday afternoons, and the Friday afternoons are what requesters remember.

When the desk cannot keep the promise, change the page, not the truth. A desk that has lost a technician and can no longer reply within the hour should publish "within two working hours" that week, with a line saying why. It should win back the hour when it can. A desk that keeps the old page and misses it daily has turned a promise into a decoration, and requesters notice decorations faster than desks expect. The same applies the other way. A desk that has quietly got faster should publish the better number, because a page that promises four hours to a desk that delivers in thirty minutes is leaving trust on the table. The page is a mirror. Keep it clean, and look in it monthly.

Review the page whenever the desk changes shape, and at least twice a year regardless. Hours change, people leave, a new department joins, the on-call rota is reorganised, and each of those makes some line on the page untrue. Put a "last reviewed" line at the bottom with the month, so that a requester can see the page is alive and the desk can see when it was last checked. A page that has not been reviewed in a year is probably wrong in two places. I have found hours on an expectations page for a desk that had moved buildings, changed its phone number and absorbed another team, all without anyone touching the page. It was still, technically, published.

A Short War Story: The Invented Promise at Acme

Acme's three-person desk had never written down its hours. One Saturday Raj, who was in the office to patch a server, answered the desk phone out of habit. Raj spent twenty minutes getting a sales laptop working for a regional rep before a Monday pitch. The sales team concluded, reasonably, that the desk worked Saturdays. Four months later, at a Saturday trade show, the demonstration laptop would not connect to the projector. Sofia, the sales director, rang the desk number fourteen times between ten and one. She got voicemail every time and ran the day's demonstrations from a printed deck while a competitor two stands away showed theirs live. On the Monday she took it to the IT manager as a service failure. The IT manager pointed out that the desk had never offered weekend cover. Sofia asked where exactly that had been written down. There was no answer. The lost demonstration day and a Monday of meetings were the visible cost. The quieter one was that sales stopped trusting the desk's unspoken promises and started demanding written ones for everything, which took a quarter to settle. Acme published its hours the same week, with an out-of-hours line that said plainly there was no weekend cover and how to request it in advance for an event. Nobody has rung the desk fourteen times on a Saturday since. An unpublished expectation is set by whatever happened last, and whatever happened last was a favour.

The "What to Expect From the Desk" Page

The page below is the full version for the knowledge base, written to be read by a new starter in under two minutes. The shorter extracts for the portal front page and the acknowledgment are marked at the end. Fill it from your own hours and your own service-level agreement, never from what you wish were true. Read every line aloud as a requester before publishing. The service-level table from earlier in this article slots in under "how fast". The "last reviewed" line is not decoration; it is the reminder to the desk to check the page, and the signal to the reader that someone did.

WHAT TO EXPECT FROM THE IT DESK — ONE PAGE
Last reviewed: ______________   Owner of this page: ______________

WHEN WE ARE HERE
  The desk is open ____:____ to ____:____, ______________ to ______________.
  Outside those hours: [ ] there is no cover; we will see your ticket at ____:____
                       [ ] emergencies only, on ______________ (see "urgent" below)
  Public holidays: ______________________________________________

HOW TO REACH US
  Web form:  ______________________   (best for anything that is not urgent)
  E-mail:    ______________________   (creates a ticket automatically)
  Phone:     ______________________   (for anything stopping people working now)
  Chat:      ______________________   (open ____:____ to ____:____)
  Every route creates a ticket with a number. Reply to the ticket to add anything.

WHAT HAPPENS WHEN YOU RAISE A TICKET
  1. You get an automatic message with your ticket number. A person has not read it yet.
  2. A person reads it and replies within ____ working hours, usually within ______.
     That reply tells you who has it and when you will next hear from us.
  3. We set the priority, because we can see every ticket and you can see one.
     If people cannot work, say so in your first line, and say how many.
  4. You hear from the person who has your ticket at least every ______ while it is open,
     even when there is nothing new.
  5. We ask you to confirm it is fixed before we close it. Replying to a closed
     ticket reopens it.

WHAT "URGENT" MEANS HERE
  Urgent: many people cannot work, a site is offline, or something is unsafe.
  Phone us for these; do not wait for a reply to a ticket.
  Out of hours, urgent means: ______________________________________
  and the route is: ______________________

HOW FAST
  Insert the service-level table here: what it looks like from your chair, examples,
  when a person replies, the fix or workaround aim, and how to tell the desk.

WHAT WE SUPPORT, AND WHAT WE DO NOT
  See: ______________________ (the "what IT supports" page)

IF SOMETHING IS ALREADY BROKEN FOR EVERYONE
  Check ______________________ before raising a ticket; we post known outages there.

PORTAL FRONT PAGE (the glance version)
  "IT desk: ____:____ to ____:____, ____ to ____. A person replies within ____ hours,
   usually within ______. Urgent and stopping people working? Phone ______________.
   Already broken for everyone? Check ______________."

ACKNOWLEDGMENT TEXT (the automatic reply)
  "This is ticket ________. This message is automatic; a person has not yet read
   your request. A person will reply by ______________. To add anything, reply to
   this message. If people cannot work right now, phone ______________."

Aoife wrote the page for Wexford Timber on the Monday afternoon, after replying to Pete at 08:10 with the honest version. The message said the desk opens at eight, and pointed to the spare scanner in the yard office for next time. It also described the card going up by the charger this week. Pete's reply was "fair enough, didn't know", which is the reply the whole page exists to produce. The accounts ticket got a password reset at 08:15 and a line pointing at the new out-of-hours text. The new starter was told, in writing, that small tickets were welcome and that most of the desk's day was small tickets. Three requesters, by Tuesday, with the same idea of what the desk was, and the desk had done nothing except say so.

Frequently Asked Questions