In this episode of Implementation Stories, our guest, Apoorva S from Branch Metrics, shares how she designs customer onboarding journeys for different segments, including those converted from a POC stage.
Apoorva started her Customer Success journey in 2015 at Belong, an HR tech startup that followed a high-touch, one-to-many CS approach, focusing on customer education and adoption. During her next stint with Hortonworks (now a part of Cloudera), a big data firm, she worked with large enterprise accounts on a low-touch CS model closely aligned to Sales and Support. Since 2018, Apoorva has been working as a CSM with Branch Metrics, a deep-linking and attribution analytics startup. Her current role is a mix of sales, customer education, onboarding, and support.
Though Apoorva has been in CS roles for over six years, her roles have vastly differed in terms of scope. In this free-wheeling chat, she shared some of her experiences, challenges, and learnings from her Customer Success journey.
Note: We have edited the conversation for brevity and clarity
I've realized that customers who have already seen our product or used our dashboard do not need the conventional customer journey we have in mind for them. So I’ve learned to be more open to making changes to the ideal customer journey based on the customer’s experience with our product.
For example, instead of a dashboard walkthrough that I have on my implementation checklist, I may need a cheat sheet for customers already familiar with our dashboard.
There was a customer who had come to us after a POC. They’d told us that they had used our dashboard, that data integrations were up and running, and they already had live campaigns on our platform.
I saw that they were already deriving value and were set up to see success. So I went ahead and set up a cadence for our future catch-ups, assuming that they were good to go.
That was a mistake.
It turns out that their POC and technical implementation had been done a while ago, and as a result, they weren’t properly integrated with the current setup. I would have caught that if I had done a tech audit when they came to me.
Now, I perform a tech audit irrespective of the stage they are at—even if customers claim to be comfortable with the product.
Onboarding for the dashboard was mainly offline, with PS teams or big data teams managing it on site. CS would do dashboard training but was mostly looked to for support.
If the deal size is picked, we are involved in the pre-sales process.
In the case of POCs, there is a pre-sales engineer who leads the integration and the setup for the customer; CS doesn't get involved mainly due to bandwidth constraints, given that multiple POCs are in progress every quarter.
We get involved during the handoff from Sales to CS and lead customer onboarding from thereon.
For non-POC customers, we look at where the customer is currently. For instance, if they have used certain aspects, we skip those. Instead, we identify what touchpoints will bring them value and customize accordingly, making it an adaptive journey based on gauging the maturity of the customer.
We don’t have a playbook right now. It’s on Google Sheets and draft/canned emails.
We look at customers in three categories: those coming after a POC, those that have signed up fresh, and those switching over from a competitor. For the third category, we focus on differentiating our product from the competitor instead of focusing on customer education.
In my personal experience, one-to-many does not work for us—even for customers in non-competing spaces.
In our case, the pre-sales and post-sales approaches are very different, with pre-sale activities being number-driven—focused on the dollar difference, LTV, ROI calculations, etc.
At the CS stage, we find that every customer sees value in different aspects, so we tie the value back not to the dollar but to the various open projects. For instance, in our quarterly business reviews, we show our customers the new things they’ve been able to do using our product.
In the first meeting, we show them everything we have—the whole range of what they could accomplish with us. I do this for different buckets: engagement, improving UX, etc. At the end of this, we’ve seen that they can pinpoint two or three things that excite them.
Sometimes, customers pick up use cases/features/functions that don't necessarily make sense for them at their current stage. We push them to reconsider by asking many questions and digging deeper into the ‘why’. It helps to draw from our experiences with other customers while doing this.
At Branch, CS has become more focused on technical account management and implementation over pinning down ROI. We don't measure TTV. Our average implementation duration is ten business days or two weeks.
I've seen Trello boards work well for customers from SE Asia. What has not worked is using Google Sheets to assign tasks to customers. I guess that’s probably because a Trello board makes the process appear more collaborative, while Google Sheets could give the impression that we’re washing our hands off those tasks.
Qapita was using multiple tools for their customer onboarding projects. Switching to Rocketlane made their implementations efficient.
I think so. I have seen tech-savvy startups are more open to it. On the other hand, enterprises would rather get on a working session on Zoom or a phone call instead of filling up a Google Sheet.
Our product team has a three-page document that talks explicitly about the technical details of what does not work even before the paperwork is done. We ask our customers to sign off as an acknowledgment of this document.
We also have a team that approves deals after looking at their technical scope, so only after they approve the deal can the paperwork be closed.
We track the number of open implementations; since our product can be used to do multiple things, this is a good indication of complexity. We also look at projects that customers switch from another product as these can be more complex owing to data import needs, etc.
We started doing this recently based on how long the implementation took, how effective it was, etc. It is a good leading indicator, but we’ve found that customer sentiment often fluctuates based on factors sometimes outside our control in our sector. Tracking support tickets has been a better indicator of customer sentiment for us.
CSMs typically handle high-touch accounts. For example, engagement leaders use the community and academy.
Here are the key takeaways from our conversation with Apoorva and inputs from other participants:
1. During the sales process, provide technical documentation to the customer explaining what works and what doesn’t in your product. It is a good idea to obtain an acknowledgment of these terms and conditions before you begin onboarding and implementation.
2. Adapt your onboarding journey based on the maturity and the needs of the customer. Having a conversation with your customer will help you to gauge their maturity level. For instance, if the customer is familiar with your product or has worked on a POC with you, a regular product walkthrough may not be as helpful as a cheat sheet or FAQ.
3. Even for mature customers, it helps to perform a comprehensive audit for their technical implementation to make sure you don’t miss anything.
The difference in the onboarding journeys between a POC and a non-POC customer should depend on how familiar the POC has made them with the product. Identify touchpoints that can still create value for the customer and work them into your onboarding journey for them. E.g., for the attribution analytics product from Branch, “attribution fraud” is a topic around which conversations reveal the maturity of the customer.
4. During the initial conversation with your customer, explain your product and highlight some useful features/functionalities based on your experience with other customers. In cases where customers choose more complex use cases, probe deeper and ask questions to understand why they need those use cases. If the customer is switching from a competitor, focus on educating them on the differences between the products and explaining how they gain more value from you.
5. While using tools for accountability and updates, use tools that have a collaborative approach that shows who is responsible for which tasks, allows changes from both sides, and is easy to update. This helps retain (and build) customers’ confidence since such tools indicate to the customer that you, too, are committed to their work.
6. The metrics and factors below can help you understand the complexity of an implementation project:
7. Here are some factors that influence customer sentiment and can help with churn prediction:
8. Other best practices discussed:
If you found this useful, consider joining our private, invite-only Slack community and attend the next Implementation Stories session or just access more such resources. You will also gain access to peers and share knowledge on customer onboarding, implementation, and customer success.