Health score scorecard: 7 steps to build it in Gainsight

Building a health score scorecard in Gainsight follows a specific sequence of seven actions. First, you choose the entity, either a Company or a Relationship, that the scorecard will track. Second, you create individual Measures to capture specific data points. Third, you group similar Measures into Measure Groups to organize the data logically. Fourth, you add these Measures and Measure Groups to the Scorecard itself. Fifth, you let the scores set automatically, as the system calculates the Scorecard score from the underlying Measures without manual input. Sixth, you assign one scorecard to the customer or Relationship, noting that while several can apply, only one is active at a time. Seventh, you check the feed limits and timing for the external data sources that populate your Measures.

According to Gainsight, a Scorecard is a collection of Measures and Measure Groups. This structure allows you to build a composite view of account health from distinct data streams. The score for this collection is not typed in by hand. According to Gainsight, a Scorecard's score is automatically set, based on the scores of the Measures, present in the Scorecard. This automatic calculation means you do not need to manually update an overall health number after each data refresh.

• Structure is modular: Each dimension in a Scorecard is known as a Measure, and you can create any number of them to represent different aspects of account health according to Gainsight.
• Grouping organizes data: You can group similar Measures to form a Measure Group, which helps structure the scorecard into logical categories according to Gainsight.
• Scoring is automatic: The Scorecard score comes from its Measures, and a Measure Group score comes from the Measures inside it, so there is no manual overall score to type in according to Gainsight.
• Assignment is exclusive: There can be multiple Scorecards applicable for a Customer or Relationship, but at any given point of time, you can assign only one scorecard to a customer or Relationship according to Gainsight.
• Entity flexibility: Scorecards can be created for a Company or Relationship entity, allowing you to tailor the health view to the specific account structure you manage according to Gainsight.

The first three steps establish the structural foundation for your health score before any data feeds are connected. You begin by selecting the entity type that the Scorecard will track. According to Gainsight, you can create Scorecards for a Company or Relationship entity. This choice determines the scope of the account data you will aggregate. Once the entity is selected, you move to creating the individual metrics that will serve as the dimensions of your score. The platform allows you to create any number of Measures or Measure Groups, and then add the required Measures and Measure Groups to your Scorecard, as stated by Gainsight. This flexibility means you are not limited to a fixed set of metrics; you can define as many distinct data points as your book of accounts requires.

When selecting which Measures to create, consider the specific signals that indicate account health in your context. The documentation notes that just like the Product usage metric example, you can set and view scores for other important Measures like Customer Support, Renewal Chances, Product Bugs, and so on, according to Gainsight. This indicates that the system supports a wide variety of metric types beyond simple product usage. For instance, if you are tracking support interactions, you might create Measures for ticket age or severity. A support Measure Group can contain Measures for ticket age and severity, according to Gainsight. This grouping mechanism allows you to organize related Measures into logical clusters.

Grouping Measures into Measure Groups is a critical step for organizing your scorecard. Instead of listing every single metric individually in the final score calculation, you can bundle related metrics. For example, the ‘Support group’ mentioned earlier would contain the specific ticket-related Measures. This structure helps in managing the complexity of the scorecard and allows for hierarchical scoring. You can create any number of these groups, providing the flexibility to structure your data however best fits your operational needs. The key is to ensure that each Measure you create is clearly defined and that the Measure Groups logically reflect the different aspects of customer health you are monitoring.

Once your Measures are grouped, the next phase is assembling them into a Scorecard and managing how that Scorecard applies to your accounts. In the Scorecards Overview documentation, the system calculates the Measure Group score automatically based on the scores of the Measures present in that Measure Group, according to Gainsight. This means you do not manually type an overall score for the group; the platform derives it from the underlying components. You add your defined Measures and Measure Groups to the Scorecard structure, and the individual scores roll up into the group score without manual intervention.

When you have different needs for different segments of your book, you can maintain multiple Scorecards, according to Gainsight. This allows you to create distinct scorecard configurations for various account types or business units. However, while you can build and maintain several Scorecards in your environment, only one can be assigned to a specific customer or Relationship at any given time. This single-assignment constraint ensures that each account has a clear, primary health indicator rather than conflicting scores from multiple active scorecards.

To execute this, you first add your Measures to the Scorecard. Then, you allow the automatic scoring process to populate the Measure Group scores based on the Measures inside them. Finally, you assign the specific Scorecard to the target Company or Relationship entity. If you later need to switch to a different scorecard configuration for that account, you must assign the new one, which replaces the previous assignment. The documentation does not specify a manual override for the automatic score calculation; the score is set based on the Measures present.

Action step: Identify which of your existing Scorecards will be the primary one for your largest accounts and assign it to those entities.

Once your Measures are defined, you must connect them to the data sources that actually generate the values. Each source has specific technical constraints that determine how much data you can pull and how often you can refresh it. Understanding these limits helps you set realistic expectations for how current your health scores will be.

Support data from Zendesk When pulling ticket data to feed a support-related Measure, the API has hard caps on volume and frequency. The Tickets endpoint in the Zendesk Developer Docs will return up to 100 ticket records in a single response, according to Zendesk. If your account has more than 100 tickets, you will need to handle pagination to retrieve the full set. Additionally, you can make 10 requests every 1 minute using this endpoint, according to Zendesk. Support-feed refresh frequency depends on how many requests each refresh requires. For incremental updates, the Incremental Exports endpoint returns tickets that changed within a specific time window, such as "Here are the tickets that changed since noon up until, and including, 5pm," according to Zendesk. This allows you to pull only new or changed tickets rather than the entire history.

Usage data from Mixpanel If you are using Mixpanel to track product usage, there is a strict cutoff for event age. Events older than 5 days will not be ingested, according to Mixpanel. This means if a user performs an action and you try to send that event to Mixpanel more than 5 days later, it will be discarded. For a health score Measure that relies on recent activity, this 5-day window is the maximum delay you can tolerate between the user action and the data ingestion. If your integration pipeline has a lag longer than 5 days, your usage Measure will be missing data.

Billing data from Chargebee Billing signals depend on how your billing system handles failed payments. In a Chargebee dunning period example, the dunning is set for a total of 10 days, and frequency is set as "1,4,7,8 and 9 days," according to Chargebee. This means the invoice will be marked as "not paid" once the dunning attempts are exhausted and the subscription will be canceled, according to Chargebee. If your Chargebee setup uses this example configuration, account for its 10 days of dunning when interpreting payment status. The subscription remains active during this period, so a "failed payment" status in your billing system may not immediately trigger a churn event in your health score.

Billing data from Paddle Paddle has a different rule for when a payment is considered failed. A status is automatically set by Paddle when payment fails for an automatically-collected transaction, or when a manually-collected transaction (an invoice) isn't paid 24 hours after its due date, according to Paddle. This 24-hour window is much shorter than the 10-day dunning period in the Chargebee example.

The following table covers the entity-selection step and external-feed considerations, including vendor limits and billing behaviors.

This defines the scope for the first step of the scorecard build. For support data, according to Zendesk, one endpoint will return up to 100 tickets records. Additionally, the same documentation states that you can make 10 requests every 1 minute using that specific endpoint. These figures apply to the documented endpoint behavior, not necessarily to every Zendesk API surface or plan tier.

For usage data, according to Mixpanel, events older than 5 days will not be ingested. This cutoff limits event age at ingestion through the documented method.

Billing data sources have distinct documented behaviors. According to Chargebee, the documentation describes a specific dunning example where the dunning is set for a total of 10 days, with a frequency of "1,4,7,8 and 9 days". In this example, the invoice is marked as "not paid" once dunning attempts are exhausted, and the subscription is canceled. This is an example configuration, not a universal default for all Chargebee sites.

According to Paddle, the developer docs describe a different billing status trigger. Paddle automatically sets a status when payment fails for an automatically-collected transaction, or when a manually-collected transaction isn't paid 24 hours after its due date. This 24-hour window for manual invoices is a documented behavior for Paddle's subscription list API.

For each account in your book, maintain a simple record that lists one usage signal, one support signal, and one billing signal. Write each signal as a named Measure, noting the specific tool that supplies the data and any known lag or limit for that source. This practice keeps your scorecard grounded in verifiable inputs rather than vague impressions.

Gainsight documentation notes that you can set and view scores for various important Measures, including Customer Support, Renewal Chances, and Product Bugs, alongside product usage metrics according to Gainsight. When you document these signals, ensure the names match the Measures you create in the system. For the usage signal, record the specific event or metric from your product analytics tool. For the support signal, note the ticket type or volume metric from your help desk. For the billing signal, identify the specific status or payment event from your billing platform.

Primary next action: For your largest account, list one usage, one support and one billing signal, and write each as a named Measure with its source and the lag or limit that source has.

• Onboarding tools: compare 4 customer project plans
• Health score setup: 8 rules for weights and validity
• NPS survey configuration: 5 checks before launch

How do I build a health score scorecard?

Create Measures and group similar ones into Measure Groups, then add them to a Scorecard for a Company or Relationship entity. The Scorecard is a collection of these Measures and Measure Groups, and its score is automatically set based on the scores of the Measures present in it, according to Gainsight. You do not manually calculate the overall value; the system derives it from the underlying components.

Can one customer have more than one scorecard at a time?

Multiple Scorecards can be applicable for a Customer or Relationship, but you can assign only one scorecard to a customer or Relationship at any given point of time. This constraint applies to both entity types, as noted by Gainsight. You may create several options, but only one remains active for a specific account at a time.

Does the Scorecard score have to be set by hand?

No, the Scorecard's score is automatically set based on the scores of the Measures present in the Scorecard. There is no manual entry required for the final aggregate value, according to Gainsight. The system calculates the result from the individual Measure scores within the collection.

Does a Gainsight Scorecard cover a Relationship as well as a Company?

Yes, you can create Scorecards for a Company or Relationship entity. The documentation confirms that both entity types are supported for Scorecard creation, according to Gainsight. This allows you to structure health scoring for either level of your customer base.

How old can Mixpanel events be for a score feed?

For the documented Mixpanel ingestion method, events must be no more than 5 days old when ingested. This age cutoff applies to the data ingestion process, according to Mixpanel. Ensure your data pipeline respects this limit to maintain accurate feed timing.

This post is general operational information, not legal advice about notice periods or renewal clauses. It does not promise that any method keeps a customer. A review model checked the facts once, and that check can miss errors, so open the sources before you act.