What this template is for
Customer support escalations are the highest-stakes ticket type by revenue impact and the most error-prone by handoff. A dropped escalation can cost a renewal; a botched communication can cost a relationship.
This template solves the two failure modes:
- Required context on the create screen - account, CSM, business impact, what support has tried, what we’ve told the customer. Engineering gets all the context they need without playing telephone with support. Configured on the Jira create screen for the escalation issue type.
- STM-created sub-tasks - acknowledge, triage, update cadence, fix, confirm with customer, document. The ‘update customer within 3 days even if no progress’ sub-task is the one that prevents the worst escalation failure mode: silence.
When to use it
Use this template when a support team can’t resolve an issue and engineering needs to get involved on a specific customer’s behalf. Reserve it for genuine escalations - reproducible issues with business impact - not for product feedback (use feature-request) or general bug reports without an attached account (use bug-report).
Don’t use it as a way for support to file feature requests in disguise. If the customer’s issue is “the product doesn’t do X yet”, that’s a feature request, not an escalation.
Fields to add to your Jira create screen
These are the fields a project admin should make sure exist on the Create Issue screen for this issue type (Project settings → Screens). Without these on the screen, reporters can't provide the information triage needs - and STM can't reference them either.
| Field | Example value | Required |
|---|---|---|
Summary | ACME Corp - data export failing for >10k issue queries since 2026-05-12 | Yes |
Customer Account | ACME Corp (Enterprise, $240k ACV) | Yes |
CSM / AM Owner | @samira.kerr | Yes |
Linked Support Tickets | Zendesk #12345, #12350; first reported 2026-05-12 | Yes |
Business Impact (custom) | Customer's compliance reporting blocked; renewal at risk | Yes |
Urgency (custom) | Renewal blocker / Adoption blocker / Annoyance | Yes |
What's Been Tried (custom) | Steps support has already taken; what didn't work | No |
Customer-Communicated Status (custom) | What we've told the customer; manage expectations | No |
SLA / Contractual Commitment (custom) | If a written SLA applies, link it | No |
Engineering Owner | Assign when triaged | No |
Components | checkout, exports | No |
Note on custom fields. STM currently supports up to 5 custom fields per template. You can add as many custom fields as you like to your Jira Create Issue screen - the 5-field limit only applies if you want STM to set or update those custom fields itself.
Sub-tasks STM creates automatically
Build an STM sub-task template containing the items below, then wire it to an On Create Issue Executor scoped to this issue type. Whenever a new issue of this type is created in the project, STM creates the full sub-task set in one step - with assignee, due date, and components inherited from the parent unless you override them.
- Acknowledge to CSM within 1 business day
- Triage and assign engineering owner
- Update customer via support within 3 business days (even if no progress yet)
- Engineering investigation and fix or workaround
- Confirm fix with the customer through support
- Document the issue and resolution for future support tickets
- Post-mortem if escalation revealed a process gap (rare; only when warranted)
Common questions
When should customer support escalate to engineering in Jira?
When the issue is reproducible and either (a) the support team can't resolve it with existing tools, (b) it's affecting a strategic account, or (c) it's the third report of the same underlying issue. Escalation is expensive on both sides; don't escalate generic how-do-I-use-X questions, but don't sit on real bugs either.
What context should a customer support escalation include?
Account context (who, value), reproduction details, what support has tried, customer-facing status (what have we told them), and business impact. The single most useful field is 'what's been tried' - engineering should never have to ask support 'have you tried turning it off and on again'.
Who owns customer communication during an escalation?
Support owns customer communication throughout. Engineering investigates and resolves but does not communicate directly to the customer unless support explicitly hands that over. This is what 'escalation' means - the work moves; the relationship doesn't.
How do you automate customer-support-escalation sub-tasks in Jira?
Build an STM sub-task template containing the acknowledge / triage / update / communicate / close sub-tasks. Wire it to an Executor that fires On Create Issue scoped to the escalation issue type. Every new escalation gets the same workflow so high-touch customer issues never lose track of who owes the customer their next update.
Automate the sub-tasks with STM
STM Issue Templates saves the sub-task list above as a reusable template and creates them on every new issue of this type - via an Executor on issue creation, on status transition, or triggered manually from the issue's "Create bulk sub-tasks" menu. STM does not change the parent issue's create screen (that's a Jira project-settings job) but it removes the manual work of creating the sub-tasks every time.
Try STM on the Atlassian Marketplace ↗ See how STM templates are built →