The Bad-Tool Signal: When the Application Is the Ticket

Wednesday, 11:30, at Tollgate Foods. Ticket 6141 reads "quoting tool frozen again", and Sam knows the rest before he opens it. The screen has stopped responding halfway through a quote. The sales rep has waited five minutes in case it comes back. The only fix is to end the process, start it again and type the quote in a second time. He has done this twenty-two times this month. The quoting tool was bought by the previous sales director and is owned on paper by the current one. It is supported by a vendor whose last three replies have each suggested upgrading. Sam ends the process, confirms the rep is back in, and closes the ticket in nine minutes with the note "restarted, advised to save often". The ticket is fixed. The application is the ticket, and it will be back tomorrow.

A bad-tool signal is a run of tickets whose common cause is one application. There is the same error, the same workaround, and a desk that fixes each occurrence quickly and prevents none of them. That is because the real fix belongs to the application's owner or its vendor, neither of whom has seen the count. Finding the application in the numbers, and telling a tool that fails from one that makes tickets by design, is the subject of Application and Process Hotspots. This article leans on it rather than repeats it. This article is part of our Ticket Data as Organisational Intelligence series. This article is about what happens after the application has been named. It covers who owns it, what evidence moves them, and the vendor conversation that the desk can prepare in full and almost never has.

The article covers the application that writes its own tickets, then the three kinds of bad: fault, design and fit. Next come recognising the signal without blaming the tool, the evidence an application owner will accept, and who owns the tool. Then come the vendor conversation the desk prepares but cannot have, the workaround trap, and when the answer is replacement. A short war story and the tool-fault brief to copy finish the article.

The Application That Writes Its Own Tickets

Every desk has one. Cut a quarter's tickets by the system named in them, and divide by the number of people who use each system. One application sits above the rest by a margin that is not a rounding error. The desk knows its error messages by heart and has a template reply for each. New technicians learn its workaround in their first week, before they learn where the spare keyboards are. It has a nickname, and the nickname is not affectionate.

The reason the signal persists is that each ticket is small and the fix is known. A fault that nobody can fix gets escalated, discussed and eventually solved. A fault that the desk can clear in nine minutes gets cleared in nine minutes, twenty-two times a month, for years. That is because at no point does anyone experience it as a problem large enough to carry anywhere. The desk's competence is what keeps the application alive. That is not a reason to be less competent. It is a reason to count.

The count is the thing nobody else has. The application's owner sees an occasional grumble. The vendor sees whichever tickets the desk bothered to raise with them, which is usually few. That is because raising a ticket with a vendor for a nine-minute fix feels disproportionate. The sales reps see it as the way the tool is. Only the queue holds the number, the dates, the users affected and the hours, all in one place, and only the desk can read it.

Three Kinds of Bad: Fault, Design, Fit

A fault is the application not doing what it is built to do. It might be the freeze, the crash, the error on save, or the report that fails on the last day of the month. The vendor owns the fix; the application's owner owns the decision to make the vendor fix it. In the queue a fault looks like identical error text, a workaround that the desk applies and that holds until the next time, and a pile that does not shrink when the users get better at the tool.

A design problem is the application doing exactly what it was built to do, in a way that makes tickets. That might be a role that must be granted per person per project, or a password that expires on its own schedule separate from the directory's. It might be a form with a field nobody can fill in without phoning. Nothing is broken. The tool was built for a different organisation, or for an administrator who was expected to sit beside it full time. The owner can often fix a design problem without the vendor at all, by changing a setting or a process around the tool. The hotspot article's by-design discussion is where that case is made.

A fit problem is the hardest to say out loud, because it is the tool being the wrong tool. That might be a spreadsheet used as a database by forty people, or a system bought for a team of eight and used by two hundred. It might be an application that was adequate until the organisation changed shape around it. The tickets are varied rather than identical. The workarounds are many. The honest finding is that no setting and no vendor fix will make the pile go away. This one ends in a replacement decision, which is not the desk's to make and is the desk's to evidence.

Sort the pile into the three before writing a word of the brief. That is because the owner's first question will be "what do you want me to do?" The answer is different for each. A fault wants a vendor pushed. A design wants a setting changed. A fit wants a decision taken. A brief that asks for all three has asked for none of them.

Recognising It Without Blaming It

The test is the counterfactual: if this application were replaced tonight by one that worked perfectly, how many of this quarter's tickets would not exist? Count them. If the answer is a dozen, the application is ordinary. If the answer is a hundred and ten, you have a bad-tool signal, and the number is the first line of the brief. The test keeps the finding honest. It excludes the tickets that are about the users, the network or the desk's own habits and that happen to mention the application.

Three tells confirm it. The error text repeats: the same words, the same code, from different people on different days. The workaround repeats: the same resolution note, or the same known-error article linked from every ticket. The discipline of writing that article once is in Known Errors and Workarounds. And the fix never prevents the next occurrence. The desk's action restores the user and changes nothing about the tool. That is the signature of a fault whose real fix lives somewhere the desk cannot reach.

Keep the tool's reputation out of the reading. The desk's technicians have opinions about the application and most of them are correct. None of them belong in the brief. That is because an owner who chose the tool will defend the choice before they read the count. The brief says the application produced a hundred and ten tickets this quarter from forty users, with the error text and the hours. It does not say the application is terrible. The count says that, and the count cannot be argued with the way an adjective can.

The Evidence an Application Owner Will Accept

The owner will accept six things, and all six are in the tickets. The count per month and per user, so that "twenty-two a month from forty users" is understood as more than half the team hitting it monthly. The exact error text and the steps that reproduce it, copied from a ticket, so that the owner or the vendor can see it for themselves within the hour. Since when, and what changed around then: an update, a new integration, a move to a different server, more users. The workaround the desk applies and what it costs each time. What the vendor has already said, with the vendor's own ticket numbers. And the hours, with the users' hours before the desk's.

Where the complaint is slowness rather than failure, the evidence has its own shape. It includes timings from the user's desk, from a spare machine and from outside the network. That shape is laid out in The Slow Application, whose evidence sheet this article links rather than rebuilds. A bad-tool brief about a slow application attaches that sheet and adds the count. The two together are what an owner, or a vendor, can act on. A brief that says "it's slow and people are fed up" has given the owner a feeling. Owners reply to feelings with feelings.

The hours at Tollgate ran like this for one month. There were twenty-two freezes. The desk spent nine minutes each; call it three and a half hours. The sales rep's five minutes waiting plus the quote typed in twice took between fifteen and twenty-five minutes each. Call it six to nine hours. And there were the quotes that went out late because the freeze happened at half past four, which the brief said existed and did not count. That meant between ten and thirteen hours a month, most of it sales time. Over a year that is somewhere around a hundred and twenty to a hundred and fifty hours, or most of a working month. That was all lost to one application in one team. The owner had experienced it as "the quoting tool is a bit flaky". The arithmetic was the first time anyone had told him what flaky cost.

Who Owns the Tool

Every application has three owners and the desk needs the right one. The business owner is the person whose department uses the tool and whose budget pays for it. That person decides whether to push the vendor, change the configuration or replace it. The technical owner is whoever keeps the server, the integration or the updates running, which may be the desk itself. The vendor owns the code. The bad-tool brief goes to the business owner, every time. That is because the business owner is the only one of the three who can make the other two act.

Finding the business owner is harder than it should be, because applications outlive the people who bought them. Ownership of an application is often discovered the way ownership of a stray cat is discovered: by asking who has been feeding it. Ask who approves the renewal, who the vendor's account manager e-mails, and whose team would scream first if it were switched off. Those three answers usually agree. When they do not, the person who approves the renewal is the owner, whether they know it yet or not. In that case, the brief will be the moment they find out. Be gentle about that. Nobody enjoys inheriting a cat.

Expect the owner's first response to be a version of "it works fine for me". It does, because the owner uses it twice a week and the sales reps use it all day. A fault that strikes once in fifty operations strikes the owner once a month and a rep every afternoon. The per-user count answers this without argument, and it is why the count is per user rather than in total. The owner is not wrong about their own experience. They are only being shown someone else's.

The Vendor Conversation the Desk Prepares but Cannot Have

The desk is not the vendor's customer. The contract, the account manager and the leverage belong to the business owner. A technician who phones vendor support about a nine-minute freeze is one more voice in the vendor's own first-line queue. That queue has heard "it freezes" before and has a template reply for it. The desk's role is to prepare the conversation so completely that the owner can have it in twenty minutes. Or the owner can hand the desk written authority to have it on their behalf. Some owners will do that and most will not. Escalating to a vendor without losing the ticket is covered in the article on escalating to vendors and other teams. This is about the pack that goes with it.

The pack has five parts. The reproduction: the exact steps, the exact error text, and whether it happens on a clean machine, which the desk tests before writing anything. The frequency: per month and per user, from the queue, with dates. The history: when it started, what changed, every vendor ticket raised so far with the vendor's reply beside it. The impact: hours, with the users' hours first. And the ask is a specific thing the vendor can say yes or no to. It is one of a known-issue acknowledgement, a fix with a date, a configuration change they recommend, or a workaround better than the desk's. "Please fix it" is not an ask. "Is this a known issue in the release we are on, and is it fixed in a later one?" is, and the answer to it changes what the owner does next.

Three things the desk must not do. Do not promise the owner that the vendor will fix it; the desk cannot deliver that and will be remembered for having said it. Do not argue with vendor support on the owner's behalf without the owner's written say-so. That is because the owner will hear about it from the account manager before they hear about it from the desk. And do not accept "upgrade" as an answer without asking what the upgrade changes. Sometimes it is the fix; sometimes it is the vendor's template. The question "which item in the release notes addresses this?" tells you which. Vendor support is a help desk too. It responds to a good ticket the way yours does.

The Workaround Trap

The desk's own part comes first, as it does for every signal in this series. It includes a known-error article with the workaround, a template reply, and a five-minute fix instead of a nine-minute one. It also includes advice to the users that reduces the damage when the fault strikes. All of this is right and all of it makes the fault invisible. The owner who hears nothing assumes nothing is wrong. The vendor who receives no tickets closes the case. The reps who know the workaround stop raising tickets at all, and the count falls for the worst possible reason. A fault the desk has made bearable is the most dangerous kind, because it has stopped generating evidence while continuing to generate cost.

Keep the evidence flowing even as the workaround does its work. Ask the reps to keep logging each freeze, even a one-line ticket, and say why: the count is what gets the fault fixed. Keep one standing ticket for the fault and link each new occurrence to it, so that the history of the fault is one document rather than a pile of closed tickets. If you run QuerySolv, linked tickets give the owner a single history to read. Most tools can do something similar with a reference in the note. Then carry the count to the owner on the schedule the quarterly review sets, whether or not the desk is coping. Coping is not the same as fixed, and only the desk knows the difference.

When the Answer Is Replacement

A fit problem, and a fault the vendor will not fix, both end in a question the desk does not answer: should this application be replaced? The desk's contribution is evidence, in two forms. The first is the ticket history, which is the most honest requirements list a replacement project will ever get. Every ticket the old tool generated is a thing the new tool must not do. A quarter of tickets sorted by task is a better first page for a requirements document than anything a vendor demonstration will produce. The second is the hours, over a year, in ranges, stated as the cost of doing nothing. That is the number leadership will weigh the replacement against.

Then step back. The decision belongs to the owner and to leadership. The evaluation belongs to whoever is given it. The desk's opinion of which replacement to buy is worth exactly what any other user's opinion is worth, which is something, but not a vote. The conversation about carrying the finding upward, and what to do when the owner declines and the tickets keep arriving, is the subject of Taking the Signal to the Owner Without Making an Enemy. The desk's job is to make the cost of the current tool impossible to misunderstand. What the organisation does with that is the organisation's business, and the queue will record the outcome either way.

A Short War Story: The Check-In Error at Westmere Legal

Westmere Legal's desk of two closed around three hundred tickets a year that read "document won't check in". Each came from a fee-earner whose edited document was stuck between the document management system and their machine. Each was cleared by Rhys or his colleague in about twenty minutes by copying the file out, clearing the lock and checking it in by hand. Each cost the fee-earner about the same again. The firm's practice manager owned the system by default, having inherited it from a partner who retired. The manager had never seen a count, because nobody had ever added the tickets up. The vendor had a support ticket open from two years earlier that had been closed as "cannot reproduce" after the desk stopped replying. Rhys sorted a year of tickets by system for the first time. The document system came out at a hundred hours of desk time and roughly the same in fee-earners' time. He wrote a one-page brief with the error text, three examples and the vendor ticket number. The practice manager phoned the account manager that week. The account manager's answer was that the fault was a known issue. It was fixed in a release the firm had been entitled to for over a year and had never asked for. That release was applied over a weekend, and the following year the desk closed thirty-one. Two hundred hours a year had been spent working around a fix that already existed. That is because the only team that could count the tickets had never thought the count was anyone else's business.

The Tool-Fault Brief

The brief below is one page, addressed to the application's business owner. It is built to answer "what do you want me to do?" before the owner asks it. Section one says which kind of bad it is, because the ask depends on it. Sections two to four carry the evidence an owner and a vendor will both accept, in the order the vendor's own support desk will want it. That way, the owner can forward the page unchanged. Section five is the one ask. Fill it from the tickets. Test the reproduction on a clean machine before you write it down, and attach the slowness evidence sheet if the fault is slowness.

TOOL-FAULT BRIEF — ONE PAGE
To (application owner, by role): ______________________   From: ______________   Date: ________
Application: ______________________   Users: ______   Vendor: ______________________

1. WHAT KIND OF PROBLEM
   [ ] Fault: the application does not do what it is built to do
   [ ] Design: it works as built, and the way it is built makes tickets
   [ ] Fit: it is the wrong tool for how it is now used

2. THE COUNT
   Tickets in the period: ______   Period: __________   Per month: ______   Per user per month: ______
   Of these, would not exist if the application worked: ______
   Since: __________   What changed then: ______________________________

3. THE REPRODUCTION (for a fault)
   Steps: _______________________________________________________________
   Exact error text: ____________________________________________________
   Happens on a clean machine: Y / N      Happens for every user: Y / N / some
   The desk's workaround, and minutes per occurrence: ______________________ (____ min)

4. WHAT IT COSTS, AND WHAT HAS BEEN TRIED
   Users' time: ____ to ____ hours per month      Desk's time: ____ to ____ hours per month
   Over a year: ____ to ____ hours
   Vendor tickets so far: #________ (reply: ____________)  #________ (reply: ____________)
   Three example tickets, names removed:  #______  #______  #______

5. THE ONE ASK
   [ ] Raise it with the vendor as a known issue and ask for a fix date (pack attached)
   [ ] Try the configuration or process change: ______________________ for one month
   [ ] Begin a replacement evaluation; the ticket history is the first requirements list
   We will count again on ____________ and send you the result either way.

Sam sent the Tollgate brief to the sales director with the reproduction tested on a spare laptop and the two vendor ticket numbers beside their replies. The sales director forwarded it to the account manager unchanged, which is what a good brief is for. The account manager's reply named a setting that limited how many quotes the tool held open at once. Nobody at Tollgate had known that setting existed. The freezes fell from twenty-two a month to three. The desk still restarts the tool three times a month, in nine minutes each. It has simply stopped being the only thing anyone did about it.

Frequently Asked Questions