Support requests concentrate on the same screens
If support requests cluster around a few screens and the same questions recur, investigate the affected tasks. Tag tickets by task, screen, cause and severity.
A cluster can indicate a confusing interface, but it can also come from defects, permissions, integration failures or missing functionality. Compare ticket rates with usage before prioritising a redesign.
Key facts
- Support requests concentrating on the same screens are a common signal that a redesign is due.
- Support load can be measured by tagging tickets by screen.
- Tickets asking how to undo a step point to screens designed only for the case where everything goes to plan.
- When a correction is harder than an entry, corrections arrive by message, email or ticket.
- Tickets tagged by screen give a redesign a baseline to measure against.
Why it happens
No path for exceptions. Short picks, partial receipts and rework have no path, so users ask support how to record them.
Correction harder than entry. An entry takes one step, and fixing it needs a supervisor, a separate screen or a support ticket.
Status stored and not shown. The system knows a record is on hold, blocked or late, and the screen where users act does not show it. Users ask why something does not work.
Silent defaults. The system applies defaults without showing them, and users who need different settings find out when results are wrong.
A message that says something failed, without saying which input, turns every error into a ticket.
How it shows up
- Tickets asking how to undo a step
- Corrections requested by message or email
- Support answers that start with a hidden setting
- The same question answered in a help article and still asked
- Different results for users with the same visible setup
- Support volume peaks during onboarding
Options and trade-offs
- Tag tickets by screen before changing anything. It shows where to start and gives a baseline. Tagging adds work for the support team.
- Redesign the screens with the most tickets first. The effect is measurable quickly. Those screens are often the most connected, so changes reach other modules.
- Add help content and tooltips. It is fast and leaves the cause in place. Users who do not read help keep sending tickets.
- Make corrections a normal action. It removes a large share of tickets, and it needs rules about who may correct what and an audit trail of every change.
Common mistakes
- Answering the same ticket repeatedly without tracing it to a screen
- Adding a tooltip where the flow needs an exception path
- Measuring support by response time only
- Designing corrections as an administrator’s task