Organizing Customer Success Data
Your customer success team is only as effective as the data underlying it. Without data, your team will struggle to grow and scale. If you are intending to create a lifecycle, tech touch, or scale program within your success org, your data will be integral to support the initiative.
When I joined Bazaarvoice, I didn’t have a framework for organizing and requesting the data I need most. Instead, I went down an iterative and explorative process of finding and then organizing the data I needed
Hopefully, this short post can help you save time by outlining the core customer data needed, how to think about external event data, and best practices for the key attributes needed for most flexible analysis and implementation.
The Customer Object
The main goal here is the build a unified customer object. On this object will be store the attributes that are most important to your customer success strategy. It will allow you the proper segmentation, lifecycle stage tracking, and reporting that you’ll need to first begin the process of customer tracking.
So begin to put down to paper the primary fields your customer object may have. Here are the ones I would recommend you start with.
- Customer Name
- Created Date (or original contract date)
- Renewal Date
- ARR or MRR
- Industry
- Status (active, churn, inactive)
- Stage (onboarding, adopting, etc.)
- Client Success Manager
- Region
- Current Score (ex. Health score)
- Tag
This list of fields will get you very far in having a full view of your customers. It will also provide you with numerous ways in which you can segment your customers, here’s a few use cases:
1. Customers by stage by health score
2. Customers by ARR by health score
3. Customer renewing in 90 days, by health score
This now allows you to understanding the risk, opportunity, and performance of customers across segments, lifecycle stages, ARR, and more.
Snapshotting
The next important aspect of this is to ensure the customer data you have stored here is “saved” aka “snapshotted”. As your customer information is updated periodically, you’ll lose the historical records for your customers. Adding a “snapshot” table will allow you to look back and view the trends across your customer base. You’ll thank me later when you want to review historical trends, such as:
- Is your ARR growing over time?
- Are your health scores improving over time?
- Are your customers progress through their stages over time, and improving the time spent in each stage?
Events Data
Now that you have your source record for your customer profile. You can now begin to build a roadmap for the events, activities, and other data sources that would contribute to a augment your customer profile and support your client success strategy.
While these are directly stored on your customer object, they should be tracked in separate tables and be available to complete joins. You can think about bucketing these in major areas:
- Usage: adoption and frequency of product usage here
- Engagement: how are customers engaging with you? Emails, Phone, Social, Web, product
- Sentiment: are customers completing surveys, or telling you how they feel?
- Support: CSAT and support frequency, escalations
- Financial: paid invoices, past due statuses, length of contract, etc.
Within each bucket you can begin to create specific measures that might make up each bucket. These are the events you want to start tracking. You might have this data today to best track, or you’ll need to partner with product or engineering to collect this over time. Once you have these tables, the sky is the limit as to how you want to slice the data to build triggers for your CSMs, reporting for Execs, or just raw data to inform strategy and health score creation.
Now you might have something like this:
There's a benefit from this organized approach. As you add more data sources or event inputs, the same logic applies. You can add more attributes to the customer object if the data proves important enough. Or you can keep sources separate and use SQL or joins for any analysis and reporting later on. The logic does not change as you expand your data inputs.
Business Logic
Once the foundational data is in place, you can then turn the customer success or business logic that powers your health score calculations, risk and growth triggers, and automated lifecycle sequences from your lifecycle team. It could look something like this:
