Bug Report Templates: Word-Ready Formats for Support and Jira

A bug report template gives customer support and engineering a shared way to describe a problem. It should capture the task, reproduction steps, expected and actual results, impact, and evidence without requiring a customer to diagnose the cause.

Copy the templates below into your helpdesk, issue tracker, or shared document. Use the short version to collect a customer report and the detailed version for a support-to-engineering handoff. Add-on blocks for UI, API, performance, crash, and intermittent issues follow the four formats. For completed reports, see our six filled bug report examples.

Use the bug report template in Word

To use a bug report template in Word, choose the customer, engineering, visual, or regression format below. Use the template toolbar to copy the block or download its Word-compatible .doc version. This is a document version of the visible text, not a macro-enabled file or a claim that an issue-tracker configuration is included.

Open the downloaded document in Word, replace the placeholders, and save it under your team’s normal naming convention. Keep the full expected and actual results; a document with only the title and a screenshot loses the context an engineer needs. If Word displays the text differently, use Copy and paste the same visible template into a blank document.

Before attaching it, check the document for leftover sample fields, private information, and links the recipient cannot open. Keep one report per problem. Link to the filled bug report examples for the level of detail, rather than treating the blank fields as a completed report.

1. Simple bug report template for customers

This version asks for information most customers can provide. Keep account details and evidence in your approved support channel.

Subject: [What you tried to do and what went wrong]
What were you trying to do?
[Describe the task.]
What steps led to the problem?
1. [...]
2. [...]
3. [...]
What did you expect to happen?
[Expected result.]
What actually happened?
[Actual result and any error text.]
Can you repeat the problem?
[Every time / sometimes / only once / not sure.]
Which device and browser are you using?
[Device, operating system, browser; version if known.]
How is this affecting your work?
[Blocked task and any workaround.]
Screenshot or recording:
[Evidence link, with private details removed.]
Relevant timestamp:
[Where the issue appears in the recording.]

Ask for a customer support screen recording when the sequence matters. Tell the customer which steps to capture and remind them to avoid displaying passwords or other sensitive information.

2. Detailed bug report template for engineering

Support can enrich the customer report with environment details, investigation notes, and the original ticket reference. Separate observed facts from hypotheses.

Title: [Action + affected feature + failure]
Original support ticket: [Internal reference]
Reported by / owner: [Team or assigned owner]
Environment:
- Application and release: [...]
- Browser and version: [...]
- Operating system / device: [...]
- Relevant settings or permissions: [...]
Preconditions: [Required account state, configuration, or test data]
Steps to reproduce:
1. [...]
2. [...]
3. [...]
Expected result: [...]
Actual result: [...]
Frequency: [Observed attempts and outcomes]
Scope: [Known affected users or environments; unknowns]
Customer impact: [Blocked task, data impact, workaround]
Severity: [Impact classification using your team's policy]
Priority: [Triage decision, or awaiting triage]
Evidence:
- Screenshot / recording: [...]
- Relevant timestamps: [...]
- Sanitized error, request ID, or logs when relevant: [...]
Investigation notes: [What was checked and what remains untested]
Verification plan: [Steps to repeat after a proposed fix]

For evidence of the report format in use, see the login, UI, performance, API, browser, and validation examples. The examples use fictional test scenarios and should be adapted to your actual product.

A support agent may need to file before detailed investigation is possible. This compact filled report, using fictional data, keeps the same sequence and labels what remains unknown:

Summary: Contact-email change reverts when Profile Settings is reopened.
Context: Example Portal demo build 4.4.0; staging; synthetic member account.
Steps: Open Profile Settings → change contact email → Save Changes → leave and reopen.
Expected: New contact email remains saved under fictional requirement PROFILE-CONTACT-03.
Actual: Old contact email appears; no visible error message.
Frequency: 2 of 3 attempts in the same starting state.
Impact: Contact details cannot be updated reliably for the tested account.
Evidence: Recording, 00:05–00:18.
Unknown: Exact failure cause and scope beyond this test account.

3. Visual bug report template

Visual evidence is useful for intermittent problems, multi-step workflows, and UI issues. The written summary helps an engineer decide what to look for before watching the recording.

Title: [...]
One-sentence summary: [Task and failure]
Recording link: [...]
Recording access: [Who can view it]
Environment: [...]
Steps shown:
1. [...]
2. [...]
3. [...]
Expected result: [...]
Actual result: [...]
Useful timestamps:
- [00:00] Starting state
- [00:00] Action that triggers the issue
- [00:00] Error or unexpected result
Impact / workaround: [...]
Technical evidence, if relevant: [Sanitized details]
Next action and owner: [...]

Screendesk provides screen recording workflows for showing an issue and video support calls for investigating it together. Check recording access before attaching a link to a ticket or issue.

4. Regression bug report template

A regression report needs the current failure and the evidence that the workflow previously worked. If the earlier behavior has not been verified, state that explicitly.

Title: [Previously working task now fails]
Current version / environment: [...]
Last version known to work: [Verified version, or unknown]
How the earlier behavior was verified: [...]
Steps to reproduce in the current version:
1. [...]
2. [...]
3. [...]
Expected result: [Previously verified behavior]
Actual result: [...]
Impact and workaround: [...]
Evidence: [Current recording, earlier evidence if available]
Related change: [Known change, or hypothesis clearly marked]
Verification plan: [Repeat the same task after the fix]

Add-on fields for specific issue types

Keep one stable core and append a small block when the issue type needs it. These original prompts are optional, not a required diagnostic list.

UI or layout issue

Page or component:
Browser viewport / device orientation:
Zoom or text-size setting, if relevant:
Content or input needed to show the issue:
Interaction method: mouse / touch / keyboard / other
Annotated screenshot or short recording:

API or integration issue

API / integration version:
Method and path:
Sanitized test input:
Expected response and documentation reference:
Observed response status and relevant body:
Attempt timestamp / approved correlation reference:
Retry result and side effects, if tested:

Performance issue

Task and dataset size:
Observed duration and how it was measured:
Browser/device and relevant network conditions:
Attempts and comparison conditions:
Whether the interface remains usable:

Crash or mobile issue

Device model / OS / app version and build:
Relevant permissions and network state:
Action before the crash:
Whether the app closed, froze or displayed an error:
Approved crash-report reference, if available:
Data or work lost, if confirmed:

Intermittent issue

Original event: [time, time zone, workflow, evidence]
State immediately before it: [known facts / unknown]
Later attempts: [conditions and result for each]
Differences between working and failing attempts:
Recent changes: [known timing, not an asserted cause]
Information still missing / next evidence request:

For layout issues, viewport and content often matter more than monitor resolution. A failed API response does not show whether a record was created, so check that separately, and omit credentials and session cookies. A crash may need a diagnostic source other than the browser console; our iOS bug reporting guide covers the Apple, third-party app, and TestFlight routes.

For errors that involve loading data, saving or exporting, add a “Network evidence” field: the failing request URL, status code and time, plus a sanitized HAR file. See how to get a HAR file for steps in each browser.

Using a bug report template in Jira or a helpdesk

The template does not depend on a particular issue tracker. In Jira, place the reproduction steps and results in the issue description, add evidence links, and use your existing severity or priority fields. In a helpdesk, collect the short customer version first and link the resulting engineering issue back to the support ticket.

Teams using those systems can review Screendesk’s Jira integration and Zendesk integration to understand the available visual support workflows. Follow your organization’s access rules when sharing recordings between systems.

Whatever the tool, test what a reporter actually sees. In company-managed Jira Cloud spaces, a required field missing from the create screen can block submission. GitHub issue forms in .github/ISSUE_TEMPLATE support structured inputs and validation, and ClickUp, Asana, and Azure Boards have their own task or work-item templates. Check that a new report does not inherit an old status, assignee, or attachment.

For customer-submitted evidence, compare the customer recording workflow with the fields above: request the minimum steps, review the returned video, and link the relevant timestamp in the engineering handoff. A Zendesk recording macro can keep the request tied to the ticket. If you are selecting a tool, use the Screendesk and Birdie.so comparison to check capture requirements and plans.

How to choose the right fields

• Make the core information easy to provide. Require the task, steps, expected and actual results, environment, and impact. Allow “unknown” when a reporter cannot determine a detail.
• Keep technical fields conditional. Request logs, request IDs, or network traces when they help the investigation, rather than making them mandatory for every customer.
• Use severity consistently. Describe observed impact using your team’s definitions. Severity describes impact; priority is the triage decision about when to address it. Do not equate every customer request with a critical incident.
• Record frequency as observed attempts. “Failed on two of four attempts” is evidence; “randomly broken” or an unsupported percentage is not.
• Collect one issue per report. Separate unrelated failures so each has a clear owner and verification outcome.
• Protect sensitive information. Use test data when possible and remove secrets and unrelated personal information from evidence.
• Make verification part of the handoff. Include a repeatable task the team can check after a proposed fix. A code change is not a verified fix, and a fix verified in testing is not automatically available to customers.

Collecting many reports at once? How to run a bug bash includes a one-minute report format for group testing, and the user acceptance testing guide has a test case template that links each failure to a defect.

Before sending the report: a quick checklist

1. Does the title explain the task and failure?
2. Can another person follow the steps from the stated starting point?
3. Are expected and actual results separate?
4. Does the report describe customer impact and any workaround?
5. Can the intended recipient access the evidence?
6. Have private details and secrets been removed?
7. Are assumptions marked as unverified?
8. Is there a clear owner or triage destination?
9. Have you searched for an existing report and linked related work?

Screendesk for support teams helps teams add visual context to customer troubleshooting. Use the template to explain the problem and the recording to show the steps.

Common questions about bug report templates

What is the difference between a bug report template and an example?

A format defines how the information is organized. A template supplies blank fields to fill in. An example shows a completed report so you can see the level of detail needed. Use both when introducing a reporting process to a team.

Should every bug report include a video?

No. A screenshot may be enough for a static visual issue, and a sanitized error response may be more useful for an API problem. Use a recording when it makes the sequence or behavior easier to understand.

What if the reporter cannot reproduce the issue?

Record the original occurrence, time, environment, and evidence, and state that later attempts did not reproduce it. Use the intermittent block rather than forcing invented steps.

Is an issue report the same as a bug report?

A bug report is one kind of issue report. A service incident also needs a timeline, coordinator, next update time, and recovery criteria; a project blocker needs the affected deliverable, the decision required, and an owner. Send security concerns through your designated security-reporting route, not a general form.

Can I use this template in Jira, Zendesk, or a document?

Yes. Copy the relevant fields into your existing workflow and map ownership, status, and priority to the fields your team already uses.