How to Structure your SaaS Onboarding Team Video

How to Structure your SaaS Onboarding Team

In this video, Jeff walks you through how many startups create their first onboarding team.

Full Transcript:

[00:00:00] Hello, this is Jeff Kushmerek from Infinite Renewals. One of the things I get asked all the time is how do I structure my, onboarding team and, you know, so we normally come in and we either, help companies get up to speed, set the organization up or make tweaks, I can say, you know, and what's, what's, what's set the focus here, usually series.

Companies start off this way that I'm about to describe and, and then, and sort of just sort of amplifies up and goes from there. And I'm usually dealing with SaaS, B2B companies, but this can still apply to, to non b2b. But, for the context of what we're talking about, there's just some things around there, especially when you get into integrations and APIs and training and, and things like that, that this covers.

So without a. . And I have an article I went to as well too called the, evolution SaaS Onboarding or something like that. It's a couple years old now. Where, the first thing is the CSM just does everything right. And there may be [00:01:00] some iterations of this before where it's a, you know, it's a, it's a, it's a receptionist or, or some other, random person that gets in.

But let's get, let's assume get to the stage where you've got a CSM and they're just doing everything. What normally happens here is that you then amplify that and you say, we've got three CSMs now, or five CSMs, and they're doing everything as well too. And, what, what winds up happening is that nothing gets done well.

Right. The typical thing that happens is when we start interviewing the csm, And the, the classic quote is, it's like a bomb goes off in, in our, in our world, and we really can't focus on anything. You know, it's the big new customer and the big new logo and, suddenly, renewals aren't happening.

Churn rates go up. . Usually in this method too, I think csn are also doing support too. So the first thing that we normally say to, to fix this is, okay, let's, let's get them to stop doing support. But I then suggest for them to start doing,[00:02:00] separate onboarding resource and, actually pulled up some stats from, insight Financial here, that you should see that, across their whole full portfolio.

Their whole portfolio, that, their coverage looks like this, right? So if you're at the 30 million range, how many dedicated onboarding resources should you have? And that's about six. And, and to be honest, that's about right. I'm gonna get into some of those reasons why. And then you'll see from 30.

to a hundred million, you get into that 10 range, not exactly linear, because you're gonna pick up some efficiencies with different role types. And then from there, after that, it just kind of starts scaling. I don't exactly love the revenue number. . One of the reasons why is that you can have a really complicated, I, I mean, I'm sure it works out and I actually haven't sat down and done the extrapolation with the math.

But what happens is that you can have some very complicated Products [00:03:00] that, that you might need separate resources. I have some customers where their average ARR is like 200 K and it's a long five, six month process and you need three to four resources to go along. And so you might start putting people into pods and things like that.

So I don't like to just. Narrow right down to the revenue numbers. I like to see and get a baseline for how many people can handle, and then start scaling things out. So let's, let's start, start taking a look at that. The, sorry. These are all sort of blending in here. Let's take some, Let's take some things here where your average implementation is 30 to 90 days.

Your average time to value is 60 to 90 days. Notice this isn't time to launch, this is your time to launch would be 90 days, but you should start seeing value within those first 60 days and, and be sharing what that value is back to the customer, including the, the people who might not be in all the day-to-day meetings.

Where. . You know, let's say for example, [00:04:00] you have a nice data visualizer or you finally got data in, like there's a massive data. You're able to aggregate sources together, or people are starting to configure the API and get integrations going that they previously didn't have. Well, that's a value and you should really be showing that value up there.

But when we get back to the. Org structure things, what normally happens is suddenly people go final, let's hire that one implementation manager, and they start loading 'em up with like 10 to 15 implementations. And, and then from there they start scaling that number out. I'm gonna show what that might look like above, but the normal model here, as you start just bringing in more implementation managers, right?

So you might have, you know, two or three. And then going from there, and then you start bringing in some different structure, and going from there, I'm just gonna move this around a little bit and show that what they're normally doing here is they're doing all the tech tasks, right? They're doing some configuration, they're doing some training, they're bringing them through the launch process.

Do another video later on, [00:05:00] project management tools and things like that. But you should have a baseline plan that you're walking people through and going, for that, so, This can work for a lot of people, a lot of organizations. But what winds up happening is that, you start, especially finance starts saying like, why do we need so many implementation people?

And you can use these numbers that we're looking at here, but instead of just multiplying, okay, like, we're going two x next year, so we're gonna need six people now, and then, and going from there. I prefer to start specializing the roles a little bit, but, you might have a hybrid organization. It's what normally winds up working out well, where especially when you have some SMB customers and maybe some enterprise customers.

What I'm gonna show here is a little bit of what a, this is sort of what a pod would look like here, or two separate pods. . Notice here I'm gonna remove it from the customer success line of business here. And I'm also gonna differentiate [00:06:00] what that looks like from professional services. I do like to differentiate those two organizations I would consider professional services.

You're doing custom work, custom code, custom integrations, maybe building a portal. You'll probably eventually have this all report. PS and maybe PS becomes its own org and things like that, that eventually winds up, winds up going up to a cco. But, for this look easy and to start, stop doing all the, it depends stuff that we do in cs, this kind of works well if, if people have worked on technical projects where you've got like a project manager and then like an old Java developer and now like a Python developer.

I like to structure it like, and this is where you start getting into this differentiation where you might have had this onboarding lead, might be this person, implementation manager. I would probably just create that as the implementation manager and double it over here. [00:07:00] This is how I would differentiate it.

Perhaps as you're growing your organization, your implementation manager can do everything, and you have these jack of all trade people, and then they can start working on, what normally happens at the s and b customers where you just need one resource to take care of everything. But when you start going into enterprise, you'll start seeing this type of a breakdown here or this type of a pod where you've got the project manager, implementation manager, where there are.

Going through and they're watching the project plan, but then for all the technical configuration stuff, this happens to be an engineering type where they're maybe writing some Python or they're working on an admin panel. Usually in startups, you don't have all of the fancy admin stuff that's going on.

and you might wind up needing to be doing some more custom work in the background config files and things like that. Those types of resources aren't the best to manage customers. So I like to break that up. And then from there you can scale that. So these resources are [00:08:00] usually more expensive. They're usually over a hundred thousand dollars.

These might be around a hundred or in the 80 range. We're talking u s D here. So suddenly you can get an implementation manager slash project manager that can manage. More customers, project managing them through, then you're gonna have these sort of developer types that can do a little bit more of the focused work.

And then from there you can scale up this number as well. And you don't have to get as many implementation engineers. So that's, that's one way. This, this is pretty successful, for. Sometimes there's a solution architect as well. They can, they can architect things through as well, and I would just copy this and bring 'em into this flow.

It all depends on how technical your product is and sometimes people will just, can just go with this onboarding resource. Whereas we're seeing here, just have a bunch of implementation managers knock 'em out in 30 days and things like that. But when you start getting into the enterprise realm, you in s and b, I would consider this more [00:09:00] your s and b role here, and this is more of your enterprise flow.

And then you just start taking this pod aspect and then. You know, just copying them, copying and pasting, and just having more and more of these pods as they break out. They could be vertical pods as well too, as well as regional. And, it, it, it really just depends on how your organization works, especially if you're selling more.

Vertically as well too. So I hope that helps. I've been really trying to keep these in 10 minute tips and I, I think I'm hitting that, that number right around now. So that's, that's where we are. And, fire any questions in the comments and I'll answer them back. And, hope you enjoy this and look for some more.