Status Updates That Prevent the Angry Follow-Up
Thursday, 15:50, at Stonebridge Insurance. Dev has just received the third "Any update??" of the day on ticket 6105, from Rosa in claims, whose document scanner has stopped indexing files into the claims system. Dev has spent two hours on it since Tuesday. He has a case open with the scanner's maker, three internal notes describing what he has tried, and a workaround half-built. From where Dev sits, 6105 is one of his most active tickets. From where Rosa sits, the last thing she heard from the desk was Monday's automatic acknowledgment, and the question marks have been multiplying since Wednesday. Both of them are right about what they can see.
A status update is a message from the desk to the requester, sent before they ask. It says what has happened since they last heard, what happens next, and when they will hear again. The chase is the message the requester sends when the update did not come: "any update?", "is anyone looking at this?", "just checking in". This article is part of our Managing Expectations series, and its argument is simple. Every chase is an update you had the information to send and did not. The rest is how to send it.
It covers why the chase is a symptom rather than a personality, then how often to update, by the state of the ticket. Next come what one update contains and the no-news update and why it still counts. Then it covers replies versus notes and who actually reads what, followed by updates while the ticket is waiting on somebody else. Making the habit stick, a short war story and the status update message to copy finish the article.
The Chase Is a Symptom, Not a Personality
Requesters who chase are not impatient people; they are people who have run out of information. Rosa does not know that Dev has a vendor case open. She cannot see his notes, his queue, or the half-built workaround. What she can see is that it is Thursday, the scanner has been broken since Monday, claims are piling up on her desk, and nobody has said a word. "Any update??" is the only tool she has. She is using it exactly as designed. The two question marks are not rudeness. They are a measure of how long she has been holding her breath.
Each chase costs the desk more than the update would have. Dev has to read the chase, open the ticket, and re-read his own notes to remember where he was. He writes a reply that says, in effect, "still working on it". It is the same reply he could have sent unprompted on Tuesday evening in forty seconds. Chases also arrive at the worst moment, because they arrive when the requester's patience runs out rather than when the technician has a gap. A chase that lands mid-task costs the task as well as the reply. Three chases in a day have cost Dev the best part of an hour. A Tuesday update would have cost him one minute. The arithmetic is not close.
The deeper cost is what the chase does to trust. The requester has now learned that if they had not asked, nothing would have come. Every future wait is coloured by that; they chase earlier next time, and earlier again the time after, and the desk starts describing them as "one of the difficult ones". They are not difficult. They were trained, by silence, to assume silence meant nothing was happening, and the only cure is to be the desk that writes first. Why silence does this damage, and the three questions a requester is really asking, are covered in What Users Actually Want to Know About Their Ticket. This article picks up at the second message and every message after it.
The Interval: How Often Is Often Enough
The only interval that matters is the one you promised. If the last message said "I will update you by Wednesday noon", the interval is Wednesday noon, and Wednesday 12:30 is late regardless of how busy you were. This is why every update ends with the time of the next one. It turns a vague duty to keep in touch into a specific promise with a deadline the desk can see. A desk that never names the next time has no interval, only a general intention, and general intentions are what the queue eats first.
For the default, when nothing has been promised yet, let the interval follow the state of the ticket. A high-priority ticket that is being actively worked gets an update several times a day, because the requester is probably standing still until it is fixed. A normal ticket being actively worked gets one each working day it is open. A ticket that is waiting on a part, a vendor or a project gets one a week, on a fixed day. The requester needs to know it is alive more than they need to know the details. A ticket waiting on the requester gets a reminder and then a closing warning, on a schedule the desk publishes. The intervals shrink as a promised date approaches, because that is when the requester's planning depends on knowing.
The outer limit on any interval is the requester's expectation of the fix. If a requester believes a password reset takes an hour, an update three hours later is late even if the desk's policy says daily. If they believe a new laptop takes two weeks, a weekly update is generous. Set the interval against what they expect, not against what the work needs. When their expectation is unrealistic, correct it in the first update rather than waiting for the chase to tell you it was wrong. The table below is a starting point, to be adjusted to your desk's volume and your requesters' patience, which are both measurable if you count the chases.
| State of the ticket | Default interval | What the update usually says | Who sends it |
|---|---|---|---|
| High priority, actively worked | Two or three times a day, and at every change | What was tried, what is next, next contact in hours | The owner |
| Normal priority, actively worked | Once each working day it stays open | Progress since yesterday, plan for today, next contact tomorrow | The owner |
| Waiting on a vendor, part or project | Once a week, same weekday, plus any change in the date | Where the dependency stands, workaround reminder, next contact next week | The owner |
| Waiting on the requester | Reminder after the agreed days, closing notice after the agreed days more | What is needed from them, what happens if nothing arrives | The owner or the daily sweeper |
| Promised date within two days | Daily until the date, then on the date | Whether the date still holds, and if not, the new one | The owner |
| Handed to a new owner | Immediately, once | The new owner's name, that the history has been read, and the next contact | The new owner |
What One Update Contains
A status update has three parts, and a good one has nothing else. First, what has happened since the requester last heard: the facts, in a sentence or two, in words they can use. Second, what happens next: the step the desk will take, and if it depends on someone else, who. Third, when they will hear again: a specific time, with "whether or not there is news" attached. Dev's Tuesday update would have read: "Since Monday I have confirmed the scanner itself works and the fault is in the step that passes files to the claims system; I have raised it with the scanner's maker, case 41877. Next I am building a way for you to index files by hand while we wait, which I expect to have for you tomorrow. I will update you by 16:00 Wednesday either way. Dev, IT desk." Four sentences, and three chases that never happen.
Keep the first part short and skip the archaeology. The requester does not need the eleven things you tried that did not work; they need the one thing you learned. "The scanner is fine, the problem is in the handoff to the claims system" is useful because it tells Rosa the scanner does not need replacing and the fault is being narrowed. A list of every setting Dev checked tells her that Dev has been busy, which she will believe anyway if he keeps writing. Put the full list in the internal notes, where the next technician needs it. The update is for the person waiting, and the person waiting wants the shape of the news, not the shape of your afternoon.
The third part is the one people drop, and it is the one that prevents the next chase. Without "I will update you by 16:00 Wednesday", the requester has to guess when to expect the next message. They will guess wrong, in the early direction, and chase. With it, the update has set the interval, and a requester who knows the next message is coming at four on Wednesday does not write at ten on Wednesday. The time must then be kept, which is the whole discipline. The honest way to choose a time you can keep is the subject of Honest ETAs: Promising a Time You Can Keep. Here the rule is only that the time is present, in every update, every time.
The No-News Update
"Nothing has changed" is news, and a desk that does not send it has misunderstood what the requester is asking. The no-news update is the message you send at the promised time when there is nothing new to report. It says there is nothing new, that the ticket is still alive and owned, and when the next check is. It feels pointless to write. It is the opposite. The requester's fear is not that the fix is slow; it is that the ticket has fallen into a drawer. A message that says "still here, still waiting on the vendor, next update Friday" is proof that it has not. Silence proves nothing except that nobody is writing.
The failure mode is embarrassment. A technician who promised an update by Wednesday and has nothing to show for it feels that writing "no change" is admitting failure. So they wait a day in the hope of having something. The Wednesday promise dies quietly while they hope. Then the chase arrives, and the technician has both no news and a broken promise. A one-line message on Wednesday would have given them no news and a kept one. The no-news update is not a confession. It is the promise being kept in the only form available. Send it on time and move on. (The requester, who has also had weeks with nothing to show for them, will understand.)
A no-news update still carries all three parts, and the third is non-negotiable. "No change since Wednesday; the vendor has not yet replied to the case and I have chased them this morning. The workaround I sent you still stands. I will update you again on Friday by noon, whether or not they reply." The desk-side act of chasing the vendor, and the wording that gets vendors and requesters to actually reply, belong to Follow-Up Messages That Get Replies. The update to the requester is the other half of the same moment. When the no-news update has gone out three times in a row with the same text, the message is telling you something. The dependency needs escalating rather than waiting on. Three identical no-news updates is a pattern. The fourth is a habit.
Remember: every update, including the one that says nothing has changed, ends with the time of the next one. The chase is what happens when that time is missing or missed.
Replies, Notes, and Who Actually Reads What
Updating the ticket is not updating the requester, and the gap between the two is where most chases come from. Dev had three internal notes on 6105, each a careful record of what he tried. Rosa saw none of them. An internal note is written for the desk and a public reply is written for the requester. Tools keep the two apart on purpose. The note is the right place for the full list of settings checked. The reply is the only thing that counts as an update. A technician who has written four notes and no replies has, from the requester's side, been silent for four days, and the notes will not defend them.
Where your tool makes the distinction, learn which is which and check before you send. In QuerySolv a public reply reaches the requester and an internal note stays with the desk. The discipline is to finish every working session on a ticket by asking whether the last thing written was a note or a reply. If it was a note, the requester has heard nothing. Most tools draw the line somewhere similar. Most desks have at least one technician who has written a beautifully clear update as a note, felt good about it, and been chased the next morning. I was that technician for most of one year. The notes were excellent.
The status field is not a message either. Changing a ticket from "In Progress" to "Waiting on Vendor" tells the desk something. It tells the requester nothing unless the tool sends a notification on status change and the requester reads it. Neither of those is safe to assume. Some tools notify on every change; some on none. Some send a message so generic ("your ticket has been updated") that it is worse than silence. It makes the requester open the portal to find out that nothing they can understand has happened. Treat every status change as a reason to send a reply in plain words, and send it on the channel the requester used. A requester who e-mailed does not check the portal and a requester who used chat does not read e-mail until Friday.
Updates When You Are Waiting on Someone Else
The desk still owes the requester an update when the ticket is waiting on a vendor, a part or another team, and this is where the longest silences happen. The technician has handed the problem on and, from their side, there is nothing to do until it comes back. The ticket sits in a waiting status, excused from every list that measures activity, and the requester hears nothing for a fortnight. Nothing being yours to do is not the same as nothing being yours to say. The waiting is the news, and the requester deserves to know who is being waited on, since when, and what the desk is doing to hurry them.
Tell the requester the shape of the wait in plain words, without turning the vendor into a villain. "The replacement part is on order from the maker; they have given a date of the 14th and I will confirm it with them on the 10th" is honest and complete. "The vendor is useless" is a mood, not an update, and it tells the requester that the desk has given up and is now merely complaining alongside them. Name the dependency, name the date, name when you will check it, and leave the editorial out. If the wait will be weeks rather than days, the rhythm changes and so does the message, and that is the subject of When the Fix Is Weeks Away.
When the ticket is waiting on the requester, say so, clearly and once, and then say what happens if nothing arrives. "I need the error text from your screen to go further; could you send a photo of it? If I have not heard by Thursday I will send one reminder, and if nothing arrives by the following Thursday I will close the ticket, which you can reopen just by replying." That is an update, a request and a schedule in three sentences, and it means the ticket can be closed later without the requester being surprised. The reminder itself, and the closing notice, are desk-side follow-ups covered in the aging and follow-up series. The update here is about being honest that the ball is in their court. Requesters do not resent that when it is said plainly, and do resent it when they discover it from a closure notice.
Making It a Habit, Not a Heroic Act
Updates happen reliably when there is a view that shows what is promised today and a time when someone reads it. The view is a list of open tickets sorted by the next-contact time. In most tools, that is a due date, a custom field or a date in the first line of the notes. Whichever it is, use the same one on every ticket so the sort works. The time is the last half hour of the working day. Each technician opens the view, finds every ticket whose next contact is today, and sends the update or the no-news update before leaving. A desk that does this has no chases the next morning, because every requester who was owed a message got one.
Put the next-contact time on the ticket at the moment you promise it, not later. The promise exists the instant the reply is sent. A promise that lives only in the reply is invisible to the end-of-day view and to a colleague covering your leave. It is invisible to you on Wednesday when you cannot remember whether you said Wednesday or Thursday. Write the reply, write the time on the ticket, and move on. This is thirty seconds per update. It is the difference between a desk that keeps its promises because it tries hard and a desk that keeps them because it can see them. Trying hard runs out at four o'clock on a Thursday. The view does not.
Count the chases, because they are the measure of the whole thing. Once a month, search the closed and open tickets for replies from requesters containing "any update", "any news", "checking in" or "is anyone", and count them. The number is how many times the desk was asked a question it should have answered first. Watch it fall as the end-of-day pass takes hold. Watch for the technician or the ticket state where it does not fall, because that is where the view is not being read. A desk that counts its chases will find they drop from dozens a month to a handful. The handful are the ones where the requester chased before the promised time, which is a different problem, and a small one.
A Short War Story: Twenty-Six "Any Update?" Replies at Bellweather Logistics
Hamid, who managed the Northfield depot for Bellweather Logistics, raised a ticket about handheld scanner batteries that were dying halfway through the afternoon shift. Jon on the desk found within a day that the batteries were a known bad batch and raised a replacement claim with the maker. Over the next month Jon added seven internal notes as the claim moved along. They covered the batch numbers sent, the maker's acknowledgment, a request for photographs, a revised date, a shipping reference. Hamid saw none of them. Over the same month, he replied "any update?" to the ticket twenty-six times, roughly once each working day. Each reply bumped the ticket to the top of Jon's list. It cost Jon ten minutes to re-read and answer with a variant of "still waiting on the maker". In the fourth week Hamid forwarded the whole chain to the operations director. The director spent a morning assembling a timeline from Hamid's side of the correspondence and concluded the desk had been ignoring a depot for a month. Jon's notes, when he was asked for them, showed the opposite: the desk had worked the claim steadily for the whole period. The director's morning, Hamid's month and a quarter of rebuilt trust were the price of twenty-six updates that had been written and never sent.
The Status Update Message
The template below is the three-part update as a fill-in message, with the no-news variant underneath it, because the no-news variant is the one people need written down. Use the first block whenever something has changed and the second at the promised time when nothing has. The last line of both is the next contact, and it is never left blank. Fill it from the ticket, send it as a reply the requester receives, write the next-contact time on the ticket, and move on. It should take under a minute. The whole point of the template is that it takes under a minute.
STATUS UPDATE — SEND AS A REPLY, NOT A NOTE Ticket: ________ Requester: ______________ Promised by: ________ ____:____ WHAT HAS HAPPENED SINCE YOU LAST HEARD "Since ________ I have ________________________________________________. What that tells us: ___________________________________________________." WHAT HAPPENS NEXT "The next step is ______________________________________________________, which is being done by [ ] me [ ] ______________ (outside the desk)." Workaround still in place, if any: ________________________________ WHEN YOU WILL HEAR AGAIN "I will update you by ________ at ____:____, whether or not there is news." Sign-off: "________, IT desk" NO-NEWS VARIANT (send at the promised time when nothing has changed) "No change since ________: we are still waiting on ______________, and I chased them on ________. The workaround I sent still stands. I will update you again by ________ at ____:____, whether or not they reply. ________, IT desk" AFTER SENDING [ ] Sent as a reply the requester receives, on the channel they used [ ] Next-contact time written on the ticket [ ] Third identical no-news update in a row? Escalate the dependency today
Dev sent Rosa a proper update at 16:10 on the Thursday, after the third chase, which was the wrong order but the right message. It gave what he had found, the hand-indexing workaround with a two-line how-to, the vendor case number, and "I will update you by 16:00 tomorrow either way". Rosa replied "thank you, that helps a lot" and used the workaround for the eight days the vendor took. She did not write again until the Friday update arrived two minutes late and she asked, gently, whether everything was all right. The scanner was fixed on the ninth day. The chases stopped on the first.
Frequently Asked Questions
How often should I update a requester when nothing is happening?
Does changing the ticket status count as an update?
I wrote everything in the internal notes. Why is the requester still chasing?
What do I say when the vendor has gone quiet and I have nothing new?
Should updates go by e-mail, the portal, or chat?
How do I know whether the updates are working?
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.