Users report problems weeks after they happen
By the time a problem reaches you, the details are gone and others have hit it too. Why reports come late, and how to hear about problems on the day they happen.
Short answer: people report late because reporting is a chore they put off, and they only do it once the problem has happened again and again. By then they don’t remember details, and many others have quietly hit the same problem. Make reporting take seconds, at the moment it happens, and watch for early signs before reports arrive.
Why reports arrive late
- The first time, people assume it is a one-off. They try again later.
- Reporting means switching to email. They mean to, and forget.
- They work around it. Until the workaround stops working.
- It takes a third time to annoy them enough. Then the report is angry, and vague.
The cost of late reports
| On the day | Weeks later |
|---|---|
| They remember what they did | “It’s been broken for a while” |
| The screen is in front of them | They can’t find it again |
| One person is affected | Many people have hit it |
| A quick fix and a happy customer | A frustrated customer and a damaged rating |
Hear about it on the day
- 1
Put reporting where problems happen
A feedback option on every page or screen, and especially on error screens.
- 2
Make it a sentence
Capture the context for them, so reporting takes seconds rather than an email.
- 3
Ask after things fail
When a payment, upload or save fails, offer to tell you right there.
- 4
Reply fast
People who get a reply the same day report the next problem straight away.
Early signs before anyone reports
- A spike in errors or failed requests after a release.
- A drop in a key step, such as checkout or sign-up, without a known reason.
- Support questions that start “Is it just me…”.
- The same problem mentioned once in a review, a chat and a feedback report in the same week.
When a late report does arrive
- Thank them. They are telling you what others haven’t.
- Check whether the problem is still happening before asking for details.
- Search for related reports. One late report often has quiet companions.
- Tell them when it’s fixed.
A worked example
A customer writes in November: “Your invoices have been wrong for weeks.” The team searches recent reports for “invoice” and finds two short ones from October that were never followed up: “VAT looks odd” and “total doesn’t match”. All three point to the same rounding change in a September release. Had the first report been read that week, it would have been one fix and one reply, instead of three unhappy customers and a stack of corrected invoices.
Build a habit of reading early reports
- Read every new report within a day, even the vague ones.
- Reply to vague reports with a question rather than parking them.
- Search for related reports before deciding something is a one-off.
- After each release, read reports daily for the first week.
Ask people to report the first time
Tell users it’s fine to report small things. A line in your onboarding or help pages, such as “If something looks off, even once, tell us with the Feedback button”, changes behaviour more than you’d expect. People hold back because they think one glitch isn’t worth your time.
Close the loop with everyone affected
When you fix a problem that went unreported for a while, look for everyone who hit it: the people who reported, and anyone who reported something related. Tell them it’s fixed. Customers who see that you followed up are much more likely to report the next problem straight away.
Questions to ask about your own setup
- How long between a problem starting and your first report about it?
- Do you read vague reports the same day?
- Is reporting possible from the screen where things fail?
- Do you tell users that small problems are worth reporting?
What not to do
- Don’t ask “Is this still happening?” weeks later without checking yourself.
- Don’t blame the customer for reporting late.
- Don’t fix it silently. Tell the people who reported.
How quickly should we read new reports?
Within a day. After a release, daily for the first week.
What if a problem has affected people for weeks?
Fix it, then find everyone affected and tell them. Apologise plainly.
An early warning view
| Watch | Warning sign | Check |
|---|---|---|
| Errors after each release | A rise the day after | What changed in that release |
| Key steps (sign-up, checkout) | A drop with no known reason | Recent reports from that page |
| Vague reports | Two or more about one page in a week | Try the page yourself |
| Support questions | “Is it just me?” | Whether others are affected |
| Reviews | A new theme appearing | In-app reports with the same theme |
Reviewing this weekly takes ten minutes, and it is often the first sign of a problem nobody has reported properly yet.
How Bopmigo helps
People can report from inside your website or app in a sentence, at the moment something goes wrong, with the page, device and screenshot attached. Related reports are grouped, so a problem several people hit shows up as one, early. Bugs that went unnoticed for weeks.