A problem report template captures what went wrong, where and when it happened, who or what is affected, and what the team will do next. It should work before the cause is known and leave room for investigation, corrective action, and verification.
Use the template below for a customer-service issue, operational failure, software problem, or quality concern. Start with the short intake section, then let the responsible team add investigation details. A reporter should not have to invent a root cause or complete every specialist field before an issue can be recorded.
Copy this problem report template
This is an original, general-purpose structure. Adapt its fields to your approved reporting process, audience, and information-handling requirements.
PROBLEM INTAKE Report ID: [assigned by the tracking system] Title: [affected task/process + observed failure] Reported by / contact route: [approved reference] Observed time and location: [include time zone where relevant] Affected service, product, process, or item: [...] Description: [what happened, using observable facts] Expected condition: [requirement or stated expectation] Actual condition: [result and exact error, if any] Sequence or reproduction steps: [actions leading to the observation] Frequency: [known occurrences or attempts; unknown if not established] Impact and scope: [blocked work, affected people/items, known limits] Immediate action / workaround: [what was done and its observed result] Evidence: [restricted references, timestamps, or sanitized attachments] Related reports: [links; relationship not yet confirmed if uncertain] TEAM REVIEW AND INVESTIGATION Category and classification: [team's definitions] Priority: [triage decision and reason] Owner: [person or team responsible for the next action] Current status: [...] Known facts: [verified findings with evidence] Hypotheses / unknowns: [clearly separated from facts] Next action and review point: [task, owner, date or trigger] ACTION AND VERIFICATION Corrective action: [approved change or response] Verification method: [how the outcome will be checked] Verification result: [who checked, when, conditions, evidence] Remaining limitations: [...] Resolution / closure reason: [decision and supporting evidence] Follow-up knowledge or process updates: [owner and reference]
Keep required intake fields short: title, description, time or context, impact, and a contact or evidence route. Make specialist fields conditional. Allow “unknown” or “not applicable” instead of encouraging invented values.
How a problem report differs from a bug report
A bug report focuses on unexpected software behavior and often needs a reproducible sequence. A broader problem report may begin with a delayed shipment, recurring account discrepancy, unreliable device, or process failure that is not yet classified.
In IT service management, a problem record has a more specific purpose. Atlassian’s problem-management guide distinguishes restoring service during an incident from investigating its underlying causes. Your team’s incident, request, bug, and problem records may therefore have separate workflows.
Use general intake to capture the observation, then route it appropriately. Do not label every customer complaint an ITIL problem or require a customer to decide which internal record type is correct. If the issue is confirmed as a software defect, use the more focused bug report templates for the engineering handoff.
Write the core fields clearly
| Field | What to capture | Common error |
|---|---|---|
| Title | Affected task and observed failure | A guessed cause such as “Database broken” |
| Description | What, where, when, and relevant context | A long history that hides the actual observation |
| Expected and actual conditions | The requirement or expectation, then the discrepancy | Assuming an undocumented preference is a confirmed defect |
| Sequence | Events or actions that led to the result | Making an intermittent problem look reliably reproducible |
| Impact and scope | Known affected work and what remains unchecked | Claiming everyone is affected from one report |
| Immediate action | Action taken and result observed | Treating a temporary workaround as permanent resolution |
| Owner and next action | Who will do what, with a review point | Assigning a team name without an actionable handoff |
Copy exact error text where useful, while removing secrets and unrelated personal information. Use references to approved systems for sensitive records instead of duplicating them into a broadly shared document.
Filled problem report example
The following is a fictional operational scenario. It demonstrates a report with an unknown cause, not an actual customer incident or measured result.
Title: Approved equipment request has no dispatch reference after status change
Observed context: Demonstration workflow; test request R-104
Description: Request status changed from Approved to Dispatched.
No dispatch reference is visible in the request.
Expected: Under the demonstration process, a dispatched request includes
a reference that the employee and support team can use.
Actual: Status is Dispatched; dispatch reference is blank.
Sequence:
1. Submit the test equipment request.
2. Have the authorized test approver approve it.
3. Process the request through the demonstration dispatch step.
4. Open its tracking details.
Frequency/scope: One request observed; wider scope unknown.
Impact: Tracking cannot be confirmed from the request page.
Immediate action: Asked the fulfillment team to check the dispatch record.
Evidence: Sanitized screenshots and internal test-record references.
Facts: Visible status and missing reference verified.
Hypotheses: Missing entry, failed synchronization, or display issue;
none is confirmed.
Owner/next action: Fulfillment reviewer checks the source record;
support follows up with the reporter.
Verification: Compare source and request details after the proposed action.
Status: Investigating; closure not yet justified.
The report does not assume that the equipment was never dispatched. It records the missing information and the check needed to establish what happened. If a workaround makes tracking available, record that result while leaving the underlying investigation open where needed.
Adapt the template to the industry and team
Keep a common intake structure, then add only the details needed by the receiving workflow. The variants below are editorial starting points rather than complete regulated forms.
Software development
Add application and build version, browser or runtime, operating system, account role, test inputs, and reproduction steps. For an integration failure, include a sanitized request, response, timestamp, and correlation identifier when available. The reporter may not know internal infrastructure versions; let the investigating team supply those.
Keep expected and actual results separate. Link the original customer ticket, investigation, and fix verification. Avoid requiring console logs from every customer when a task description and screenshot would provide a useful starting point.
Manufacturing and quality
Add product or item references, batch or lot identifiers where applicable, process stage, location, observed condition, and inspection evidence. Record containment or other immediate actions only as actually taken through the authorized process.
Preserve the link between the observed item and its relevant records. A general problem form is not automatically a complete quality or compliance record. Use the organization’s established quality workflow and required forms for that purpose.
Healthcare and patient-safety reporting
Use the organization’s approved event-reporting system and terminology. Relevant fields may include event timing, location, process stage, observed circumstances, and references accessible to the authorized review team. Do not copy a patient’s full history into a generic shared issue template.
The AHRQ PSNet primer on reporting patient-safety events discusses structured review and action plans, along with limitations of voluntary reporting data. A report supports review; a generic template does not establish privacy compliance or replace required reporting and response procedures.
Customer service
Add the customer’s task, an approved account or order reference, the relevant contact history, business impact, and the next communication step. Use a manageable set of categories such as billing, delivery, access, or product behavior, with space for context the category does not capture.
Collect customer demographic information only if it serves a defined need in the approved process. For most troubleshooting, the affected task and account context are more useful than unrelated personal details. Keep the support conversation linked to any specialist investigation.
Use one tracking system and a visible lifecycle
Choose the system that already holds ownership and follow-up: a help desk, issue tracker, controlled form workflow, or appropriately managed spreadsheet. Smartsheet’s issue-tracking collection provides real Excel and Google Sheets examples for software, IT, project, and customer issues.
Map the template to existing fields rather than maintaining conflicting status, owner, or priority values in several places. A useful general lifecycle might be New, Reviewing, Investigating, Action planned, Verifying, and Closed. Define the meaning of each stage locally.
Every open report should have a next action and an owner. For closure, record the reason and evidence: verified correction, linked duplicate, confirmed intended behavior, or another documented decision under the team’s policy. “Closed” should not silently imply that every unresolved condition has disappeared.
Turn reports into useful trends
Review categories, recurring symptoms, affected products or processes, waiting stages, and reopened reports. Link suspected related reports while investigating the relationship; similar wording does not prove a shared cause.
Keep definitions stable when comparing periods. If a category changes, note the change. Report counts also depend on usage, access to reporting, and willingness to submit a report. An increase can reflect better capture rather than a deterioration in the underlying process.
| Measure | What it can show | Interpretation limit |
|---|---|---|
| Time awaiting first review | Whether intake receives attention | Define working or elapsed time consistently |
| Age by status | Where work waits | Separate intentional waits from stalled ownership |
| Resolution time | Duration of the tracked lifecycle | Case complexity and closure policy affect comparison |
| Reopened reports | Possible incomplete verification or a changed condition | A reopened symptom may have another cause |
| First-contact resolution | Which support cases are resolved at initial contact | Use for the relevant support population, not every specialist problem |
Use the findings to select an investigation or process change, then check its outcome. A chart of reported categories alone does not prove that a proposed intervention will prevent a given percentage of future problems.
Introduce the template through a small pilot
- Review recent reports. Identify missing details, confusing fields, and unclear handoffs.
- Include reporters and reviewers. Check what reporters can reasonably know and what the team needs to act.
- Try representative cases. Include a straightforward issue, an uncertain one, and a case needing restricted evidence.
- Observe completion and review. Find fields that invite guesswork or do not affect a decision.
- Adjust the structure. Simplify intake, add conditional fields, and define ownership and status transitions.
- Keep improving it. Revisit the template when the process or recurring information gaps change.
For a visual software problem, Screendesk screen recordings can help show the sequence. Describe what to capture, sanitize the evidence, and keep it connected to the report’s observation and next action. The template supplies a shared record; investigation and verification supply the facts needed to resolve it.
