Every SaaS support org I've seen runs some version of the same model.
L1 picks up the ticket. L1 has scripts, runbooks, and a clear mandate: triage, resolve what you can, escalate what you can't. If the issue is too technical, too sensitive, too cross-functional, it goes to L2. L2 has more access, more product knowledge, more authority. L2 has fewer people. L3 is engineering. You don't get to L3 unless you have to.
This model isn't wrong, exactly. It comes from somewhere. It's borrowed, more or less directly, from telco call-center operations of the 1980s and 90s — where the product was simple, the staff was massive, and the cheapest thing to do was filter at the front door. It works there.
In modern product-led SaaS, it slowly stops working. Here's why.
What the L1/L2 model is optimizing for
Strict tiering optimizes for one thing: keeping expensive labor away from cheap problems. It does this by trying to filter the cheap problems out at L1 and only forwarding the expensive ones up the stack.
This works when:
- The product is simple enough that L1 scripts can solve most cases.
- Customer problems are independent of each other — solving one customer's issue doesn't tell you anything about another customer's.
- The cost of L1 labor is dramatically lower than L2 labor.
- The customer relationship is transactional — they don't need to feel known.
For a 1980s telco support line, all four of those held. For a SaaS company in 2026 selling a platform that does fifty things, none of them hold cleanly.
Where it breaks
The model breaks down in a few specific, predictable ways.
The escalation tax
Every escalation costs context. The L1 agent has to write up what they tried. The L2 agent has to re-read the ticket, re-engage with the customer, often re-ask questions L1 already asked. By the time L2 actually starts working the issue, the customer has explained their problem three times. Every layer of tiering adds a hand-off, and every hand-off has a cost.
The script-shaped solution
L1 agents under load reach for scripts. Scripts work for the modal customer in the modal problem. But the customer with the slightly-off-pattern issue gets a slightly-off-pattern answer that doesn't quite solve their issue, and they have to come back. The metric looks fine — ticket closed in seven minutes — but the customer just got their first answer to a question that took three more answers to actually resolve.
The talent ceiling
The best L1 agents eventually have to leave L1 to grow. If your org doesn't have a clean path for them to move up, you lose them to a competitor that does. If your org does have a clean path, you spend a lot of time training the next L1 to replace the one you just promoted. Either way, the model has a built-in drain on the talent that matters most.
The product-feedback loop
L1 sees patterns that nobody else sees. Every recurring ticket type is a product signal. In a strict tier model, that signal gets diluted as it travels up the chain. By the time it reaches the team that could do something about it, the texture is gone. "Customers find this confusing" — okay, but which customers, how confusing, where are they getting stuck, what did they try first. L1 had all of that and it didn't survive the hand-off.
The alternative: technical generalists
The alternative is to staff support with people who can credibly own the full product surface. Call them whatever you want — Account Specialists, Technical Support, Product Support, Solutions. The label matters less than the staffing model.
A technical generalist can:
- Take the ticket from intake to resolution without escalation, for the vast majority of cases.
- Recognize when a "simple question" is actually a signal of a larger structural problem in the customer's setup.
- Write a workflow or a snippet or a script that ends the recurring class of tickets, instead of just closing this one.
- Run a customer through a feature they didn't know existed, on the same call.
- Feed real, textured product signals back to the engineering and PM teams.
This staffing model is more expensive per head. It's also dramatically cheaper per outcome.
The pilot
I'm not making this up out of theory. We ran a pilot on this at HighLevel. I was on the pilot team. The setup was: a subset of the Priority Support folks would take ownership of tickets across the L1/L2 boundary, end-to-end, for a defined customer base, for a defined period.
The results were almost embarrassingly clear. Tickets resolved faster. Customers stopped having to re-explain themselves. The number of tickets that "stalled" in handoff queues dropped to near zero. Customers started asking for the specific pilot members by name, which is the cleanest market signal you can get for whether the staffing model is working.
The pilot ended. Some of its DNA is now built into how we staff. It's still not perfect — strict-tier habits die hard in any organization — but the case for the model is no longer hypothetical.
When tiers actually help
I'm not arguing tiers should never exist. Two specific places they earn their keep:
- True engineering escalation. Some problems require code access, a deploy, or a bug fix. A separate channel for those — call it L3 if you want — makes sense. The goal is to get to that channel quickly, with the right context, not to gate access to it.
- Specialized domains. Things like A2P 10DLC, regulated industries, payment-platform escalations — these are deep enough that a dedicated specialist is the right answer. But "specialist" is not the same as "tier." The specialist gets the ticket directly, not via a hand-off chain.
The honest summary
If your support model is doing real work — closing real tickets, solving real customer problems — strict L1/L2 is mostly making that work slower and more frustrating than it has to be. The fix is to invest in fewer, better-trained, more empowered support people. The case is straightforward; the implementation is hard, because it requires hiring different people and paying them differently and trusting them with more.
Most orgs won't do this. The ones that do tend to pull ahead on every customer-facing metric a year or two later.
If you can't restructure your support org, you can still run a pilot. Pick a customer segment. Assign a small group of generalists to it for a quarter. Measure. The numbers will tell you what to do next.
If you're running a SaaS support team and want to talk through staffing model trade-offs, happy to chat.