Tier 1 vs tier 2 vs tier 3 support for SaaS teams

Tier 1 is the first person a customer reaches, the generalist who answers the common questions. Tier 2 takes what needs deeper product knowledge or a look inside the customer’s account. Tier 3 is the engineers who build the product, for bugs and anything the product can’t do yet. Level 1, level 2 and level 3 support are the same tiers under another name.

A question starts at the lowest tier that might answer it and moves up only when that tier can’t. Each move up is an escalation, and the share the first tier solves without one is its first level resolution rate.

If you answer support yourself, you’re tiers 1, 2 and 3 at once, and a how-to question lands in the middle of a bug fix. Deacon is an AI customer support agent that takes the first line off you. It answers your customers from your own docs in seconds, passes you the questions that need you, and shows you what customers keep asking about. It has a free plan.

What each support tier handles

Zendesk’s guide to customer support tiers, 5 support tier levels explained, last updated on 18 June 2026 and read on 23 September 2026, counts five. It says the standard is tier 0 to tier 3, and that only some industries add tier 4. Most pages that rank for these words describe an IT help desk, where tier 1 resets passwords and fixes printers. This is what each tier takes in a software company.

Zendesk’s own descriptions add detail. It puts chatbots in tier 0, beside FAQ pages, because no person is involved. Its tier 1 handles account setup and account questions, and points customers to knowledge base articles. At Zendesk, tier 2 handles customising add-ons and “anything that requires a deeper understanding of our underlying technology”, and passes a ticket to tier 3 when it can’t solve it or hasn’t met the issue before. Tier 3 vets every issue that has to go to the software development team, tests the fixes, and works tickets that “have no time limit for resolution”. Its tier 4 example is Microsoft contacting IBM when a customer’s problem with a Microsoft product comes down to an IBM chip inside it.

Customer self-service covers tier 0 in depth, and ticketing system covers the tickets the other tiers pass between them. HDI’s definitions of the levels, its survey of where tickets end up and MetricNet’s cost per ticket at each level are in first level resolution.

How escalation moves a question up the tiers

Each tier either solves a question or passes it up with what it has learned. This is one question’s way up at a company that sells invoicing software.

1. Tier 0. A customer’s CSV import fails. They search the docs for “import” and find the page on file formats, which doesn’t mention their error.
2. Tier 1. They write in. An agent asks for the file and the exact error, “Row 1,204: invalid date”, checks the file against the documented limits and finds nothing wrong. They pass it up with the file, the error, the customer’s plan and what they checked.
3. Tier 2. A specialist runs the import on a copy of the customer’s account and finds every date written day first, such as 23/09/2026, which the importer reads month first. That’s a bug, so it goes up with the steps to reproduce it.
4. Tier 3. An engineer fixes the date parsing and ships the fix two days later.
5. Back down. Whoever owns the ticket tells the customer it’s fixed and asks them to try again.

Step 2 worked because the details went up with the question. An escalation should carry six things.

• The customer’s own words, not a summary of them.
• Who they are, their plan and anything else about their account that bears on it.
• What happened, what they expected, and any error word for word.
• The steps to reproduce it, if it looks like a bug.
• What the lower tier tried or ruled out, and which articles it sent.
• What the customer has been told, including when they’ll hear back.

Without them, the question bounces. The Consortium for Service Innovation, a nonprofit alliance of companies that develops the KCS and Intelligent Swarming methods, describes cases bouncing when “the case needs more information to proceed, or is assigned to the incorrect team”, which it calls “time-consuming and very frustrating for the customer”. It also points out that tiers create queues. Any issue level 1 can’t solve waits in one, “turning a real-time activity into a backlog item”. Ticket backlog covers how to measure that queue.

Tiers, levels and first-line, second-line and third-line support

Tier 1, level 1, L1 and first-line support all name the people who take a question first. Zendesk’s guide says levels 1, 2 and 3 “are different ways of saying tier 1, 2, and 3 support”.

The lines come from ITIL, the framework many IT service desks follow. Its 2011 glossary defines first-line support as “the first level in a hierarchy of support groups involved in the resolution of incidents”, and the second and third lines the same way. It differs from the tier guides in three places.

• A line can sit higher for more than skill. ITIL says each level “contains more specialist skills, or has more time or other resources”, so a second line can be people much like the first, freed from the queue to dig.
• The second and third lines also investigate problems, which ITIL defines as “a cause of one or more incidents”. The first line gets the customer working again, and the lines above find out why it broke.
• The glossary stops at the third line. It has no line for self-service, and an outside firm is “a third party responsible for supplying goods or services”, a supplier rather than a fourth line.

When tiers stop paying off

The Consortium for Service Innovation argues that many teams would do better without tiers. It says the tiered model “is an efficient way of working if the majority (95% or more) of issues are simple and known, and resolved during the customer’s first contact”. In the past, it says, each tier worked as a filter, “with each level resolving 70 to 80 percent of the problems it received”. Self-service changes that. Known issues, the ones your docs already answer, get solved before anyone writes in, so more of what reaches a person is new and needs digging into.

Its alternative, Intelligent Swarming, has no tiers. Teams that are good at self-service, it says, are “collapsing their tiers and creating a single team of people who collaborate”, instead of tossing issues between teams, which it calls playing ping pong. “The person who takes ownership of the issue owns the issue until it is resolved”, and brings in others when they need help.

What the tiers become when you’re every tier

A founder answering support alone already works the swarming way. You own every question until it’s solved, and nothing is lost between tiers, because there’s nobody to hand it to. What you lose is focus. The how-to question and the database fix land on the same person, often in the same hour.

So the five tiers collapse to one line that matters, between the questions your docs can answer and the ones that need you.

Some questions should always reach you, whatever answers first. They’re the ones about one customer’s account, invoice or data, the bugs, and anything that needs your decision, such as a refund, a custom deal or a date for a feature. Everything else is a question your docs either answer or should.

Deacon as your first line

Zendesk’s scheme puts chatbots in tier 0, but Deacon does the first line’s job. It takes each question asked in the chat on your site, answers what your docs cover in seconds, at any hour and in the visitor’s language, and passes the rest up to you rather than guessing.

• When your docs don’t cover the question, Deacon says so in its own words, and the widget offers a box for the visitor’s email.
• When the question is about the visitor’s own account, invoice or data, it always declines, whatever your docs say. Those need someone who can open the account.
• When a question is too vague to answer, it asks one question back. After three, it stops asking and hands over, summing up in one sentence what the visitor told it. That sentence is the note a tier 1 agent writes on an escalation.

A decline doesn’t end the chat, and Deacon keeps answering the visitor’s other questions until you reply. When a visitor leaves their address, the conversation shows as unread in your dashboard. When they leave it or ask for a person, the owners on your team get an email three minutes later, unless one of you has opened the conversation since or has the dashboard open. A visitor who walks away from a decline without leaving an address emails nobody, though the conversation is still there when you look.

You take it over the way tier 2 takes a ticket, without the ticket. Reply inside the conversation and Deacon stops answering in it. A visitor who still has the chat open sees your reply there under your first name and your company’s, such as “Maya from Acme”, and one who has left gets it by email, if they gave an address in that conversation. Your replies and their messages to you don’t count towards your plan’s answers. When you’re done, send it back down a tier. Press Hand back to Deacon, and Deacon answers again and tells the visitor so.

Then move the answer down for good. Every question your docs didn’t cover waits in Conversations with an Answer this button. Write the answer once and it becomes part of what Deacon knows, so it can answer the next person who asks without reaching you. Support teams call this shifting left, and the more you answer, the less Deacon needs you.

The questions customers ask also show you what they need. Topics group similar questions, count the people who asked and label most groups, for example as a how-to, a bug report or a feature ask. A how-to group is a gap in your tier 0, and a bug report group is tier 3 work, with a count of the people who asked about it.

Deacon has no tickets, no routing between teammates and no helpdesk integration, so there are no tiers inside it to route between. Anyone on your team can reply in any conversation, on every plan. Human handoff walks through one question from the decline to your reply, and the free plan needs no card and has no end date.