Client bug reports often arrive as a screenshot, a short message, or a call note. That is enough to know something is wrong, but usually not enough to reproduce it.
Use this template when clients, testers, or non-technical stakeholders need a simple way to report bugs without learning your internal issue tracker.
Client-facing template
Send this version to the person reporting the issue.
What were you trying to do?
What went wrong?
What did you expect to happen?
Where did it happen?
Page URL:
Account, project, or client name:
How can we reproduce it?
1.
2.
3.
What device and browser were you using?
Device:
Browser:
Operating system:
How often does it happen?
Every time / Sometimes / Once / Not sure
How much does it affect your work?
Blocks work / Slows work down / Cosmetic / Not sure
Can you add evidence?
Screenshot:
Recording:
Error message:
Anything else:
Internal cleanup checklist
Before the report reaches engineering, someone on your team should check:
- Is the affected URL or product area clear?
- Are the steps specific enough to reproduce?
- Is expected behavior separate from actual behavior?
- Is the client impact clear enough to decide urgency?
- Is there a screenshot, recording, error message, or browser detail?
- Is this a duplicate of another client report?
- Does the report belong in GitHub, Linear, Jira, Slack, or a client follow-up note?
What to avoid asking clients
Do not ask clients to choose your internal severity scale, assign an owner, understand labels, or decide whether the bug belongs to frontend, backend, QA, or support. Those are your team’s routing decisions.
The client should describe what happened. Your team should turn that into a clean engineering handoff.
Handoff packet
Use this format when you move the report into your team’s tool.
Title:
Client:
Affected URL or product area:
Summary:
Steps to reproduce:
Expected behavior:
Actual behavior:
Evidence:
Browser/device:
Client impact:
Frequency:
Duplicate reports:
Suggested destination:
Client follow-up needed:
How pagemarkr fits
pagemarkr is being built for the space between client feedback and the issue tracker. The first version focuses on structured intake, report cleanup, and copy-ready handoff packets. Native routing and deeper agency/client workflows are later roadmap items, not something this page claims is already finished.
Next step
Use the template above with your next client report, or request early access to pagemarkr if your team spends too much time translating client feedback into reproducible issues.