how to kill "how do i" tickets

the ticket that shouldn't exist

"hey, how do i export this to csv?"

picture the person who answers that. they've probably typed the reply so many times it lives in a saved snippet, with a screenshot attached. the screenshot is from two redesigns ago, so the menu in it doesn't quite match the menu on the screen, and now and then someone writes back to say so.

nothing in this story is broken. export works. the user just couldn't find it, because it sits behind a small ⋯ in the corner of the reports page, and almost nobody opens small ⋯ menus unless they already know what's inside.

that's what we mean by a "how do i" ticket. the user's goal is clear, the product supports it, and they still can't get there alone. we started heytappr because of tickets like this one, so what follows is the process we'd run if we were sitting in the support seat ourselves.

these tickets deserve their own treatment because they behave so differently from the rest of the queue. a bug has to be investigated. a billing dispute needs someone with judgment. a "how do i" question has one correct answer, and your team already knows it by heart. the questions also cluster. a handful tend to make up most of the volume, and they spike right after releases, when a setting moves and everyone who relied on the old location writes in at once.

and you only see some of them. for every person who asks, others give up quietly and never touch the feature again. the ticket count is the visible part of a larger drop-off, which is a good reason to take it more seriously than its size suggests.

find out what people were actually trying to do

most helpdesks tag tickets by product area. billing, reports, integrations. that tells you where people got confused, but it doesn't tell you what they wanted, and what they wanted is the thing you can fix.

so add a second tag for the goal, written the way a user would say it: export-data, invite-teammate, change-billing-email, connect-integration. do this for about four weeks of tickets. if that's more than anyone has time for, tag a random 200 and scale up. the result usually looks something like this (the numbers are made up for illustration):

the last column is the interesting one. when the answer is three menus deep, better documentation won't help much, because documentation isn't what's missing. what's missing is a way to find the control.

once you have the tally, weight it. multiply each intent's volume by how long it takes to handle. forty tickets that each need a screen share cost more than a hundred that get closed with one saved reply. sort by that number and keep the top five. five is few enough to actually finish in a sprint, and in most products it covers a surprising share of the queue.

move the button, or show people where it is

for each of the five, the first question is whether the fix is design. if nearly a fifth of your tickets ask how to export and export hides in an unlabeled menu, put an export button on the page. help content will never beat a control people can see.

plenty of controls can't move, though. billing settings belong in billing. permissions belong in admin. a decent rule of thumb: if new users and long-time users ask about the same control, you probably have a design problem. if it's mostly new users, you have a guidance problem, and the fix is getting the answer to them at the moment they're stuck.

that moment matters more than the content. the second someone opens your help center, they've left your product. now they have to search, pick an article, read it, switch tabs, and match a screenshot to a screen that may have changed since the article was written. a lot of people give up halfway through that and file the ticket anyway. so the answer should live inside the product.

there are a few ways to do that. a help widget with search keeps people in the app but still hands them something to read. a tooltip works for a one-step answer on a single page and gets clumsy for anything longer. the strongest option for a "where is it" question is a walkthrough on the live screen: the user asks, and the product points at the actual control, one step at a time. nobody has to translate a screenshot into anything.

that last format is what heytappr does. the user types or says the question, heytappr picks the guide your team approved, then speaks each step and spotlights the real button, moving on when they click it.

whatever format you choose, write the answers in your users' words. people type "how do i get my data out", not "data export configuration". the tickets you just tagged are the best source of real phrasing you'll ever get, so borrow from them freely.

put the answer where the question starts, and keep it there

most help widgets record which page a ticket came from. look at that field for each intent and you'll often find something unexpected, like change-billing-email tickets arriving mostly from the invoices page rather than from settings. that's where the answer needs to be reachable.

letting people ask, instead of guessing where they'll need help, makes this much easier. you don't have to predict the page at all. heytappr scopes each guide with URL patterns and reads the current page when it matches a question, so "where do i change this" asked on the invoices page and on the profile page gets two different answers, each right for where the person is.

then there's the slow problem. in-app help goes stale. someone renames a menu during a redesign, a tooltip ends up pointing at empty space, and a month later the tickets are back as if nothing had been done.

two habits prevent most of it. first, anchor guidance to stable identifiers, like a data-testid or a real id, instead of a CSS class that changes whenever someone touches the styles. second, make sure you find out when a target disappears. heytappr checks each step's selector on live sessions and lists broken ones in a needs-attention view, so the guide gets fixed before users hit it. if your tool can't do that, add your top five walkthroughs to the release QA checklist.

measure each intent, not the whole queue

total ticket volume is a misleading scoreboard. it rises when signups rise and falls in slow months, regardless of anything you did. track each intent separately instead:

the unanswered list is the one we'd watch most closely. it's users telling you, in their own words, which guide to write next. heytappr logs every question that no approved guide covers, so that list fills in without anyone having to build it.

one intent, start to finish

take change-billing-email from the table above: 71 tickets a month, each closed with a saved reply and a screenshot. the setting can't move, since it belongs in billing, so this is a guidance fix. the whole thing fits in a short checklist.

1. write one guide using the phrases people actually sent: "change billing email", "invoices going to the wrong person", "update the email on receipts".
2. give it three steps (open settings, open billing, click edit next to the invoice email), each pointing at a stable selector.
3. approve and publish it, scoped to the settings and invoices pages.
4. for a month, watch tickets per 1,000 users for that intent and the walkthrough completion rate.

if completion is high and tickets fall, move to the next intent on the list. if completion is low, look at which step people abandon. usually it's one where the thing they need isn't obvious even with the spotlight on it, and that's a hint to reconsider moving the button after all.

that's the whole method, and it's less clever than it sounds. five intents, roughly one sprint each, measured one at a time. the hard part is starting, and starting only means tagging some tickets.