A support ticket audit: what users can’t do

Your help desk is a list of everything your users tried to do and couldn’t. Each “how do I…” ticket names a task, in the user’s own words, at the moment it went wrong. Read a month of them together and the same handful of tasks come up again and again.

Most teams read tickets one at a time, answer them and move on. A ticket audit reads them as a set. It takes an afternoon or two, needs nothing more than an export and a spreadsheet, and gives you a ranked list of what to fix. This post is the checklist.

Pick the month and export it

Take one full recent month of tickets from every channel your users write in: email, chat, the help desk form. One month is usually enough to see the pattern without drowning in rows. If you get very few tickets, take a quarter.

For each ticket you want:

• the first message the user sent (not your reply)
• the date, and the plan or account type if you have it
• whether it was solved, and roughly how long it took

Leave out spam, sales enquiries and messages that aren’t from users of the product. You are looking for people who were inside your app and got stuck.

Tag each ticket by task, not by topic

This is the step that makes the audit work. Most help desks tag by area: “billing”, “integrations”, “account”. Those tags are too wide to act on. Instead, tag each ticket with the task the user was trying to do, written as a short verb phrase.

• Not “calendar”, but “connect a calendar”.
• Not “team”, but “invite a teammate” or “change a teammate’s role”.
• Not “export”, but “export last month’s invoices”.

A few rules keep the tags clean:

1. One task per ticket. If a ticket asks two things, tag the first, or split it into two rows.
2. Reuse tags. Keep a running list and pick from it before you write a new one. “Add a teammate” and “invite a user” are the same task.
3. Tag what they wanted, not what broke. A user who says “the import is broken” usually wanted to bring in their contacts. If it turns out to be a real bug, mark it as one in a separate column.
4. Add a type column. For each ticket, note whether it was a how-do-I request (the product can do it, they couldn’t find the way), a bug, a missing feature, or a needs a person case (refunds, exceptions, judgement calls).

Rank the tasks

Count the tickets for each task tag and sort the list, largest first. For each of the top tasks, also note how many were how-do-I requests and the usual time to solve.

For example, say a scheduling product tagged 300 tickets in one month. These numbers are made up to show the method.

Change opening hours62

Connect a calendar48

Invite a teammate41

Add a buffer between bookings33

Refund a booking21

Everything else95

Show as a table

Change opening hours	62
Connect a calendar	48
Invite a teammate	41
Add a buffer between bookings	33
Refund a booking	21
Everything else	95

Example

tickets tagged in the month

300

were for the top five tasks

205

of those were how-do-I requests

184

In that example, five tasks make up most of the queue, and almost all of them are things the product already does. That is the usual shape: a short head of repeated tasks and a long tail of one-offs. The head is where the audit pays off.

To put a cost on the head, try the support ticket cost calculator.

Decide what each task needs

Not every repeated task needs the same fix. Go down the ranked list and give each top task one of four answers.

If the task…	Then	Good for
is hard because the screen is confusing	Fix it in the UI	A setting that is buried, a label that misleads, a step that could have a default
is clear once someone explains it	Document it	Questions with one answer, such as “what does this setting do?”
is clear but tedious, repeated and safe	Automate it for the user	Multi-step changes the user knows they want, such as updating hours or adding a buffer
needs judgement, money or a person	Keep it with your team	Refunds, exceptions, account changes that need approval

Some questions help you choose:

• Would a better screen make this ticket go away? If yes, that is usually the best fix, because it helps every user, not only the ones who write in. Start there for your top one or two tasks.
• Does the user know what they want but not the path? “Make my 30 minute meeting 45 minutes” is a clear goal with a fiddly path. That is a candidate for doing it on the user’s behalf.
• What happens if it goes wrong? Changing hours is easy to undo. Deleting a workspace isn’t. The safer and more reversible the task, the better it suits automation.
• Is it a bug? Send it to engineering with the ticket count attached. A count is easier to prioritise than a single complaint.

1. Step 1Export a monthEvery channel, the first user message›
2. Step 2Tag by taskA verb phrase, plus a type column›
3. Step 3RankCount per task, largest first›
4. Step 4DecideFix the UI, document, automate or keep›
5. Step 5Re-runSame tags on next month’s tickets

Run it again next month

Keep your tag list and run the same audit on the next month’s tickets. If a fix worked, that task drops down the list. If a new task appears near the top, it often follows a release: something moved, and users can’t find it any more.

Two things are worth tracking alongside the ranking:

• How-do-I share. How-do-I tickets divided by all tickets, times 100. This is the part of your queue the product already handles, if users could find the way.
• Repeat askers. Users who wrote in about the same task twice. They are telling you the first answer didn’t stick.

If a task keeps showing up in your audit and also stops new users during setup, it is worth checking your setup funnel for the same step.

Where an in-app agent fits

The “automate it for the user” row is where an in-app AI agent fits. These are tasks the user can describe in one sentence but has to click through several screens to do. A help article tells them the path; an agent can take the path for them.

Stiro is one. You add it to your app with one script tag, and there is nothing to train. A user types or says “add Saturdays 10am to 2pm to my hours”, and Stiro does the steps in your real interface while they watch.

• It does the repeated tasks from your audit. You don’t script each one. Users ask for the task they would have written a ticket about.
• It reads the live screen. When you fix a confusing screen from the first row of the table, Stiro works from the new version. There are no flows to update.
• It says so when it can’t. If the request isn’t possible in your app, it stops, says why and changes nothing.
• The user keeps the final say. Anything that sends, spends or deletes is set up and handed back for the user to press.
• The rest still reaches your team. If Stiro can’t finish, a signed-in user can message your team from the same panel, with the request attached, or it goes to your help desk.

everyday requests passed, cold, in three apps it had never seen

44 of 44

on a repeat run of the same code

43 of 44

The benchmark tasks look a lot like the head of a ticket audit: change an event’s length, add a buffer, update a record. Each was checked in the app’s own database, and the benchmark lists every task and reply. For more on measuring the tickets that never get written, see ticket deflection.

Start with your top five

Export a month, tag by task and look at your top five. Fix the screens you can, document the questions, keep the judgement calls with your team. For the repeated, safe tasks that remain, add Stiro to your app and let users ask for them. The free plan includes 50 runs a month, so you can try it on the tasks from your own audit first.