Improve Product Adoption on Low Usage Accounts
Previously: I covered how Deal Scores can help you predict who is going to be most successful with your product, and how to develop intervention strategies for low-fit customers.
TLDR: Focus on three key factors when creating strategies to help customers improve low product usage:
1. Make it Contractually Relevant: Focus on levers that are directly tied to your commercials/contract. Customers are anchored on price and line items. If this is out of line and difficult to do, re-evaluate your pricing strategy.
2. Make it Easy: People are busy and they’re already not using you. Don’t shoot yourself in the foot with some huge transformation project. Give them something they can do in a day. Make it easy to implement. And tell them it’s easy and that you’ll help them.
3. Make it Impactful: Tie it to the business or monetary impact this will deliver. Do the thinking for them and tell them why it’s important.
The Full Story
Low product usage is the devil’s speak on the CS team — that’s the last thing we want to hear. Especially when we know a renewal is coming up. If you’ve read my previous posts, you know that we have developed an innovative way of combining product usage, feature adoption, and engagement metrics to build a product adoption score for all of our customers.
The score is amazing, but the real work only begins once we get our short-list of customers to reach out to. I’ll walk through how we approach this at RudderStack and pull out commonalities for you to think about with your own product.
The first approach we took over the past year or so with customers was to talk to them about additional use cases — where else could they send the data within their company? Are there are functions or stakeholders that would benefit from having access to the data?
This approach was moderately successful. We were able to increase our stickiness within an account and become more multi-threaded. We had more business stakeholders like marketing and product using and consuming the data we provided, and were able to build relationships beyond the engineering team.
This is an incredibly valuable motion for us, and helps prove out the business value, but it didn’t directly address the commercial aspect of our contract.
Our billing is directly related to the event volume we ingest from sources — not the data exhaust going to destinations. That means if a customer had their marketing tools set up, and then added a CRM, warehouse, and product analytics tool, the event volume for the purpose of their contract would effectively stay the same.
Sometimes we’d see a nominal increase if there was 1 or 2 additional events needed for a specific destination, but that was pretty rare to see.
We then shifted our focus back to ways to increase ingestion. We realistically had 2 levers:
1. Increase the Number of Sources: If you only have your web app instrumented, add in your mobile app, or potentially add additional Cloud sources like ZenDesk, Salesforce, or Stripe.
2. Increase the events instrumented per source
Increasing Sources
Increasing the number of sources proved to be difficult. Many customers already had maxed out on their existing sources — they had web and mobile and weren’t going to use our ETL product.
In limited cases, we’ve been able to showcase to a customer why instrumenting their backend-server was valuable, and in even fewer we were able to showcase the value of ETL and get them to upgrade.
Adding ETL pipelines (sending cloud sources like ZenDesk and Stripe) are big step-function change in event volume though, and require heavy lift on the customer side to get things into production.
Getting a customer to commit here (if they weren’t planning to do it) proved to be more challenging because of the level of effort on the customer side. This needed to be part of a strategic, longer term roadmap they were committing to.
As a note, I’m specifically speaking about customers who weren’t planning on adding things in the future — we do have a large cohort of customers who are actively expanding with this motion as part of a longer internal transformation. The customers I’m speaking about generally purchased RudderStack for a single pain point which we solved, and things were “running in the background fine”. We needed to 1) build awareness of our other pipelines 2) identify the new source for them 3) convince them of the value and 4) get them to take action.
Increase Events
The other lever to increase usage is to make sure customers have all of the events on their website/app instrumented to drive business decisions.
For those not in the CDP or tech SaaS space — RudderStack basically lets you track user behavior on your website, and send that data to places like Snowflake, Facebook, Mixpanel, etc. An “event” is something like when a user clicks on a “Purchase” button to complete a transaction, or when they click to navigate to a new product page, or submit their information in a form to request a product demo or schedule and appointment.
There’s different ways you can track that, and you have to be very specific about WHICH actions you’re tracking what KIND of data you’re tracking on each of those events. For example, if someone is clicking on a new product, it could be helpful for a marketing team to know which product, where was the customer looking before that, what time did they look, how long did they spend on page, if they’re logged in, do we have their email, etc.
This kind of information is generally planned out in a tool called a Tracking Plan. A Tracking Plan is a best practice in this space, and done well, can be an amazing tool to manage your data in a very thoughtful way.
It can also be super annoying to deal with though — it’s usually done in a massive google sheet and you have to be extremely detailed with it. It’s basically how you can look at your user journey across your site, decide what you’re tracking and what attributes or properties to collect, and ensure it’s all tied to a downstream business case. It helps you make sure the data is actually getting used somewhere useful.
So, because of that, we often have customers who skip the tracking plan and just start instrumenting events they think are important. They want to start collecting data, and it can be more productive to just get going and then come back and fill in gaps later, or sort out your data in the warehouse retroactively. It’s a completely valid approach and helps people visualize data in the tools and then figure out what gaps they need to fill as they start using it. We actually did this with our own C360 table — we had an initial set of data, started using it to make decisions, and went back and added more data later.
These missing events are what we wanted to highlight to customers — it’s really valuable to give recommendations if they’re missing some basic events that help them accomplish a business goal. We also have general “best practice” templates on what customers should be tracking that are pretty universal — ecommerce companies, for example, have pretty standard data that should be tracked to understand the purchase funnel.
The first challenge we had was it was really difficult to see what a customer had on their website — we had to go into a dashboard and look at list of events, and you just had to know what standard events were and then look for something that could be missing. This isn’t scalable and leaves a lot of room for errors. You can’t do this unless you’ve looked at this a million times and are an expert in the standard tracking plan. Identifying “what’s missing” is incredibly difficult without a checklist to cross-reference.
To address this, one of our Technical Account Managers (TAM) built a browser extension tool so we could inspect a customers website. We all installed it on the CS team, and then you could go to a customers website and start to poke around as you navigated through the site. We’d write down anything obvious that was missing. The most common thing we saw was people didn’t have page calls and were missing really basic things like what customers are landing on their page.
We then put together some quick slides that highlighted 2 to 3 events we thought would be really impactful for them. And the most important part of it — we wrote down WHY it was valuable. What would they be able to understand or see with that data? With page calls, they’d be able to track upper funnel site visitors and understand where they were referred from. Super useful to marketing, right?
We tried to be really cognizant of not overwhelming customers with too much. Our customers are busy running the actual business, and often have other major projects they’re working on.
Our primary goal was to
- illustrate that there were gaps
- show these were really important business metrics and
- communicate thatit would actually be really quick to implement.
This was the most important part of what worked, so I’ll restate it: Find something with high value, but low lift.
It’s on you to tell the customer why it’s so valuable.
Quantify it if you can.
Explicitly write down the value or impact and who gets the value.
And then give really clear instructions on how to do it. Offer to be on calls and coach them through it. It’ll serve as an educational period and you need to capitalize on the fact that you have their attention.
We’ve only recently started doing this but so far, we’ve seen green shoots of customers getting re-engaged with us. They’re excited about the value and aren’t intimidated by the amount of work. Of course we have a backlog of events we can show them, but we need them to take the first step with a low hurdle to action.
Summary
To wrap this up, the most important thing for low usage customers is to make sure you’re focusing on vectors that are tied to your pricing model. Even if something is driving business value, customers anchor on your contract structure and pricing.
Next, find actions for your customers that are easy to do. They’ve already stopped using your product for a reason — don’t create even higher barriers for them.
And lastly, make sure it’s 100% clear on what this action is valuable to them. It either needs to save them time, or it needs to drive revenue. Do the thinking for them and connect the dots.
People are busy and they aren’t going to infer things to the 3rd and 4th order — just tell them.
Next Up: Product Enablement and a Culture of Learning on Customer Success
