Answers before the ticket
The FAQ had fallen behind the product. Before refreshing it, I asked a different question: would anyone stuck in a banking system actually read it?
My role: Product Designer, research to UI Team: Product, Support, Frontend lead
- 37%of ~1,000 tickets had one fixed answer, often a bank policy
- ~15% fewerguidance questions after launch, by my own count
- 1 pageFAQ and ticket merged, with answers as users type
The product had moved on. The FAQ hadn't
We had added and removed widgets and changed how the platform works, but the FAQ still described the old version. The product owner and I agreed it was time for a refresh.
Would anyone read it?
I put myself in the user's place:
“I'm stuck in the middle of a payment in a banking system. Do I go and read the FAQ?”
Probably not. So before touching the FAQ, I went to see what users were actually asking.
Many tickets had one fixed answer
A large share just needed information. “How do I add a signatory?” has one answer: bank policy requires a branch visit, and neither we nor support can change that. Yet users called to ask, filling the phone lines and taking the support team's time.
- 37%One fixed answer360 ticketsQuestions with one answer, often a bank policy. Nothing had gone wrong; the user needed information, not a person.
- 43%About the user's own case420 ticketsThe answer depends on the user's role, their organisation, or a specific transaction. These need someone to look at the case.
- 20%Genuinely support work195 ticketsNew bugs, feature requests, and edge cases that needed a person.
No short list would cover it
The most common topic, account statements, was only 1.5% of tickets. The twelve most common together came to about a tenth. A curated list of top questions would miss most users, so whatever we built had to search everything.
Answer first, ask later
We took the analysis to the PM and product owner as a short deck: the ticket breakdown, what each group needed, and one principle: answer first, ask later. It was approved in the same meeting. The PM wanted the help desk spending less time on questions with a fixed answer and more on the financial issues that need a person.
Adding answers to the FAQ wouldn't change anything
Users still wouldn't go looking. The answers had to reach them where they already were: in the middle of filing a ticket. But without blocking them. Forcing users to search the FAQ before they can ask for help would only frustrate them. And 43% of tickets were about the user's own case. Blocking the ticket form would hurt the people with the most at stake.
Merge the FAQ and the ticket form, with live search
As the user types their question into the ticket, matching answers appear beside it. If one helps, they're done. If not, they just send the ticket.
Matching users' words was hard for the backend, so I phased it
Mapping a user's question to the right FAQ answer was the biggest technical issue.
- First: words that appear in the question, plus known synonyms, like loan and facility, or deposit and transfer.
- Then: grow the synonym list by watching how real users phrase things.
- Later: match whole sentences and meaning.
I used AI to pull the keywords for every question, both the exact words and their synonyms, then checked them.
Live, and learning from real users
The merged page is live. By my own count of the support queue, guidance questions fell by about 15% after launch, and most of what's left is about how features work. We're now studying what users type to plan the next phase of matching.
What I learnedBefore improving something, ask whether anyone uses it. The answer changed the whole project.