How our customer 360 transformed customer success at RudderStack

Knowledge is power. In customer success, we always want to have a deep understanding of our accounts at the portfolio and individual account levels. The more we know about our accounts, the more effectively we can drive retention and expansion.

If you’re a CS leader today, a wealth of data about your customers is available to you, and it’s probably scattered across several different tools. Turning that data into knowledge that can help you and your team understand every account and plan smart actions accordingly isn’t easy. Without a customer 360, it requires tedious, manual work to find the data you need and pull it together into a useful view. Even if you manage to put together something useable, chances are there’s a big gap between the value you’re getting and what’s possible.

I say this as someone who’s been there before. I’ve led the customer success team here at RudderStack since May 2021. In the early days, I spent my time exporting CSVs from Salesforce into a Google Sheet and meeting with my account teams every month to go line by line through each account. I’m proud of what we accomplished even with this rudimentary approach, but I’m here to tell you, thankfully, it’s a far cry from where we are today.

In this piece, I’ll show you how we use our own product, RudderStack Profiles, to create a unified customer 360 table that now serves as the foundation of our customer success function. Our customer 360 enables me to quickly assess health at the portfolio level. It also makes it easy for me to dive in on an account-by-account basis. I can see how each customer uses the product, our commercials, and what it takes to support that customer. It also includes a product health Score that’s transformed how we approach our work.

Before we implemented a customer 360

At RudderStack, the customer data we use for customer success comes from many touchpoints. There’s behavioral data from customers visiting our website to check out new articles and docs (often, this is multiple people from the same account). These same customers are in Slack sending us tickets. Salesforce contains information on paid accounts. Health and sentiment data lives in Gainsight. Customer calls are stored in Gong. Plus, there’s the product usage data from our product database.

With this fragmented landscape, it used to take a lot of tool-hopping for me to understand what was happening with an account. Here’s a look into what I used to do:

1. Log in to Salesforce to look at usage and contracts
2. Log in to Foqal to look at tickets
3. Log in to the product admin dashboard to understand their technical setup
4. Log in to Snowflake/Tableau to review usage

Even with all that work, I still couldn’t see how many users are on an account, when they last logged in, how many Transformations (one of our stickiest and most valuable features) they’ve set up, and the list goes on.

In this previous life, I had no quick way to see who was a low-adoption customer. I couldn’t quickly zero in on accounts that were churn risks. The only way for me to turn our customer data into knowledge was by reviewing the data and processing it myself. This wasn’t efficient or shareable, and it certainly wasn’t scalable. To say I’m glad those days are in the rearview is an understatement. Today, our team is more efficient and more effective than ever, thanks to our customer 360.

After we implemented a customer 360 with RudderStack Profiles

With RudderStack Profiles, I can now combine all of our customer success-relevant data into one unified table within Snowflake. We then use a tool called Superblocks (a simple BI tool like Tableau, which would also work) that sits on top of Snowflake to visualize the data in both a table format with nice color coding as well as building some really easy dashboards that I use to monitor our customers. Here’s what it looks like:

This rolled-up view of a customer starts to become a lot more compelling and insightful. I get a single view of how our customer is using the product, what our commercials are, and what it takes to support that customer. We didn’t initially have the product health metric – we developed that in the second iteration of the dashboard – but it’s been the game changer. Here’s how we created it.

Our secret sauce: The product health score

For product adoption, we brainstormed a variety of metrics that would indicate someone is getting use out of RudderStack. The score doesn’t just capture product usage. It shows a customer's overall engagement with us, including the breadth of their feature and product usage. We started by making a list of the questions we wanted to answer with the score:

1. Are customers getting what they paid for?
2. Are customers using things that tend to be sticky within our platform?
3. Are customers actively engaged with us?

To create the product health score, we came up with this initial list of input attributes and gave a value from 1-5 for each:

• Contract usage
• Pipelines enabled (yes/no)
• Number of tickets
• Number of sources
• Profiles enabled (yes/no)
• Number of transformations
• Destination categories/types (types of categories like CRM, Marketing, Product Analytics, etc.)
• Number of calls
• Unique logins
• Number of users in the workspace
• Number of destinations
• Tracking plan enabled (yes/no)

For example, if someone is below 40% contract utilization, that tends to be pretty risky for a churn or contraction, so we give them zero points. If they’re between 40-60%, they get two points, 60-80% is four points, and 80-100% is five points. For the binary attributes, we assign a zero or a five.

After that, we ascribed a weighting across all attributes to add to 100% of the score. It’s subjective, but it’s based on our first-hand experience working with customers and the behavior or usage we want to drive. Here’s what a score might look like for a customer:

I can look at this detailed score holistically for an account, but I can also quickly look at the entire portfolio of customers to zero in on low-scoring customers. We can quickly diagnose why a score is low, what we should focus on to build more engagement with a customer and look for positive signals that a customer may be retained.

In the case above, I can quickly see that:

• Usage is low, but they only kicked off with us three months ago (per the previous table).
• They are a large enterprise working with several cross-functional teams to get through initial setup.
• They’re only working on our primary product of Event Stream, so I can see that ETL and Reverse ETL are future expansion discussions we can have.
• We’ve had several calls in the last 30 days (four total).
• The total number of unique log-ins in the last 30 days (seven unique users) is solid.
• They have 27 total users attributed to their account.

After a quick look, I can tell they’re pretty solid overall, and I’m much less concerned about churn. I also know exactly what to discuss when they finalize onboarding.

This view immediately became a first stop for me and our CSMs and TAMs to prepare for a customer call, a QBR, or a renewal strategy. It enables us to quickly understand what a customer is doing, where we can push them to expand, and see flags of when to worry.

Creating customer success superpowers with our C360

Once we realized the power of what we had created, we began operationalizing the data. As I said above, I wanted this to be the foundation for how we ran the Customer Success function. Our team’s three primary goals are around:

• Time to go-live
• Customer health
• Tickets

It took several weeks of iteration to get the data exactly right, but now we have a view from our customer 360 that corresponds to each goal. Our whole team relies on these views to guide their work day-to-day, and I’m proud to say they really do form the bedrock of how I run our organization. Here’s a breakdown of each view with details on how we use it.

Onboarding and go-live

Looking at “Days to Go Live,” I have a quick view of the number of customers that are both in and out of the onboarding period. I can track our metric for a particular period of time, and when I look at “Details,” I can immediately see the customers that are outside of our onboarding period timeline, the ARR, and the account team.

In practice, I look at this and ping the CSM/TAM to ask what’s going on with the account. I have also started looking at any customer that is over the 45-day mark to make sure that customers are making progress and are engaged.

Onboarding is a critical part of the customer journey, and I can now intervene before things get out of control if I see any red flags.

Product adoption and usage

We’ve also added a rolled-up view of our product adoption metrics. These values help show the relative performance of accounts across our portfolio - the absolute score is less important. These values also reflect CS’s view of the world, and we’re indexing on a more conservative/pessimistic view than an impartial judge. Eventually, we’ll build in a historical view, but we’re still testing the weightings to see if anything needs to be adjusted.

One thing to note here is that RudderStack has gated products and features, which are significant portions of the score. For example, Reverse ETL as a product isn’t available to anyone in our Starter tier, so those customers will always get a 0 for that score. It’s a heavily weighted attribute for product adoption.

That means our Starter accounts will systematically score lower. I opted to keep this for now because having only one pipe does create more limited product stickiness, and I believe that’s important to note. Again, this scoring matrix may change as we learn more about what indicates adoption and stickiness.

Tickets

Finally, we also have a weekly view of our TAM ticket performance. I can look at the team collectively and immediately pull up individual TAM metrics.

Using this method, I can ensure that all TAMs have a relatively equal workload on number of tickets. I can also spot anyone with a spike in newly created tickets that may need additional support that week.

We sometimes have weeks where customers are making big sprints or are onboarding, so we can see big swings for a single person on the number of tickets coming in. I can also track tickets open longer than 30 days. Those are the ones that tend to be more complicated or have been escalated to our engineering team.

Our TAM Manager, Dave, will follow up with anyone who has a high number of tickets – or whose ticket load shows little to no change week over week – to understand if any issues need addressing. We also track engagement metrics. We want to see active conversations with customers on tickets, so we look at the total messages per day that a ticket has been open. We don’t want open tickets sitting and getting stale, so we encourage a note back to the customer, giving them a brief update that something is still being looked at. Slack is a channel that creates high expectations on frequency of communication, and we need to be able to adapt to that.

What’s next? Automation and scaling

Automation will be critical as our company grows and we continue to scale the CS function, and with Profiles there’s a whole new world of automation open to us! We’re excited to think about how creative applications of our Customer 360 will help us continue to deliver the same excellent customer experience while ensuring our team doesn’t have to grow linearly with our customer count. We’ve already removed much of the monitoring workload in identifying which accounts need extra attention to get in a better place. Now, we’re working on how to do that work proactively – we’re building triggers based on customer behaviors and creating content that we can proactively serve to engage customers. Here are the priority areas we’ve identified for customer 360-fueled automation:

• Internal reporting – Sending reports directly to internal slack channels for key accounts to give our C-level, account team, product, and engineering folks a holistic view of what the customer is doing, as well as serve as a quick reference for the CS team who may need to ping the customer.
• Low engagement – We know low engagement is a red flag. While some customers want us “just working” in the background, there’s no real way to tell if a customer is cool and wants us to leave them alone or if their low engagement is a negative signal. We already have a metric for this, but we want to trigger an automatic outreach message to the customer in Slack if they’ve had 0 Gong calls, 0 tickets, and 0 unique logins in the last 30 days.
• Renewal notifications – Our CSMs spend a significant amount of time reaching out to customers to notify them of an upcoming renewal. We are setting up an internal notification to ping a CSM directly 120 days from renewal to prompt them to reach out. Eventually, we’d like these notifications delivered to a Slack channel and emailed to the customer automatically.
• Transformation (or other feature) usage – Transformations is a helpful, sticky feature that customers love. However, because it has broad applications, it can be challenging to help customers understand the flexibility it can offer. So, for customers not using Transformations, we want to start proactively pushing content with use cases, how-to guides, and even quick Loom videos that showcase how they can set up and use Transformations.
• Customer turnover or new user – To make it easier for new users on an account to get up to speed and ensure our team supports smooth transitions when champions change, we’re setting up a proactive workflow based on signals from our customer 360 table. Whenever a new user is added to an account, we’ll send a welcome message with RudderStack 101 content and a few videos to help them get familiar with their company's implementation. To start, we’ll feed this trigger into the internal slack channel and have CSMs/TAMs manually reach out. Eventually, we’ll transition this all into the external shared Slack channel.
• Low contract utilization – Our commercial model is based on an annual contract with monthly data or event volume. Contract utilization percentage is a big indicator for us on whether or not a customer will churn, contract, renew, or expand. So, if a customer is below a certain threshold, we want to encourage more productive utilization. To facilitate this, we’re building content with our marketing team that our CSMs and TAMs can proactively share to get customers re-engaged with our product.
• Onboarding – As we grow, we’re working on a lower-touch model for onboarding Starter and Growth tier customers. We’ll still offer Slack support for those customers, but we want to develop self-guided onboarding assets to make it easier for customers to get started without heavy involvement from our team. We have monitoring tools in place so we can reach out to support customers who aren’t making progress, but by automatically sharing onboarding content in Slack channels on a timeline based on the contract signed date from Salesforce, we hope to save time for customers that don’t need as much assistance.

Conclusion

Our customer 360 table transformed the Customer Success function at RudderStack. Now, we can proactively provide our customers with better support. I no longer have to do the tedious work of manually pulling data just to get an idea of where we are with a particular account, and we’re able to more efficiently provide a level of service that wasn’t possible before. Our customer data is now knowledge, and it’s easy to share with our team and other stakeholders internally. If you’d like to learn more about creating a customer 360 with RudderStack, request a demo with our team today.

Even if you’re not quite ready to implement your own customer 360 – it took us two years to get here – it's helpful to start with an end in mind. Here are a few tips to help you at the beginning of your journey creating knowledge for your customer success function from your customer data:

• When selecting tools, consider who will have access to the tool and how many connections/integrations the tool has. You want to minimize data silos and make sure you can pull relevant data into your warehouse.
• Work with your product and engineering team to ensure you can track product usage data.
• Start moving today, but be willing to change direction. You’ll learn as you go, so create a culture on your team that is comfortable with pivoting. Have a process that works until it doesn’t.
• Be creative with what you want to measure, and make sure it’s attached to the behavior you really want to drive.

If you’re a customer success leader interested in more insights on effectively scaling your team, you can read my 12-part series on Building a CS Unicorn on Medium. I share the lessons I’ve learned about tooling, NPS scores, forecasting, hiring, ticketing and tracking, and, of course, more on data. I hope my experiences can help you avoid some of the challenges we’ve navigated and share in some of our successes. If you have any specific questions or want to connect, please reach out on Linkedin.