---
Title: "How to escalate a customer-reported outage to engineering: a six-step incident escalation process"
Url: "https://devrev.ai/blog/how-route-customer-reported-outage-engineering"
Published: "2026-10-22"
Last Updated: "2026-10-22"
Author: "DevRev Editorial"
Excerpt: "The fix takes as long as it takes. This guide shows support how to hand engineering a linked record, not a message, so the outage does not worsen at handoff."
Reading Time: 17
---

# How to escalate a customer-reported outage to engineering: a six-step incident escalation process

**TL;DR**

- A customer-reported outage gets worse at the handoff, before anyone opens a log. A good incident escalation process protects the customer context first.
- Support sends one escalation packet with eight fields. It’s complete when nobody has to ask the customer twice.
- Link every customer ticket to the incident and to the engineering work. Leave the cause open until someone proves it.
- Named people own severity, fixes, and promises. Customers get approved wording and the time of the next update.

At 9:12 AM, a customer’s admin writes in to say dashboards won’t load for their whole team. The agent pastes the email into an engineering channel with “urgent!” and a link, then hears nothing back. Twenty minutes later, an engineer asks which account it was, what the error said, and when it started, and the admin has gone into a meeting. The fix hasn’t started, and the handoff has already cost 20 minutes.

## Which escalation setup fits your team?

Pick the row that matches the report in front of you and where support, engineering, and on-call already work. The first three rows cover teams whose support runs its incident escalation process in Computer, by DevRev, our AI teammate that links customer tickets to engineering issues.

| What’s in front of you | How to route it | Know before the next outage |
| --- | --- | --- |
| Several customers report the same symptom, and support works in Computer | Run the six steps below, and link every ticket to one engineering issue | Who may change severity, and what the automatic stage-change notice tells customers |
| Engineering stays in Jira | Keep Jira as the system of record, and sync it to Computer with Jira AirSync | How often the sync runs (hourly by default) |
| Your on-call rotation runs in PagerDuty | Sync incidents between Computer and PagerDuty with our PagerDuty snap-in | It’s in limited availability, so ask us first |
| Support runs on Zendesk and engineering on Jira | Link the reports to one Zendesk problem ticket, then link that to the Jira issue | What a Jira issue created from a ticket carries over (step 4) |
| Everything runs in Jira Service Management | Link the incident to the software work item that follows | Where the cause gets recorded (step 4) |
| Monitoring paged someone before any customer wrote in | Follow the alert-led path, and link customer tickets as they arrive | Whether support can see the open incident |
| One customer has one stuck ticket | Escalate it through your normal support tiers | The service-level agreement (SLA) timer, not the on-call rotation |

When monitoring got there first, our [blueprint for agentic incident response](https://devrev.ai/blog/agentic-incident-response) covers that path. A stuck ticket is different. It climbs tiers to a specialist or a manager, as our guide to [ticket escalation](https://devrev.ai/blog/ticket-escalation) explains, while an outage skips that ladder and goes to whoever is on call.

## What you need in place before the first report

You need four things in place before the next outage:

- A severity scale people have read. Define each level by customer impact, and get every team to agree to it. Atlassian, the company behind Jira, recommends the same in its incident management handbook: impact-based levels that every team has agreed to.
- A named on-call owner for each product area. That’s a person or a rotation, never a channel.
- One place where incidents live, with one record per incident that support can see.
- A status page or an agreed channel for customer updates, with a first-update template approved in advance.

If one is missing, fix it first. The steps below assume someone can answer “who owns this?” in one lookup.

## A six-step incident escalation process for customer-reported outages

In these six steps, support captures the outage, checks for a live incident, and routes it to a named owner. The team then links every ticket to the incident and the engineering work, leaves severity and promises to named people, and sends customers only approved updates.

This is desk research: we wrote these steps from other vendors’ incident guides and help centers and from our own help center, product, and customer pages, each rechecked on October 16, 2026. What Computer does in your workspace depends on your plan, setup, and policies.

### Step 1: Capture the outage while the customer is still on the line

“Capture” means writing down what engineers will ask for while the customer is still there. You get one cheap chance. Every later question costs a round trip to someone who’s already annoyed.

What to do:

- Fill in the escalation packet on the first report.
- Ask for the exact error text, the time they first saw it, and their timezone.
- Copy identifiers character for character, and note what you’ve told the customer and when you’ll come back.

| Field | Why engineering needs it | Who fills it in | What goes wrong without it |
| --- | --- | --- | --- |
| Affected account and reporter | Shows which tenant, plan, and region to look at | Support agent, from the ticket | “Which customer?” in Slack, asked twice |
| Symptom, in the customer’s words | Lets them search logs for the real error | Support agent, quoting | Engineers debug your summary |
| First seen, with timezone, and whether it’s still happening | Narrows the search and lines it up with recent changes | Support agent, asking the customer | A three-hour search where 10 minutes would do |
| Environment: product area, region, workspace ID, app version, and integration | Decides which team gets called | Support agent, from the account record | The wrong team wakes up |
| Evidence: error text, request ID, screenshot, and URL | Points to the failing request | Customer, prompted by support | “Can’t reproduce” |
| Severity signals: other accounts reporting, customer tier, and contractual SLA | Gives the incident owner facts to set severity with | Support lead | Severity set by whoever shouts loudest |
| What you’ve told the customer, and when the next update is due | Stops two people promising two different things | Support agent | Contradicting updates |
| Existing incident ID, if any | Attaches this report to work already under way | Support agent, after step 2 | A parallel incident |

Here are the same eight fields as plain text, for a form or a macro:

1. Affected account and reporter.
2. Symptom (customer wording, not a summary).
3. First seen (time and timezone), and is it still happening.
4. Environment (product area, region, workspace ID, app version, and integration).
5. Evidence (exact error text, request ID, screenshot, and URL).
6. Severity signals (other accounts reporting, customer tier, and contractual SLA).
7. What you’ve told the customer, and when the next update is due.
8. Existing incident ID, if any.

Atlassian’s handbook asks whoever files an incident to describe the impact on customers, which is what fields 1 and 6 record.

On Hacker News, a technology discussion forum, one commenter described engineering teams that used to accept almost any customer escalation. Then the volume hit them like a distributed denial-of-service (DDoS) attack, which floods a system with more requests than it can handle:

“We’re being ‘DDoSed’ by poorly explained tickets filed at much too high of a priority.” [Hacker News, November 2025](https://news.ycombinator.com/item?id=46089603)

Those teams’ fix was a form that support fills in, saying what’s wrong, why it needs escalating, and which senior person vouches for the form’s accuracy. The commenter admits the hoops are “slow and annoying,” and support staff get frustrated when they know developers would want to hear about a problem. A short packet is the compromise.

Make the evidence and first-seen fields required on your outage ticket type. A field nobody has to fill in is a field nobody fills in at 9:40 AM.

In Computer, a ticket [already carries severity, product part, customer workspace, and reporter](https://support.devrev.ai/en-US/devrev/article/WX96DY0b-tickets), and admins can [add custom fields and mark them “required.”](https://support.devrev.ai/en-US/devrev/article/2it-yKhx-object-customization) Zendesk, the customer service software company, lets an admin mark a custom ticket field “Required to submit a request” on the customer’s form. Jira Service Management, Atlassian’s service desk product, sets it per request type, with a Required checkbox on each field.

### Step 2: Check for a live incident before you open a new one

Before you escalate, look for an open incident with the same symptom. A second incident for the same outage splits the responders, and each group knows half the story.

Search open incidents by product area and symptom, and scan the last hour of tickets for the same error text. If an incident exists, link your ticket to it and add your packet as evidence. If none exists, you’re the first reporter, so go to step 3.

Every report you attach to one incident is a data point on scope. Atlassian’s handbook says its support teams tag each customer case with the incident’s issue key, so the count stays right and nobody is forgotten at resolution. PagerDuty, the incident management company, gives the customer liaison in its incident response guide a standing job: telling the incident commander how many customers report being affected.

Never merge tickets from different customers. Merging is for one customer who wrote in three times. Linking is for 40 customers with one outage.

Computer draws the same line. Merging needs tickets with the same customer workspace (or none) and the same reporters (or none), and opening a ticket shows a short list of similar ones.

For different customers, our docs run the join through the engineering issue. Our [guide to links and dependencies](https://support.devrev.ai/en-US/devrev/article/Uq5H-3GO-links-and-dependency-management) says, “When a customer reports a problem, link the support ticket to the engineering issue tracking the fix,” so that “engineers see how many customers are affected.”

ActionIQ, a customer data platform company that helps enterprises with complex data problems, works this way. [Our ActionIQ customer story](https://devrev.ai/customers/actioniq) says its support agents “now see which engineering incidents affect customer tickets.” In the same story, we publish a “67% reduction in median incident resolution times” for ActionIQ after it adopted DevRev. The story doesn’t give a baseline or a time period.

Is an incident already open somewhere else? If your on-call team works in PagerDuty, our PagerDuty snap-in can keep incidents in sync between Computer and PagerDuty. As of October 2026, its [help article](https://support.devrev.ai/en-US/devrev/article/cRJBvgPG-pagerduty) lists it in limited availability, so talk to us before you plan around it.

Zendesk links each report to one problem ticket. Jira Service Management shows a “Similar incidents” panel, matched on title.

### Step 3: Route it to the owner who can act, with the packet attached

Hand the incident to one named person who owns the product area right now. Posting in a channel and hoping isn’t routing.

Look up the on-call owner for the affected area. Open the incident, or page through your on-call tool, with the packet attached. Put the ask and the request ID in the first line, not the fifth message. Then stay reachable, because you’re the customer’s voice in the room now.

Here’s a first line support could post in the incident or the page:

“Four accounts can’t export since 9:20 AM UTC. Packet attached. Need an owner and a severity.”

Context leaks at four handoffs, and the steps close each one.

| Handoff | What gets lost | What prevents it |
| --- | --- | --- |
| Customer to support | Exact error, timestamp, environment | The packet, filled in on first contact (step 1) |
| Support to engineering | Which accounts, their tier, what you’ve told them | The packet travels as a linked record, not as a chat summary (steps 3 and 4) |
| Engineering to support | What’s confirmed, what’s safe to say, whether it’s fixed for everyone | One incident record with an approved status (steps 5 and 6) |
| Support to customers | Affected customers who never heard back | The linked-ticket list drives the resolution message (step 6) |

Support doesn’t need permission to raise the alarm. PagerDuty’s incident response guide says so outright: “if our Support team starts to receive requests that indicate a system issue, they need to have the power to trigger our response.” What support does need is a target, and that’s the engineer on call, not the engineer you like.

In Computer, you can open an incident from Slack with a command or a message action. [The Slack snap-in can also create a channel for each incident and invite its owner](https://support.devrev.ai/en-US/devrev/article/nDruC5fJ-slack-snapin).

[This DevRev video](https://www.youtube.com/watch?v=2Elnl2admaM) shows how to create issues and incidents from Slack.

Whatever pages your owner, check who it reaches and when. PagerDuty’s escalation policies, for example, notify one target at a time until someone acknowledges the incident.

### Step 4: Link the tickets, the incident, and the engineering work

Linking joins three records: each customer ticket, the incident, and the work that follows.

Link every affected ticket as it arrives, and link engineering’s work when it opens. That work can be an issue, a Jira ticket, a configuration change, or a case with a vendor. Name the incident by its symptom (“exports failing in the EU”), and leave the guessed cause out.

| What differs | Routine bug report | Customer-reported outage |
| --- | --- | --- |
| Scope | One customer, one workflow | Several accounts, or a whole capability |
| Urgency | Planned into a sprint | Restore service now, find the cause after |
| Owner | The product team’s backlog owner | A named on-call owner |
| What gets linked | One ticket to one engineering issue | Many tickets to one incident, then to whatever work follows |
| Cause | Assumed to be a defect | Unknown until proven. Configuration, a third party, or the customer’s side can all cause it |
| Who talks to the customer | The ticket owner, when the fix ships | One liaison, on a schedule, with approved wording |
| How it closes | The fix ships | Service is back and every linked customer has heard |

Links keep the engineer out of the help desk, because the customer, severity, and stage sit beside the work.

Our Chief Technology Officer, Ahmed Bashir, makes the wider case in his introduction to our paper on team collaboration:

“The idea at the heart of this paper is that collaboration should live where work lives. Not in a separate stream, but woven into the very entities teams care about: tickets, accounts, incidents, and code.” – [Ahmed Bashir, Chief Technology Officer at DevRev](https://devrev.ai/blog/the-collaborative-computer)

Don’t turn the first ticket into a bug and call it linked. Some outages end in a code fix, and others in an expired certificate, a vendor’s rate limit, or a customer’s own firewall change. A bug record for a non-bug can sit in a backlog with nobody to close it, while the customers attached to it wait. Jira Service Management avoids this by keeping the cause in a separate problem record.

In Computer, the engineering issue is the hub, so treat it as the record of the investigation. Link Records on a ticket attaches related tickets and issues. Our [workflow action library](https://support.devrev.ai/en-US/devrev/article/I5gcoCnY-workflow-action-library) adds an action that “creates a link between an incident and an issue,” so you get two documented links with the issue in the middle.

If engineering works in Jira, [Jira AirSync lets Jira stay the system of record](https://support.devrev.ai/en-US/devrev/article/tdhvD7Q0-jira-software-airsync). You import a project and turn on periodic sync, and by default Jira issues then sync with issues in Computer once an hour. The docs describe the result as “allowing you to search Jira issues and link them to customer tickets without leaving DevRev.”

Inside Jira, the [DevRev for Jira app](https://support.devrev.ai/en-US/devrev/article/a3yD4RZ2-devrev-for-jira-app) shows the linked tickets beside the issue, with the customer, part, severity, and stage. The app needs Jira AirSync to work.

Uniphore, an enterprise AI platform company, uses the Jira half of this setup. [Our Uniphore customer story](https://devrev.ai/customers/uniphore) says “support can create an issue within DevRev and it automatically gets updated on Jira.”

Zendesk’s Jira integration links up to 200 tickets to one Jira issue. Its “Copy fields from this ticket” button copies only the subject and the most recent comment. Jira Service Management links an incident to a software work item with an “is caused by” link.

### Step 5: Keep named people in charge of severity, mitigation, and promises

Three calls stay with named people: how severe this is, what to change to mitigate it, and what to promise customers. Tools, Computer included, can gather the evidence for each call, but a person makes it.

Name one incident owner, who confirms severity from the packet’s signals and can raise or lower it. Engineers propose mitigations, and the owner decides. One support liaison drafts customer updates for the owner to approve. Put all three names in the incident before anyone needs them.

In our view, severity is a business decision dressed as a technical one. It weighs contracts, customer tier, and what you’ll risk breaking to fix something else. Google’s [Site Reliability Engineering book](https://sre.google/sre-book/managing-incidents/) says to declare an incident when any of three conditions is true, and one of them is “Is the outage visible to customers?” When you can’t choose between two levels, PagerDuty’s guide says to pick the higher one.

Daniel Rojo, our Head of Global Customer Outcomes, has spent “the better part of twenty years inside support,” in his own words. In his post on why complex support tickets still stall, he describes the same rule in teams that use AI on hard tickets:

“The teams doing this well are not trying to remove their agents. They draft, they suggest, they assemble – and a person still approves what goes out.” – [Daniel Rojo, Head of Global Customer Outcomes at DevRev](https://devrev.ai/blog/why-complex-support-tickets-still-stall)

The riskiest message is the helpful one. An engineer spots a possible cause and mentions it to a support agent in a direct message, and the agent passes it on to the customer. Now an unapproved root cause is in writing, in a customer’s inbox.

In Computer, severity is a ticket field with four values: low, medium, high, and blocker. Incidents carry their own severity, which the PagerDuty snap-in can sync with PagerDuty’s priority, so write down who may change each. The Incident AI agent in our Slack snap-in “can assist with incident triage, summarization, and recommended actions,” and assist is the verb we chose.

What about actions an AI agent takes by itself? Our [Agent Studio page](https://devrev.ai/agent-studio) puts it plainly: “If the stakes are high, require human approval before your agent takes action.” That approval is a setting you turn on for each skill. The [Agent Studio reference](https://support.devrev.ai/en-US/devrev/article/kIjLyjeT-agent-studio-reference) lists “Needs Approval” as off by default. Switched on, it makes the agent confirm before that skill runs.

Support can also request sign-off inside a ticket with the [Ticket approval workflow](https://support.devrev.ai/en-US/devrev/article/1QEA8_8Z-ticket-approval-workflow), a Marketplace snap-in you install separately.

On its paid plans, PagerDuty ships two default incident roles: Incident Commander and Customer Liaison. Each goes to one responder. In Jira Service Management, on Premium and Enterprise plans, a person marks an incident as major with a toggle.

### Step 6: Send only approved status, then close the loop with every linked customer

Customers get one message at a time, and the incident owner approves each one. Everyone linked to the incident hears when it’s over, because the linked-ticket list from step 4 is your distribution list.

Send a first acknowledgment once the owner confirms the incident. State the impact, leave the cause out, and give the time of the next update. Keep that time even when there’s nothing new.

At resolution, confirm with the owner and message every linked ticket. Then use the post-incident review to note which packet fields were missing, and fix the form.

| Risky | Safer | Why the first one bites |
| --- | --- | --- |
| “We expect a fix within 30 minutes.” | “Engineers are working on it. Next update by 10:30 AM UTC.” | You can keep a promise about an update. You can’t keep one about a fix you haven’t found |
| “A database failure caused this.” | “We’re investigating failed exports. We’ll share the cause once it’s confirmed.” | A first theory can be wrong, and this one is now in writing |
| “Our cloud provider is having problems.” | “Some customers can’t load dashboards. We’re working to restore access.” | It may not be them, and the customer bought the service from you |
| “Only a few customers are affected.” | “If your exports are failing, you’re affected. Here’s a workaround.” | You haven’t measured scope yet, and “few” insults the one reading |
| “It’s fixed!” (relayed from chat) | “Exports have been working again since 10:52 AM UTC. We’re monitoring.” | One engineer’s optimism isn’t a confirmed recovery |

PagerDuty’s incident response guide is direct with customer liaisons: “Don’t estimate resolution times.” Statuspage, Atlassian’s status page product, describes an incident post as one that tells readers when to expect a fix. We side with PagerDuty.

On timing, Atlassian’s incident communication guide recommends never going more than an hour without an update while customers are affected.

On Reddit’s _r/sre_, a forum for site reliability engineers, one commenter wants to tell customers before they notice, and shares the holding line their team uses:

“Yes, this is broken, but scale/scope and cause are under investigation.”

[r/sre, April 2025](https://www.reddit.com/r/sre/comments/1jqjpgr/do_you_alert_users_when_you_know_something_is/mlfxosm/)

It names no cause and no fix time. Add when your next update is due, and you have a holding line.

Don’t close the incident and forget the tickets. The customers who reported first got the earliest holding reply, and without a closing message, it’s also the last thing they heard.

Computer sends one message on its own. New workspaces get the [Convergence snap-in](https://support.devrev.ai/en-US/devrev/article/qR1VuAs7-convergence) by default, and with it, a ticket’s stage moves when its linked issue changes state. A stage change then [sends the customer an email notification](https://support.devrev.ai/en-US/devrev/article/bdTvezeR-customer-email-notifications), so agree in advance when engineering closes the issue. That way, the notification and the approved message say the same thing.

Every other update carries words a person writes, and our docs give you four ways to send them:

- **To tell every ticket owner:** from Jira, the DevRev for Jira app has a “Broadcast to ticket” button. It sends one comment to every ticket linked to the issue.
- **To tell customers in Slack:** the [Slack Broadcaster snap-in](https://support.devrev.ai/en-US/devrev/article/aE1x22U7-slack-broadcaster) posts to the customer channels you’ve linked to accounts. Only people in groups you authorize can post.
- **To tell one customer:** a reply on a ticket [emails that customer](https://support.devrev.ai/en-US/devrev/article/bdTvezeR-customer-email-notifications).
- **To tell many parties at once:** our Tickets article describes a ticket used to broadcast “service status updates.”

Whoever sends them, our own [support best practices](https://support.devrev.ai/en-US/devrev/article/K_Q8Upm_-customer-support-best-practices) say to “agree on messaging before responding to the customer.” Agree once, with the incident owner, and every channel carries the same words.

Zendesk closes the loop from the other end. Solving the problem ticket solves every linked incident ticket and adds the closing comment to each one that isn’t already solved. Statuspage reaches subscribers who opted in, which is a different list from the customers who reported, so you’ll want both.

Have your team’s current holding line ready for a demo. We’ll show you one approved update reaching every linked ticket, and the email each customer gets when the engineering issue closes. [Book a demo →](https://devrev.ai/demo)

## What to measure after your next outage

Count three things after your next outage, then count them again after the one that follows. We don’t know of a published benchmark, so these become your baseline:

- Questions engineering asked that the packet should have answered.
- Minutes from the first report to a named owner acknowledging it. Averaged over incidents, that’s your mean time to acknowledge (MTTA).
- Linked customers who got a resolution message, out of all linked customers.

When the first count falls and every linked customer gets a resolution message, your handoff no longer costs the 20 minutes it cost that 9:12 AM report.

Bring those three counts to a demo, and we’ll map your packet’s eight fields onto ticket fields in Computer, starting with the ones engineering kept asking about. [Book a demo →](https://devrev.ai/demo)

## FAQ

### What is an incident escalation process?

An incident escalation process is the agreed path a suspected outage takes, from the person who first hears about it to the people who can fix it. It sets who captures the report, who owns the incident, who decides severity, and who approves what customers hear.

### When should support escalate a ticket as an incident?

Escalate as an incident when the same symptom arrives from more than one account, or when one customer loses a whole capability. One stuck ticket follows your normal support tiers instead. If you can’t tell which it is, raise it anyway. A false alarm costs minutes, and a missed outage costs customers.

### Who should declare incident severity?

A named incident owner should, and you should name that person before the outage. The reporter can suggest a level, and the owner confirms or changes it as facts arrive. Support’s job is the evidence: how many accounts are affected, their tier, and what their contracts promise. When in doubt between two levels, pick the higher one.

### How do you avoid duplicate incident tickets?

Make one person, usually the support liaison, responsible for matching new reports to open incidents while an outage runs. Everyone else checks with them before opening anything. If two incidents slip through for one symptom, keep one, link the other’s tickets to it, and close the duplicate with a pointer, so every report counts toward one scope.

### Should support give customers an ETA during an outage?

Not unless the incident owner approves one. An estimated time of arrival (ETA) for the fix is a promise about work nobody has finished, and a missed one costs more trust than the outage. Promise the time of the next update instead, and keep it, even when the update is “nothing new yet.”