Tier 1 support answers the tickets whose answer is already written down. Tier 2 takes the ones that need an account opened up, a log read, a permission changed. Tier 3 is whoever can alter the product its self, which on most desks means the engineers. That is the whole ladder, and it is a good deal less complicated than the org charts make it look.
The part worth your time is not the definition though. It is that the line between tier 1 and tier 2 is not a line of skill, whatever the job titles say about it, and once you can see what the line really is made of you can go and move it, which is a thing almost nobody tries, on account of the ladder turning up in most companies already built and nobody thinking to ask who built it or why they went with three.
What tier 1, tier 2 and tier 3 support actually mean
Tier 1 is the first person who reads the ticket. They answer anything that has an answer already sitting somewhere findable, they take the details, and they pass on what they cannot finish. Tier 2 gets the ones needing something looked into, an account examined, an integration checked, a refund approved by somebody with the authority to approve it. Tier 3 is the smallest group and the dearest, and their work changes the product rather than the ticket, which is a different job entirely even when it starts from the same email, and the two get measured differently, and staffed differently, and confused with one another constantly all the same.
You will see the same thing written L1, L2 and L3, and some desks add a tier 0 for the help articles and the search box that answer a customer before any person is involved at all. The vocabulary came out of IT service management, out of ITIL and the ITSM world, and it went and spread into customer support desks that have no infrastructure whatsoever to speak of. That is mostly fine, truth be told. It does mean a great many teams inherit a three rung ladder without once asking whether three is the right number for the shape of it they have actually got, and for a good few of them it is not, and nobody notices for years.
Here is the bit that matters more than the naming. A tier is not a rank. It is a description of what a ticket needs before it can be closed, and the person is only attached to it on account of somebody having to do the work. Get that the wrong way round and you end up with tiers as a career ladder, where moving to tier 2 is a promotion and going back is a demotion, and after a year or so of that nobody at tier 1 will admit to not knowing something, which is the exact opposite of what you built the thing for.
Why the tier line is a documentation line and not a skill line
Watch what actually happens when a ticket gets escalated and you will nearly always find one of two reasons underneath it, and neither one of them is that tier 1 was not clever enough.
The first is that the answer exists perfectly well but it is not written anywhere tier 1 can go and find it, seeing as it is sitting in somebody’s head, or in a thread from March that nobody thought to archive, or in a system nobody ever got around to giving them a login for. The second is access. Tier 1 knew the answer perfectly well and could not click the button, on account of the permission sitting with tier 2, and so a ticket that needed nine seconds of work went and took two days and three people instead. That one stings when you count it up, because it looks for all the world like a skill problem right up until the moment you ask the person what they would have done if they had the access, and they tell you, and they are right.
So the tier line is drawn by two things you control. What is written down, and who is allowed to do what. Both of those are yours to change on a Tuesday afternoon, unlike the skill of your team, which takes months and hiring and a fair bit of luck. Write an article and a category of ticket moves down a tier permanently. Widen a permission, carefully, with an audit trail behind it, whether that permission lives in your SSO directory or in Active Directory or in the product’s own roles, and another whole category of ticket moves down along with it. Nobody had to get better at anything and the escalation queue got shorter all the same.
The mistake is to treat the line as fixed and staff up around it. You hire another tier 2 person on account of tier 2 being swamped, the escalations keep coming at the same rate because nothing about why they escalate has altered, and now you have got a bigger tier 2 and the very same ratio. Six months of that and tier 2 has quietly become most of the desk, doing a pile of work that was meant to belong a rung further down.
What belongs at each tier, ticket by ticket
Most guides on this subject stop at the definitions and leave you to work the rest out. Fair is fair, here is the actual sorting, written the way it turns up in a real inbox rather than the way it looks in a diagram. Copy it, argue with it, change the rows that do not match your product, that is what it is for.
| What actually arrives | Owns it | Why it sits there | Move it up when |
|---|---|---|---|
| Password reset, account locked out | Tier 1 | Documented, and the action is a form | The lock returns within an hour, or the account is shared |
| “How do I export my data” | Tier 1 | One article, one link, one CSV | The export runs and returns nothing |
| Invoice copy, VAT number, billing address | Tier 1 | Read-only lookup in the billing system | Money is being asked back |
| Refund or credit request | Tier 2 | Needs a judgement and an approval tier 1 has not got | Above your own approval ceiling, then it is a manager, not a tier |
| “It is broken for me and nobody else” | Tier 1 for 15 minutes | Half of these are cache, browser or permissions, all documented | Tier 1 has reproduced it and it is still wrong |
| Same fault from 3 customers in an hour | Tier 2 directly, skip tier 1 | It stopped being a ticket and became an incident | Confirmed by tier 2, then tier 3 and the incident process |
| Report totals look wrong | Tier 2 | Wants the data and the logs read, not the screen | The source data is wrong rather than the view |
| Integration stopped syncing | Tier 2 | Credentials, OAuth scopes and API rate limits are all checkable | The failure is on our side of the API |
| “Can you add X” | Tier 1 logs it, nobody escalates it | It is not a fault, and escalating it teaches the customer the wrong thing | Never. It goes on a list, not up a ladder |
| Suspected breach, or phishing using your domain | Skip every tier, page the on-call | Minutes matter more than routing does | Immediately, and every single time |
| Angry customer, no technical fault at all | Tier 1 keeps it, a manager joins | Sending this to engineering fixes nothing whatsoever | Sideways to whoever owns the account, not upward |
Three rows in there do the most work and they are the ones that break the ladder on purpose. A feature request has no tier above tier 1, seeing as there is nothing up there that can close it any faster, and a security report has no tier at all. The row about the same fault arriving from three customers in an hour is doing much the same thing, mind you, on account of it having stopped being a ticket somewhere around the third one and turned into an incident, which wants a different process rather than a higher rung. If your routing rules cannot express “this one skips the queue entirely” then they are not finished yet.
How a ticket ought to travel when it moves up
The handoff is the place most of the cost of tiering goes and hides, and it hides well enough, seeing as any single one of them looks far too small to be worth stopping over.
A ticket goes up with nothing attached to it. Tier 2 opens it, sees a customer complaint and no working, and asks the customer the same four questions they already answered on Monday. The customer answers them again, more shortly this time, and their sense of how this is going drops through the floor. Nothing in your reporting catches that. First response was quick, the ticket is moving, all the numbers look grand, and the only person who knows the truth of it is the customer, who has now explained their own problem twice to a company that appears not to have been listening.
What ought to travel with the ticket is four things and the whole lot of them take about 90 seconds to write down properly. What was tried. What that ruled out. What the customer has already been told. And what they were promised, in what words, by when. If you run an SLA clock over any of this, note that the clock does not stop obligingly just because the ticket changed hands, which catches people out. That last one gets left off constantly and it is the one with teeth, on account of tier 2 having no way to know that somebody said “I will have this back to you today” unless somebody wrote it down.
Then there is the other half of it, which is telling the customer that the ticket moved at all. Not the internal mechanics, they neither know nor care what a tier is, just that it is with the people who can fix it now and roughly when they will hear next. A handoff the customer cannot see feels exactly the same to them as a handoff that never happened, and we have written more about how that ought to read in the piece on escalation.
Why a low escalation rate is not the good news it looks like
Somebody puts escalation rate on the dashboard, it comes down over a quarter, and everybody takes a bow. Mind you, that same picture gets produced by two things with nothing whatsoever in common.
The good version is that tier 1 genuinely absorbed more, on account of articles getting written and permissions getting widened and the line shifting down to where you wanted it all along, which is the whole of it working as intended. The bad version is that tier 1 is holding on to tickets it cannot finish. Nobody decides to do that, it just happens, especially where escalating has been quietly treated as an admission that you did not know. So the ticket sits at tier 1 for two days getting sympathetic updates and no progress, and the escalation rate looks beautiful, and the resolution time is a disgrace.
That is why the number is close to meaningless on its own, and it wants a companion. Measure how long a ticket sits at tier 1 before it goes up, and look at the spread rather than the average, because the average will be dragged down by all the ones that went up in four minutes. A desk in decent health escalates a small share of tickets and escalates them quickly. A desk in trouble escalates a small share slowly. The headline number comes out the very same either way, which is most of the trouble with it.
You will notice we have not told you what a good escalation rate is. That is deliberate, and it is not us being coy. We do not publish figures we cannot stand over, and any number floating about for this is an average of desks selling things you do not sell, staffed differently, counting escalations by rules of their own. Your own last quarter is the only honest benchmark on offer here. So measure that one and work from it.
The debt tier 2 runs up and almost never pays
Here is the thing that quietly decides whether your ladder works in two years.
Tier 2’s output is not the fix. The fix was always going to happen, that is what they are there for. Their real output is the write-up, the four paragraphs that mean the next one of these never reaches them at all. Skip it and you have not simply saved yourself twenty minutes, you have gone and created a permanent tier 2 ticket type, one that will arrive again next month and the month after and every month until somebody writes it down or the product changes underneath it.
Do that a hundred times over a year and tier 2 is no longer a tier. It is a queue, with its own backlog and its own waiting time, and tier 1 has learned that escalating is faster than thinking, which from where they are sitting is perfectly true. The ladder inverted its self quietly while everybody was busy, and no meeting was ever held about it, and there is no line on any dashboard anywhere that would have shown you the start of it happening.
The rule that fixes this is unglamorous and it works. A tier 2 ticket is not closed until either the article exists or somebody has decided on purpose that it should not, and that second option is a real option, plenty of one-off tickets deserve nothing written. What is not allowed is the decision never getting made. Whether that write-up lives in a proper knowledge base or a shared document nobody has tidied since spring matters far less than whether tier 1 can find it at half nine on a Monday with sixty unread mails in front of them.
A Thursday on a six person desk, costed out
Take a desk of six. Four on tier 1, two on tier 2, no tier 3 of its own because engineering is engineering and they have their own week. Say two hundred and forty tickets land in the week. These numbers are invented for the sake of the arithmetic, they are not a benchmark of any description whatsoever, and nobody should go and quote them at anybody, ourselves very much included.
Tier 1 closes 168 of them and sends 72 up. That is the whole of what most desks know about their own escalations, and it is the point at which the counting normally stops, mind you, which is a pity, seeing as the next twenty minutes of it is the useful part of it. So go and read the 72, one by one, and put each into three piles. Answer existed but was not written down. Tier 1 knew the answer and lacked the access. Genuinely needed tier 2.
Say it comes out at 18 in the first pile, 20 in the second, 34 in the third. Which means 38 of your 72 escalations, better than half of them, had nothing at all to do with what your tier 1 people know. Eighteen articles is a fortnight of somebody’s afternoons. The 20 access cases will collapse into two or three permission changes, on account of the same button being the culprit over and over. Do both and the escalation queue goes to 34 and stays there, and it did not cost you a hire.
Now the version nobody enjoys. You did not read the 72. You hired a third tier 2 person instead, at whatever a good technical support hire costs where you are, and next quarter you have got 72 escalations again spread over three people rather than two. The individual workload improved. The desk did not. And the eighteen articles are still not written, and truth be told they are less likely to be written now, seeing as tier 2 has a bit more room and the pressure that would have forced the issue has gone.
Where we come into this, and it is less than the org chart suggests
Straight out with it, since this is the part where a piece like this usually oversells. Maxdesk has no tier object. There is no field called tier, no skill-based routing, nothing you configure by drawing three boxes. If you want tiers here you build them out of tags, rules and people, the same as you would build them out of labels and habits and a bit of shouting across a room in a plain mailbox, and fair is fair, that is a thing worth knowing before you sign up to anything.
What is here is the plumbing underneath. Every mail lands in one shared inbox so a handoff is a reassignment rather than a forward into somebody’s personal mail, which is the single biggest reason handoffs lose their history. Automation rules tag and assign on arrival, so the rows in that table above that ought to sort them selves, mostly do sort them selves. And on Elite, at $99 a month per workspace, the AI support agent sets a priority from the issue, files it into a category and assigns it by each person’s live open-ticket count.
Read that last bit carefully, because it is a workload balance and not a skill match. It spreads work by who is least buried, not by who knows the most about billing, and on a tiered desk those two answers are frequently different people. Better you hear that from us now than work it out your own self somewhere in week three.
One thing does land squarely in your favour on this subject. We charge per workspace rather than per agent, and there is no cap whatsoever on how many humans you put on the desk, the free plan very much included. Tiering is precisely the shape of team that per-seat pricing punishes hardest, seeing as your tier 3 people log in twice a month, contribute the two hardest fixes of the quarter and cost a full seat all the same. Here they cost nothing extra. Add the whole of engineering as agents if it helps, it does not change the bill.
What tiers will not do for you, said plainly
They do not reduce your ticket volume. Not by one. Tiering sorts the work, it does not shrink it, and any improvement you get comes from the sorting being cheaper than the alternative, which on a small desk it very often is not. Under about five people the ladder usually costs more in handoffs than it saves in specialisation, and two people quietly deciding between them who takes the hard ones beats a formal structure most weeks, and does it without a single rule having to be written down or maintained by anybody afterwards.
There is a whole serious argument going about doing away with the ladder altogether and putting three people on the hard thing at once instead of passing it upward. It has more to it than we can do justice to in a paragraph here, so it is getting its own piece rather than a dismissive line in this one.
The rest of the honest list, since you may as well have all of it now. Email is the only channel Maxdesk ships, so if your tier 1 is meant to be a live chat queue we are not the thing you want. The free plan carries our ads and our branding on outgoing mail and keeps three months of history, which matters more than it sounds on a tiered desk, on account of tier 3 wanting to look at something from last year fairly often. Twelve months on Pro at $20, twenty-four on Elite. All of the plan figures here are as of 26 August 2026 and we re-check them at the turn of the year. Active automations are capped on free as well, and routing rules are exactly the thing you will want more of.
And no software of ours or anyone else’s will settle the permissions argument for you. That one is a conversation between support and whoever owns security, it is usually the real blocker of the lot, and it is nearly always worth the awkwardness of having it.
Where to start, if the ladder is not built yet
Two jobs, both of which fit in a week, neither of which needs anybody’s approval to begin.
Pull last month’s escalations and sort them into the three piles from further up. Not a sample, all of them, however tedious that gets, seeing as the whole value is in the true proportion. Most desks find their first pile is far bigger than anybody guessed and the finding is uncomfortable and useful in about equal measure.
Then time them. From arrival at tier 1 to arrival at tier 2, ticket by ticket, and look at the slowest ten rather than the average. If those ten sat for days, your escalation rate is lying to you and you now know in what direction.
Do that much and the table further up stops being somebody else’s opinion and turns into your own routing rules, with your own products and your own awkward customers sitting in the rows of it, and that is the version that actually gets used on a Monday.
Common questions about support tiers
What is the difference between tier 1 and tier 2 support?
Tier 1 handles tickets whose answer is already documented and whose action it has the permission to take, such as password resets, billing lookups and how-to questions. Tier 2 handles anything needing investigation or authority tier 1 has not got, such as reading logs, approving refunds or diagnosing a broken integration. The boundary is set by documentation and access rather than by seniority.
What is tier 3 support?
Tier 3 is the group that can change the product its self, which usually means engineering or a specialist team. Tier 3 work resolves the underlying cause rather than the individual ticket, so it is measured in releases and fixes rather than in reply times.
How many support tiers should a team have?
Below roughly five people, one tier is normally enough and a formal ladder costs more in handoffs than it returns. Tiers start earning their keep when the same escalation types repeat weekly and when access or approval genuinely sits with different people. Three tiers is a convention inherited from IT service management, not a requirement.
What is a good escalation rate?
There is no honest universal figure, and any number quoted for it is an average of desks with different products and different counting rules. Your own previous quarter is the only benchmark worth using. Pair the rate with time-to-escalate, because a falling rate can mean tier 1 is absorbing more or that it is sitting on tickets it cannot finish.
What is the difference between escalation and tiering?
Tiers are the structure and escalation is the movement through it. A tier describes what a ticket needs before it can be closed; an escalation is the act of moving one ticket because its current owner cannot finish it. Escalation can also travel sideways, to an account owner or a manager, rather than upward.
Does Maxdesk support tiered routing?
Not as a built-in tier field, and there is no skill-based routing. Tiers are built from tags, automation rules and assignment. On the Elite plan the AI triage agent sets priority, files a category and assigns by each agent’s live open-ticket count, which balances workload rather than matching skill. Human agents are unlimited on every plan and billing is per workspace, so extra tiers add no cost.