Letting the severity scale do the triage
Reporters pick the strongest label they can justify. Ask what the problem stopped them from doing, and keep the team's own severity for the triage step.
Bug report form for people outside your team
A bug report form for people outside your team should capture what they did, what they expected, and what happened, in words a non-engineer can write. Keep the required fields few so that a reporter with a real problem does not give up before the last question. Treat the reporter's severity as a description of their impact, and set priority yourself after you have tried to reproduce the problem.
What people search
Bug report form: 320 average monthly searches.Google Ads Keyword Planner · 2026-10-09 · United States
A filled example
A report a developer can reproduce on the first attempt
Example only, not a real submission
- Summary
- Discount code shows an error on the cart page in iPhone Safari
- Steps
- 1. Add two items to the cart. 2. Open the cart and tap the discount code field. 3. Enter SPRING25 and tap Apply. 4. Wait five seconds.
- Expected
- The 25 percent discount applies and the total changes.
- Actual
- A red message says 'Something went wrong.' The total does not change, and reloading the page does not fix it.
- How often
- Every time with this code. A different code worked yesterday.
- Device and browser
- iPhone 14, iOS 18, Safari
- Contact
- [email protected] (optional)
Field blueprint
Ten fields that give a developer something to reproduce
| Field | Type | Required | Why you ask it |
|---|---|---|---|
Short summaryFor example: Discount code error on the cart page | Short text | Required | Becomes the title of the ticket, so it should name the screen or action where the problem appeared. |
Steps to reproducePlease leave out passwords, card numbers and one-time codes. 1. Open the cart page. 2. Enter a code. 3. Tap Apply. | Long text | Required | Gives the team a path to the same failure. Numbered steps that start from a known page work better than a story. |
What you expected to happen | Long text | Required | Separates a defect from a behavior the reporter did not understand. Both cases need a reply, but they go to different people. |
What actually happened | Long text | Required | The observed result. Copy any error message word for word, because the exact wording helps the team find the code path. |
How often does it happen?Every timeSometimesOnly once | Single choice | Required | Separates a consistent defect from an intermittent one, which is much harder to reproduce. |
Where did you see it?Web pageMobile appDesktop appSomewhere else | Single choice | Required | Points the team to the right product area before anyone opens the full report. |
Browser, device and operating systemFor example: Chrome 130 on Windows 11 | Short text | Required | The same defect often appears on one browser or one operating system version only. |
How much does this get in your way?I cannot finish what I came to doI can finish, but it takes extra effortIt is a small visual problem | Single choice | Required | Describes the effect on the reporter's work. The team still sets priority after reviewing the steps. |
Link to a screenshot or recording (optional)Paste a link to a file you have shared. Uploads are not possible in this form. https:// | Short text | Optional | Adds evidence without an upload field. Keep it optional so that a missing link does not stop a clear report. |
Your email for a follow-up (optional)Leave this blank if you do not need a reply. | Optional | Lets the team ask one question. A reporter who does not want a reply should not have to give contact details. |
Try it
Fill in the form as a reporter would
Mistakes to avoid
Reports that cost a developer time
Asking for internal names
Outside reporters do not know your service or component names. Ask where the problem appeared, in their own words, and let the team map it to a component later.
Making a screenshot required
A required screenshot blocks everyone who cannot share one. Keep the link optional and say in the help text what it helps the team see.
Sending outages through the form
A bug form is reviewed on a schedule, not watched around the clock. Name a separate channel for site-wide failures in the introduction, so a customer who sees an outage does not wait for a review.
After a response arrives
What happens after a report is sent
Stored first, then a scheduled run
Processing runs hourly in production, and only the form's creator is notified once it finishes. Tell reporters that a reply will take time, and promise only a window your team can meet.
Triage from the grid
Each submission appears in the form's grid. Open the steps, check the environment, and decide whether to reproduce the problem, ask a question or close the report.
Move accepted reports by export
You can export the responses as CSV and bring accepted reports into the tracker your engineers already use. Keep the reporter's email out of public tickets and shared channels.
Optional support case for each report
Each submission can also open a Customer Care case, with the priority, tags and assignees set in the form settings. Turn this on when every report needs an owner in the support queue, and leave it off when the team triages from the grid alone.
No automatic reply to the reporter
The form notifies its creator only and does not send the reporter a reply. Decide who writes back, and agree in advance what you will say when a report is reproduced, duplicated or closed.
Working checklist
Before a report goes into the backlog
Reproduce it
- Start from the first step with a clean browser session or a new test account.
- Confirm the behavior on the environment the reporter named.
- Note the earliest version where it appeared, if the reporter knows it.
Check what is already known
- Search the tracker for the exact error text.
- Check whether a recent release changed the screen named in the summary.
Handle the report safely
- Remove passwords, tokens, card numbers and one-time codes before you copy the text anywhere.
- Keep the reporter's email out of public comments and shared channels.
Frequently asked questions
Is there a bug report template I can download?
There is no Word or PDF template in this guide, only the fields, their order and the checks. Attain OS makes forms that people fill in on a web page, so you share a link rather than a document. Export the responses to CSV if you need a file.
What should a bug report from a customer include?
At minimum, include a summary, numbered steps, the expected result, the actual result, the browser or device, and how often the problem happens. Ask for a contact only when the team may need to follow up. Keep technical detail optional, because many customers will not know which component is involved.
Can reporters attach screenshots or log files?
Not through this form, because it has no file upload field. Ask for a link to a file the reporter has shared, or ask them to describe what the screen showed. For logs, ask for only the lines around the error, and ask them to remove anything private before they paste them.
How fast will someone look at a report?
Processing runs on a schedule, so the creator hears about a report only after a run finishes, and a review is never immediate. Publish a response window your team can meet, and send anything that stops customers from using the product to a channel that someone watches continuously.
Browse by category
More reports in Product & Engineering
Requests
Design/UI Request
Surveys
Product Feedback
Checklists
Release Sign-off
Surveys
Sprint Retrospective
Surveys
Third-Party Vendor Evaluation
Applications
User Research Screener
How to build it
Choose a category and a form type in the wizard. Answer three Atty Suggestions questions, then give the form a title. Atty builds the fields in the background. Edit the fields and ask Atty to refine them, then publish and share the /f/ link.
