Business practice
Support team structure.
Your support team structure grew around the people who happened to be there. We help SaaS and AI companies redraw it around the work: tiers and escalation paths that make sense, a named owner for every queue and recurring decision, and nothing important stuck between support, CS and implementation.
Your support structure wasn't designed. It accumulated, one good hire at a time.
That's not a criticism. It's how most SaaS companies your size got here. Somebody capable took on the escalations nobody else could handle, then the enterprise accounts, then the implementation that went sideways, and the job title never caught up. It works until that person is stretched, or leaves, and the work turns out to have no other home. Spans are growing, too. In Pave's benchmark data, the average span of control for managers and senior managers grew from 4.4 to 4.9 direct reports between Q4 2023 and Q3 2025.
What we build is a structure people can act on. Tiers from L1 to L3, with escalation paths everyone describes the same way. Who owns what across support, CS and implementation, written down and agreed out loud. Where each recurring decision sits. And the gaps and overlaps, surfaced before they cost you. It's a working document about responsibility, not a chart to hang on a wall.
The approach
Three words we work by.
Name.
Every queue, tier and recurring area of work gets an owner by name, and every owner sees the list before it's final. Written ownership that hasn't been said out loud in the room isn't ownership. It's a document. The conversation where support and CS discover they both thought they owned onboarding tickets is the useful part.
Decide.
Decisions are mapped separately from tasks, because that's where the queue forms. For each recurring decision, from an SLA exception to a credit over the usual limit: who makes it, who's consulted, and what threshold sends it up. Most of what waits on a manager could have been settled a tier lower, which is why Manager Fundamentals starts with what a manager owns, decides and escalates.
Close.
Gaps and overlaps get surfaced and closed while they're still cheap. The work sitting between support and CS, the approval two people both believe they give, the implementation task everyone assumed belonged to the person who left. Each one gets a name or an explicit decision to leave it open.
The work
Four workstreams, in sequence.
Ownership map
Every queue, tier and recurring area of work listed against a named owner, built from what people actually do rather than from job titles. The draft goes back to the people named on it, because ownership somebody hasn't agreed to is a wish.
Decision rights
The recurring decisions across support, CS and implementation written down with who decides, who's consulted, and what threshold escalates. This is normally where the queue behind one calendar comes from, and it's the fastest thing to fix.
Gaps and overlaps
The work with no owner and the work with two, listed plainly. The churn signal support spotted and CS never heard about. The onboarding call both teams show up to. Each item gets resolved in the room or gets an explicit note saying it stays open and why, so nothing quietly goes back to being nobody's job.
Structure on paper
The agreed structure written down in a form your team can use and change: tiers from L1 to L3 and what each one resolves, escalation paths, owners, decision rights, and a review date. Handed over with the settled disagreements noted, so the next change starts from a record rather than from memory.
Related reading.
All insights
Operations
The two-person dependency test
Every SaaS company has them. Two people, sometimes one, who hold a process together through memory and habit. They're usually excellent, they're usually loyal, and they're usually the reason nobody has ever needed to write the process down.
Retention
The six questions that find churn before it finds you
Churn in a SaaS company almost never looks like a decision. It looks like a slow drop in contact, a QBR that keeps getting rescheduled, a champion who stops replying, and then a non-renewal notice that arrives as a surprise to everyone except the customer.
Questions
Asked before, answered plainly.
Usually not. Most of what we find is fixed by naming an owner and moving a decision down a tier, with nobody changing seats. If the structure genuinely needs to change, we'll say so and show you why, but that's the less common outcome.
That's not what this is for. The question we answer is where responsibility is unclear, not who's surplus. If the work says you're short a person somewhere, we'll say that too, and support capacity planning is the piece that answers it properly.
By telling them what it is before it starts and by showing them their own section before it's final. The exercise is about work, not performance, and every person named on the map sees it and can argue with it.
The smaller you are, the more decisions tend to queue behind one or two people, so the value often shows up faster. It doesn't have to be a framework. For most companies your size it's a single page listing the decisions that actually recur.
Then you've found one of the more expensive items on the list, and it's better found here than during an incident. Somebody with the authority to settle it needs to be in the room, which is why we ask for that person up front.