Write a Jira ticket from this customer issue and internal investigation: [CUSTOMER REPORT]. Use this account and user context: [CUSTOMER CONTEXT]. Here is the observed behavior, evidence, logs, screenshots, or timestamps: [EVIDENCE]. Here is the expected behavior and relevant product rule: [EXPECTED BEHAVIOR]. These are the known scope, severity signals, workaround, and dependencies: [TRIAGE CONTEXT]. Do not guess at root cause, affected users, revenue impact, browser versions, or reproduction steps that are not supported by the inputs. Preserve exact error text and timestamps when provided, but remove unnecessary personal data. Treat customer statements as reports, not confirmed facts. Return a ready-to-paste ticket in this structure: 1. Title: specific, searchable, and framed as observed behavior plus affected area. 2. Customer impact: 2-4 sentences describing who is blocked, what they were trying to do, frequency if known, and whether a workaround exists. 3. Environment and account context: only confirmed details. 4. Steps to reproduce: numbered, deterministic steps; explicitly mark any incomplete step as "needs confirmation." 5. Actual result and expected result. 6. Evidence: bullets with links, timestamps, request IDs, error messages, or attachments supplied. 7. Acceptance criteria: 3-6 testable Given/When/Then statements covering the primary case, a relevant edge case, and regression protection. 8. Triage notes: suspected component only if evidence supports it, dependencies, proposed owner or team if given, and unanswered questions. Add a separate customer-facing next-step note of no more than 60 words that acknowledges the issue without promising a fix date. Before answering, check that acceptance criteria are testable and that the ticket distinguishes confirmed facts from assumptions. Ask up to 3 clarifying questions only if a required input is missing.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [CUSTOMER REPORT] | Paste the customer's description of the issue and any support conversation summary. | Northstar Dental says office managers receive an error when exporting the September appointment report |
| [CUSTOMER CONTEXT] | Provide the account type, user role, plan, and relevant workflow without unnecessary personal data. | Business plan; office-manager role; three clinic locations; export used for month-end billing |
| [EVIDENCE] | Paste confirmed observations such as timestamps, error text, logs, screenshots, request IDs, or recordings. | Sept 23, 10:14 ET: "Export failed. Try again." Request ID r_8f21; support reproduced with a report over 10,000 rows |
| [EXPECTED BEHAVIOR] | Describe the intended product behavior or policy that should apply. | Office managers can export appointment reports they are authorized to view as CSV |
| [TRIAGE CONTEXT] | State known scope, severity, workaround, dependencies, and prior investigation findings. | Potentially affects large reports only; workaround is filtering by clinic and exporting separately; no confirmed root cause |
How to use
- Paste the customer report and attach or summarize only evidence your team can verify.
- Read the reproduction steps line by line; mark gaps as needing confirmation instead of allowing the model to fill them in.
- Confirm the acceptance criteria can be executed by QA without interpreting intent.
- Follow up with: "Create a separate engineering investigation sub-task that tests the row-count threshold and captures query timing."
Variations
Bug Report
You need a technical bug ticket from a reproducible issue.
Turn this issue into a concise Jira bug: [ISSUE DETAILS]. The confirmed environment is [ENVIRONMENT], and the reproduction evidence is [REPRODUCTION AND EVIDENCE]. Expected behavior is [EXPECTED RESULT]. Return Title, Description, Steps to Reproduce, Actual Result, Expected Result, Evidence, Scope, and 3-5 Given/When/Then acceptance criteria. Do not infer a root cause or add a version, browser, or device not supplied. Mark unknown fields clearly. Check that each reproduction step is executable and each criterion is testable. Ask up to 3 questions only if a required input is missing.
Support Escalation
You need to hand an unresolved support case to product or engineering.
Create a Jira escalation ticket for this support case: [CASE SUMMARY]. The customer impact and urgency are [IMPACT]. Support has already tried [TROUBLESHOOTING]. Evidence is [EVIDENCE], and the requested decision or investigation is [ASK]. Return a ticket with a neutral title, customer impact, timeline, troubleshooting completed, evidence, questions for the receiving team, and customer-safe next steps. Separate facts from customer claims and do not promise a resolution date. Check that no sensitive customer data is copied unnecessarily. Ask up to 3 questions only if needed.
Feature Request
You need to document a customer request without presenting it as a committed feature.
Write a Jira feature request based on [CUSTOMER NEED]. The requesting users are [USER CONTEXT], their current workflow is [CURRENT WORKFLOW], and the business impact is [IMPACT EVIDENCE]. Existing alternatives or workarounds are [ALTERNATIVES]. Return Title, Problem Statement, Jobs To Be Done, Current Workflow, Desired Outcome, Evidence, Non-Goals, Open Questions, and 3-5 testable acceptance criteria for a possible solution. Do not design a solution beyond the supplied requirements or claim demand is broad without evidence. Ask up to 3 questions only if required.
Tips
- Use the exact point of failure in the title, such as "CSV export fails for reports over 10,000 rows," instead of a title like "Export issue."
- Keep customer impact separate from technical diagnosis; the first helps prioritize while the second may change during investigation.
- Acceptance criteria should describe observable behavior, including permissions and boundary conditions where relevant, rather than implementation choices.
- Remove names, email addresses, tokens, and raw personal data from ticket bodies unless your organization's process specifically requires them.
FAQ
Should a Jira ticket include a suspected root cause?
Only label it as a hypothesis and link it to evidence. A ticket should remain useful if that hypothesis is later disproved.
What makes acceptance criteria good?
A tester should be able to determine pass or fail without asking the author what was meant. Given/When/Then wording helps expose ambiguity.
Can I paste customer messages directly into Jira?
Paste only what your data-handling rules allow. Summarize personal details and retain the original in the approved support system when needed.