Honest ETAs: Promising a Time You Can Keep

Monday, 11:15, at Redbrook Engineering. Tom is in his third week on the desk. Sunil from the design office has raised ticket 7734: his workstation will not launch the drawing software since the licence server was moved on Friday. Tom has seen this once before and knows the fix, a change to one setting on the licence server, takes twenty minutes. "Should be sorted this afternoon," he says. He has eleven tickets ahead of Sunil's and a team meeting at 13:00. The licence server belongs to Priyanka, who is on a site visit until Wednesday. At 16:30 Sunil replies to the ticket: "Any news? You said this afternoon." Tom had estimated the work. Sunil heard a promise about the wait.

An ETA, estimated time of arrival, is a phrase borrowed from transport. On a help desk it means the time you tell a requester that something will happen. The something can be a fix, a part, a call back or a decision. The moment you say a time out loud it stops being an estimate in the requester's mind and becomes a promise. That is not a misunderstanding on their part. It is what the word means to the person waiting. This article is part of our Managing Expectations series. It is about giving times you can keep: where the honest number comes from, how to phrase it, and what to do when you do not have one.

It covers why every time you say is a promise and the two different times a requester may be asking about. Next comes estimating from the queue rather than from the fix, with a worked example. Then come ranges rather than points, padding honestly, and the sentence for when you do not know yet. It finishes with re-estimating early, why a service-level target is not an estimate, a short war story, and the ETA phrasing table to copy.

Every Time You Say Out Loud Is a Promise

A requester hears a time, not the words around it. "Should be this afternoon", "probably by Wednesday", "hopefully end of the week" are all heard as this afternoon, Wednesday and Friday. The requester has to plan, and you cannot plan around "probably". Sunil told his project lead that the workstation would be back after lunch. The project lead moved a review to Tuesday morning on that basis. By 16:30 the estimate had become a commitment two people had built on, and the word "should" had done nothing to soften it. Hedging words protect the speaker. They never reach the listener.

The asymmetry is what makes estimates dangerous. A kept estimate is forgotten by Friday; the requester got what they were told, which is what they expected, and nothing memorable happened. A missed estimate is remembered for a year. It is the story told about the desk in the kitchen, and it colours every estimate the desk gives afterwards. That is why desks with a history of optimism find that nobody believes them even when they are right. You cannot earn trust with an accurate estimate. You can only lose it with an inaccurate one.

The fix is not to stop giving times. A desk that refuses to estimate has answered "when will I hear?" with a shrug. The requester invents their own deadline, which is always sooner than yours, and measures you against it. The fix is to give times that are built on what you actually know, phrased so that the requester hears what you meant, and revised before they become wrong. That is three skills, and the rest of this article takes them in order. (The fourth skill is keeping your mouth shut for the ten seconds it takes to work the number out. It is the hardest one.)

Two Different Times: When You Will Hear and When It Will Be Fixed

A requester asking "how long will it take?" may be asking one of two things, and they are not the same promise. The contact ETA is when they will next hear from you. The fix ETA is when the thing will work again. The first is always within your control, because you decide when you write. The second depends on the queue, on parts, on other people and on whether the first fix works. Mixing them up is how Tom got into trouble: Sunil asked about the fix, Tom answered about the work, and neither of them noticed the gap.

Always give the contact ETA, and give the fix ETA only when you can see it. "I will update you by five today, fixed or not" is a promise you can make about any ticket in the first minute. It answers the question that is actually causing the requester's anxiety, which is whether they have been forgotten. The three questions behind every ticket, and why "when will I hear" matters more than "when will it be fixed", are the subject of What Users Actually Want to Know About Their Ticket. This article picks up from there, with the fix ETA, which is the harder of the two.

When you do give a fix ETA, say which one you are giving. "It will be working by Wednesday noon" and "I will have an update for you by Wednesday noon" are different promises. A requester who hears the first when you meant the second will be at your desk at 12:05 on Wednesday. The phrasing table at the end of this article keeps them apart. The habit to build is to never say a time without a verb attached to it: fixed by, updated by, delivered by, decided by. The time is the easy part. The verb is the promise.

Estimate From the Queue, Not From the Fix

A fix ETA has three parts, and the fix itself is the smallest of them. The first part is the work: how long the fix takes once you are doing it. The second is the wait: how long before you can start. That is set by what is ahead of this ticket in the queue and by the rest of your day. The third is the dependency: anything that has to happen first and is not in your hands. Examples are a part, an approval, or a colleague who owns the system. Tom's estimate counted the first part and ignored the other two. Twenty minutes of work was true. It was also irrelevant until Wednesday.

The wait is estimated from the queue, and most people on a desk have never done the arithmetic. Count the tickets you intend to do before this one. Multiply by the time a typical ticket takes you. And add the meetings, the walk-ups and the lunch you will actually take. Tom had eleven tickets ahead of Sunil's. At about half an hour each, that is five and a half hours of work. In a day that also holds a team meeting and the usual interruptions, that is not this afternoon. It is tomorrow. An estimate that ignores the queue is an estimate of how long the ticket would take if it were the only ticket, and it never is.

The dependency is the part that turns hours into days, and it has to be checked rather than assumed. Who owns the system you need to change? Are they in? Is the part on the shelf, or is "we have one of those" a memory from last year? Does anyone have to approve this, and when do they next read e-mail? One phone call before the estimate saves a week of apology after it. Tom could have asked whether Priyanka was in. He did not, because the fix was so clearly twenty minutes that it did not occur to him anyone else was involved. Dependencies hide behind easy fixes. The easier the fix, the less you look.

The table below is Tom's estimate worked honestly, part by part, next to the one he gave. The honest contact ETA is end of day Monday, which he could have met without touching the licence server. The honest fix ETA is Wednesday, and "Wednesday" said on Monday at 11:15 is a mild disappointment Sunil can plan around. "This afternoon" said on Monday and missed is a broken promise on Monday evening, a second one on Tuesday, and a third on Wednesday. That is for the same fix delivered at the same time.

Ranges Beat Points

A range is an honest estimate; a point is a guess wearing a tie. "Between Wednesday noon and Thursday noon" tells the requester what you know, which is that the fix is roughly a day's work away with some uncertainty about the day. "Wednesday noon" tells them you know exactly, which you do not. The first time Wednesday noon slides to Wednesday three o'clock they learn that your exact numbers are not exact. Give the range, and let the near end be the thing you hope for and the far end the thing you would bet on.

How wide should the range be? Wide enough to be true and narrow enough to plan around, and when those two conflict, true wins. "Sometime this month" is true and useless. "Wednesday afternoon or Thursday morning" is true and useful. A range might need to span an unknown dependency, such as "two days to three weeks depending on whether the supplier has the part". That is not a range. It is two different estimates glued together, and it should be replaced by the sentence in the next section but one. The width of the range is a measure of how much you have found out. Narrow it as you learn.

The trap with ranges is saying only the near end. "Wednesday, maybe Thursday" is heard as Wednesday, with Thursday as a footnote nobody reads. Say the far end first if you must say them in order ("Thursday noon at the latest, possibly as early as Wednesday"). The far end is the promise and the near end is a hope. I spent a year telling people the near end out of a wish to sound efficient. Every single one of them heard a deadline.

Padding Honestly

Padding is adding time to an estimate to cover what you have not thought of, and it is an honest practice when done in the open. The things you have not thought of are real. They include the fix that needs a restart nobody mentioned and the walk-up that eats the hour you had set aside. They also include the second ticket from the same requester that turns out to be the same problem. An estimate with no room for them is an estimate that is wrong whenever anything happens, and something always happens. Add the room. Then say the padded time as the far end of your range and deliver early when you can.

Padding becomes dishonest when the padding is presented as precision, or when a reason is invented to justify it. "The system needs forty-eight hours to replicate" is a lie if the system needs forty minutes and you wanted the slack. "It is policy" is a lie if the policy is that you were busy. The requester may never find out, but you now have a desk whose explanations cannot be trusted. Explanations are the only tool you have when something genuinely does take forty-eight hours. Pad the number, never the explanation. "I am saying Thursday to be safe; it may well be Wednesday" is padding said out loud, and nobody has ever objected to it.

Padding has a ceiling, and the ceiling is the point at which the requester's plan changes. If "Thursday to be safe" means Sunil's project lead moves a client review that could have stayed put, the padding has cost the organisation something real. Ask, when the estimate matters, what the requester is deciding based on it. Often the answer is "nothing, I just want to know", and you can pad freely. Sometimes it is "whether to book the room". Then the honest thing is a narrower range with a promise to confirm, which is a more demanding promise and the right one.

"I Do Not Know Yet, But I Will Know By"

There is a sentence for the ticket you cannot estimate, and it is not "I don't know". It is "I do not know yet, but I will know by Wednesday noon, and I will tell you then." This is the estimate of an estimate. It is the most useful sentence on a desk, because it answers the requester's real question (will I be left in the dark?). It does so without inventing an answer to the one you cannot answer (when will it be fixed?). The requester gets a time to plan around. You get the time to find out. Nobody has been promised a fix.

Use it whenever the dependency is unknown rather than merely slow. If the part may or may not be in stock, you do not know the fix ETA. In that case, any number you give is a coin toss with your name on it. What you do know is how long it takes to find out whether the part is in stock, which is one phone call. So "I will know by two o'clock" is honest and precise. Resist the pressure to fill the silence with a guess. The requester would rather have a real time for a real answer than a fake time for the fix. Most of them will say so if asked, and the ones who would not are the ones who most need you to hold the line.

The sentence carries an obligation: you must actually know by then. "I will know by Wednesday noon" followed by silence on Wednesday is the worst outcome available, because you have now broken a promise you designed to be unbreakable. Write the time on the ticket as the next-contact time, and do the finding out. At Wednesday noon send either the fix ETA or the honest "I still do not know, because the supplier has not answered; I will chase them and update you by Thursday noon". The second message is disappointing. It is not a broken promise. The difference is the whole of this article.

Re-Estimate Early, Never at the Deadline

An estimate is a living number, and it changes the moment you learn something that moves it. The rule that keeps estimates honest is to re-estimate at the halfway point: when half the promised time has gone, ask whether you can see the finish from here. If you can, say nothing and carry on. If you cannot, the estimate is already wrong. The requester should then hear the new one now, while there is still time for them to adjust. At the deadline, the only thing left to adjust is their opinion of you.

The cost of a late re-estimate rises steeply with lateness. A new time given at the halfway point is a mild correction: "Wednesday is looking more likely than Tuesday; I will confirm tomorrow." The same new time given an hour before the deadline is bad news with no warning. Given an hour after the deadline it is a broken promise with an excuse attached. The information was identical in all three cases. Only the timing differed, and the timing is what the requester remembers. Tom knew by 13:30 on Monday that the licence server was Priyanka's and that she was away. He said nothing until Sunil asked at 16:30, by which time the afternoon had been promised, planned around and lost.

The halfway check is a habit, not a tool feature. And it works on any desk that writes the promised time on the ticket where it can be seen. Each morning, look at every ticket whose promised time falls today or tomorrow and ask of each one whether you can see the finish. For the ones where you cannot, send the re-estimate before lunch. What goes in that message, how to apologise without grovelling, and how to make the second promise more cautious than the first are the subject of Resetting Expectations When the Plan Changes. Here the rule is only about timing: early is a correction and late is a confession, and the facts do not care which one you choose.

A Service-Level Target Is a Ceiling, Not an Estimate

Many desks publish service-level targets, maximum times for a first response and for a resolution by priority. It is tempting to quote the target as the ETA. Do not. A service-level target is the longest the desk has agreed a ticket of that priority may take. It is the ceiling, and the desk is meant to come in under it most of the time. Quoting it as the estimate tells every requester they will wait the maximum, which is both discouraging and usually untrue. The honest estimate is the queue arithmetic from earlier in this article, and the target is the line that arithmetic must never cross.

Where the two meet is useful, though. If your honest estimate lands beyond the target, you have learned something before the requester has: this ticket is going to breach. In that case, now is the moment to re-prioritise it, hand it to someone with a shorter queue, or escalate it. Do not wait for the moment the breach report lands next week. If you run QuerySolv, the service-level targets are set per priority on a business-hours schedule. So the ceiling for any ticket is visible from the moment it is prioritised. An honest estimate that overshoots it is an early warning you can act on. The difference between response targets and resolution targets, and what each should promise, is explained in Response vs Resolution Targets. This article only asks that you never confuse either of them with an estimate.

A Short War Story: The Four O'Clock Promise at Tollgate Foods

Hollie, who ran the desk at Tollgate Foods, took a call on a Thursday morning from Marco, the production planner. It was about the pallet-label printer in the packing hall, which had stopped printing cleanly and was turning out labels the scanners could not read. She had replaced a print head on the same model before, knew it took forty minutes, and told Marco it would be working by four. The spare print head was not in the cupboard. It had been used in the spring and never reordered, and the supplier could not deliver another until Monday. Hollie found this out at half past one and spent the afternoon hoping a different supplier would come through, so that she would not have to make the call. At ten past four Marco rang her. The evening and night shifts hand-wrote pallet labels for two days. Three pallets went to the wrong customer because a handwritten code was misread. Monday started with a recount of the whole despatch bay. Hollie's estimate had been accurate for a fix that was not in the building. The three hours she spent hoping cost more than the four days the part took.

The ETA Phrasing Table

The table below is the estimate in words, by situation. The middle column is what to say. The next is the phrase people reach for instead, which sounds similar and makes a different promise; the last says why the difference matters. Use the left column to find your situation, say the middle column more or less verbatim, and write the time on the ticket. The table is deliberately plain. Estimates are not the place for personality.

Before you say any time out loud, run the short check below. It takes ten seconds, which is the ten seconds Tom skipped on Monday at 11:15.

• Have I counted the work, the wait and the dependency, not just the work?
• Is the time I am about to say the far end of what I believe, not the near end?
• Have I attached a verb: fixed by, updated by, or decided by?
• If I cannot see the fix, am I saying "I will know by" instead of guessing?
• Have I written the time on the ticket so the halfway check can find it?

Tom gave Sunil a new message on Monday evening, after Sunil had asked, which was the wrong order. It read: "I should have said this at lunchtime. The change has to be made by Priyanka, who owns the licence server and is back Wednesday morning. Your workstation will be working by Wednesday end of day, and I will confirm the exact time on Wednesday at 09:30. Sorry for the silence this afternoon." Sunil replied with one word, "thanks", and the review was moved to Thursday. On Wednesday at 09:20 Priyanka made the change, and Tom's confirmation message said "done" instead of giving a time. The desk had not got faster. It had started saying Wednesday when it meant Wednesday.

Frequently Asked Questions