What a vague ticket actually costs, in numbers a manager can use

Engineers describe vague tickets in terms of annoyance. Managers have to describe them in terms of money, and the translation is usually done badly, because the obvious cost is the small one.

The obvious cost is the developer's time: ten minutes reading a bad report, ten minutes writing a clarifying comment. Twenty minutes, call it £15. Multiply by a few hundred tickets a year and you get a number that is real but unpersuasive, and that any competent finance person will discount as noise.

That number is wrong because it prices the wrong thing.

The expensive part is wall-clock time, not work

Here is what happens to a ticket that needs one clarifying question.

• Day 0, 16:40. Reporter files "export is broken" and goes home.
• Day 3, 09:15. It reaches the top of someone's queue. They read it, cannot start, and ask which export.
• Day 3, 18:00. Reporter is in a timezone five hours behind and has finished for the day.
• Day 4, 11:00. Reporter answers.
• Day 4, 11:00 onwards. The developer is now mid-way through something else, so the ticket waits for the next slot.
• Day 6. Work begins.

Twenty minutes of effort, six days of latency. And every hour of that latency is one where a customer is still hitting the bug, a fix is still not shipped, and the ticket is occupying space in somebody's head.

Three costs that do not appear on the timesheet

The context switch is not twenty minutes. Reading a ticket, deciding you cannot act on it, and writing a question is an interruption with a tail. The developer had to load enough context to know the ticket was unanswerable, and that context is then discarded. Estimates for recovering deep focus vary between fifteen minutes and half an hour, and it happens twice: once going in, once when the answer arrives days later and they have to reload the whole thing.

Unclear tickets get deprioritised, not clarified. This is the one nobody measures. Faced with a queue containing one crisp ticket and one vague one, everybody picks the crisp one, every time, and it is the right local decision. The vague ticket is not scheduled according to its importance, it is scheduled according to how well it was written. Over a quarter this quietly reorders your roadmap by writing quality, and you will not see it in any report.

Reporters learn. Somebody who files a careful report and hears nothing for six days files a shorter one next time. The feedback loop teaches the opposite of what you want, and it teaches it to the people who were trying hardest.

A number you can actually take to a meeting

Do not price the effort. Price the delay, and price the queue distortion.

Take your median time from issue filed to work started. Split your tickets into ones that needed a clarifying round trip and ones that did not. The difference between those two medians is the cost of vagueness, in days, per ticket, measured on your own data rather than an industry study. Most teams have never separated those two populations and are surprised by the gap.

Then multiply by the number of tickets a year that needed a round trip. That is your annual delay, expressed in the only unit that matters to the person who asks when the fix ships.

If you want a second number, count the tickets where the clarifying question was never asked at all, and the issue simply went quiet. In most trackers that population is larger than anyone expects, and it is pure waste: somebody took the time to report a real problem, and the organisation did nothing with it.

The fix is timing, not discipline

Every remedy that relies on the reporter writing better fails for the same reason: the reporter does not know what you need, and they never will, because they cannot see your code.

What changes the number is when the question gets asked. Asked on day 3, it costs six days. Asked at 16:41 on day 0, while the reporter still has the failure on screen and their coat is not yet on, it costs about four minutes and the ticket arrives complete.

Nothing else in the chain has to change. Same reporter, same question, same developer. Just asked while somebody is still there to answer it.