A while ago, while working on the design of customer onboarding for a software company, I found myself wondering: why do we measure customer onboarding in detail but not put in the same effort when onboarding is internal?

With our customers, we measure maturity by phase, milestones, signs of progress and risk, criteria for knowing when a customer is self-sufficient, which modules they’re actively using to identify upsell opportunities… But when you look at your internal customer, the person who works alongside you, it’s not just that we don’t measure their progress: we give them a couple of manuals, several videos and a few scheduled meetings to get to know people, and with that, we consider their onboarding complete and tell them they can start managing accounts.

With this disparity between internal and external customers, the question is obvious: why do we design the customer’s path to autonomy so carefully and leave the path of the person who has to guide them to chance?

Today, we’ll try to find an answer to this question, but first, we need to understand that this isn’t a lack-of-content problem, because in many cases there are actually too many hours of training. The problem is that this person does things at your company but takes too long to understand what they’re for.

A checklist isn’t onboarding

Sound familiar? This is exactly what we say about customers, but why do we repeat the same mistake with our team? Just because someone has completed the training doesn’t mean they’re ready to manage a portfolio, and if you apply that same thinking to an external customer, finishing training doesn’t mean they’ve adopted the product or found value in it.

When discussing this with industry peers in the past, one of the most common observations is that when you join a new company or take on a new role, the material tends to be dense, and no matter how many videos you turn it into or business cases you include, it won’t help anyone tackle their new job without a strategy behind it. Another important consideration is that, with remote work, where there’s less human connection, even if you arrive full of enthusiasm, spending the first 2 or 3 weeks training without any other information or contact drains your motivation, and someone can even end up burned out before they’ve really started.

So the question isn’t how much content to give them, but the same one we ask about a customer: what does this person need to make decisions independently? From there, there are four things I’ve found worth balancing.

1. Context: why the company exists and what problem it solves

Here comes the most important task your onboarding should cover, and it’s what makes the difference between having someone who executes tasks and having an advocate and champion for your product. Before you teach a single feature, this person needs to understand why the team exists, what problem it solves, how it fits into the rest of the company and what value it brings to the customer.

In our case, that meant writing a page explaining what our role was, what it wasn’t (not support, not implementation, not sales) and how it connected with everyone else. It wasn’t a pretty document; it was the answer to the question everyone asks themselves in their first week without daring to say it out loud: what exactly am I here for? What impact do we have on the company to help it grow? What impact do we have on customers?

It’s also worth developing a part of this section that almost never appears in onboarding: your customers’ industry. We didn’t have any internal material on this, so we selected some introductory industry reading and worked on improving it over time. You often read here and there that you need to understand your customers’ industry, what’s expected of them, which regulations they work under or what keeps them up at night. But nobody prepares you for that, and when you ask around and find someone with a similar customer, they share the information verbally because it usually isn’t documented.

And although you tend to review each individual customer’s goals in meetings. Why not do it now to understand how much impact your work will have? Looking at what they wanted to achieve when they bought from us, their expected timeline and what success means to them provides account-level context that should also be brought up to the segment and business level to build a strategy.

And one last thing that may seem minor but isn’t: how things work here. They need to know where customer information is recorded, how to escalate an issue, what gets documented and where, because these will be their everyday tools. If nobody shows them, they’ll spend their first few weeks asking the same questions over and over or, worse, making up their own way of doing things and mixing up data—or worse still, leaving it out because nobody told them it needed to be recorded there.

2. Contact: from day one, not once they know what they’re doing

If someone doesn’t feel supported, why should they represent you later? If you value culture, this is the moment to demonstrate it, not six months later when they’ve found their rhythm, but when it’s needed to lay the foundations.

What I would do is share that support across three roles so that culture and guidance go hand in hand. Why three? Because each one covers something the others can’t.

  • You, as the lead. In the first week, daily 1:1s: to check progress, give feedback, keep them from getting stuck on something trivial and, above all, make sure they don’t feel like they’re bothering you by asking questions. From the second week onward, space them out, which is exactly what you do with a customer: intensive support at the start, decreasing as they gain autonomy. You also get to know the person behind the professional.

  • A mentor from the team. This is different from a 1:1 with a lead or Head. The mentor shows how things are really done, provides support on real cases and answers the small, day-to-day questions that people don’t always ask a manager.

  • The other departments. Implementation, Support, Product, Sales. So they can get to know the people and the processes the customer they’ll be managing goes through, and understand what those teams expect from us.

And here’s something I’ve tried that works quite well: make those sessions about more than just listening. Give them a blank template to fill in during each meeting, with who each person is, what to go to them for, what they expect from us and how much influence they have over decisions that affect us.

Because an org chart tells you who reports to whom, and that isn’t particularly useful day to day. Very often, what they really need to know is who to go to for what.

Also, when you review that map with them at the end of the week, if there are no notes, those meetings were introductions rather than valuable conversations.

3. Practice and judgment: from knowing the product to knowing how to decide

One of the things I find hardest to achieve is getting someone to think critically rather than relying solely on the product manual or predefined use cases, because sound judgment lets you find the fit between your product and their needs, develop it, simplify it, expand it, upsell, connect customers and projects… If someone can explain perfectly how your tool works but doesn’t know why that matters to the person using it, they’re not ready to sit down with a customer and help them find value.

Because judgment isn’t handed over; it’s built through practice. That’s why progression matters so much when bringing people onto the team. The first step is to observe: join real meetings and cases without responsibility, just listening and asking questions afterward.

And how do you develop judgment? One of the most powerful exercises I’ve seen is presales demos. They’re a way for someone new to learn the product from the outside rather than the inside, because they hear questions from a customer who doesn’t know it either—the exact same questions they have. Also, they hear how value is explained rather than features, and they hear real objections, the ones that would take months to discover on their own.

Next comes participating: having them start contributing in those same meetings, with someone beside them who can add nuance or fill in what they say. Then executing under supervision: having them handle the case, prepare the session and respond to the customer, with someone reviewing before or afterward. And finally, deciding independently, when they no longer need prior approval for routine matters and only escalate what truly requires it.

What does all this look like in practice?

Here’s a condensed version of how we structured it in our case, with the caveat that this depends heavily on the complexity of your product and your customers’ industry. A SaaS product you can understand in an afternoon isn’t the same as one that requires knowing the regulations and the day-to-day work of its users.

  • Week 1. Context and not much else. Basic learning from the materials about our role, what we do and don’t do, along with the basics of our customers’ industry and 1:1s to remove blockers and share any updates from that week. This also includes setting up their technology and permissions, the tools they’ll use and why, and the types of sessions and recurring meetings.

  • Week 2. More product knowledge, use cases and the first sessions with other departments, filling in the map of who’s who. The 1:1s start to become less frequent, and they begin building context and judgment around why and how things are done. Introductions to the team and the first team sessions.

  • Week 3. Mentoring with another team member begins, along with observing real cases involving active customers. I deliberately placed mentoring here: I didn’t want to keep the mentor busy explaining basic concepts they could already have learned on their own or with me. Their time is valuable for what isn’t written down anywhere and where they can add value.

  • Week 4. First account, exercises to assess competencies and strengthen any remaining gaps, participation in team sessions, involvement in projects and alignment on the roadmap for the next 4–8 weeks.

Four weeks sounds like a lot if you’re used to two-day onboarding, and not much if your product is complex. What matters isn’t the number; it’s that each week has a different goal and that the person knows which stage they’re at.

And within each day, here’s a split that works well: no more than half the working day spent consuming content. The rest should be spent with people and on practice, because if someone spends six hours straight reading and watching videos, by two in the afternoon they’re no longer learning; they’re turning pages. Three hours of content with a fresh mind is better, with the rest of the day spent in a session with someone, doing an exercise on the platform or simply organizing what they’ve learned.

And be careful about filling every slot in their calendar, because a full calendar creates pressure too. This person needs gaps to reread, try things on their own and write down their questions before the 1:1. If you don’t leave them that time, they’ll take it out of their breaks or feel like they’re falling behind from day one.

And finally, something I found essential: put in writing what’s expected at 30, 60 and 90 days. Not as an evaluation, but as a guide, so they always know whether they’re on track, because the biggest source of strain during onboarding isn’t the workload; it’s the uncertainty of not knowing whether you’re doing things as expected.

How do you know they’re up and running?

Not by completed tasks, but by asking the same question you would about a customer: can they make decisions without asking you yet?

We looked at three things, and they’re the ones I’d keep looking at.

  • Tests on customer pain points. Not on product features, but on what hurts the customer and how what we sell solves it. These work much better when, instead of isolated questions, you put a real case in front of them: this account is in this situation—what would you do? That’s where you see judgment, not memory.

  • The mentor’s assessment. Someone supporting them on real cases sees things that don’t show up on any test: whether they ask the right questions, spot what matters and know when to ask for help.

  • And their contributions in meetings with other departments. This is the best signal of all, because when someone moves from listening to contributing something useful in a meeting with Product or Support, it means they understand the business, not just their part of it.

There’s one more signal, informal but quite reliable: when the person starts feeling eager to get going, when they ask you when you’ll give them an account. That only happens when they feel they have enough context.

Onboarding goes both ways

There’s something we almost always fail to take advantage of, because we assume that information flows in only one direction during onboarding: from us to the person joining. It doesn’t.

Someone who’s just arrived sees what those of us already inside no longer see. They see missing documentation where things seem obvious to us, a step nobody can fully explain, two teams describing the same thing differently. And that perspective lasts only a short time, because after three weeks they’ve gotten used to it, just like everyone else.

So ask them what was hard to find, what surprised them and what they didn’t understand the first time. And don’t do it just to be nice; do it because it’s the best free audit of your own processes (and customers) you’ll ever get. Along the way, you’re telling them something important from day one: their judgment matters.

An exercise for this week

If you want to know where your internal onboarding stands today, take the last person you hired and split their first week into the three categories: how many hours were spent on context, how many on contact with people and how many on real practice.

And if context takes up almost everything, you have your diagnosis: you don’t have onboarding; you have a course. People pass courses, but courses don’t prepare anyone to sit down with a customer.

Because for a customer, we design a path toward autonomy, with milestones, signals and support that decreases as they gain confidence.

What were you given when you joined your CS team? I’m really interested to hear whether anyone encountered something genuinely designed.