Welcome back to Part IX of the Customer Onboarding Tips series. In part VIII we spoke about peer pressure tactics to get customers moving, cut-over plans, and handoff calls.
In this instalment, we’ll be diving into change management, the waiter vs. doctor approach to onboarding, weekly showcases, and more.
As always, grab a notebook and refill your coffee mug because this edition going to get intense!
If you have a product that needs users to change how they do their work, you are expected to have a change management plan in place. We discussed the need for change management material in tip #31, but there's more to it if we want successful adoption.
This tip is something we learned recently from a session with Kathy at BombBomb. For BombBomb, adopting their product required customer-side users to master a new skill - creating video recordings of themselves. They needed to ease them into it with a plan centered around getting confident with the new skill.
This meant having a training program that included making multiple videos during this period. Only then do the users feel confident that they've picked up the new skill, and adoption succeeds. So they devised a program that included training sessions, and the trainees created videos as homework between the sessions.
Similarly, think about what other actions in your onboarding would need significant change on the customer side - and ensure they do those specific actions as part of the onboarding journey so that it becomes a habit or till they get comfortable with the new way of working!
The "Waiter vs. Doctor" is an interesting analogy to remember when you engage larger customers about your onboarding plan for them.
You can either present the options to the customer, make a recommendation, and let them make their choice - the waiter approach, or consider all their inputs and prescribe the approach to them - the doctor approach.
An acquaintance shared this with me last week, and it made a lot of sense.
When it comes to onboarding, smaller customers let you take the lead. But often, larger customers will have their own PMO and operations teams working with you and informing your approach to implementation, adoption, and roll-outs.
Herein lies the challenge. The project team and your champion on the customer side know their teams and internal challenges well. At the same time, you have the most experience implementing your product with customers of different sizes and types. So how do you ensure the customer doesn't hijack your process, and at the same time, you are using their know-how well?
We believe that a well-informed prescriptive approach is best suited for customer onboarding projects since you are the expert in your product and implementation. At the same time, you need to consider the additional risks, challenges, and context of the customer being shared by the insiders.
Here's what makes your team most qualified to decide on your process:
It would help if you got your team ready to challenge the customer when they propose alternative ways to implement your plan or any individual steps.
Going with the customers' wisdom and trusting in their ability to drive things in their team may seem tempting, but it is more likely to lead to surprises for both sides. Instead, consider their inputs, but you chart out and own the final plan.
This week's idea is something I saw in use in one of our onboarding projects just a few weeks ago. It's an agile practice that you can borrow for complex, time-critical projects, especially when a large team is involved in your implementation and setup. This tip may be evident to the agile practitioner or folks in project management, but not so much for people from customer success, support, sales, or engineering roles, who are running customer onboarding projects.
One of the common issues we run into when executing on larger/complex implementations with multiple teams and team members is that a lot of work gets 80-90% done and remains in that state, causing delays closer to launch. Things get marked as done or pending review, but the work is in the "Draft 1.0" stage, and the reviews don't happen promptly either.
Even worse, the team marks it as done, believe it is done and doesn't have anyone review and point out the pending work.
So how can we solve this?
One method I've seen work well is a "Sprint Review"-style demo to the steering committee or leadership at the end of every week or every two weeks to showcase the work done. Even when the onboarding project is waterfall-style, this helps in many ways:
Most implementation efforts need validation and acceptance from the customer on how you've configured the product, data migration, how the integrations work, etc.
UAT is important as you don't want any surprises after go-live. It allows the customer to go through how the product and integrations are set up and provides an opportunity to make modifications before a full roll-out.
This tip is about what you can do to plan and smoothen this part of your onboarding journey.
Here are some recommendations based on what we've seen some of our customers do to help make UAT and validation easy and fast:
Do you have anything else you do around customer-side testing and validation that helps you keep your onboarding smooth and on track? Do let us know at firstname.lastname@example.org.
By now, many CS leaders acknowledge that happy or unhappy customers are often made from their experience during the first partnership with your team - the onboarding or implementation journey. Those who go through a fast and successful onboarding have much more trust in the partnership, while those who experience a sloppy journey have buyer's remorse and may churn at the first opportunity.
So why not measure the success of your onboarding by counting the number of advocates you create during onboarding? Peter called it PSQAs - Professional Services Qualified Advocates. But for smaller teams, we can think of it as OQAs or Onboarding Qualified Advocates.
So let's hold our customer onboarding teams accountable for creating more of these advocates during the early journey. Measure and reward your CS and Onboarding teams based on the number of OQAs they create.
This can mean an excellent opportunity to create early wins like:
Did you find this series of tips insightful or enjoyable to read? Have any thoughts or inputs to share? Do tell us at email@example.com!
See you all soon with the next edition.