Gainsight Administration

Gainsight overview

Gainsight is a customer success software that our Customer Success Managers (CSMs) and Enterprise Sales team use in order to support our customers and manage their workflows. This page shows the data structure, integrations, and other technical information about how GitLab uses Gainsight. Gainsight is owned by CS Operations, and Sales Operations and Sales Systems play very active and important roles in its continual expansion and improvement.

Gainsight support

All teams should use the #gainsight-users Slack Channel for questions or issues with Gainsight for quick attention. Customer Success Operations provides support for all Customer Success teams.

Guidelines for CSOps teams assisting in addressing questions/concerns on the `#gainsight-users’ channel

• For general Gainsight questions, start by exploring in system to see if you can find an obvious reason; some exaples include: simple setup questions, adding a filter or column to a report, straightforward reasons for a rule failing, etc.
• For product usage reporting questions, loop in the SME who can usually support/address the concerns directly; the product usage reporting SME can decide if / when to loop in other team member as needed. SME: @nk312
• For questions about Digital Customer Programs, please reach out to the SMEs: @mharris3 and @jgamboa;
• For questions about Scale programs, process, operations, please reach out to Scale SME: @rgorbanescu

What items can be handled via channel vs. an issue

• Any questions that will take minimal amount of time to sort out (15-30 min) can be handled directly via the channel
• If troubleshooting time piles up, ask to have an issue created
• If the ask if for an enhancement, ie new process, changes to existing ones, feature request, etc - ask to have an issue created

For Sales teams, we use this escalation path:

1. Login problems (Tier 1 support) = Sales Ops
2. If Sales Ops diagnoses the issue to be more significant than login problems (Tier 2)
   • Updates to permissions/access bundles = CS Ops
   • Issues with rules, connectors, etc. that are not sales-specific = CS Ops
     • Example: issue with contact loading in SFDC
   • Issues with rules, connectors, etc. that are sales-specific
     • Example: processes that support account planning
     • Issue diagnosis and requirements collection = Sales Ops
     • Fixing issue = CS Ops

Important old issues with resolutions

• Duplicate records in Instance Data table
• Snowflake > Gainsight connector - known data issues

Account Classification Fields (FY24)

With some changes made in FY24, some fields used in Gainsight for account classification purposes have shifted. In order to align more with the Sales org, the same fields with the same naming conventions that are used in Salesforce are now being used in Gainsight.

Fields no longer used in Gainsight

Fields Used Now in Gainsight

Gainsight User Provisioning

See Gainsight User Administration.

Gainsight data structure

Gainsight uses a series of standard and custom objects. Some objects/data closely mirrors others systems (such as Salesforce) while other objects are unique to Gainsight.

Hierarchy

We use the account structure in Gainsight for hierarchy. There are also subscriptions under accounts.

Standard objects

These are some notable standard/system objects in Gainsight:

Custom objects

These are some notable custom objects that we have created in Gainsight:

Data designer objects

• Issue #276: GS Documentation - Review Data Designer designs and add descriptions
• Defined in Google doc: Gainsight Data Dictionary

Gainsight connectors and integrations

The Gainsight connectors are the main way we pull data from other systems into Gainsight. We have connectors set up for the following external systems:

• Zendesk
• Snowflake
• Salesforce

Zendesk connector

The Zendesk connector has one active job: Zendesk Sync - Tickets. This maps to the Zendesk Tickets V2 custom object and runs daily.

Zendesk objects used in Connector job to load data to Zendesk Ticket V2 MDA object:

• Organizations
  • Contains general information about the organization/customer related to the ticket.
• Tickets
  • Contains data on specifics related to individual Zendesk tickets.
  • Updated_at field is used as the indicator for the timestamp of date closed or last modified.
• Users
  • User object contains data on both internal (GitLab agents) as well as external requester data (who submitted the ticket.)
• Closed Date
  • Zendesk does not provide a field for the closed date of the ticket. Instead, use Updated_at with a filter for ticket status == closed. This is based on the assumption that the last update on a ticket is its closure.

Snowflake connector

More details in the Product Usage Data section.

At the time of writing, the Snowflake connector is only available to use in the Data Designer and in Adoption Explorer. You cannot see the jobs from the Connector 2.0 interface in Gainsight.

We are only using this in Data Designer. We pull product usage data from Snowflake in the MonthlyMart SelfManaged Usage Data object.

Username and password are saved in Jeff Beaumont’s 1Password account. If you need to reset permissions, please ask him.

Salesforce Connector

Connectors is used as one of the main import methods of data from Salesforce to Gainsight, and is a native integration that exists between the two systems. The connector is authenticated using a Gainsight Integration user in our Salesforce instance. More information in regards to the connector and how to set it up in the Gainsight Knowledge Base.

Connectors is used between our Salesforce and Gainsight instances to sync these objects:

Note: The Upsert key for contacts is their email address. This is useful when it comes to the bi-directional sync of contacts that are created in Gainsight.

Gainsight rule chains

We have to supplement the data that is brought in through the connector to correctly display it within Gainsight and to coordinate bi-directional data syncs. The rules that exist in Gainsight are highlighted and shared to reflect their use in various Rule Chains in Gainsight.

Gainsight to Salesforce sync data

The following fields are pushed from Gainsight to their associated Salesforce field:

To see the complete list of fields and objects that are synced back from Gainsight to Salesforce, see Using Gainsight Data in SFDC.

Gainsight rules engine

The rules engine is the main automation tool in Gainsight, and allows us to do a variety of actions including bring in and/or send data to other systems, populate field values, create CTAs, set scores, and many others.

We have a team email address cs-ops@gitlab.com that we use for rule failure emails in Gainsight.

CSM assignment push to SFDC

Gainsight is the single source of truth (SSoT) on this field (CSM often labeled as CSM Name in GS and Customer Success Manager in SFDC).

• This field is updated in Gainsight and synced one-way to Salesforce. It is locked in Salesforce so users are unable to update there.
• The update is done with a real-time rule called Push CSM change to SFDC. This is triggered any time the field changes, and any change should load to Salesforce within seconds. The rule uses the SFDC User ID found in the CSM field in Gainsight to push to the Customer Success Manager field in Salesforce.

CSM History Tracking object

You can pull reports on when the CSM changed on an account with this object.

The CSM Change Date Stamp rule runs every time the CSM field changes in Gainsight, for any account. It loads some information to the CSM History Tracking object which includes:

• The old CSM name
• The new CSM name
• The timestamp when the CSM field was changed

A field on the Company object called CSM First Assigned Date was created based on the MIN date of the CSM Change Date Stamp per Account.

Create Gainsight CTAs and success plans

We have several rules that create items in Gainsight such as CTAs and Success Plans. Some notable rules are:

• Assignment needed CTA
• Onboarding CTA
• Triggered when an opportunity is greater than $50k
• EBR cta
• ROI success plan

Set score

All of the scorecard measures in Gainsight are set using rules.

Rules in place:

• Baseline rule
• Changes rule
• Blanks rule
• CSM sentiment
• Engagement
• ROI
• Data designers (null)

Rules to null scorecard measures

A rule exists to null Health Score Measures (ROI, Engagement, CSM Sentiment) for Non-CSM owned accounts, or when no CSM is assigned on accoun. The rule runs once per week on Monday.

Admin Daily - Stage Adoption

These rules act as field rollups to calculate fields within Gainsight:

• Admin - Load Stage Counts to Company
• Admin - Load Aggregated Stage Adoption Data to MDA

Deleting and Merging Old Records

When an account record is deleted or merged in Salesforce, the matching record in Gainsight is not automatically deleted/merged. In order to catch these records and clean them up in Gainsight we have some rules and reports to identify them.

Rules

• Admin - Mark old Account records to be Deleted/Merged: this rule brings in a list of all accounts in Salesforce and a list of all accounts in Gainsight. It then compares the lists and retains only the accounts that exist in Gainsight but NOT in Salesforce. The rule also looks to see if the Gainsight record has any important information attached to it such as a CSM name, CTAs, Success Plans, or Timeline activities. If the Gainsight record does have these items, the boolean field Merge? is checked. If none of these items exist on the account, the field Delete? is checked. The account name will also be appended with either “TO BE MERGED NO LONGER IN SALESFORCE” or “TO BE DELETED NO LONGER IN SFDC.”
  • The rules Load to Company: Count CTAs, Load to Company: Count Success Plans, and Load to Company: Last Timeline Activity all calculate information about the account that is then used in the Admin - Mark old Account records to be Deleted/Merged rule to determine if the account needs to be merged or deleted.

Reports

The following reports are located on the CS Ops dashboard in Gainsight. They are also scheduled to be emailed to the CS Ops email address every Monday morning so that a member of the team can be reminded to review them weekly.

• Accounts Flagged to Merge: This report identifies accounts where the Merged? field is checked. The accounts that appear on this report need to be reviewed and merged with the correct account. This can be done in the Data Operations section in Gainsight by filtering to accounts where Merge? = Yes. More instructions on merging accounts in Gainsight can be found on the Gainsight documentation website.
• Accounts Flagged to Delete: This report identifies accounts where the Delete? field is checked. These accounts need to be deleted completely from Gainsight. This can be done in the Data Operations section in Gainsight by filtering to accounts where Delete? = Yes. More instructions on deleting accounts in Gainsight can be found on the Gainsight documentation website.

GS Admin quick tip on resetting dashboards

Some of our Gainsight users and champions have reported not being able to see new field, field values added to GS Dashboards. One known reason why that can happen is that Gainsight caches dashboards for quicker loading. This includes both the state of the dashboard and the data in reports. When GS Admins make changes to dashboards, it is likely for users to still see the cached version of the dashboard (previous version).

In order to reset the cache, GS Admins can take one of the following actions:

1. Next to “Save Layout” click on the 3 dots and select “Clear State”. This will clear the cached state and the next time a user loads the dashboard, it will be the most recent version of the dashboard.
2. A GS admin can add and remove a filter to the dashboard. The act of adding a filter automatically clears the state.

Gainsight sync timing

Gainsight syncs any updates, new customer accounts, and more into Gainsight first before pushing information back to Salesforce.

Recommendations

Codification standards and naming conventions are to be used to clearly articulate how we organize our terminology

Rule title labeling

When creating rules, we add the following prefixes to rule titles for organization and clarity:

• STAGING: For any rules that are being tested/are not live/are not active or scheduled. Meant to be either deleted/deactivated or name-changed once done with testing.
• OTR: One-time run rules. These are used in specific situations such as loading historical data, clearing fields, etc. Should be deactivated after use.
• Load to SFDC: Rules that push data to Salesforce. Example: Load to SFDC - Account Attributes
• Load to Company/GS Object Name: Rules that update any Gainsight object. Example: Load to Company - Last Timeline Activity
• CTA
• Set Score

See more about labeling in this issue.

Description recommendations

• Always add a rule description when creating rules.
• Link to the GitLab issue in the description: Issue #275: GS Documentation - Review rule descriptions and titles

Gainsight Scorecards

We are currently using the following scorecard groups and measures:

Product usage data in Gainsight

We bring in product usage data to Gainsight directly from Snowflake. We use a Data Designer project called MonthlyMart SelfManager Usage Data.

The Gainsight integration with Snowflake is still new, so we use a Data Designer project to import the data. Once Gainsight enhances the Snowflake connection we will be able to use a Connector job if needed.

(To be completed:)

• Identifiers explained and why we have multiple identifiers
• How instances roll up to account
• Different types of instances

Troubleshooting tips

• If you see a null value in Gainsight, check Snowflake. If there are values in Snowflake and not Gainsight, try a Data Designer reset and report update.

Explanation of redis, namespace_ids, and snowplow collection

The data team does not use Snowplow as a source for the new Automated Service Ping processes. Instead, they use clones of GitLab.com postgres and GitLab.com Redis counters.

Here are the four types of Service Ping we have:

1. Self-Managed Service Ping
2. Manual SaaS Service Ping
3. Automated SaaS Instance Service Ping
4. Automated SaaS Namespace Service Ping

The namespaces list used by SaaS Namespace Service Ping is driven by a clone of the GitLab namespaces table.

Caveat: Redis-sourced metrics (noted in the metric dictionary as either redis or redis_hll) are not yet available at the namespace level. For the time being, SaaS Namespace Service Ping will only have Postgres-sourced metrics (as of 2021-09-08).

Data definitions

• UUID: originally intended as unique identifier
• Hostname: the url for the company’s on-prem server (e.g., gitlab.gainsight.com)
• Namespace id: the GitLab-defined ID for namespaces (SaaS)
• Namespace name: the customer-defined name for their namespace. Note: many are listed as “BLOCKED” because of PII
• Metric definitions: https://metrics.gitlab.com/
• Ping_date: The specific date of the Service Ping (e.g., 2021-08-11 12:00). This is a weekly ping so the rows of data are updated with the latest ping values.
  • Use case: Use this field to see the exact date that the ping was sent.
• Snapshot_month: each row of data is tied to the snapshot month. The ping_date field will update the values in Snapshot_month for the current month.
  • Example: The monthly values (the fields) are updated on a weekly basis (Friday). Using July as an example, the ping date will update (July 1, July 8, July 15, July 22….) but the snapshot_month will remain 2021-07-01. When comparing July and August, you’ll see the value as of July 31 (roughly) and August 7 (assuming 1 week off). Put differently, July and August may be very similar in numbers.
  • Use case: 99% of the time use snapshot_month vs. ping_date.
  • Reasons we wouldn’t see snapshot month:
    • Canceled subscription (they canceled in May and, thus, stopped sending us data)
    • Data quality (something broke somewhere)
    • For self-managed, the customer disabled or blocked sending us data

Product usage data flows

Product usage mapping

GitLab customers will have an account and may have multiple subscriptions. Each subscription may have multiple instances, such as production or staging.

In Gainsight there is a tri-level structure, so an account will have multiple instances related to it. While we have the subscription ID mapped so we can see which subscriptions have instances, the visualization in Gainsight is a one-to-many relationship (Account:instances).

Journey Orchestrator Program Names

When the CS Ops team creates a new program in Journey Orchestrator, utilizing an easy-to-follow naming convention will allow other Gainsight Administrators to understand its context. Try to use the following order:

1. Issue # - Related issue number from the Customer Success Operations GitLab Project.
2. Segment - CSM/CSE or Sales Segment this JO Program affects.
3. Title - Description of the program’s purpose or objective.
4. Region - The region/timezone this program is designed to serve.

The naming convention is as follows:

[Issue #] - Segment - Title (Region)

E.g., 1661 - Scale - CI Enablement (APAC)

From this program name, we are ble to quickly understand that it relates to Issue #1661, focuses on Scale segment customers in the Asia-Pacific region and is a CI Enablement program. Don’t forget to add the program to your preferred folder!

Snowflake tables

• Monthly metrics
• Latest metrics
• Self-managed and SaaS

View page source - Edit this page - please contribute.