Verify 8 customer health score items in 4 tools

This guide walks through eight specific configuration items to verify across four platforms. The items include weight configuration, data source validation, display column setup, default scorecard selection, property mapping, segment logic checks, historical data review, and automation trigger review. Each platform handles these elements differently, so a unified checklist helps you confirm your setup before launch.

Start by identifying which tool you are using and locate its specific configuration area. For example, some platforms require manual property mapping to calculate scores, while others use automated triggers. Your goal is to ensure that the weights sum correctly and that the data sources are valid.

As you work through each item, note any discrepancies between your current setup and the recommended logic. This prevents issues where scores display incorrectly or automation fails to trigger. The following sections break down each of the eight items in detail, providing the specific steps needed to verify your configuration.

• Gainsight requires selecting the "Make this scorecard the default scorecard" checkbox to set a specific scorecard as the default, as noted in the Gainsight documentation.
• In Gainsight, once a measure's validity period has passed, the system displays a stale score rather than updating the value, according to Gainsight.
• Vitally allows users to set weights for all health scores by clicking on the value for the corresponding column, as described in the Vitally help center.
• Vitally provides a dedicated column for each individual health score you create, plus a separate column for the overall health of the account, according to Vitally.
• Gainsight directs users to the "Measure Weights in Scorecards" article for detailed instructions on configuring weights, as stated by Gainsight.

The following table lists four core configuration items that require immediate verification across your platforms. Each row identifies a specific setup task and the publisher that documents that behavior, allowing you to cross-reference your current settings against the source documentation.

Verify that the weight settings in your Vitally instance are accessible by clicking the column values, as Vitally documents this interaction for setting weights. In Gainsight, confirm that your measures have not exceeded their validity periods, since Gainsight states that measures display a stale score once this period passes. For Planhat users, check that your Success Units are configured to appear in Data Tables and Grouped Lists if you intend to compare multiple Companies at once, a capability described by Planhat. Finally, ensure that the checkbox to make a specific scorecard the default is selected in Gainsight, as this setting determines which scorecard is used by default according to Gainsight.

Open the health score configuration in your tool and review its weight and column settings.

Weight configuration and data validity are the two pillars that determine whether a health score reflects current account behavior or outdated metrics. In the Create Scorecards interface, Gainsight directs administrators to refer to the Measure Weights in Scorecards article to learn more about configuring weights.

For data source validation, Gainsight states that once the Validity period has passed, the measure displays a stale score. Once the validity period has passed, the measure displays a stale score. When you verify your configuration, check the validity period for each measure to ensure it aligns with your data refresh frequency. If the validity period is too short, measures may display stale scores prematurely; if too long, the score may not reflect recent activity.

In the Health scores section of its documentation, Vitally explains that clicking on the value for a specific column allows you to set weights for all your health scores. This suggests a centralized weight management interface where a single interaction can adjust weights across multiple score models. When setting up your weights, verify that the total percentage for each score model sums to 100% to avoid calculation errors.

Regarding data integrity, Vitally notes that accounts that repeatedly match and unmatch a Playbook can appear to lose their trait values, which in turn changes their health score. Review your Playbook logic for accounts that repeatedly match and unmatch a Playbook, because they can appear to lose their trait values.

To verify these settings, open your scorecard configuration in Gainsight and confirm that each measure has an appropriate validity period and that weights are set according to your strategic priorities. In Vitally, navigate to the health scores column and verify that weights are correctly assigned for each score model. Check your Playbook definitions to ensure that matching logic is robust against minor data changes. These steps ensure that your health scores remain accurate and reliable indicators of account health.

When you configure how health scores appear to your team, the column setup determines what information is visible at a glance. In upgraded Planhat, individual Success Units can be displayed as columns in Data Tables and Grouped Lists, which is super useful if you'd like to compare them for multiple Companies at once, according to Planhat. This specific display capability allows you to compare them for multiple Companies at once.

Success Units have some similarities with Health Scores, in that they are scores applied to Companies, and they typically have red/amber/green coloring, as noted by Planhat. Success Units typically have red, amber, and green coloring. Success Units are scores applied to Companies and can be displayed as columns in Data Tables and Grouped Lists.

In Vitally, the system provides columns for each health score you create, plus a column for the overall health of the account, reported by Vitally. This structure ensures that both specific component scores and the aggregate account health are visible in the same view.

When verifying your display configuration, check that the columns you intend to use are actually rendered in the Data Table or Grouped List view. For Planhat, confirm that the specific Success Units you want to compare are selected for display as columns. For Vitally, verify that each individual health score you have created appears as its own column alongside the overall health column. This verification step ensures that the data integrity of the display matches the underlying score definitions.

Property mapping connects raw data to actionable insights in your health score model. In HubSpot, the customer success team can use mapped properties to identify accounts that need immediate attention and prioritize outreach before issues escalate, as noted in the guide to Create a health score in the customer success workspace. This step ensures that the data points you select actually drive your prioritization logic.

For Gainsight, the process involves preparing the dataset from various standard and custom objects using the Rules Engine, followed by the Load to HubSpot Action to send the data to the Company and Contact objects in HubSpot, according to the Rules Engine Horizon Experience Overview. The workflow prepares the dataset from standard and custom objects, then uses the Load to HubSpot Action to send that data to Company and Contact objects.

Segment logic in Vitally determines how accounts are grouped for automated engagement. If your Playbook's conditions are the same—there's 1 Account rule and 1 User rule—Vitally needs to look at the Account and go, "Should we add this Account to this Segment?", as explained in the Automated Playbooks documentation. This logic check is critical for ensuring your segmentation matches your intended trigger conditions.

Consider a scenario where you want to auto-engage Accounts the moment all Users at the Account stop using your product for 7 days. In that case, targeting the Account is 100% the right way to go, according to Vitally. This example illustrates how segment logic must align with the granularity of your engagement rules.

To verify your configuration, check that each property maps to the correct object type in HubSpot and Gainsight. Ensure that your Vitally Playbook conditions correctly identify whether the trigger is Account-level or User-level. Misalignment here can lead to missed outreach or incorrect segment assignments.

Remember that property mapping is not a one-time task. As your data sources evolve, revisit these mappings to ensure they still reflect your current business logic. For HubSpot, confirm that the properties used for health score calculation are up-to-date. For Gainsight, verify that the Rules Engine prepares the dataset from standard and custom objects. For Vitally, test your Playbook conditions with real data to confirm that segments are populated as expected.

Verify that your automation triggers align with your data model before activating rules. In Planhat, manual triggers are defined at the data model level, so ensure your custom fields and objects support the specific trigger conditions you intend to use Planhat. This configuration requires checking that the underlying data structure matches the trigger logic to avoid execution errors.

For Gainsight, the Rules Engine serves as a one-stop location where admins can set up a rule with the preferred data setup, add criteria, and set up actions on the datasets and schedule rules based on time or event Gainsight. When configuring these rules, confirm that the scheduling logic—whether time-based or event-based—matches your operational cadence. Additionally, the Rules Details section enables admins to work with multiple data sets from multiple Objects, as well as process the data and perform actions Gainsight. Verify that each rule correctly references the intended objects and datasets to prevent unintended side effects on other account records.

Historical data review is critical for auditing how health scores have changed over time. In Vitally, to see what a trait was set to before an object exited, open its Customer 360 and click the clock icon beside the trait Vitally. This feature allows you to see what a trait was set to before an object exited. Use this history to validate that your segment logic and automation rules are updating traits as expected.

Recommendation: Cross-reference your automation schedules with your data refresh rates. Ensure that rules scheduled to run on a specific time or event have access to the most current data from the objects they reference. This prevents rules from acting on stale information.

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

What happens to a Gainsight measure score after its validity period passes?

According to Gainsight, once the Validity period has passed, the measure displays a stale score. This behavior is documented in the Create Scorecards guide. You should verify your validity periods during configuration to account for this display state.

How does Vitally handle health score changes when an account repeatedly matches and unmatches a Playbook?

As reported by Vitally, accounts that repeatedly match and unmatch a Playbook can appear to lose their trait values. This fluctuation in trait values in turn changes their health score. Monitor these accounts closely if you see unexpected score drops.

Where can you configure Health Scores in the upgraded version of Planhat?

The Planhat Help Center provides specific instructions for configuring health scores and success units in the upgraded version.

How can you view the history of a trait value in Vitally's Customer 360 profile?

To see what a trait was set to before an object exited, open its Customer 360 and click the clock icon beside the trait, according to Vitally. This feature allows you to review previous trait states.

What is the purpose of the 'Make this scorecard the default scorecard' checkbox in Gainsight?

Select the Make this scorecard the default scorecard checkbox to set this scorecard as the default Scorecard, according to Gainsight. This setting determines which scorecard is used by default. Confirm this selection during your final configuration review.

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.