Gainsight 管理

Gainsight の概要

Gainsight は、Customer Success Managers (CSMs) と Enterprise Sales チームが顧客をサポートしワークフローを管理するために使用するカスタマーサクセスソフトウェアです。このページは、GitLab が Gainsight をどのように使用しているかについて、データ構造、統合、その他の技術情報を示します。Gainsight は CS Operations が所有しており、Sales Operations と Sales Systems はその継続的な拡張と改善において非常に活発で重要な役割を果たしています。

Gainsight サポート

すべてのチームは、Gainsight に関する質問や問題について迅速な対応を得るために、#gainsight-users Slack チャンネルを使用してください。Customer Success Operations はすべてのカスタマーサクセスチームにサポートを提供しています。

#gainsight-users チャンネルでの質問/懸念への対応を支援する CSOps チームのためのガイドライン

• 一般的な Gainsight の質問については、まずシステム内を探索して明らかな理由を見つけることができるかを確認します。例えば、簡単なセットアップの質問、レポートへのフィルターまたは列の追加、ルールが失敗する明らかな理由などです。
• 製品利用レポートの質問については、通常、懸念を直接サポート/対処できる SME を巻き込みます。製品利用レポートの SME は、必要に応じて他のチームメンバーをいつ巻き込むかを決定できます。SME: @nk312
• デジタルカスタマープログラムに関する質問については、SME @mharris3 と @jgamboa にお問い合わせください。
• Scale プログラム、プロセス、オペレーションに関する質問については、Scale SME: @rgorbanescu にお問い合わせください。

チャンネル vs Issue で処理できる項目

• 解決するのに最小限の時間がかかる質問（15〜30分）はチャンネルで直接処理できます
• トラブルシューティング時間が積み重なる場合は、Issue を作成するよう依頼します
• 依頼が機能強化、つまり新しいプロセス、既存のプロセスへの変更、機能リクエストなどの場合は、Issue を作成するよう依頼します

セールスチームのために、私たちはこのエスカレーションパスを使用します:

1. ログイン問題（Tier 1 サポート）= Sales Ops
2. Sales Ops が問題をログイン問題よりも重要なものと診断した場合（Tier 2）
   • 権限/アクセスバンドルの更新 = CS Ops
   • sales-specific でないルール、コネクタなどの問題 = CS Ops
     • 例: SFDC でのコンタクトの読み込みに関する問題
   • sales-specific なルール、コネクタなどの問題
     • 例: アカウントプランニングをサポートするプロセス
     • 問題の診断と要件収集 = Sales Ops
     • 問題の修正 = CS Ops

解決された重要な古い Issue

• Instance Data テーブル内の重複レコード
• Snowflake > Gainsight コネクタ - 既知のデータ問題

アカウント分類フィールド (FY24)

FY24 で行われたいくつかの変更により、アカウント分類目的で Gainsight で使用される一部のフィールドが変更されました。Sales 組織との整合性をより高めるために、Salesforce で使用されているのと同じフィールドと同じ命名規則が Gainsight でも使用されるようになりました。

Gainsight でもう使用されていないフィールド

Gainsight で現在使用されているフィールド

Gainsight のユーザープロビジョニング

Gainsight ユーザー管理を参照してください。

Gainsight のデータ構造

Gainsight は、一連の標準オブジェクトとカスタムオブジェクトを使用します。一部のオブジェクト/データは他のシステム（Salesforce など）に密接に対応し、他のオブジェクトは Gainsight 独自のものです。

階層

私たちは階層のために Gainsight でアカウント構造を使用します。アカウントの下にはサブスクリプションもあります。

標準オブジェクト

これらは Gainsight の主要な標準/システムオブジェクトの一部です:

カスタムオブジェクト

これらは Gainsight で作成した主要なカスタムオブジェクトの一部です:

Data designer オブジェクト

• Issue #276: GS Documentation - Review Data Designer designs and add descriptions
• Google ドキュメントで定義: Gainsight Data Dictionary

Gainsight のコネクタと統合

Gainsight のコネクタは、他のシステムから Gainsight にデータを取り込むための主要な方法です。次の外部システム用のコネクタを設定しています:

• Zendesk
• Snowflake
• Salesforce

Zendesk コネクタ - もはやアクティブではない

Zendesk コネクタには1つのアクティブなジョブ Zendesk Sync - Tickets があります。これは Zendesk Tickets V2 カスタムオブジェクトにマップされ、毎日実行されます。

Zendesk Ticket V2 MDA オブジェクトにデータをロードする Connector ジョブで使用される Zendesk オブジェクト:

• Organizations
  • チケットに関連する組織/顧客に関する一般的な情報を含みます。
• Tickets
  • 個々の Zendesk チケットに関連する詳細データを含みます。
  • Updated_at フィールドは、クローズされた日付または最終変更日のタイムスタンプの指標として使用されます。
• Users
  • User オブジェクトには、内部（GitLab エージェント）および外部リクエスター（チケットを提出した人）のデータの両方が含まれます。
• Closed Date
  • Zendesk はチケットのクローズ日のフィールドを提供しません。代わりに、ticket status == closed のフィルターと一緒に Updated_at を使用します。これは、チケットの最後の更新がそのクロージャーであるという仮定に基づいています。

Snowflake コネクタ

詳細は Product Usage Data セクションを参照してください。

執筆時点では、Snowflake コネクタは Data Designer と Adoption Explorer でのみ使用可能です。Gainsight の Connector 2.0 インターフェイスからはジョブを見ることはできません。

私たちはこれを Data Designer でのみ使用しています。MonthlyMart SelfManaged Usage Data オブジェクトで Snowflake から製品利用データを取り込みます。

ユーザー名とパスワードは Jeff Beaumont の 1Password アカウントに保存されています。権限をリセットする必要がある場合は、彼にお尋ねください。

Salesforce コネクタ

Connectors は、Salesforce から Gainsight へのデータの主要なインポート方法の1つとして使用され、2つのシステム間に存在するネイティブの統合です。コネクタは、Salesforce インスタンスの Gainsight Integration ユーザーを使用して認証されます。コネクタとそのセットアップ方法の詳細については、Gainsight ナレッジベースを参照してください。

Connectors は、Salesforce と Gainsight のインスタンス間でこれらのオブジェクトを同期するために使用されます:

注: コンタクトの Upsert キーはメールアドレスです。これは、Gainsight で作成されたコンタクトの双方向同期に関して有用です。

Gainsight のルールチェーン

コネクタを介して取り込まれるデータを Gainsight 内で正しく表示し、双方向データ同期を調整するために、データを補完する必要があります。Gainsight に存在するルールがハイライトされ、Gainsight のさまざまな Rule Chains での使用を反映するように共有されています。

Gainsight から Salesforce への同期データ

以下のフィールドが Gainsight から関連する Salesforce フィールドにプッシュされます:

Gainsight から Salesforce に同期されるフィールドとオブジェクトの完全なリストについては、Using Gainsight Data in SFDCを参照してください。

Gainsight のルールエンジン

ルールエンジンは Gainsight の主要な自動化ツールで、他のシステムとのデータの送受信、フィールド値の設定、CTAの作成、スコアの設定など、さまざまなアクションを実行できます。

Gainsight でルール失敗のメールに使用するチームのメールアドレス [email protected] があります。

CSM のアサインメントを SFDC にプッシュ

Gainsight は、このフィールド（GS では CSM Name というラベルが付けられた CSM、SFDC では Customer Success Manager）の単一のソースオブトゥルース (SSoT) です。

• このフィールドは Gainsight で更新され、Salesforce に一方向で同期されます。Salesforce ではロックされており、ユーザーはそこで更新できません。
• 更新は Push CSM change to SFDC というリアルタイムルールで行われます。これはフィールドが変更されるたびにトリガーされ、変更は数秒以内に Salesforce にロードされます。ルールは、Gainsight の CSM フィールドで見つかった SFDC ユーザー ID を使用して、Salesforce の Customer Success Manager フィールドにプッシュします。

CSM History Tracking オブジェクト

このオブジェクトを使用して、アカウントの CSM が変更されたときにレポートを取得できます。

CSM Change Date Stamp ルールは、すべてのアカウントについて、Gainsight の CSM フィールドが変更されるたびに実行されます。次のような情報を CSM History Tracking オブジェクトにロードします:

• 古い CSM 名
• 新しい CSM 名
• CSM フィールドが変更されたタイムスタンプ

CSM First Assigned Date という Company オブジェクトのフィールドは、アカウントごとの CSM Change Date Stamp の MIN 日付に基づいて作成されました。

Gainsight CTA と Success Plan の作成

Gainsight に CTA や Success Plan などのアイテムを作成するルールがいくつかあります。注目すべきルールは次のとおりです:

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

スコアの設定

Gainsight のすべてのスコアカード測定値は、ルールを使用して設定されます。

設定されているルール:

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

スコアカード測定値を null にするルール

非 CSM 所有のアカウント、または CSM がアカウントに割り当てられていない場合に、Health Score 測定値（ROI、Engagement、CSM Sentiment）を null にするルールがあります。このルールは月曜日に週に1回実行されます。

Admin Daily - Stage Adoption

これらのルールは、Gainsight 内のフィールドを計算するフィールドのロールアップとして機能します:

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

古いレコードの削除とマージ

Salesforce でアカウントレコードが削除またはマージされたとき、Gainsight で一致するレコードは自動的には削除/マージされません。これらのレコードをキャッチして Gainsight でクリーンアップするために、それらを識別するためのいくつかのルールとレポートがあります。

ルール

• Admin - Mark old Account records to be Deleted/Merged: このルールは、Salesforce のすべてのアカウントのリストと Gainsight のすべてのアカウントのリストを取り込みます。次に、リストを比較し、Gainsight に存在するが Salesforce には存在しないアカウントのみを保持します。ルールは、CSM 名、CTA、Success Plan、Timeline の活動など、Gainsight レコードに重要な情報が添付されているかどうかも確認します。Gainsight レコードにこれらの項目がある場合、ブールフィールド Merge? がチェックされます。アカウントにこれらの項目がない場合、フィールド Delete? がチェックされます。アカウント名にも「TO BE MERGED NO LONGER IN SALESFORCE」または「TO BE DELETED NO LONGER IN SFDC」が付加されます。
  • ルール Load to Company: Count CTAs、Load to Company: Count Success Plans、Load to Company: Last Timeline Activity はすべてアカウントに関する情報を計算し、それが Admin - Mark old Account records to be Deleted/Merged ルールでアカウントをマージまたは削除する必要があるかどうかを判断するために使用されます。

レポート

以下のレポートは、Gainsight の CS Ops ダッシュボードにあります。これらのレポートは、チームのメンバーが毎週レビューするよう促すために、月曜日の朝に CS Ops のメールアドレスに送信されるようにスケジュールされています。

• Accounts Flagged to Merge: このレポートは、Merged? フィールドがチェックされたアカウントを識別します。このレポートに表示されるアカウントは、レビューして正しいアカウントとマージする必要があります。これは、Gainsight の Data Operations セクションで、Merge? = Yes のアカウントにフィルタリングすることで行えます。Gainsight でのアカウントのマージの詳細は、Gainsight ドキュメンテーションウェブサイトで見つけることができます。
• Accounts Flagged to Delete: このレポートは、Delete? フィールドがチェックされたアカウントを識別します。これらのアカウントは、Gainsight から完全に削除する必要があります。これは、Gainsight の Data Operations セクションで、Delete? = Yes のアカウントにフィルタリングすることで行えます。Gainsight でのアカウントの削除の詳細は、Gainsight ドキュメンテーションウェブサイトで見つけることができます。

ダッシュボードのリセットに関する GS Admin クイックヒント

私たちの Gainsight ユーザーとチャンピオンの一部は、GS ダッシュボードに追加された新しいフィールド、フィールド値が見えないと報告しています。これが発生する既知の理由の1つは、Gainsight がより迅速にロードするためにダッシュボードをキャッシュすることです。これには、ダッシュボードの状態とレポートのデータの両方が含まれます。GS Admin がダッシュボードに変更を加えると、ユーザーはまだキャッシュされたバージョンのダッシュボード（以前のバージョン）を見る可能性があります。

キャッシュをリセットするには、GS Admin は次のいずれかのアクションを取ることができます:

1. 「Save Layout」の横にある3つのドットをクリックし、「Clear State」を選択します。これはキャッシュされた状態をクリアし、次回ユーザーがダッシュボードをロードするときに、ダッシュボードの最新バージョンになります。
2. GS Admin はダッシュボードにフィルターを追加して削除することができます。フィルターを追加する行為は自動的に状態をクリアします。

Gainsight の同期タイミング

Gainsight は、Salesforce に情報をプッシュバックする前に、まず Gainsight に更新、新しい顧客アカウントなどを同期します。

推奨事項

用語の整理方法を明確にするために、コード化標準と命名規則を使用します。

ルールタイトルのラベリング

ルールを作成するときは、整理と明確化のためにルールタイトルに次のプレフィックスを追加します:

• STAGING: テストされている/ライブでない/アクティブでないまたはスケジュールされていないルール用。テストが完了したら削除/非アクティブ化または名前を変更することを意図しています。
• OTR: 一度実行されるルール。これらは、履歴データの読み込み、フィールドのクリアなどの特定の状況で使用されます。使用後は非アクティブ化する必要があります。
• Load to SFDC: Salesforce にデータをプッシュするルール。例: Load to SFDC - Account Attributes
• Load to Company/GS Object Name: Gainsight オブジェクトを更新するルール。例: Load to Company - Last Timeline Activity
• CTA
• Set Score

ラベリングの詳細については、この Issue を参照してください。

説明の推奨事項

• ルールを作成するときは常にルールの説明を追加してください。
• 説明に GitLab Issue へのリンクを記載します: Issue #275: GS Documentation - Review rule descriptions and titles

Gainsight スコアカード

私たちは現在、次のスコアカードグループと測定値を使用しています:

Gainsight の製品利用データ

製品利用データを Snowflake から直接 Gainsight に取り込みます。MonthlyMart SelfManager Usage Data という Data Designer プロジェクトを使用します。

Gainsight の Snowflake との統合はまだ新しいため、データをインポートするために Data Designer プロジェクトを使用します。Gainsight が Snowflake 接続を強化したら、必要に応じて Connector ジョブを使用できるようになります。

(完了予定:)

• 識別子の説明と、なぜ複数の識別子があるのか
• インスタンスがアカウントにどのようにロールアップするか
• インスタンスのさまざまなタイプ

トラブルシューティングのヒント

• Gainsight で null 値が表示される場合、Snowflake を確認してください。Snowflake に値があり Gainsight にない場合、Data Designer のリセットとレポートの更新を試してください。

redis、namespace_ids、および snowplow コレクションの説明

データチームは、新しい Automated Service Ping プロセスのソースとして Snowplow を使用していません。代わりに、GitLab.com postgres と GitLab.com Redis カウンターのクローンを使用します。

これが私たちが持っている4つのタイプの Service Ping です:

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

SaaS Namespace Service Ping で使用されるネームスペースリストは、GitLab namespaces テーブルのクローンによって駆動されます。

注意点: Redis ソースのメトリクス（メトリクスディクショナリで redis または redis_hll として記載）は、まだネームスペースレベルで利用できません。当面、SaaS Namespace Service Ping には Postgres ソースのメトリクスのみが含まれます（2021-09-08 時点）。

データ定義

• UUID: もともと一意の識別子として意図
• Hostname: 会社のオンプレミスサーバーの URL（例: gitlab.gainsight.com）
• Namespace id: ネームスペースの GitLab 定義 ID（SaaS）
• Namespace name: 顧客が定義したネームスペースの名前。注: PII のため多くが “BLOCKED” としてリストされています
• メトリクス定義: https://metrics.gitlab.com/
• Ping_date: Service Ping の特定の日付（例: 2021-08-11 12:00）。これは週次の Ping であるため、データの行は最新の Ping 値で更新されます。
  • ユースケース: このフィールドを使用して、Ping が送信された正確な日付を確認します。
• Snapshot_month: データの各行はスナップショット月に紐付けられます。ping_date フィールドは、現在の月の Snapshot_month の値を更新します。
  • 例: 月次値（フィールド）は週次（金曜日）で更新されます。7月を例にすると、ping date は更新されます（7月1日、7月8日、7月15日、7月22日……）が、snapshot_month は 2021-07-01 のままです。7月と8月を比較すると、7月31日（おおよそ）と8月7日（1週間遅れと仮定）の値が表示されます。言い換えれば、7月と8月の数値は非常に似ている場合があります。
  • ユースケース: 99% の時間、ping_date ではなく snapshot_month を使用します。
  • スナップショット月が表示されない理由:
    • サブスクリプションのキャンセル（5月にキャンセルし、そのためデータの送信を停止）
    • データ品質（どこかで何かが壊れた）
    • セルフマネージドの場合、顧客がデータの送信を無効化またはブロックした

製品利用データフロー

製品利用マッピング

GitLab の顧客はアカウントを持ち、複数のサブスクリプションを持つ可能性があります。各サブスクリプションは、本番またはステージングなど、複数のインスタンスを持つ可能性があります。

Gainsight にはトライレベルの構造があるため、アカウントには関連する複数のインスタンスがあります。サブスクリプション ID をマップしてどのサブスクリプションにインスタンスがあるかを確認できますが、Gainsight での可視化は1対多の関係（Account:インスタンス）です。

Journey Orchestrator のプログラム名

CS Ops チームが Journey Orchestrator で新しいプログラムを作成するとき、簡単に従える命名規則を活用することで、他の Gainsight 管理者がそのコンテキストを理解できるようになります。次の順序を使用するようにしてください:

1. Issue # - Customer Success Operations GitLab プロジェクトの関連する Issue 番号。
2. Segment - この JO プログラムが影響する CSM/CSE または Sales Segment。
3. Title - プログラムの目的または目標の説明。
4. Region - このプログラムが対応するように設計された地域/タイムゾーン。

命名規則は次のとおりです:

[Issue #] - Segment - Title (Region)

例: 1661 - Scale - CI Enablement (APAC)

このプログラム名から、Issue #1661 に関連し、Asia-Pacific 地域の Scale セグメント顧客に焦点を当てた CI Enablement プログラムであることがすぐに理解できます。プログラムを好みのフォルダに追加することを忘れないでください！

Snowflake テーブル

• Monthly メトリクス
• Latest メトリクス
• Self-managed と SaaS

ページのソースコードを見る - ページの編集 - please contribute.