Onboarding vs. Implementation - reflecting the difference in process?

"This often involves a fair deal of change management which I would not lump in with "implementation". When executed intentionally, onboarding should be a cross-functional, strategic motion whose foundation is laid during the pre-sales process to ensure there is a strong, well communicated, and validated launch plan or "success plan" with the right actors interfacing on both sides (including executives)."

That is so well said. @Donna Weber teaches the orchestrated onboarding framework to help ensure just that. Great minds think alike! 

@Donna Weber  Ha- we could do a panel on this!!

When I am usually brought in, a company is in the ugly teenager stage when implementations have not been done well, TTV is way too long, no repeatable processes, etc. This usually means that the Sales leadership is dying because they are trying to get new sales, but they are having to listen to angry new customers. So I let them know that by bringing in implementation/onboarding earlier, that problem will be fixed. The promise of happy, referencable customers is the big selling point. 
There are other factors too- having another non-sales "adult in the room" looks more professional in the sales process. From my experience, having the post sales team involved creates tighter bonds. People will open up more to the people that are not commission based. 

To combat this, I created templates to make onboarding during the sales process as streamlined as possible and also coached the sales team on value-based selling. If a CSM involved - usually for very large implementations or pilots requiring PM work, we followed the agreed-upon timeline for implementations. This timeline was developed with sales and the customer's exec leadership. Ultimately, the sales team trusted we wouldn't slow down a deal. They also had no reason to believe we would. This trust was developed through years of working together and building alignment between the two teams. 

We want sales and the customer to be successful. Sales had the same goal. Closing a deal too eary on or forcing a deal always backfired. This is something sales learned the hard way and overtime.

Any suggestions for how to deal with sales teams and leaders that worry about CS slowing down the deals? I see bringing onboarding earlier is a way to show customers how you partner for success in the long term, but how do you convince the sales teams of that?

I love this question!

How is the difference between onboarding and implementation reflected in your teams' processes?

Internally, we have a separate "Technical Implementation" process from our "Onboarding/Configuration and Training" process. Our technical implementation is owned by an Implementation Specialist who works to get the backbone of the system connected for our customer, and once the bones are there, the CSM takes over to begin configuring and training the new users on their system. The CSM also takes the customer through the "Team training" phase where we open up the system and introduce the entire customer team to the software. The configuration/training phase is used to train up the Admins who need the additional knowledge.

The key here, and @Tiffany Morin alludes to it, is to having a strategic sales team. Its very common to have sales block implementation from presales conversations. They are scared we will slow the deal down, or bring up things that the sales team might have glossed over or even wrongly answered to get the deals.
The problem with that is bad expectation settings.

-------------------------------------------
Original Message:
Sent: 9/1/2020 12:23:00 PM
From: Benedict Fritz
Subject: RE: Onboarding vs. Implementation - reflecting the difference in process?

Great post! ?

Love the idea of onboarding before the deal even closes. Guessing this involves some handoff from the sales to the success team-how do you advise teams handle that process smoothly?

@Donna Weber is right. Ideally, you want to get introduced close to the initial close of the deal.
This does require typically an AE to CS handoff and SE to CSE (Customer Success Engineer or whomever handles technical post sales).

The timing of this does get tricky as you typically want to do this right around when the customer has moved to contract negotiation (typically the last step) right before the deal closes.  There are a few challenges here because some contracts take a few days to negotiate and others can take months. Then there is the factor that you can do this internal handoff prep and also the intro with the customer and then deal falls through.

While there is risk, there is also the benefit of introducing CS can also help drive the deal to closure faster (especially with a strong onboarding plan) as you can use the deadlines that the customer has to show when they have to start to reach those deadlines.

Great post! ?

Love the idea of onboarding before the deal even closes. Guessing this involves some handoff from the sales to the success team-how do you advise teams handle that process smoothly?

Onboarding ? Implementation.

You build trust and relationships in onboarding, not just go live with your product.
I'm working with two companies right now to start onboarding before the deal even closes.

Learn more here. 

-------------------------------------------
Original Message:
Sent: 8/26/2020 9:22:00 AM
From: Benedict Fritz
Subject: RE: Onboarding vs. Implementation - reflecting the difference in process?

Awesome, thank you! Did your team have a segmented set of implementation guides that covered most typical use cases? Or were these guides custom-made by the CSM for each customer?

Awesome, thank you! Did your team have a segmented set of implementation guides that covered most typical use cases? Or were these guides custom-made by the CSM for each customer?

Love your emphasis on getting everyone (marketing, product, sales, finance, CS) involved with the onboarding process! Do you have any specific techniques/process for getting all of those teams a seat at the table and feeling like they can actually have an impact?

Thanks Jeff! Great post-love "Project Pangea" as a stage name

Though onboarding and implementation happen simultaneously, onboarding (as Jeff defined) must be done before the implementation is complete. For example, unless you understand the scope, business needs, goals, etc. you would not be able to properly scope out the implementation. At my previous company, the implementation started pretty early on. This resulted in challenges after the sale. The implementation was not done correctly and didn't fit the business requirements. It was a developer going in blind on what the implementation should result in. Of course, this example refers to a very technical solution but I think the same still applied regardless of the product line. Without onboarding, how do you know if the customer is using your product as expected? 

To solve for this, we brought CSMs into the process earlier on and created implementation guides that matched how most customers used us successfully to prevent this 'blind development' issue. This resulted in fewer gaps during the customer's early lifecycle with us.

------------------------------
Tiffany Morin
------------------------------
-------------------------------------------
Original Message:
Sent: 08-18-2020 12:04
From: Benedict Fritz
Subject: Onboarding vs. Implementation - reflecting the difference in process?

Hey all!

@Jeff Breunsbach made a recent post on onboarding vs implementation on LinkedIn that lead to a fascinating discussion thread.





After reading all of the comments I feel like I got a great high-level view of how different teams approach onboarding vs implementation. But I'd love to get tactical, so I'm curious:

How is the difference between onboarding and implementation reflected in your teams' processes?







------------------------------
Benedict Fritz
Building the high-touch onboarding tool at https://arrows.to
------------------------------

As many have pointed out, there are many factors that determine what type of team is needed. The stage that the Product you are selling will most likely determine the level of resources needed (in addition to the factors mentioned above regarding pre-sales and customer lifecycle mapping). Enterprise software will typically require a higher skill set of Project Manager, as well as possible Solution Architects, developers, etc. This is usually due to integration work. 

The person that is responsible for overall customer success and renewal should not be the resource that is project managing these (sometimes) complex waters. The CSM should be focused on the relationship and account strategy. 

A few months ago I did a little writeup for startup founders here -- https://www.jeffkushmerek.com/blog/the-natural-evolution-of-saas-onboarding

and would love feedback. 

Jeff

I personally agree with @Jarren Pinchuck's on the point that "implementation is a phase of onboarding".  Having experienced a fair share of escalations and botched launches over the years, I now consider onboarding to be the entire suite of operations that allows customers to go live and accomplish the most critical/time-sensitive jobs they have hired your product to perform. This often involves a fair deal of change management which I would not lump in with "implementation". When executed intentionally, onboarding should be a cross-functional, strategic motion whose foundation is laid during the pre-sales process to ensure there is a strong, well communicated, and validated launch plan or "success plan" with the right actors interfacing on both sides (including executives). Without setting proper expectations, involving appropriate stakeholders (internally and on the prospect/customer side), creating effective enablement content, and selling the customer the right professional services support, you risk subjecting your customers and CSMs to onboarding hell. We've all been there. How many customers have failed to launch at their first renewal anniversary? More than most companies would like to admit. While the conventional CS wisdom is to focus on the first 90 days of the customer journey, I would argue that onboarding motions should "start" from T-30 or T-15 prior to contracts being signed to facilitate seamless handoffs and triggered outreach. Marketing, product, sales, finance, and CS should each have a seat at the onboarding strategy table to align on product plays, messaging, pricing, support structure, training, etc. Onboarding needs to go beyond simple configuration/technical support and consider the full customer experience.

Incredible, thank you Markus! Really appreciate the detail you dug into here-exactly the sort of thing I'm curious about!

I really like how you break out the strategy component. It's easy to get caught up in the day-to-day and miss that higher level view.

And thank you for sharing those specific steps! Been looking for examples on how people explicitly iterate on a success/strategy plan throughout a lifecycle ?

I agree with what Jarren said in his summarization of what Jeff was talking about, "you can easily get lost in the implementation phase but forget that you're onboarding people, which takes a different skill."

However, it depends on the complexity of your software on if it should be 2 separate phases or teams.

We use Strategic planning sessions for our clients. This is done throughout all the lifecycle phases (onboarding, adoption, renewal etc) but we have certain goals for what the clients tool usage should be at each phase. This allows us to internally figure out which stage the user is in but the client is getting what Jeff says "a tailored strategy" to help them find success with your software.

Here is the template we use for our Strategic Planning Sessions;

• Review Results
• Heres the impact of what we have done so far
• Review Recommendations bringing to table now
• idea/discussion level
• The WHAT not HOW "ex keyword analysis; moving keywords into top 10 or creating new content"
• Agree on goals for next call
• The how the user achieves their goal with your software
  

In the Agree on goals stage we can use this to recommend the user making integrations that are crucial for success. So long story short we blend Implementation and Onboarding into one but we do so by making the Onboarding strategic and only make Implementation recommendations when it aligns with the strategic direction of the customer.

 

This is partly broken out by which level the customer is and the level of engagement we will provide.
Our mid-market team, the CSM's handle the majority of onboarding and implementation themselves (after gaining insights from the AE, SE's and customers on their criteria).  For some very technical aspects, the CSE may get involved to help.
For our Enterprise to Strategic CSM's, they work with SE's & CSE's and the customer to create what is called an onboarding plan which is a combination of BVA and Onboarding plan that lays out the implementation roadmap.  The CSM and CSE will then divide the appropriate tasks with the stakeholders at the company.  The challenge when building out what is essentially a project plan is that if you onboard too early, you might lose them when they cannot act due to delays in implementation.  However, waiting to onboard can cause a loss of engagement.
The SMB market is all self-service via doc's, videos, webinar trainings and our support team.

Thanks @Markus S! Agreed, onboarding is huge!

Do you split out the technical implementation requirements/steps/progress of the onboarding at all? Or is everyone who is part of the onboarding (CSM, customer, implementation engineer/specialist, stakeholders, etc.) fully involved with every step of the implementation?

Love this summation @Jarren Pinchuck, you nailed it!

Maybe I'm getting too in the weeds, but does your team explicitly separate the technical work from the higher level onboarding work when engineers or solutions architects are brought in so everyone doesn't get overwhelmed by the technical details?

Basically, how do you avoid getting "lost" in the implementation phase?

Well said @Markus S

@Benedict Fritz I agree with @Jarren Pinchuck .  For the companies I have worked at in SaaS, Onboarding also includes implementation. 
One way to think of it is can you onboard someone into a platform they cannot use if the software/service has not been implemented. 
We tiered the customer lifecycle into

• Onboarding/Implementation
• Adoption
• Expansion
• SteadyState
• Renewal

With most software solutions, the greatest potential for churn is if a solution is not implemented, which is why we made it a higher priority to focus on onboarding & implementation.

Hey @Benedict Fritz, this may be oversimplifying but I'd say that implementation is a "phase" of onboarding.
Onboarding, for me and my teams, starts from when the customer is handed over from sales and we'd a consider a customer "onboarded" based a certain set of criteria specific to our product and customers.
Implementation of our platform or product into their business is just part of that onboarding process. It is most probably the biggest part and often the most complex but it is still a piece of the bigger pie.

Then, not too dissimilar from what Jeff says in his post, you can focus on implementation as a specific, "technical" part of the onboarding process. In some cases, an implementation may require engineers or solution architects that would work alongside the CSMs. 

The key take-away and what I think Jeff was getting at was that you can easily get lost in the implementation phase but forget that you're onboarding people, which takes a different skill.

Thanks Kevin! This is totally the kind of experience I'm curious about. Agreed that the lines and responsibilities are often totally blurry.

Perhaps it's helpful to think of "onboarding" and "implementation" as terms that point in specific directions (onboarding => human, implementation => technical), while recognizing that it won't be possible to pull them clearnly apart in many specific cases ?

Sadly, I can't say it has made a difference with us at RingCentral, but it is definitely worth exploring. We conduct our onboarding and implementation simultaneously so the lines are very blurred. It also doesn't help to differentiate when your implementation manager is responsible for onboarding as well.