When the Fix Is Weeks Away: Keeping Faith Over a Long Wait

Wednesday, 09:30, at Larkspur Vets. Kwame on the desk has ticket 3890 open, from Ines, the practice manager. It is about the month-end reporting in the practice software crashing on the second branch's server. He also has two e-mails that between them decide the ticket's future. The software's maker says the crash is a known fault, fixed "in the next release", with no date. And the branch server is old enough that the next release will not run on it. So the real fix is a new server, which procurement says is a purchase order, a quote and a six-week lead time away. Ticket 3890 is going to be open for two months. The question is not how to fix it. The question is what Kwame says to Ines this morning, and every week after.

A long wait is a ticket whose fix is more than a couple of weeks away because it depends on something outside the desk's control. That could be a vendor's release, a purchase, or a project that the fix is part of. The work the desk can do is finished in a day; the waiting takes a month or more. And the waiting is where the requester's trust is either kept or lost. This article is part of our Managing Expectations series. It is about the ticket that will be open for eight weeks through nobody's fault. We cover how to keep the requester believing in it the whole time.

It covers the three reasons a fix ends up weeks away, then saying "weeks" on day one. Next come the workaround as the real deliverable in the meantime, and the long-wait update rhythm, with a picture. We cover where the ticket lives while it waits, then keeping faith over a month, including the day the date moves. We move on to what to do when the thing finally arrives. We finish with a short war story and the long-wait message to copy, in that order.

Three Reasons a Fix Is Weeks Away

Long waits come from three places, and each one changes what you can honestly promise. A vendor dependency is a fix that only the maker of the thing can supply. Examples are a software release, a repair under warranty, or a replacement under a support contract. A procurement dependency is a fix that needs something bought: a part, a device, a licence, a server. A project dependency is a fix that will arrive as a side effect of something bigger that is already planned. That could be the migration next quarter, the new phone system, or the office move. In each case the desk has done its part and is waiting on a process it does not run.

What you control differs in each case, and the requester deserves to know which case they are in. With a vendor, you control how often you chase and how loudly, and nothing else. With procurement, you control how quickly you raise the order and how complete it is, and after that the finance process sets the pace. With a project, you control whether the requester's need is on the project's list, and the project's schedule sets the rest. Saying which one applies is not passing the blame. It is telling the requester where the clock is, so they stop looking at you for the time.

The table below puts the three side by side, with what the desk controls and what it does not. It includes the one sentence the requester most needs to hear in each case. The last column is the same in every row for a reason. Whichever dependency it is, the requester's question is still "who has it and when will I hear". The answer still has to come from a named person on the desk, not from the vendor, the finance team or the project.

Say "Weeks" on Day One

Tell the requester it will be weeks on the day you know it, in those words. The temptation is to say "we are looking into it" and let the weeks reveal themselves gradually. That is because "weeks" sounds like bad news and "looking into it" sounds like effort. It is the wrong instinct. A requester who is told "six to eight weeks" on Wednesday can plan: arrange cover, warn their own manager, change how they do the month-end. A requester who is told "looking into it" plans for Friday, and on the second Friday they stop believing anything the desk says. Bad news early is a fact. Bad news late is a betrayal.

The day-one message says four things. What the fault is, in a sentence. Why the fix is weeks away, naming the dependency without editorial. What the requester can do in the meantime, or that a workaround is coming and when. And when they will next hear, which for a long wait is a fixed weekday every week. Kwame's version: "The month-end crash is a known fault in the practice software that the maker fixes in their next release, and the branch server will need replacing to run it. I have raised the order today; the realistic timescale is six to eight weeks. By Friday I will have a way for you to run the month-end on the main surgery's server in the meantime. I will update you every Friday until this is done, starting this Friday, even if there is nothing new. Kwame, IT desk."

Give the timescale as a range with the far end you would bet on, and give the dependency's own date only once you have it in writing. "Six to eight weeks" is honest when procurement has said six and you have seen procurement before. "The 14th" is honest when the supplier has confirmed the 14th on the order acknowledgment. Saying a precise date you have not been given is how long waits turn into a series of broken promises, each one a week apart. The craft of choosing a range you can keep is in Honest ETAs: Promising a Time You Can Keep. On a long wait the only extra rule is that the far end moves out by a fortnight for every organisation that has to approve something.

The Workaround Is the Deliverable in the Meantime

For the length of the wait, the workaround is the thing the desk actually delivers, and it deserves the care a fix would get. A workaround is a tested way of getting the job done while the real fix is pending. It could be a different machine, a manual step, or a second route to the same result. It is not "try turning it off and on" and it is not a suggestion. It is written down, it has been tried by someone, and the requester has confirmed it works for them. Ines does not care that the server is on order. She cares that the month-end runs on the last working day of the month. The workaround is the only thing that makes that true between now and the new server.

Deliver the workaround as a dated promise and follow it up like a fix. "By Friday I will have a way for you to run the month-end on the main surgery's server" is a fix ETA for the workaround. It is kept or reset like any other. When it is in place, send the steps in writing and check a week later that it is still working. Ask the question most desks forget: "Is this good enough to live with for six weeks, or do we need something better?" Sometimes the answer is that the workaround is fine and the wait is comfortable. Sometimes it is that the workaround costs the requester an hour a day, which changes how hard the desk should push the dependency. You do not know which until you ask. Workarounds are also an unreliable guide to urgency on their own. A wait that is comfortable for the desk is not necessarily comfortable for the person doing the manual step every afternoon.

Where the same fault will hit other people during the wait, write the workaround where the desk can find it. In that case, link every new ticket to it, so the second requester gets the steps in the first reply instead of a second investigation. The record that does this, the known-error entry with its recognition test and its linked-ticket count, is the subject of Known Errors and Workarounds. And a long wait is the most common reason a known error exists. The count of linked tickets is also what makes a procurement officer move faster. "Three branches are running month-end by hand" is an argument. "It would be nice to have the server" is a wish.

The Long-Wait Update Rhythm

On a long wait the update goes out once a week, on the same weekday, whether or not anything has happened. The fixed day is the whole mechanism. It gives the requester a day to expect the message, so they do not wonder on Tuesday. It gives the desk a day to send it, so it is not forgotten. And it makes the absence of a message loud, because a Friday with no update is noticed by both sides within hours. Pick the day that suits the desk's week, usually a Friday, so the requester goes into the weekend knowing the ticket is alive. Never let the day pass.

Each weekly message is short, often one or two lines. It carries the same three parts as any update. It says what has changed, which is often nothing, and where the dependency stands, with its date. It says that the next message is next Friday. "No change this week: the server order is with the supplier, delivery is still expected the week of the 14th, and I confirmed that with them on Wednesday. The month-end workaround still stands. Next update Friday the 7th. Kwame." Nobody has ever complained about receiving that message. Plenty of people have complained about not receiving it.

The picture below is the rhythm over an eight-week wait. Day zero is the acknowledgment that says "weeks" and names the owner and the first contact date. Day two is the workaround, tested with the requester. Then one blue mark every Friday, the routine update, news or no news. In week three the orange mark is the day the date moves, and the message goes out that same day rather than waiting for Friday. In week eight the green mark is the arrival, the scheduled fix and the close. The requester never goes more than seven days without hearing from a named person. And the desk never has to remember anything except that it is Friday.

Two things make the rhythm cheap enough to keep. The first is that the weekly message is written from the ticket, not from memory. The dependency, its case or order number, its current date and the workaround are all on the ticket already. And the message is a sentence built from them. The second is that the day is the same for every long-wait ticket on the desk. So the Friday pass is one view, sorted by next contact, worked top to bottom in half an hour. The general discipline of the end-of-day update pass is covered in Status Updates That Prevent the Angry Follow-Up. That article also covers what to do when the no-news message has gone out three times unchanged. On a long wait, three unchanged weeks is normal; it is the dependency's date slipping without a message that is the warning sign.

Where the Ticket Lives While It Waits

A long-wait ticket is parked in a waiting status, with the date it is waiting for written on it. And it is never closed to tidy the queue. A waiting status is any status that means "the next step belongs to someone outside the desk": waiting on vendor, waiting on part, on hold. It takes the ticket out of the active list, which is right, because nothing on the desk is due on it between Fridays. The danger is that it takes the ticket out of every list. And a ticket in no list is a ticket that is forgotten the week the server arrives. The protection is the date on the ticket and the Friday view. Together they make the waiting ticket reappear every seven days whether or not anybody remembers it. Which waiting status means what is covered in Pending User vs Pending Vendor vs On Hold. That article also explains why the distinction matters when the wait is on a requester rather than a supplier.

Closing the ticket "because there is nothing we can do" and promising to open a new one when the part arrives is the mistake to avoid. It is made for understandable reasons: the ticket is old, it makes the aging report look bad, and the desk's part really is finished. Close it anyway and three things happen. The requester gets a closure notice for a problem that is not fixed, which reads as the desk giving up. The order, the vendor case and the workaround lose their home, and in six weeks someone has to reconstruct them. And the second requester with the same fault gets a fresh investigation instead of a link. Leave it open, in a waiting status, with the date. An honest aging report has long-wait tickets on it. A flattering one has closed them and will pay for that in week six.

When several requesters are waiting on the same fix, link their tickets to one record. That gives you one place that knows who is waiting and one Friday message that reaches all of them. The record can be a parent ticket, a problem entry or a known-error article, depending on the tool and the desk. What matters is that the list of waiting people is in one place. The weekly update must not depend on anyone remembering that the third branch asked too. If you run QuerySolv, linking the tickets keeps that list on the tickets themselves. So the Friday message goes to everyone who is waiting and nobody is discovered in week seven. Whatever tool you use, the test is the same: can you name, from the ticket, every person who will want to know when the server arrives?

Keeping Faith Over a Month

Trust on a long wait is lost in three ways: silence, a missed date, and a surprise. Silence is the Friday with no message, and the rhythm prevents it. A missed date is the 14th arriving with no server and no explanation. It is prevented by checking the dependency before the date, not after. That way, the message on the 10th says "the supplier has confirmed the 14th" or "the supplier has moved to the 21st". It replaces the message on the 15th saying "I will find out what happened". A surprise is any news the requester gets from somewhere other than the desk. Examples are the server arriving at reception, the vendor e-mailing them directly, or a colleague mentioning the project slipped. Surprises are prevented by the desk being the first to know and the first to say.

The date will move at least once on any wait of more than a month. The day it moves is the most important day of the whole wait. The message goes out that day, not on Friday. It says the new date, the reason in a sentence, and what the desk is doing about it. "The supplier has moved delivery from the 14th to the 28th because the model we ordered is out of stock; I have asked procurement whether the next model up can ship sooner at the same price and will know by Wednesday. The workaround still stands. Kwame." The craft of the reset is the subject of Resetting Expectations When the Plan Changes. That includes the apology that is not grovelling and why the second promise must be more cautious than the first. On a long wait, the one addition is that a moved date is also the moment to re-examine the workaround. A fortnight more of an hour a day may no longer be acceptable.

Check in on the requester in the middle of the wait with a question, not just a status. Around the halfway point, add one line to the Friday message: "Is the workaround still manageable, or has anything changed on your side that I should know about?" The answers are often useful. Ines may say the month-end now has to be run twice because of an audit, which changes the urgency. Or she may say that a locum is covering next month and will need the steps written more carefully. Or, most often, she may say "fine, thanks for asking". That costs nothing and reminds her that the person on the other end of the Friday message is a person. A long wait is a relationship, and the relationship is mostly maintained in one-line messages. It is still a relationship.

When the Thing Arrives

The arrival of the fix is where long waits most often go quiet. And it is the worst place to go quiet, because the requester has been counting down to it. The server arrives at reception on a Tuesday; the desk is busy; it gets built on Thursday. It goes in on the following Wednesday. At no point was Ines told that the thing she had waited eight weeks for was in the building. Tell them the day it arrives, with the plan: "The server is here. I will build it this week and need an hour at the branch next Tuesday morning to swap it over; does 08:00 work for you? The month-end workaround stays in place until I confirm the new server has run it cleanly." The requester has been patient for two months. The least the desk can do is let them watch the finish.

Confirm the fix with the requester before closing, and confirm it against the thing they were waiting for, not the thing the desk installed. The server being in and the practice software being upgraded is the desk's definition of done. Ines's definition is the month-end running on the branch server without a crash. The honest close waits for that, even if it means leaving the ticket open until the last working day of the month. Close it with a note that says what was wrong, what was done, and what to do if it comes back. Include a thank you for the wait, which they earned. If the fault does return, the requester's reply reopens the ticket with its whole history attached, as it does in QuerySolv. The history is where eight weeks of order numbers, dates and workarounds are waiting for whoever picks it up.

A Short War Story: The Eight-Week Scanner at Northgate Retail

Jas, who managed Northgate Retail's Westgate branch, raised a ticket for a replacement handheld stock scanner after the store's only one stopped charging. Mei on the desk ordered a new one through procurement that afternoon, told Jas it was "on order", and moved on. The order took eight weeks, through a quote, a budget approval and a supplier back-order. Mei checked on it every fortnight and wrote what she found in the ticket's internal notes. Jas heard nothing after the first day. In week four he raised a second ticket asking whether the first had been lost. In week five he asked the regional manager, who authorised buying a cheap barcode scanner from a shop in the retail park. It turned out not to run the stock application and went into a drawer. By week seven Jas had stopped opening messages from the desk. So when the real scanner arrived in week eight and Mei wrote to arrange delivery, the message sat unread for four days. The branch did five weeks of stock counts by hand, bought a device it could not use, and had two tickets for one scanner. The lesson Mei took from it was that from the outside, a long wait with no rhythm looks exactly like a forgotten ticket.

The Long-Wait Message

The template below is the long wait in three messages. The day-one message says "weeks", and the Friday line keeps the ticket alive. The arrival message lets the requester watch the finish. Fill the first from the ticket and the dependency's paperwork. Send the second every week from the Friday view, and send the third the day the thing arrives. The same-day reset message for a moved date is in the resetting article and is not repeated here. Keep every line short; the requester reads these on a Friday afternoon and needs the date, not the story.

LONG-WAIT MESSAGES — SEND AS REPLIES THE REQUESTER RECEIVES
Ticket: ________   Requester: ______________   Owner: ______________
Dependency: [ ] vendor  [ ] procurement  [ ] project
Reference (case / order / project): ______________   Their date: ________
Weekly update day: ______________

DAY ONE — SAY "WEEKS"
  "The problem is ________________________________________________.
   The fix depends on ______________________, which I have raised today
   (reference ________). The realistic timescale is ____ to ____ weeks.
   In the meantime, by ________ I will have a way for you to
   ____________________________________________________.
   I will update you every ________ until this is done, starting this
   ________, even if there is nothing new.
   ________, IT desk"

EVERY WEEK — THE FRIDAY LINE
  "[ ] No change this week  [ ] Change: ______________________________.
   The ____________ is with ______________; their current date is ________,
   confirmed with them on ________. The workaround still stands.
   Next update ________.   ________"
  Mid-wait, add once: "Is the workaround still manageable, or has anything
  changed on your side that I should know about?"

THE DAY IT ARRIVES
  "The ______________ has arrived. The plan is ______________________ on
   ________; does ____:____ work for you? The workaround stays in place
   until I have confirmed ______________________ works for you.
   ________"

BEFORE CLOSING
  [ ] Requester has confirmed the thing they were waiting for, not just the install
  [ ] Closing note: what was wrong, what was done, what to do if it returns
  [ ] Linked tickets from other requesters updated and closed with them

Kwame sent the day-one message to Ines on the Wednesday, the workaround on the Friday, and a Friday line every week for nine weeks. It took that long because the supplier moved the date once. The reset went out on a Tuesday in week three. Ines replied to three of the nine Friday messages. Once she said the workaround was fine, and once she said a locum would need the steps. Once, in week six, she said "you don't need to keep sending these, I know it's coming". Kwame took that as the best review the desk had ever received and kept sending them anyway. The server went in on a Tuesday in week nine, and the month-end ran cleanly on the Friday. The ticket closed that afternoon with a note and a thank you. Nobody had chased, nobody had bought anything from the retail park, and nobody had been surprised.

Frequently Asked Questions