Resetting Expectations When the Plan Changes

Tuesday, 15:20, at Bluewater Bank. At eleven that morning Chloe on the desk told Daniel in treasury that the market-data feed on his terminal, ticket 8812, would be back by 14:00. The vendor sent a fix at 13:30. Chloe applied it, restarted the terminal, and watched the feed fail in exactly the same way at 13:40. She has known for an hour and forty minutes that the two o'clock promise is dead. She has not told Daniel, because each time she opened a reply she thought the second attempt might work. She would rather send "fixed" than "not yet". Daniel has a report due at 16:00 that needs the feed. Hope has been doing Chloe's communicating for her, and hope does not send e-mail.

A reset is telling the requester that the plan has changed, before the old promise runs out. It replaces that promise with a new promise you can keep. It is the hardest message on a help desk to send and the most important. The first promise was made in good faith. The reset is where the requester finds out whether the desk's word means anything when things go wrong. This article is part of our Managing Expectations series, and it is about that message. We cover when to send it, what it apologises for, what it explains, and what it promises next.

It covers the three ways a plan changes, then telling them before the deadline rather than after. Next come the apology that is not grovelling, and saying what changed and why in one line. We cover why the new promise must be more cautious than the first. Then we cover resetting scope when the fix is not what they asked for, and what to say when the fix did not work. Next comes the second reset, when it slips again. We finish with a short war story and the reset message to copy, in that order.

Three Ways a Plan Changes

A plan changes in three ways, and the requester experiences each one differently if nobody tells them. A slip is the same fix arriving later than promised. For example, the part is delayed, the queue grew, or the person who owns the system is off sick. A scope change is a different fix from the one promised. For example, the laptop cannot be repaired and will be replaced. Or the report cannot be restored and will be rebuilt. Or the feature they asked for will arrive as something smaller. A failed fix is the fix that was applied and did not work, which is a slip and a surprise at once. Chloe has a failed fix. By 16:00 she will also have a slip, and if the vendor's second attempt is a different approach, she may have all three.

Each trigger needs a reset, and each reset says something slightly different, but all three share the same shape. They include an acknowledgment that the old promise has changed, one sentence on why, and one sentence of apology where one is owed. They include a new promise that is built on what you now know. The table below sets out the three, with what the requester notices when the desk says nothing. That is the column to read if you are tempted to wait and see.

Tell Them Before the Deadline, Not After

The moment you know a promise is at risk, it is at risk for the requester too. And the only question is whether they find out from you or from the clock. Chloe knew at 13:40. Daniel will know at 14:00, when the feed is still dead. At that point the information is the same but the message is different. At 13:45 it is a correction; at 14:05 it is a confession. The requester's ability to do anything about the change shrinks with every minute between those two times. They might warn their own manager or find another way to get the figures. Waiting does not improve the news. It only removes the requester's options for dealing with it.

The reason people wait is hope, and hope is a decision dressed up as patience. "The second attempt might work, and then I will not have to say anything" is a bet that the fix will arrive before the deadline. That bet is placed with the requester's time rather than your own. When the bet pays off, nobody notices. When it fails, the requester has lost the hour they could have spent planning. They have learned that the desk's silence before a deadline does not mean the deadline is safe. Make the rule mechanical so hope does not get a vote. The moment you cannot see the finish from where you stand, the reset goes out. If the second attempt then works at 14:10, send "fixed, sooner than I feared" and enjoy it. Nobody has ever been annoyed by that message.

The halfway check that catches slips before they are late is described in Honest ETAs: Promising a Time You Can Keep. When half the promised time has gone, ask whether you can see the finish, and if you cannot, reset now. Failed fixes do not wait for the halfway point. The moment the fix fails is the moment of the reset, because the old promise died at that moment. The requester deserves to be told while they still have the afternoon. Chloe's reset was due at 13:41. Every minute after that was a minute she spent protecting herself from a two-line message at Daniel's expense.

The Apology That Is Not Grovelling

The apology in a reset is one sentence, it owns the thing that is yours to own, and it stops. "I said two o'clock and I should have told you at a quarter to that it was in doubt; I am sorry for the late warning" is an apology. It names what went wrong on the desk's side, which is the lateness of the message. It does not pretend the vendor's failed fix was Chloe's fault, because it was not. A requester can tell the difference between a person taking responsibility for their part and a person flagellating themselves for the weather. They trust the first and are embarrassed by the second. Grovelling asks the requester to comfort you. They have a report due at four.

Leave out the words that turn an apology into a shrug. "Unfortunately, due to circumstances beyond our control" is a sentence that apologises for nothing and blames the universe. Requesters have read it a thousand times from every utility they have ever dealt with. It tells them you are reading from the same card. "Apologies for any inconvenience caused" apologises for a hypothetical. Say "I am sorry" and say what for, in your own words, once. There may be genuinely nothing on the desk's side to apologise for. That is the case when the reset is going out the minute the change was known and the cause is entirely external. In that case, do not apologise; say "I wish I had better news" and move to the facts. An apology for something that is not your fault is a small lie, and small lies in resets are expensive.

Never blame the requester, even when the slip is partly theirs. If the fix is late because they did not send the error text until Thursday, the reset does not say so. It says "now that I have the error text, the fix will be Monday", and the requester can do the arithmetic themselves. Blaming a vendor by name is nearly as bad, because it tells the requester that the desk is now a spectator to its own ticket. "The maker's first fix did not take" is a fact. "The vendor is useless" is a mood, and it does not come with a new date. The requester may already be upset, with the reset landing on top of that. How to acknowledge the impact on them without taking on blame that is not yours is covered in Acknowledging Impact Honestly. The reset borrows one line from it: say what the change costs them, in their terms, before you say what you will do about it.

Say What Changed and Why, in One Line

The requester needs the shape of what changed, not the archaeology. "The fix the maker sent did not work; they are sending a different one" is the whole explanation Daniel needs. Consider the twenty minutes Chloe spent comparing configuration files, the three restarts, and the call to the vendor's second-line team. Those belong in the internal notes, where the next technician will be grateful for them. They do not belong in the reset, where they read as a defence. One line of cause is honest and sufficient. Three paragraphs of cause tell the requester you are more worried about your reputation than their report, whatever you intended.

The line must be true and it must be specific enough to be believed. "There has been a delay" explains nothing and invites "why?", which is a second exchange the reset was supposed to prevent. "The replacement screen arrived cracked and the supplier is sending another, which adds four working days" is specific, verifiable, and finished. It also lets the requester judge the new promise for themselves: four working days for a reshipment is plausible. And a requester who finds the cause plausible will find the new date plausible too. Vague causes make every date that follows them sound invented, because the requester has nothing to check it against.

When the cause is embarrassing for the desk, say it anyway, briefly. "I ordered the wrong part; the right one arrives Thursday" costs the desk a small amount of pride and buys a large amount of trust. The requester now knows the desk tells the truth when the truth is unflattering, which is the only time truthfulness is tested. I have written that sentence more than once. The reply has always been some version of "thanks for telling me", and never once the fury I had braced for. Requesters are rarely angry about mistakes. They are angry about discovering them.

The New Promise Must Be More Cautious Than the First

The second promise is held to a higher standard than the first, because the requester has now seen one promise fail. They are watching this one to decide whether the desk's times mean anything. A first promise that slips is forgivable; things happen, and most requesters know it. A second promise that slips tells the requester the desk does not know how long its own work takes. After that every estimate from the desk is heard as a guess, however carefully made. The reset is therefore the moment to be more careful, not less, which is the opposite of what the pressure of the moment suggests.

Build the new promise on what you have just learned, and move it one step towards certainty. If the slip was in the dependency, the new promise includes the dependency's own date, confirmed with them, not assumed. If the fix failed, the new promise is usually a contact ETA rather than a fix ETA. "I will know by 15:30 whether the second fix has worked, and I will tell you then either way" is honest when the second fix is untested. And "it will be working by 15:30" is a repeat of the mistake that caused the reset. Widen the range and say the far end first. If you genuinely cannot see the finish, say "I do not know yet, but I will know by" and mean it. A cautious second promise kept is worth more than an optimistic one that happens to come true.

Give the requester something to do with the new information. A reset that only moves the date leaves them exactly where they were, waiting, with less confidence. A reset that says "if the second fix has not worked by 15:30, the quickest route to your figures is the shared terminal in the dealing room, and I have checked that its feed is live" has handed Daniel a plan for his four o'clock report that does not depend on Chloe at all. That is the most useful sentence a reset can contain. And it is the one most often left out, because the technician is thinking about the fix and the requester is thinking about the report. Think about the report for one sentence. It is the sentence they will remember.

Resetting Scope: When the Fix Is Not What They Asked For

A scope reset tells the requester that what they will get is different from what they asked for. And it must say both halves: what they will get, and what they will not. "We cannot recover the spreadsheet as it was on Friday; what we can recover is Wednesday night's copy, which has everything except the last two days of entries" is a scope reset. It is disappointing and it is complete. And the requester can start deciding whether to re-enter two days of work or look for the figures elsewhere. "We have recovered what we could" is a scope reset that hides the scope. The requester discovers the missing two days when they open the file, which is the one way to make a partial recovery feel like a failure.

Scope resets need the trade-off stated and, where one exists, an alternative offered. The laptop that cannot be repaired within the week can be replaced with a loan unit today. The report that cannot be rebuilt in the old format can be produced in a new one by Thursday. The feature that cannot be switched on for one person can be switched on for the department with a manager's agreement. The requester asked for a thing because they needed an outcome. A scope reset that reaches the outcome by a different route is often accepted with relief. The craft of declining the thing while finding the route to the outcome is the subject of Offering an Alternative Instead of a Wall. The reset is where that conversation happens on a ticket that is already open.

Ask before you decide, when the choice is theirs. "I can give you Wednesday's copy now, or keep trying for Friday's for another day with no guarantee; which would you prefer?" treats the requester as the person who knows what the two days of entries are worth. They are, and you are not. Most requesters answer in a minute, and the answer is often not the one the desk would have guessed. A scope reset imposed is a disappointment delivered. A scope reset offered is a decision shared, and shared decisions are not resented afterwards.

When the Fix Did Not Work

A failed fix is a reset with the sting of a surprise. And the surprise is the part to take the heat out of first. The requester was told it was fixed, or was expecting it to be, and now it is not. Their first feeling is that the desk did not test it, whether or not that is fair. Say what you tested and what you saw, briefly: "I applied the maker's fix and restarted the terminal at 13:30; the feed came up for a few seconds and then dropped in the same way as before, so the fix did not take." That sentence tells Daniel the desk did the work, watched the result, and is not guessing. And it does more for his confidence than any apology.

The failed fix may be one the requester discovered, because the ticket was resolved and the problem came back. In that case, the reset starts by thanking them for reporting it and by not starting from zero. Most tools reopen a resolved ticket when the requester replies to it, as QuerySolv does. So the returning fault arrives with the whole history attached. It does not arrive as a fresh ticket in the hands of someone who has never seen it. Use that history. The reset says "this is the same fault as before; the fix we applied on the 3rd held for a week, which tells us something, and I am looking at why it stopped working rather than repeating it". A requester whose fault has come back is braced for the desk to apply the same fix again and close the ticket again. Showing them you have read what happened last time is the reset.

The new promise after a failed fix is almost always a contact ETA, because the fix ETA is now genuinely unknown. Pretending otherwise is how a failed fix becomes two. "I will have the maker's second fix by 15:00 and will know by 15:30 whether it works; you will hear from me at 15:30 either way" is the honest shape. If a workaround exists, it goes in the same message, because the requester's immediate need has just reappeared. If the fix fails a second time, the ticket has stopped being a repair and started being a problem. In that case, the right move is to say so and bring in whoever owns problems on the desk. That is the subject of the next section.

The Second Reset

When a promise slips twice, the reset changes character, because the requester's question is no longer "when?" but "do you actually know?" The honest answer may be no. The second reset should say that plainly. It should say what the desk is doing differently rather than more of the same. It should usually carry a second name: the desk lead, or whoever can bring in more help. That way, the requester can see the ticket has been raised rather than merely re-dated. "This has slipped twice and I am no longer confident in my own estimate, so I have asked Priya, who leads the desk, to look at it with me this afternoon; one of us will update you by 17:00" is a second reset that admits the problem and shows the response.

Raising the ticket inside the desk is not the same as making it more urgent, and the distinction is worth keeping. The second reset usually calls for escalation, meaning more skill or authority on the ticket, rather than a higher priority. A higher priority means the ticket jumps the queue. If you run QuerySolv, the escalation flag is separate from priority. So a ticket can be marked as needing the lead's attention without pretending the problem has suddenly become more urgent than it was that morning. Whatever your tool does, the message to the requester should say who else is now involved and why. A second name on the ticket is the most convincing evidence a desk can offer that it has noticed its own repeat.

Offer a different route to the outcome in the second reset even if it is inconvenient, because the requester's patience with the current route has been spent. A loan device, a manual process, a colleague's machine, a report run by hand this month: anything that gets the requester working while the desk sorts out why its estimates keep failing. The second reset is also the moment to review how the first estimate was made, in private, afterwards. Two slips on one ticket are usually the same mistake made twice, most often a dependency that was never checked. The review is cheaper than the third reset. There is rarely a graceful third reset. By then the requester has written their own, and it is not flattering.

A Short War Story: The Three Promises at Kingsmead Academy

Theo, the exams officer at Kingsmead Academy, raised a ticket in the spring about the exam hall's network points. They had stopped working after a refurbishment and were needed for the first on-screen mock examinations three weeks later. Ben on the desk promised the end of that week, then discovered the cabling contractor had to come back. He let the Friday pass without a word. On the Monday he promised the following Friday, then found the contractor could not attend until the week after. Again he said nothing until Theo asked. On the third Monday he promised the Wednesday before the mocks, which the contractor then missed by a day. Each promise was made in good faith and each reset arrived after its deadline, when Theo asked. From Theo's side the desk had been wrong three times and had volunteered none of it. After the second missed date Theo stopped believing the third and booked the reprographics room for the weekend. He had paper versions of every mock paper printed for three hundred students. That took two staff two days and was not needed, because the points were live on the Thursday. The desk had been eight working days late on a cabling job, which was forgivable. The three late resets cost a weekend of printing and a year of Theo checking every date the desk gave him with somebody else, which was not.

The Reset Message

The template below is the reset as a fill-in message, with the three triggers marked so the right lines are used and the rest deleted. It is sent the moment the old promise is in doubt, as a reply the requester receives. And the new time is written on the ticket as the next contact before anything else is done. The second-reset block at the bottom adds the second name and the different route. Use it when the same ticket is being reset for the second time. Read the sentence above it about reviewing the estimate afterwards. Keep the whole message under eight lines. A long reset is a defence, and the requester did not ask for one.

RESET MESSAGE — SEND THE MOMENT THE OLD PROMISE IS IN DOUBT
Ticket: ________   Requester: ______________   Old promise: ________ ____:____
Trigger: [ ] slipped  [ ] scope changed  [ ] fix did not work   Known since: ____:____

THE CHANGE (one line)
  Slipped:     "I said ________ and it will now be later, because ______________."
  Scope:       "The fix will be different from what we discussed: you will get
                ______________; what we cannot do is ______________, because ______."
  Fix failed:  "I applied ______________ at ____:____ and ______________________,
                so the first fix did not take."

THE APOLOGY (one sentence, only for what is yours)
  "I am sorry for ______________________________________________________."
  If nothing on the desk's side is yours to own, write instead: "I wish I had better news."

WHAT IT MEANS FOR YOU
  "This means ______________________________________ on your side."

THE NEW PROMISE (more cautious than the first)
  [ ] Fix:     "It will be working by ________ at the latest, possibly ________."
  [ ] Contact: "I will know by ________ ____:____ and will tell you then either way."
  Meanwhile:   "The quickest route to ______________ until then is ______________."
  Sign-off:    "________, IT desk"

SECOND RESET ONLY (same ticket, second slip)
  "This has slipped twice and I am no longer confident in my own estimate, so
   ______________, who ______________, is now looking at it with me. One of us
   will update you by ________ ____:____. In the meantime, ______________."

AFTER SENDING
  [ ] New next-contact time written on the ticket
  [ ] Cause recorded in the internal notes, in full, for the next technician
  [ ] Second reset: estimate reviewed with the lead; the dependency that was missed named

Chloe sent Daniel's reset at 15:25, an hour and forty-five minutes late, and it read: "The maker's fix did not take; the feed came up for a few seconds at 13:40 and dropped again. I should have told you then and I am sorry I did not. They are sending a different fix which I expect by 15:45, and I will know by 16:00 whether it works; you will hear from me at 16:00 either way. For your four o'clock report, the shared terminal in the dealing room has a live feed and I have checked it." Daniel replied "on my way to the dealing room, thanks" and the report went out on time from a different desk. The second fix worked at 15:52. Chloe's 16:00 message said "fixed, and thank you for your patience this afternoon". It was the first message of the day that she had wanted to send, and the only one that had been on time.

Frequently Asked Questions