“It's Broken”: Turning the Bug Report Your Customer Didn't Write Into One Your Developer Can Fix

The email arrives at 8:47 on a Tuesday: "Your system is broken. Nothing works. This is really frustrating." No screenshot, no page name, no hint of what "nothing" covers. And here's the uncomfortable truth every small support team eventually accepts: that email is a completely fair way for a customer to report a problem. Reporting bugs precisely is a professional skill your customers never agreed to learn. They told you something's wrong — that was their whole job. Making it reproducible is yours.

The teams that handle this badly split into two failure modes. The first forwards the raw email to the developer, who reads "nothing works," attempts nothing, and returns "cannot reproduce" — a round trip that costs two days and produces zero information. The second interrogates the customer: six questions, one per email, spread across a week, until the customer — who was already frustrated — stops replying, and the bug survives to bite the next customer. Between the lazy forward and the death-by-interview sits an actual craft: extraction. It has rules, and a two-person team can run all of them.

Know what a reproducible report contains

Before you can extract, you need to know what you're extracting toward. A report a developer can act on has five facts: what the customer was trying to do (the goal, not the feature name), where they were when it failed (page, screen, or the exact link), what they expected to happen, what happened instead — in their words, plus the exact text of any error — and scope: does it happen every time, just today, just on their phone, just for them? Five facts. Not device fingerprints, not console logs, not a form with eleven required fields. When all five are present, most bugs reproduce on the first try; when one is missing, "cannot reproduce" is usually hiding in that gap.

The two-round rule

Here's the discipline that separates extraction from interrogation: you get two rounds of questions, and each round is one message. Bundle everything. The first round does the heavy lifting, and it works best as three asks wrapped in an apology-for-the-inconvenience: "Sorry you hit this — let's get it fixed. Three quick things so I can chase it properly: what were you trying to do when it broke? If you can, a screenshot of what you saw — even a phone photo of the screen is perfect. And does it happen every time, or did it start today?" The screenshot request is the single highest-yield sentence in support — one image routinely answers what, where, and the error text in one attachment, and "a phone photo is perfect" removes the skill barrier for the customers who don't know what a screenshot is.

Round two exists for the one missing fact, if there is one. There is no round three. If two bundled rounds haven't produced reproducibility, the missing information isn't in the customer — it's in your logs, your instrumentation, or your own hands. Escalate to looking, not to asking. Customers forgive a bug; they don't forgive becoming your QA department.

Reproduce before you route

The step small teams skip under pressure is the one that pays best: before anything goes to a developer, support tries to make the bug happen. Same page, same steps, same account type if you can. This does three things. When it reproduces, you now own a recipe — the handoff becomes "do these four steps, it breaks on step four," which a developer can act on in minutes instead of an afternoon. When it doesn't, you've learned the bug is conditional — something about their account, their data, their device — and that is exactly what your round-two question should chase. And either way, the developer's scarce hours get spent fixing, not translating. A support person who reproduces before routing is worth two who forward.

One bug, one record — the dedupe ledger

Vague reports have a second cost nobody sees until it's embarrassing: the same defect arrives five times in five phrasings, gets five tickets, and is investigated three times by two people. The fix is a habit, not a system: every confirmed bug gets one issue record — the recipe, the error text, and the list of every customer who's hit it. New reports that smell similar get checked against the ledger before anyone investigates. The customer list on each record quietly becomes your priority queue — a bug with six names outranks a bug with one, whatever the loudest email says — and when the fix ships, that list is exactly who gets the "this is fixed, thank you for flagging it" note. Closing that loop turns your angriest reporters into your most loyal ones, because you proved a vague complaint into a shipped fix and told them so.

When it truly won't reproduce

Some bugs won't yield — intermittent, environment-specific, gone by morning. The move is an honest holding pattern, not silence: "I couldn't make this happen on my side, which usually means it depends on something specific to your setup. I've logged it with everything you gave me — if it happens again, grab the time it happened and what you'd just clicked, and we'll catch it." That reply does two jobs: it keeps the customer as a willing sensor instead of an exhausted one, and the timestamp request turns their next occurrence into a log-search coordinate. "Couldn't reproduce, watching for it" is a respectable state for a bug. Pretending it's fixed is not.

Where the tool fits

Every practice above runs on plain discipline — but the extraction email gets written forty times a month, and by the fortieth it's getting shorter and blunter. CSByDesign keeps it sharp: it drafts the bundled first-round ask in your voice with the screenshot line included, flags incoming tickets that resemble an existing issue record so the dedupe happens before the second investigation, and keeps the per-bug customer list so the fixed-it note goes to everyone who reported it — not just the last one. The judgment calls — what's reproducible, what routes, what waits — stay with your team. What the tool removes is the fortieth retyping and the five-tickets-one-bug tax.

The bottom line

"Nothing works" is not a bad bug report. It's an unprocessed one — a feeling that contains a defect the way ore contains metal. The refinery is five facts, two bundled rounds, a screenshot ask that respects what customers don't know, reproduction before routing, and one record per bug with names attached. Run it that way and the developer stops dreading your handoffs, the customer stops repeating themselves, and the bugs stop paying rent in three tickets at once. The customer did their job when they hit send. The craft is everything that happens next.

— Tom