Top 5 Onboarding Do’s

I’ve been involved in a few sales cycles over the course of my career. And if I ask those involved what is the key moment in the cycle, I get answers like the demo, the pricing, the contract signing, etc. I’m not here to debate or argue that those are important but I think there is something equally or even more important than any of those answers, and much of the time, people don’t even consider it part of the cycle.

You already know what it is since it’s in the headline of this post. Yes, I believe that onboarding or implementation of the product or service is absolutely the most important piece. I won’t get into that, maybe that will be another article. Today what I want to talk about are some of the key do’s of onboarding. If you are an onboarding organization, you definitely need to be doing these things. If you are a customer in the middle of a sales cycle or even in the onboarding phase, you should expect your partner to do these things.

Number One: Having the Right Objective

For this one, I’m not talking about taking what the customer tells you is their objective. Things like I want to start using the platform as quickly as possible, or I need to solve problem x.

Those things all feed in but are not the real thing. I’m also not talking about things like needing to get the customers doing their first live transaction in x amount of time or other KPI’s your organization most likely has. Again, those things are important and factor in but are not THE thing.

What is the thing: you need to ensure that the customer gets the right balance of value and speed. Now you probably think that is either too simple or you have no idea what it means. So let’s talk about that.

Most customers want to move as quickly as possible. Those same customers also want to get the maximum value out of their investment. Unfortunately those things generally don’t play nice with each other. The sweet spot is generally a unique balance between the two. It’s unique in the sense that most customers are going to have circumstances that must be taken into account in order to dial it in perfectly.

How Do You Figure Out the Sweet Spot

You have to ask. And generally that’s going to mean more than just asking what the goal or timeline is. I remember a first onboarding call for a client, that was one of the earliest questions asked. We didn’t even do introductions but for sure we were asked when we wanted to go live. That’s not how you kick off the most important part of the cycle.

This is going to tie into the other do’s, especially numbers two and three, but in order to ask effective questions, you need to have a good understanding of your customers. Most onboarding projects don’t have the time or bandwidth to do a full deep dive into the clients business, and I’m not sure that is even worth it, but you need to know things like why they are purchasing the product or service, how do they hope this will improve their business or lives. What is their experience level with the product or even similar products (the difference between transitioning from one system to another versus and initial implementation). Who are the key players in the project. I could go on but I think you get the idea and your list of questions may vary from client to client.

If you are a good partner with sales (also a topic for another post), then hopefully you will have some of this information before your first meeting with the client. If so, then you can repeat back to the customer your current understanding and let them provide correction and additional context.

Once you believe you have dialed in the sweet spot, talk the customer through it. Help them understand why you believe the timeline vs. value add is balanced out and what the impact of adjusting either is. Finally, help them understand that if maybe the value add isn’t perfect, how you will continue to work with them to get it where it needs to go.

Number Two: Know Your Customers Business

In order to figure out the sweet spot, you must pay the price to know your customer’s business. Too many onboarding organizations have a process that they believe all of their customers will just fit nicely into. I’ve found that a large portion can fit into a fairly standard onboarding process but there are many (and normally they are the larger and more profitable accounts) that just won’t match up well to a standard onboarding process. If you start off by NOT making the assumption that your customer will be perfect for your standard process, then you will have a more open mind to accommodating their needs.

I am not saying that you shouldn’t have an onboarding playbook or that you throw it out just because a customer might be a bit different. If you have a solid onboarding playbook, odds are you have all the pieces you need to accommodate your customers. The art to this is to identify the nuances of your customers business and then to adapt those portions of the playbook to accommodate those nuances.

Some simple examples might be the idea of pushing changes from a test environment into production. Because of the ease of doing this in your platform, you know that under most circumstances you can simply push the changes to production after testing is complete. If you are working with a large enterprise customer, that process may not be sufficient. They may have an internal change control process that needs to be accommodated. Another example may be a companies need to have IT manage all user accounts and privileges vs. your typical process of having the operational manager handle this task.

While these are simple examples, this also needs to be considered for all major areas of your implementation process. If you are a leader in this space, you also need to take this into account when developing playbooks and the KPI’s by which your onboarding teams will be measured. If your KPI’s assume 100% customer compliance then you are putting your team in a no-win situation. I have had teams in the past that had a KPI to kick off all projects in 14 amount of days from contract execution. This would drive me crazy because a very large portion, if not the majority of our customers, would be ready to have an effective kickoff in that timeframe. So what happened was we had a “kick off” just to say we had one and then the project sat idle for weeks or months.

Leaders and managers: don’t develop KPI’s that incent your team to do what is not in the best interest of the client.

Number Three: Know Enough about Your Customers Level of Expertise

This is another one that you will want to get right in order to find that sweet spot between value and speed. This one is about understanding where your customer is in relation to the level of knowledge of the product, industry, customer demand etc. and understanding if the customer knows what they really want and need. Let’s break this down.

First is getting to know each member of the customers team. I’m talking about knowing what their area of expertise is, what they are bringing to the table and where they may have knowledge gaps.

The second aspect is to figure out if your customer knows what they really want or need, thinks they know or has no clue. That last one might sound funny. What kind of a customer would sign a contract for a product not knowing exactly how they wanted or needed to use it. Well, it happens a lot. I know during the pandemic, companies were signing contracts for esign platforms because they needed some way to get documents signed without being in person. But they really didn’t know how to use it, what challenges they would face or what kinds of processes they would need to put in place.

Sometimes you get a customer that this is their first attempt at using this type of a product. Think about a customer that has been doing all of their accounting a spreadsheet and makes their first purchase of a SaaS accounting program. They know that they need it to manage their finances and generate reports and stuff like that, but they may not really understand all that they could do with the product. And they may not need it all right up front.

My recommendation is that you use probing questions to determine your customers level of expertise related to the product, their own processes, what their goals and objectives are both in the short and the long term and then incorporate all of that into your plan. You will use that to determine just how much education should be done up front and then also to decide if you are going to be a full consultant or just a guide in the implementation journey.

Think about it this way: you know the product, they should know their processes and in order to be successful, your job is to blend those two together.

Number Four: Be Deliberate and Detail Oriented

This one should be self explanatory and I’ve already talked about it just a bit. You should assume that no detail is too small to pay attention to. When your customer is educating you on their processes and needs, don’t be afraid to pause and ask for clarification, even on the small things, especially if they are in a type of business you are not that familiar with. If they are the experts in their field, you want to take advantage of that expertise but also be aware that they may skip steps or key bits of information just because they assume you already know it.

This is also true in the reverse. When you are educating them on the product, make sure you cover the important details and don’t just assume they already know what you do. Odds are at least someone on the team does not.

Be deliberate about your approach. I already talked about adapting your playbook as needed. That’s the best way to be deliberate. Make sure each step you or the team is taking has a purpose and will help you to move forward. Make sure your education approach and your probing questions lead in the right direction. If you can’t find a purpose for something you are doing, maybe you shouldn’t be doing it.

Number Five: Experiment and Push the Platform

This one is possibly my favorite but it is also the one that is most difficult to manage. I am an advocate of trying to push the platform to do things that maybe it wasn’t intended to do. Long gone are the days when a customer asks me if they can do something and I think of the product page or internal documentation and say yes or no. I suggest that you develop the skill of taking a minute or even a few days if necessary to figure out if something is possible before telling a customer no.

Now, some things are very clearly a no, but not as many as you would think. Sometimes a creative use of the platform will become the next set of a requirements for the dev team. Sometimes the creative use won’t work for your clients purpose. Or maybe it will work in the short term while the dev team works on that one thing that will move this from a work around in the system to a standard feature or process. But if you are always saying no and not experimenting with the platform, you will never know.

There are limits to this and if you are an onboarder, then you need to figure out how to work within those limits. The last thing you want to do is have a customer start using this new cool thing you discovered or created only to have it crash the system for all users. So this is something you have to work at. If you are leading an onboarding organization, I encourage you to develop this in your team and help them understand the parameters in which they can experiment and push the system. Make sure they have a staging or testing environment where they can go in an play with things without bringing the whole system down. This also implies that you give them time to do this. Tying back into KPI’s give them the flexibility to not have to account for or bill every single moment of their time. Allow them to be curious and it will make a difference.

Wrap Up

Curiosity is where I’d like to end this post. One of the skills that I value most for members of my onboarding teams is curiosity. If you think back to the 5 do’s here, all of them are made possible or easier if those working through them are curious. Are they so curious about the platform that they know tips and tricks that aren’t documented anywhere? Have they come up with ways to use the platform that makes the dev and product teams scratch their head? Are they coming to you and explaining logically and passionately why they need to change the playbook for this one customer or that they are going to miss a KPI and why that’s a good thing? When you ask them about their customers, can the talk about the customer team as a whole but also about the contributions each individual is making and how they are blending all participants knowledge for the best outcome?

If you have a team of folks that do most or all of these things, then that to me will be a high performing team that will drive the success of the organization. If your team comes up short in these areas, you can help them by making sure your playbooks and metrics allow for curiosity and doing what is best for the customer.

Ultimately, the more we can find the right way to do what is best for the customer, the more successful they will be and as a result, our teams and organizations!