Customer bug reports: a system for small teams

Customer bug reports have a habit of disappearing. Somebody emails to say the checkout page hangs on their phone, you thank them and promise to look into it, and three weeks later they write again because nothing has changed. Most of the advice written about this assumes you have a product manager to persuade and an engineering roadmap to argue with. If you run a small business where the person answering the inbox is also the person who files the bug, and some days the person who fixes it, you need a shorter system. Here is one that fits on an index card.

Why customer bug reports go missing

Almost always for the same three reasons, and none of them are laziness.

• The report lands somewhere that is not a list. An email thread, a chat window, a text message to your personal phone. You read it, you reply, and your brain marks the thread as handled. The bug itself now lives nowhere.
• Nobody owns it. In a two or three person business everybody assumes somebody else wrote it down. Usually nobody did.
• There is no status to report back. So you go quiet, because the only honest update is "I still do not know," and that feels worse than saying nothing. It is not worse. Silence is the thing customers remember.

Worth holding in your head while you triage: the people who bother to write in are a fraction of the people who hit the problem. Reporting a bug takes effort and most people would rather close the tab. If two customers tell you about something, assume more of them met it and said nothing.

First work out whether it is really a bug

Plenty of what arrives labelled as a bug turns out to be something else, and each of the three needs a different answer.

• A real defect. The product is meant to do one thing and does another. Log it.
• A misunderstanding. The product works as designed and the customer expected something different. That is a gap in your documentation, so write the help article that explains it and answer the person with that.
• A feature request in disguise. "It will not let me export to CSV" can mean the export is broken or that you never built one. Those go on a different list entirely.

The quickest test is to write one sentence saying what should have happened and one saying what did happen. If you cannot write the first sentence, you do not have a defect yet. You have a customer with an expectation you never set.

What to collect before you log it

The whole point of a good report is that whoever picks it up next week can reproduce the problem without going back to the customer. Six things get you most of the way.

1. What the person was trying to do, in their own words.
2. What actually happened, including the exact error text if there was one.
3. What they expected instead.
4. When it happened, and whether it happens every time.
5. Device, browser or app version, and roughly where they are.
6. Their account, order or invoice number, so you can find the record later.

A ten second screen recording is worth more than all six written out, and most people will happily send one if you ask. Mozilla has kept a public guide to writing these for decades and the same rules hold for a shop as for a browser: Mozilla's bug writing guidelines are worth ten minutes if you want the long version.

A bug report template you can paste

Keep it boring and keep it identical every time. Steal this one:

Title: short, specific, describes the problem and not your guess at the cause. "Checkout hangs after applying a promo code on iOS Safari" beats "Checkout broken."
Steps: 1, 2, 3, numbered, from a logged out state where possible.
Expected: one sentence.
Actual: one sentence, plus the error text.
Environment: device, OS, browser or app version.
Customers affected: names or ticket numbers, updated as more arrive.
Severity: broken, wrong or annoying.

That last line about customers affected is the one small teams leave out, and it is the field that later decides what gets fixed first.

A severity scale you can actually use

Big companies run P0 through P4. A three person business that adopts a five level scale ends up with everything marked P2 and no decision made. Use three.

• Broken. Money cannot change hands, or somebody cannot get into their account, or data is being lost. You look at this today, whatever else was on the calendar.
• Wrong. It runs, but it produces the wrong number, sends the wrong email or shows the wrong thing. Fix inside the week. These are the quiet ones that damage trust, because the customer may not notice until it has cost them something.
• Annoying. Cosmetic, rare, or there is an easy way around it. Fix next time you are already working in that part of the product.

Then weigh it by how many people are hitting it. One customer locked out of checkout beats a dozen people looking at a button that sits four pixels too low. If a bug keeps climbing the count, it earns a promotion, and your escalation process should say who has the authority to grant one.

What to tell the customer while it is open

Three short messages cover almost every case. None of them require you to know when it will be fixed.

The acknowledgement. Send it the same day, within whatever response time you promised.

Thanks for the detail, that was enough for me to reproduce it on my end. It is written up now with your name on it so I can come back to you when it ships. I do not have a date yet and I would rather not invent one.

The workaround. Only if it genuinely costs less effort than the bug. A workaround with nine steps is worse than the problem.

Until this is sorted, the promo code will apply if you enter it on the cart page instead of at checkout. Clumsy, but it works today.

The fix. The one nearly everyone skips.

That checkout problem you found in August went out this morning. Thanks for taking the time to write it up properly, it saved us a lot of guessing.

Two minutes of your day. It turns somebody who was halfway out the door into the person who tells you about the next one. Never promise a ship date you do not control, and never say "soon" if you mean "possibly never."

Where customer bug reports should live

One list, in a place you will genuinely open on a Friday afternoon. For a two person business a shared spreadsheet is fine, with a column for title, severity, date, status and a link back to the ticket. A project board works. So does your issue tracker if you already have one.

The rule that matters more than the tool: the bug has to stay joined to the customer who reported it. The moment those two live in separate systems, you lose the ability to close the loop, and closing the loop is the only part of this the customer ever sees.

That link is why we built bug tracking into SupportifyGPT itself rather than leaving it to a separate tool. A ticket becomes a tracked bug without leaving the inbox, it keeps the customer attached to it, and the developer API can push the same report into GitHub, Jira or Linear through a webhook so whoever writes the code stays where they already work. It sits on every feature on every plan, including the $15 Starter one, because a small business has exactly the same problem as a big one and less time to solve it. You can try the whole thing on a free 14-day trial.

Publish a known issues page when one bug floods the inbox

Every so often a single defect brings in twenty messages in an afternoon. Answering each one by hand is a waste of a day you probably do not have, and the twentieth reply is always shorter and colder than the first.

The cheaper move is a short public page listing what is broken, what the workaround is, and when you last updated it. Then your reply to each new report is two lines and a link. People are far more patient with a problem somebody has clearly admitted to in writing than with one that appears to be a secret.

Keep it honest and keep it current. A known issues page that still lists something you fixed in March does more damage than not having one. Three fields per entry is plenty: what is wrong, what to do instead, and the date you last touched it. If your help centre lives on your own domain, this page belongs there next to your other articles, so the same search that finds your how-to guides finds the outage too.

Take the entry down the day the fix ships, and go back to everyone who reported it.

Ten minutes on a Friday keeps the list honest

Put a recurring block in the calendar and do four things with it.

• Read every open bug top to bottom. Anything that has collected new reports moves up.
• Close what shipped this week.
• Email the customers attached to anything you just closed.
• Delete or park anything nobody has mentioned in three months. A list you do not trust is the same as no list.

That is the whole system. A test for whether something is really a defect, six facts, three severity levels, three messages and one weekly pass. It will not stop bugs arriving. It will stop the same customer emailing you twice about one you already forgot, which is the part that actually costs you the relationship.