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:
| Tier | Who handles it | Typical work |
|---|---|---|
| Tier 0 | The customer, through self-service | Help center articles, community answers and AI answers from the documentation |
| Tier 1 | Frontline agents or an AI support agent | Routine questions, account help, basic billing and known issues with documented fixes |
| Tier 2 | Support specialists with deeper product knowledge | Technical troubleshooting, configuration problems and reports that need investigation |
| Tier 3 | Engineers and senior product specialists | Bugs, integration failures and data issues that need work at the code level |
| Tier 4 | External vendors | Problems in a third-party component, such as a payment provider or a cloud service |
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:
- An export fails for one workspace but works for every other.
- A webhook stopped firing after the customer changed plans.
- The mobile app crashes on one Android version after an update.
- Single sign-on fails with a new customer’s identity provider.
- 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:
- The documented fix did not work, or no documented fix exists.
- The report describes broken behavior: an error, a crash, or missing or wrong data.
- The next step needs access tier 1 does not have, such as logs, admin tools or account data.
- The ticket passed your tier 1 time limit. Pick the number from your own data and review it every quarter.
- The impact is high: many customers, a key account, security, data loss or billing errors.
- 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:
| Field | Example |
|---|---|
| The request in the customer’s words | ”Our CSV export has been empty since Monday.” |
| Expected and actual behavior | Expected about 1,200 rows; the file contains only the header row |
| What tier 1 already tried | Ran the export again, cleared the filters, tried another browser |
| Evidence | Screenshot, export ID, browser and app version, console errors |
| Account context | Plan, hosting region, settings changed recently |
| Impact | One workspace; the customer’s monthly report is due on Friday |
| What the customer was told | ”We are looking into it and will update you here.” |
| The question for tier 2 | Why does the export return no rows for this workspace? |
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:
| Finding | Next step |
|---|---|
| The behavior is expected or caused by a setting | Answer the customer, and fix the documentation if it misled them |
| A workaround exists | Send it, and record the underlying problem |
| The customer wants a capability that does not exist | Link or file a feature request and tell the customer where it stands |
| Facts are missing | Ask one focused question, once |
| A defect in the product | Write a bug report for engineering and tell the customer the team is working on it, without promising a date |
| The cause is still unclear | Say so, and bring in engineering with what you ruled out |
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:
| Metric | What it tells you | Watch out for |
|---|---|---|
| Escalation rate | Share of tier 1 tickets that move to tier 2 | A low rate can mean tier 1 holds tickets too long |
| Time to escalate | How long a customer waits before a specialist sees the ticket | Long waits often come from unclear triggers |
| Tier 2 resolution time | Time from escalation to an answer or an engineering handoff | Split it by outcome; bugs take longer than answers |
| Handoffs returned for missing information | Quality of tier 1 handoffs | Fix the template before you blame the people |
| Engineering escalation rate | Share of tier 2 tickets sent to tier 3 | Compare it with how many engineering accepts as bugs |
| Reopen rate | Whether answers and fixes held | Reopens after a fix can mean the fix never reached the customer |
| Satisfaction on escalated tickets | How the escalation felt to the customer | Survey after the final answer, not after the handoff |
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 answers customers from your knowledge sources on every plan. On Pro, Kai Resolve, Gleap’s AI agent for tier 2 support, works the level above it. Gleap’s settings describe it as the second level of support between Kai and your team. In the Gleap widget, four settings decide when it takes over:
- When Kai can’t answer. Kai passes the conversation to Kai Resolve, or first asks the customer whether they want a deeper look.
- Kai Resolve as second level of support. When a conversation would go from Kai to your inbox, Kai Resolve tries first. If it cannot solve it, or the customer asks for a person, the conversation goes to your team.
- Widget button. A button labeled “Talk to our technical analyst” by default replaces the support team button while the setting is on.
- Analyze bug reports first. New bug reports from the widget are held while Kai Resolve investigates, then reach your team with the findings attached.
Kai Resolve makes one attempt per conversation. If it cannot settle the ticket, the conversation goes to your team. Teammates can also assign a ticket to Kai Resolve from the dashboard.
What Kai Resolve 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
- Answerable: Kai Resolve answers the customer.
- Bug: it prepares a coding task and tells the customer the team is taking a deeper look. A teammate decides whether Kai Code starts on it, and your engineers review the pull request.
- Feature request: it subscribes the customer to a matching request, or files a new one when the customer asks for it.
- Needs more info: it asks the customer at most two focused questions.
- 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 Resolve and go to your team. Questions it cannot decide reach a teammate as a card with options. An investigation is not a shipped fix: engineers still review, merge and release, and your team decides what gets built. Kai Resolve is included on Pro and Enterprise, and AI usage is billed separately through prepaid credits; see Gleap pricing.
How to add AI investigation to tier 2
Start where the evidence is richest and widen from there:
- 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.
- Connect the repositories behind your busiest product area. Investigation quality follows the code it can read.
- Read the first verdicts every day for two weeks. Compare them with what your tier 2 specialists would have concluded.
- Then let Kai hand over conversations it cannot answer. Keep the widget button for customers who ask for a specialist.
- 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.
