Bug Reports From Non-Technical Clients, Without the Back-and-Forth

"It's broken." That's the whole bug report. No page, no browser, no screenshot, just two words in a text message sent on a Friday afternoon. You now have two options: guess, or start a reply chain to extract the details that should have come with the report.

The client isn't being lazy. They genuinely don't know which three details matter. Once you know what to ask for, and where to ask for it, most of that back-and-forth disappears.

The three things that cover almost every bug

• The exact URL - not "the services page," the actual link. Sites often have more than one page that looks similar, and "the one with the form" isn't a locator.
• Browser and device - Safari on an iPhone renders some things differently than Chrome on Android. Without this, you can spend twenty minutes failing to reproduce an issue that only exists on one combination.
• A screenshot or short recording - "it looks weird" means something different to everyone. A picture settles it in one message instead of five.

That's it. Severity, steps to reproduce, expected behaviour, all useful, all optional. Get these three and you can usually diagnose the rest yourself.

Why clients leave these out

Nobody sends an incomplete bug report on purpose. A client reporting a problem is focused on the problem, not on anticipating what a developer needs to fix it. They've also usually never used a bug tracker, so there's no habit of "add a screenshot" built in. The fix isn't a lecture about reporting standards, it's removing the thinking required to do it right, by asking for exactly what you need in the same message every time.

A template that removes the guesswork

Send this once, pin it in your project thread, and reuse it every time a client reports something informally:

• "Can you share the link to the exact page?"
• "What device and browser were you using, e.g. iPhone + Safari, or laptop + Chrome?"
• "A screenshot, or a 10-second screen recording if it's an interaction, would help a lot."

Most clients will happily answer all three once asked directly. The problem was never willingness, it was not knowing what to include.

Where a review tool removes two of the three automatically

When a client clicks directly on a live page to leave a note, the page itself is the context, so there's no "which page" question left to ask. Roundmark pins the comment to that exact spot on that exact page, which solves the location half of the problem before the client even has to think about it. Browser and device are still worth asking for separately, since a pin doesn't tell you what rendered it that way, but you've already closed one of the three gaps for free.

Triage before you open the editor

Not every reported bug needs the same urgency, and treating them all the same wastes a day. Sort reports into three buckets before touching code: broken for everyone (fix now), broken on one browser or device (schedule it, note the combination so you can actually reproduce it), and not actually a bug, a design choice the client disagrees with (that's feedback, not a defect, and belongs in the next revision round, not the bug queue).

That third bucket matters more than it sounds. Mixing "the button is the wrong color" into the same list as "the form doesn't submit" blurs a distinction that keeps your revision rounds and your bug fixes from eating into each other, which is exactly the mix-up that erodes trust in both.

Set expectations on turnaround

Tell clients up front what counts as urgent and what doesn't: a broken checkout form gets same-day attention, a slightly misaligned icon does not. Without that line drawn early, every report arrives with the same implied urgency, and you end up either overreacting to small things or under-responding to real ones.

Put the turnaround expectations in the same place you put the reporting template, so both live together instead of in two different emails sent months apart. A client who knows both what to send and how fast it gets looked at stops escalating by text message out of uncertainty.