What Users Actually Want to Know About Their Ticket

Tuesday, 10:40, at Meridian Parts. Imogen in purchasing raised ticket 5218 at 08:50: the supplier portal will not let her log in, and the month's orders have to be in by noon. The desk read it at 09:05. Rhea knew within a minute that it was a locked account on the supplier's side. She knew that the supplier's own helpline opens at 11:00, and that she would have it unlocked before lunch. She put a note on the ticket saying so and moved on to the next one. At 09:40 Imogen forwarded the ticket again "in case it did not come through". At 10:10 she messaged a colleague: "Do you know anyone in IT?" At 10:40 she is standing at the desk, and the first thing she says is not "Is it fixed?" It is "Did anyone get my ticket?"

Rhea had done everything right except tell anyone. Managing expectations is telling the requester what will happen with their ticket, and when, before they have to ask, and then doing what you said. It is not spin, and it is not a way of making slow work sound fast. It is the difference between a requester who waits calmly for a fix that is three hours away and one at your desk after ninety minutes. The latter is there because, as far as they can tell, nothing has happened at all. This article is part of our Managing Expectations series. It starts at the beginning: what the requester is actually asking when they raise a ticket. That turns out to be three things, none of them "is it fixed yet".

It covers the three questions behind every ticket and why silence does more damage than slowness. Next comes each question in turn, with what the requester does when it goes unanswered and the line that answers it. Then comes the first reply that answers all three at once, with a picture and a table. It covers what the requester does not need from you yet and keeping the three answers true as the ticket ages. It finishes with a short war story and the expectation card to copy.

Three Questions Behind Every Ticket

Every ticket carries three questions that the requester rarely writes down. Did you get it? Who has it? When will I hear? The ticket's text is about the problem, the printer or the portal or the password. But the requester's attention, from the moment they press send, is on those three. They are the questions you ask when you post a parcel or leave a car at a garage, and they are the same for a broken laptop. Was it received, is a specific person responsible for it, and when is the next time I will know something.

Notice what is missing from the list. "When will it be fixed?" is not one of the three, and that surprises people on the desk, who assume the fix is all anyone wants. The fix is what the requester wants eventually. What they want now is to stop worrying about whether the thing is in hand, and a fix date is only one way of giving them that. "I will update you at three" does the job almost as well as "it will be fixed by three". It has the advantage of being a promise you can keep. Imogen did not walk to the desk because her account was still locked. She walked over because for an hour and fifty minutes she could not tell whether anyone knew it was.

The three questions arrive in order, and the order matters for how you answer. Nobody asks who has it until they know it was received; nobody asks when they will hear until they know who to hear from. Answer the first and the second arrives. Answer all three and the requester goes back to work, which is the only outcome either of you wanted. I think of them as three locks on one door. Open two and the door is exactly as shut as before.

Silence Is the Enemy, Not Slowness

Requesters forgive slowness far more readily than they forgive silence. A ticket that takes three days and is updated on each of them produces a mildly impatient requester. A ticket that takes one day and is updated at the end of it produces a requester who spent that day assuming the worst. That requester told two colleagues the desk was ignoring them, and now needs the fix and an apology. The work was faster in the second case. The experience was worse, and the experience is what gets talked about in the kitchen.

Silence is read as a verdict. The requester cannot see your queue, your notes, your eleven other tickets or the supplier's helpline hours. All they can see is that they asked and nothing came back. People fill a gap like that with the worst explanation available, not out of malice but because the worst explanation is the one that requires action. "They are busy" means wait. "They lost it" means act. Faced with the choice, people act, which is why the second message arrives, then the colleague is asked, then the desk gets a visitor. Each of those is a sensible response to not knowing. The requester is not being difficult. They are doing your follow-up for you.

The cost of silence lands on the desk as well as the requester. Every "any update?" has to be read. Every duplicate has to be found and merged with the original. Every walk-up interrupts whatever the technician was doing, which was often the very ticket being asked about. The desk that never updates spends its afternoon answering questions it could have pre-empted with one line that morning. Silence is not free. It bills you later, with interest, in interruptions. The structural version of this failure is the black hole described in The Seven Ways Support Quietly Fails. Whole departments stop raising tickets because nothing visible happens when they do. That failure starts one unanswered question at a time.

Question One: Did You Get It?

The first question is answered by evidence that a human has read the ticket, and an automatic acknowledgment does not supply it. An automatic acknowledgment is the message the ticketing tool sends the moment a ticket is created, with the ticket number in it. It is useful: it proves the e-mail arrived and gives the requester a reference. It does not prove anyone has looked, and requesters know this. They have received the same message from every company they have ever written to and been ignored by half of them. The auto-reply answers "did the machine get it". The question was "did you".

The human answer has two parts: the ticket number and a one-line restatement of the problem in your own words. The number lets the requester refer to it later. The restatement is the proof that it was read, and it catches a misunderstanding early. "Got it: ticket 5218, your supplier portal account is locked and the orders are due by noon" tells Imogen that Rhea has read the whole thing. That includes the deadline, which is the part she was most worried would be missed. Had Rhea restated it as "portal running slow", Imogen could have corrected her at 09:10. That could have prevented her discovering at lunchtime that the desk had spent the morning on the wrong problem.

When question one goes unanswered, the requester resends. Then they resend to a different address. Then they phone, and if the phone goes to voicemail they walk. By that point there are three copies of the ticket and a requester who has spent an hour of their day on logistics. Most tools merge duplicates, and merging takes a minute; the hour is gone regardless. The restatement line is the cheapest sentence on the desk. It takes fifteen seconds to write and it saves the whole morning.

Question Two: Who Has It?

The second question is answered by a name, and only by a name. "Your ticket has been assigned to the Support Team" answers nothing, because a team cannot be asked how it is getting on. The requester knows that a thing belonging to everyone belongs to nobody in particular. "I have it. Rhea, IT desk" is an answer. It tells the requester which human is responsible, which human to thank, and which human to ask if the promised time passes. It also, quietly, tells the rest of the desk the same thing, which is why it matters as much inside the team as it does to the requester.

Putting a name on a ticket is a small act with a large effect on the ticket's survival. A ticket owned by a named person appears in that person's list every morning. A ticket owned by a group appears in a list everyone assumes someone else is reading. Where the tool uses claim-based ownership, as QuerySolv does, the act of claiming is the answer to question two. In that case, a person's name goes on the ticket at the moment they take it. The requester can be told that name in the same breath. Whatever your tool calls the mechanism, the rule is the same. The first human reply carries the name of the human who sent it.

When question two goes unanswered, the requester finds a name of their own. They ask a colleague who in IT helped them last time, and they message that person directly, outside the ticket. The ticket now has two conversations: the official one, in the queue, with nobody's name on it, and the real one, in somebody's inbox. The desk discovers this when the colleague fixes the thing and the ticket stays open for a month. It is remarkable how reliably a requester will locate the one technician who is not on the ticket. Give them a name and they stop looking.

Question Three: When Will I Hear?

The third question is answered by a time, and the time is for your next contact, not for the fix. This is the distinction most desks get wrong, in both directions. Some give a fix time they cannot know yet ("should be done this afternoon"), and when the afternoon passes the ticket has become a broken promise. Others refuse to give any time at all because they cannot predict the fix, and the requester is left with nothing. The way out is to promise the one thing you control: when you will next be in touch. "I will update you by 15:00 today, fixed or not" is a promise Rhea can keep whether or not the supplier's helpline picks up.

"Fixed or not" is the phrase that makes the promise honest. It says in advance that the next message might be "no news yet". That means a 15:00 update saying exactly that is a kept promise rather than a disappointment. Requesters accept this readily. They were never expecting a miracle; they were expecting to be told. Honest estimating, including ranges, padding, and the useful sentence "I do not know yet, but I will know by", is the subject of Honest ETAs: Promising a Time You Can Keep. For the first reply, the rule is simpler: pick a time you are certain to meet, and meet it.

When question three goes unanswered, the requester invents a deadline and then measures you against it. The invented deadline is always shorter than yours, because it is set by their need rather than your queue. When it passes they reply "any update?", the two most expensive words in support. They cost the requester the awkwardness of asking. They cost you a reply that says "still working on it". They cost both of you a little trust, because the requester now knows that if they had not asked, nothing would have come. One line with a time in it prevents all of that. The time does not even have to be soon. It has to be stated, and it has to be met.

The First Reply That Answers All Three

One short message, sent by a person within the first hour, answers all three questions at once. It has the ticket number and a one-line restatement (did you get it), and a name (who has it). It also has a time for the next contact with "fixed or not" attached (when will I hear). Rhea's version, sent at 09:08, would have read: "Got it: ticket 5218, your supplier portal account is locked and your orders are due by noon. I have it. The supplier's helpline opens at 11:00 and I will call them then; I will update you by 11:30 either way. Rhea, IT desk." Four sentences. Imogen stays at her own desk, and the morning's three interruptions never happen.

The picture below lays the three questions side by side. It shows what the requester does when each is left unanswered and the line in your reply that answers it. It then shows the one first reply that covers all three. The orange marks are the behaviour you are trying to prevent; the green marks are the sentence that prevents it. Nothing in the picture takes longer than a minute to write.

The table puts the automatic acknowledgment and the human first reply next to each other, question by question. The auto-reply is not useless; it is answering a different, smaller question than the requester is asking. And a desk that relies on it alone has answered none of the three. The right-hand column is what the requester does when neither message arrives, which is a list of things you have seen this week.

What the Requester Does Not Need Yet

The first reply is not the place for the cause, the plan, or the history. The requester did not ask why the portal locked them out. And a paragraph about the supplier's authentication service is a paragraph they must read to find the one line they wanted, which was the time. Save the explanation for when there is a fix to explain, and keep it short then too. Turning a technical cause into words a requester can use is its own skill, covered in The Three-Sentence Explanation. The first reply is about the three questions. Everything else is clutter at this stage, however true.

Do not share the internal picture either. "You are number eleven in the queue" is honest and unhelpful; it invites the requester to ask about the other ten, and to wonder why theirs is not first. "The person who normally does this is off until Wednesday" is honest and alarming; it tells them their ticket depends on somebody's holiday. Both are things you should know and neither is something they need to hear. Give the time and let the queue be your problem. That is the deal: you carry the complexity, they get a time they can plan around. (They will ask about the queue anyway. Say "you are near the top" only when it is true.)

Promises you cannot keep are the other thing to leave out, and they are tempting in a first reply because they feel kind. "This should be quick" is a promise. "I will get right on it" is a promise, and it becomes untrue the moment you pick up the next ticket instead. Say what you will do and when you will next write, and nothing beyond it. Kindness in a first reply is accuracy. Everything else is a cheque you have asked the future to cover.

Keeping the Three Answers True as the Ticket Ages

The three questions do not go away after the first reply. They come back every time the ticket changes hands, changes status, or passes a promised time. If Rhea hands 5218 to a colleague, question two has a new answer and the requester needs to hear it. If the supplier says the unlock will take until tomorrow, question three has a new answer and the requester needs to hear that too, before 11:30 rather than after. Each change reopens a question the requester thought was settled. A reopened question left unanswered hurts more than the original did, because the requester had stopped worrying and now has to start again.

The simplest discipline is to attach a next-contact time to every ticket and never let it pass unmet. On most desks this is a field, a due date, or a line in the notes. Which one does not matter, as long as there is a view that shows "promised today" and someone reads it each morning. When the time arrives and there is nothing new, you send the no-news update, which is a real update and not an admission of failure. The rhythm, the interval and the contents of those later messages are the subject of Status Updates That Prevent the Angry Follow-Up. This article only insists that the first reply sets a time, and that the next message arrives before it.

Handovers deserve one extra sentence, because they are where question two quietly breaks. When a ticket moves from one technician to another, the new owner sends a line: "Rhea has handed this to me; I have read the history and I will update you by Thursday noon. Marcus, IT desk." Without it, the requester's last known contact is a person who no longer has the ticket, and the next "any update?" goes to the wrong inbox. The tool knows who owns the ticket. The requester only knows who told them last.

The same three questions apply when the ticket is finished, in reverse. Did it get fixed, who fixed it, and what do I do if it comes back are the closing versions. A ticket closed without answering them is the silent close, the one where the requester finds out by noticing the thing works. Closing well is a separate subject with its own article in this library, but the habit is identical. The requester hears from a named person, with a plain statement, before they have to ask. Open or closed, the enemy is the same. Nobody has ever complained about being told too clearly.

A Short War Story: The Silent Fortnight at Harbourview Clinic

Harbourview Clinic's practice manager, Grace, raised a ticket on a Monday about the appointment-reminder messages that had stopped going out to patients. She received an automatic acknowledgment with a number in it. Leo on the desk read the ticket that morning. Leo found that the clinic's messaging account had been suspended by the provider over an invoice that finance was already chasing. Leo wrote a detailed internal note on the ticket and set it to wait on finance. Grace heard nothing. On day four she raised the ticket again. On day six she raised it a third time from her personal address in case the clinic's mail was broken. On day nine she called the messaging provider herself and spent an afternoon on hold. She was told the matter was with her own finance team, which was the first she had heard of it. For the fortnight it took finance to settle the invoice, patients missed appointments a reminder would have saved. During that time, the reception team spent an hour a day phoning them by hand. The desk had three tickets about one problem, two of them unread. Leo had been right about the cause from the first morning. The silence, not the suspension, cost the clinic its fortnight.

The Expectation Card

The card below is the first reply as a form, with the three questions down the left and a blank for each answer. The rules that keep the answers true follow. Pin it by the screen for the first month; after that the four sentences become a habit and the card becomes a check for the ticket that slipped. Fill the blanks from the ticket, not from memory, and never leave the time blank. "I will update you when I know more" is the third question left unanswered with extra words.

EXPECTATION CARD — FIRST REPLY WITHIN THE HOUR
Ticket: ________   Requester: ______________   Received: ____:____

DID YOU GET IT?
  Ticket number in the first line:        ________
  One-line restatement, in your words:
  ___________________________________________________________________
  Their deadline, if they gave one:       ______________

WHO HAS IT?
  Owner, by name (never a team):          ______________
  Your sign-off line:                     "________, IT desk"

WHEN WILL I HEAR?
  Next contact, date and time:            ________  ____:____
  The words "fixed or not" included:      [ ]
  A fix time promised only if certain:    [ ] none given  [ ] ______

SEND IT
  [ ] Sent as a reply the requester receives, not as an internal note
  [ ] Sent within one hour of the ticket arriving
  [ ] Next-contact time written on the ticket where the desk can see it

KEEP IT TRUE
  [ ] Owner changes: the new owner sends one line with their name and a time
  [ ] Time arrives with no news: the no-news update goes out before it passes
  [ ] Time changes: the requester is told before the old time, never after

Rhea ran the card at Meridian Parts for the rest of that week, more out of embarrassment than conviction. The Friday queue held no duplicates for the first time she could remember. Imogen's portal account was unlocked at 11:20 on the Tuesday, which is the time it was always going to be unlocked. The only thing that changed came on the Wednesday, when a different account locked. Imogen read "I will update you by 11:30, fixed or not", replied "thanks", and went back to work. The desk had not got faster. It had started answering the question that was asked.

Frequently Asked Questions