Tier 2 support: how escalation works and where AI investigation fits

Update, November 3, 2026: Kai’s questions now wait on one card in the ticket, and the ticket shows as unread in the inbox until someone answers. See Kai Support.

Tier 2 support is the second level of a tiered support model. It takes the tickets frontline support cannot close: technical troubleshooting, configuration problems and reports that need investigation. When tier 2 confirms a defect in the product, it hands a bug report to engineering.

IT help desks use the same levels. This guide is about support for software products, where tier 2 is the point where support meets the product. It covers how the tiers divide the work, when a ticket should move up, what a good handoff contains, how to measure tier 2 and where AI investigation fits.

The support tiers at a glance

TechTarget’s overview of customer service tiers, published July 14, 2026, describes five levels. In a software company they usually look like this:

Small teams often merge the levels. The same two people may answer chat in the morning and read logs in the afternoon. The tiers still help, because they describe different kinds of work, each with its own skills, access and pace.

What tier 2 handles in a software product

Typical tier 2 tickets in a SaaS or mobile product look like these illustrative examples:

1. An export fails for one workspace but works for every other.
2. A webhook stopped firing after the customer changed plans.
3. The mobile app crashes on one Android version after an update.
4. Single sign-on fails with a new customer’s identity provider.
5. A report shows numbers that do not match the customer’s own data.

Tier 2’s job is to find out what is actually happening and choose the outcome. That can be an answer, a workaround, a configuration change, a question back to the customer, a feature request or a bug report for engineering.

When to escalate from tier 1 to tier 2

Escalation works when the triggers are written down. TechTarget’s overview recommends explicit triggers such as time limits, complexity thresholds and customer impact, so agents do not have to guess when a ticket should move up. For a software product, six triggers cover most cases:

1. The documented fix did not work, or no documented fix exists.
2. The report describes broken behavior: an error, a crash, or missing or wrong data.
3. The next step needs access tier 1 does not have, such as logs, admin tools or account data.
4. The ticket passed your tier 1 time limit. Pick the number from your own data and review it every quarter.
5. The impact is high: many customers, a key account, security, data loss or billing errors.
6. The customer asks for a specialist, especially more than once.

Two habits keep escalation healthy. Escalate with findings: say what you checked and what you think is happening. And escalate the question, not the whole ticket: if a message holds three requests and tier 1 can settle two, settle them before handing over the third.

What a good tier 2 handoff contains

Customers notice bad handoffs. In Zendesk’s CX Trends 2026 research, published November 18, 2025 and based on more than 11,000 respondents in 22 countries, 74% of consumers said they are frustrated when they have to repeat information, and 81% want agents to continue the conversation without backtracking. A handoff should let tier 2 continue the diagnosis, not restart it.

Here is what a complete handoff contains, with an illustrative example:

What tier 2 does with an escalated ticket

A tier 2 specialist confirms the facts, checks known issues and similar tickets, checks the account’s configuration and traces the problem through logs and, where they have access, the code. Then they choose one of six outcomes:

While the work happens, keep the customer informed: acknowledge once, avoid promising timelines and write again when the state changes.

Handing a bug to engineering

An escalation to tier 3 is a bug report an engineer can start from without asking support a question. It names the expected and actual behavior, the steps, the environment, the evidence, the suspected area and the impact, and it links the customer conversation so engineering can see who is waiting. The same brief works whether an engineer or an AI coding agent such as Kai Code picks it up.

Metrics for tier 2 support

Measure the escalation path, not only the tickets tier 2 closes:

Set targets from your own baseline. Published benchmarks rarely match your product, your channels or your customers.

Tiers or swarming

Not every team uses tiers. The Consortium for Service Innovation’s Intelligent Swarming page, accessed September 26, 2026, describes a model that removes support tiers and brings together the people with the right expertise when an issue needs them. Tiers are simpler to staff and measure. Swarming cuts handoffs on hard issues. Many software teams mix the two: tier 1 answers routine questions, and hard technical tickets go to a shared channel where support and engineering work them together.

Where AI investigation fits

An AI support agent that answers from your help center covers tier 0 and tier 1 work. Tier 2 is a different job. It needs investigation: reading the code, the logs and the account, not only the documentation.

How Gleap splits tier 1 and tier 2

In Gleap, Kai Support answers customers from your knowledge sources on every plan. On Growth, Pro and Enterprise, Kai Support also works tier 2: it investigates the hard tickets on the boards you choose. A conversation is handed over in four cases:

1. The customer asks for an expert or a person.
2. Kai Support can’t answer.
3. It is a bug report. With the built-in skill “Investigate bugs”, Kai Support investigates new bug reports from the widget, and they reach your team with its findings attached.
4. A teammate or a workflow moves it.

The ticket lands on a board. On the boards where your team turned on Kai investigates here, Kai Support investigates it, then answers the customer or hands over with a diagnosis. Boards without Kai go to their people with what Kai found so far.

What Kai Support reads and returns

It reads the ticket and the conversation, plus what the Gleap SDK captured: the logs, the click trail, the screenshot, the recording and the device details. It reads the code in GitHub repositories you connect and can query data sources you connect through MCP. The investigation runs in a sandbox and does not push code or open pull requests.

It returns a verdict with a confidence level: answerable, bug (confirmed or suspected), feature request, needs more info or inconclusive. The verdict cites the evidence it used, such as the files it read, with line numbers when it has them, and adds an explanation for your team and a proposed reply to the customer.

What happens after the verdict

1. Answerable: Kai Support answers the customer.
2. Bug: it turns a confirmed bug into a coding task for Kai Code and tells the customer the team is taking a deeper look. Kai Code opens a pull request your engineers review and merge.
3. Feature request: it subscribes the customer to a matching request, or files a new one when the customer asks for it.
4. Needs more info: it asks the customer at most two focused questions.
5. Inconclusive: it tells the customer where things stand and asks a teammate for help, with what it checked.

Destructive actions, such as deleting, merging or archiving records, refunds and cancellations, are blocked for Kai Support and go to your team. When it needs an OK, a choice or an answer, it asks the people of the board on one card in the ticket, which shows as unread until someone answers; the first answer wins and Kai carries on. An investigation is not a shipped fix: engineers still review, merge and release, and your team decides what gets built. Investigations are on Growth, Pro and Enterprise. A ticket Kai investigates costs more than one it answers, and Kai stops at $1 each time it works on a ticket; see pricing.

How to add AI investigation to tier 2

Start where the evidence is richest and widen from there:

1. Start with bug reports from the widget. In-app bug reports carry the screenshot, the logs and the environment, so the first verdicts have the most to work with.
2. Connect the repositories behind your busiest product area. Investigation quality follows the code it can read.
3. Read the first verdicts every day for two weeks. Compare them with what your tier 2 specialists would have concluded.
4. Then turn on Kai investigates here for the boards that take the hard conversations. Conversations Kai Support cannot answer, and customers who ask for an expert, then get an investigation first.
5. Track the metrics above before and after. Time to escalate, tier 2 resolution time and the share of engineering escalations accepted as bugs show whether the change helps.