Guess who’s back.
Your CS friend.
Anyways, Slim Shady shout outs side, welcome back to the second installment of our series on customer success onboarding.
In our last installment, I outlined my plan for digitally onboarding our first CSM.
Today, I’m going to cover what worked well so far and, more importantly, what failed dismally.
Psst - this is part 2 in 3 part series. If you want to see what our first 30 days was like, check out part 1 here.
Here we go!
Since we make onboarding software and firmly believe in drinking our own champagne, there are definitely some things to celebrate here.
LevelJump is built 100% on salesforce, so we’re a little spoiled with the number of technical resources we have available to us.
As a reminder, as part of our customer success onboarding, we included trails in Trailhead to teach new CSMs about the underlying infrastructure for our product.
This proved to be hugely helpful. By deeply understanding how the product was architected, it allowed our CSM to get up to speed on the granular features and functions faster.
What made this especially interesting to me is how different this is from sales onboarding. Sales onboarding should never start with Product, and instead focus on the customer – who they are, what their pain is.
In person, this is usually easier because you’re a lot more aware of what they’re doing and when they need something to work on, and can adjust and teach on the fly.
So I was worried ahead of time, and planned an extremely structured first 45 days.
And that paid some serious dividends.
It meant that our new hire stayed motivated and engaged, even though she was going through the process on her own. And while it was time-consuming to organize all of her onboarding in such a prescriptive way, it gave her an incredibly deep understanding of our product and how we help in a very short space of time.
Basically, it meant that she knew what to do every day, and meant we were able to give her her first account sooner than expected.
Again, this was unique compared to sales onboarding:
With any new hire, you’re imparting a lot of trust. You’re trusting that they’re going to be good for your team and your business, and do (eventually) what they said they would.
With remote hiring and onboarding, that increases tenfold. You’re not there to see how they spend their day. You need to trust they’re doing all the little things that don’t necessarily turn up in reports and metrics.
For example, are they organized and on top of their work? Are they documenting things correctly, and are they using the systems you’ve built correctly? At an even more basic level, are they delivering on all the tiny things that you’re not necessarily tracking day to day but are important to their job?
With remote customer success onboarding, I felt I had to extend more trust to our new hire (trust, by the way, that was well placed).
And being comfortable with a remote setup really comes back to our hiring process. At LevelJump, we have a fairly rigorous 3-step process, which includes a presentation to the wider team. I’ll be honest – it’s hard. You have to present to a room of people you don’t know, and the room often includes senior leaders like our VP product and engineering or even our founder and CEO.
Since switching to remote hiring and onboarding, I’m more grateful than ever for this process, since it means I know I can trust the people we bring on.
If you remember from part 1, one unique piece of onboarding we did was spin up a demo org for our CSM to play with. Throughout her onboarding, we had her continuously go back to the demo org to practice whatever product or use case she just learned about.
It was a pretty basic learn –> practice routine, but it meant that she could x10 her learning just by spending time in the product. And since we hired someone curious and inquisitive, she started to find and explore things, use our community resources, and actually get experienced with the platform from a really early stage of her onboarding.
Let’s be real though.
Not everything worked.
In fact, a lot of stuff didn’t work at all.
As we’ll soon see...
We used our sandbox environment and built our CSM onboarding around the customer journey. So, first our new hire would learn the product, then go and actually do that thing where it related to the customer. And the tasks followed the customer journey.
For example, since we’re a Salesforce native app, the first thing customers do is install the LevelJump app into their Salesforce instance. That’s what we had our CSM do first. Next is building the first program, which we had her do next, and so on.
This seems fine in theory, but didn’t really work in practice.
Sure, the order made sense… but it meant there was a huge lag between learning, practicing, and then actually doing.
For example, our new CSM took her first account after two months – so that’s two months since she’s last run an installation and kickoff call.
It created a ton of extra work for her, since she had to go back and re-learn the things that she’d learned eight weeks ago.
What’s more, the stuff that was top of mind when she took on her first customer was stuff like QBRs and how to run complex use cases – wildly irrelevant information for a customer who’s just starting out.
While it’s valuable to go through and understand the entire customer experience, you can get that other ways without building your entire onboarding around it. Instead, teach your CSMs new things right before they need to use them.
I built our CS onboarding as one giant program.
And that was a mistake.
What we should have done is broken it out into micro-programs, where the relevant content, training, practice, and milestones is triggered by a specific event.
For instance, learning and practicing how to run an installation call should only happen once your CSM has been assigned their first customer and the install call is on the books.
If I were doing it again, this is the single biggest change I would make.
I’d create one onboarding program. Learn about the platform, the customers, read the release notes and use cases, then listen to calls, then start shadowing.
Then, when a new CSM was ready for their first customer, enroll them in a second program solely focused on customer onboarding. Then a third program on customer usage and extracting value. Then a program on running QBRs, then negotiating renewals, and so on.
I love product release notes. When you’re as close to the product as we are, then it’s always cool to see the latest and greatest.
But they’re not actually great for a new hire because they’re not meaningful.
When you’ve been working with customers for a while, the release notes are hugely powerful because you’ve seen the product suggestions roll in from customers, and release notes are solutions rolling out.
But for a new hire, they’re just an isolated datapoint, without any context around them. At best, they’re useless, but for us they were a distraction from the core features, functions, and business benefits of the product.
We got lucky.
We hired an amazing remote CSM, who has put up with our learning pains and helped us figure out the kinks to building a repeatable remote customer success onboarding process.
But I also know that not every CSM we hire will be great. No one has a 100% success rate, so I’m trying to shore up my onboarding and make it better than ever to give us and the people we hire the best chance at success.
And I've learned a lot going through the customer success onboarding process remotely.
I’ve learned how important it is to have a fundamental understanding of the architecture and infrastructure of your product before you start digging into specific features and use cases.
I learned how critical it is to understand the customers, and how much that understanding comes from being in-person with the team. Gong has been absolutely brilliant by providing a huge repository of calls for our new CSM to listen to, to get to know the customer problems and pains.
I learned that you need to onboard and teach only what’s directly in front of your new hire. Don’t teach them about renewals before you teach them about customer onboarding!
And finally, I learned that remote onboarding cannot be a single, large program. Onboarding is a journey from novice to expert, and each step along that journey should be its own dedicated program, with key learnings, practices, and an opportunity to get actual experience doing what you just learned and practice.
Stay tuned for part 3, where I’m going to do a full review of the first four months, look at metrics and milestones, and see if our onboarding program actually worked. See you there!
Image credit: Aleks Marinkovic via Unsplash
Becca is the Director of Solutions Engineering. She first came to LevelJump as a customer, leading sales enablement at Flashstock (acquired by Shutterstock). Prior to her shift to sales enablement and customer success, Becca was the first operations hire at a string of startups, implementing HR, onboarding, and learning backends at QuickTipSurvey and Influitive, where she eventually led the North American operations teams.