カデンスコール
追加の CSM 関連ハンドブックページについては、CSM ハンドブックホームページをご覧ください。
概要
CSM がトラステッドアドバイザーになり、アカウントの健全性を評価・向上させるための主要なツールのひとつが、顧客カデンスコールです。これは CSM と顧客チームがビジネスアウトカム、優先事項、イニシアチブの進捗、懸念事項について同期する機会であり、CSM が参加すべきと感じる他の GitLab チームメンバーを呼び込む絶好の機会でもあります(例えば、機能リクエストやロードマップを確認するためにプロダクトチームを招くなど)。
カデンスコールは CSM エンゲージメントの重要な側面です。顧客の進化するニーズを継続的に把握し、GitLab が価値とアウトカムを提供していること、障壁を取り除き、Issue に対処し、フィードバックを収集し、関係を育み、顧客が引き続きポジティブな体験を持てるようにします。
頻度
- CSM: カデンスコールはオンボーディング中は週次で行い、それ以外は顧客の具体的なニーズと顧客ライフサイクルのステージを考慮した上で、少なくとも隔週で行うべきです。
- スケール CSE: スケール CSE の顧客には継続的なカデンスコールは設定されません。顧客とのコールは、スケール CSE の顧客ライフサイクルで定義された主要なポイントに基づいてプログラム的に提供されます。
カデンスコールは Gainsight にキャプチャし、エンゲージメントスコアカード指標を促進します。
カデンスコールのライフサイクル
効果的なカデンスコールは、コール自体だけでは成り立ちません。コールの前後に発生するいくつかのステージがあります。
コールの準備
カデンスコールに向けて、CSM はミーティングアジェンダを準備します。これは効果的なコールの基盤であり、すべての参加者が協力して作成すべきです。アジェンダはコールの少なくとも数日前に全員に共有してください。
アジェンダに含める推奨事項
- GitLab 側と顧客側の参加者
- 事前資料または参照のみの項目
- 議論のトピック(推奨ディスカッショントピックを参照)
- 顧客が計画外のトピックや質問を持ち込めるスペースを残しておく
- まとめと次のステップ
コラボレーションプロジェクトテンプレートには、このフォーマットに従って構成されたミーティングアジェンダ Issue テンプレートが含まれています。(注: スケール CSM の顧客はコラボレーションプロジェクトを使用しません)
カデンスコールのトピックと名称(顧客に招待状を送る際)も CSM エンゲージメントの重要な部分です。以下はカデンスコールに使用されてきた名称で、成功事例として推奨されます。人気順に記載します:
- “GitLab / <顧客名> CSM コール”
- “GitLab - 隔週コラボレーション”(頻度に応じて調整)
- “GitLab - CSM コール”
アジェンダを作成し事前に準備することで、CSM(およびアカウントチームの残りのメンバー)は顧客のために関連する質問と情報を準備できます。
最初のカデンスコールのタスクリスト
顧客との最初のカデンスコール/キックオフコールでカバー/完了すべき項目:
- アカウントチームと顧客の間の自己紹介を行う
- 購入理由と主要なユースケースを特定する
- トレーニングのニーズを特定し、イネーブルメントセッションについて合意する
- 新規顧客: 最初のカデンスコールで GitLab 入門と CI/CD 入門のイネーブルメントセッションについて話し合う
- 既存顧客: 希望するユースケースと潜在的な拡張機会に合わせて、その他のイネーブルメントセッションについて話し合う(次のセッション/トピックを、1 つ終わった直後から話し始めると効果的です)
- スケール顧客: 予定されているウェビナーのランディングページを共有し、少なくとも GitLab 入門と CI/CD 入門のウェビナーへの登録を促す
- サポートオファリングを共有する
- 顧客がセルフマネージドサブスクリプションを使用している場合:
- このページの「セキュリティ通知のサインアップ」セクションにメールアドレスを入力してセキュリティアラートに登録するよう強くお勧めする
- コミュニケーション設定センターリンクを共有し、顧客が GitLab からのメールを管理できるようにする
- 顧客が SaaS サブスクリプションを使用している場合:
- ステータスとコミュニケーション設定ページを顧客と共有し、セキュリティアラートへのオプトインを促す
- GitLab 管理者をステータスページの更新に登録する
- 定期的なカデンスコールの設定(CSM 管理のみ)
継続的なカデンスコールの準備
最初のコールの後、後続のカデンスコールが続きます。それぞれについて準備し、効果的で成功したミーティングになるよう確認が必要です。
コールの前に、以下の項目を確認してください:
- サクセスプランの目標と進捗
- オープンな CTA
- フォローアップ項目がクローズされているかどうかを確認するための最後のタイムラインエントリ/メモドキュメント(クローズされていない場合は次のコールでフォローアップする)
- 更新日の認識のための契約更新日
- ライセンス使用率 - 顧客が年間契約の後半にあり使用率が低い場合は、この傾向と予想される行動について話し合う。購入量を超えるか近い場合は、顧客に認識させ SAE/AE を巻き込む
- ユースケーススコアリングで顧客がグリーンでない領域を特定 - コールでそのうちの 1〜2 つを話し合い、これらの領域の導入の価値とイネーブルメントの機会を提案する
- 顧客はセキュリティアラートに登録しているか?顧客(特にセルフマネージドの顧客)が GitLab セキュリティアラートに登録していることが重要です。このページの「セキュリティ通知のサインアップ」セクションにメールアドレスを入力することで登録できます。CSM は連絡先(ほとんどの顧客はこのカテゴリーに該当します)とリードの関連 SFDC レポートを確認することで、顧客がセキュリティアラートに登録しているかどうかを監視できます。SFDC の個人カスタムレポートフォルダに希望するフィルターを付けた SFDC レポートのバージョンを保存して、元のレポートを誤って変更することなく効率的に使えるようにすることをお勧めします。これを行うには、レポートを開き、「名前を付けて保存」を選択し、レポート名を変更して「個人カスタムレポート」に保存します。そこから希望するフィルターを追加できます。キックオフコールと最初のカデンスコールの間に顧客がセキュリティアラートに登録しない場合、CSM はその後の会話でこのトピックを再度取り上げ、これらの通知にオプトインすることでインスタンスのセキュリティを維持するための必要なアクションを把握できることを強調すべきです。
すべての顧客コールには、必ずアジェンダを準備し、事前に顧客と共有してください。一部の CSM が顧客ミーティングのアジェンダ準備に使用しているテンプレートがあります。
さらに、セルフマネージドサブスクリプションについて定期的に話し合う価値のある特定の項目があります:
- 月次リリースについて話し合い、計画したアップグレードの頻度について確認し、メンテナンスポリシーについて知らせる
- リファレンスアーキテクチャについてお知らせし、これらがサポートされている唯一のアーキテクチャであることを伝える
- 現在および予想されるユーザー数について確認し、アーキテクチャが将来の成長に対応できる適切なスケールであることを確認する
- GitLab パフォーマンスツールについてお知らせする
- スケールアーキテクチャのサポートオファリングについてお知らせする
- アーキテクチャ図を提供してもらい、コラボレーションプロジェクトにアップロードするよう依頼する
- 顧客がバックアップ/リストアとディザスタリカバリの計画を持っていることを確認する
コールの実施
CSM が十分に準備していれば、コール自体はすべての参加者にとって快適で価値ある体験になるはずです。CSM はアジェンダに従ってミーティングを進行し、リストアップされたすべてのディスカッションポイントをカバーする準備をしてください。これは私たちの専門知識を共有し、顧客の質問に答えることで、顧客が目標に向けて前進するのを支援するチャンスです!
CSM はコールを積極的に推進し、顧客がコールに価値を感じ、何かを得たと感じて終えられるようにしてください。質問をしてディスカッションに入り、顧客がほとんどの時間を話せるようにしましょう。コールアジェンダを作成する際、顧客戦略に役立つトピックをカバーすることを確認しながら、「もし私が顧客だったら、これは関連性があると感じるか?」と自問してください。
GitLab 外部コミュニケーションガイドラインに加えて、強力なカデンスコールを行うためのいくつかのヒントを以下に示します:
- 積極的に参加する。 GitLab ではミーティング中のマルチタスクや注意の分散は許容されるですが、カデンスコールではそれは良くありません。CSM がこのコールをリードしており、割り当てられた時間を最大限に活用するために話し合われている内容に従い、会話を進め続けることが重要です。CSM はディスカッションをガイドし、メモを取る必要があります(または、すでにアカウントチームの別のメンバーにメモ担当を依頼している)。
- 柔軟に対応する。 アジェンダは適切に運営されたカデンスコールに不可欠ですが、台本から外れる準備も同様に重要です。顧客が緊急に話し合う必要があること、または価値ある情報が得られる可能性のある方向に会話が流れた場合、準備したアジェンダに無理に戻そうとしないでください。顧客の懸念に対処し、関連する質問で新しい情報を受け入れ、重要でないアジェンダ項目は次のカデンスコールまで延期できます。これは顧客との会話で「聞く準備ができている」状態に関係しています。
- 素早く対応する。 CSM とアカウントチームがどれほど準備していても、顧客は予想外の質問をすることがあります。誰もコール中に知らない情報を求められた場合は、正直にそれを認め、その情報を入手してフォローアップする計画を立ててください。質問に答えられると思う場合は努力しつつ、最善の答えを確認することも保証してください。その場でできる最善を尽くし、その他のことは適時フォローアップしてください。
コールを終える前に、数分間かけて話し合った内容のハイライトをまとめ、行動項目とそれぞれの担当者を確認してください。次回のカデンスコールがいつあるかも全員に思い出させる価値があります。
コール後
カデンスコールから行動項目やフォローアップが何も生まれなければ、そのコールは効果的ではありませんでした。 少なくとも、CSM はコールの終わりに話し合われたサマリー情報をカバーするフォローアップメールを送るか、参加者のためのフォローアップ Issue を作成し、コール中に提起された質問に答え、コールの行動項目が全員に周知されていることを確認してください。
アカウント詳細の確認と更新
コール後、コールの内容が失われないようにし、顧客との良好な関係を維持するために確認・更新する項目がいくつかあります。
- タイムラインエントリのログ記録
- 健全性スコアの更新
- 必要に応じてサクセスプランの更新
- 必要に応じて CTA の更新
- 行動項目のフォローアップ(質問、機能リクエスト、エスカレーションなど)
- 顧客へのフォローアップ送付
今終わったコールが新鮮なうちに、次回のカデンスコールのアジェンダ作成を始めるのが良いでしょう。
フォローアップ
顧客へのフォローアップメッセージを作成する際は、ポジティブな体験を確保するために以下のガイドラインに従ってください。
- フォローアップメールを送るか、コールから 1 営業日以内にフォローアップ Issue をオープンするよう努めてください。それ以上かかる場合は、顧客に事前に期待値を設定し、進捗を(たとえ何もなくても)報告してください。
- すべての行動項目に対応し、まだ更新がない場合は取り組んでいること及び見込み所要時間を知らせてください。
- 顧客は長いメールを読みたくない可能性があるため、メール/Issue はできる限り簡潔にしてください。
- 可能な限りリンクを共有してください。ただし、以下に注意してください。
- 顧客がクリックする前に何であるかがわかるよう、ハイパーリンクではなくフル URL を含めるようにしてください。
- 顧客がクリックする前にその価値を理解できるよう、リンクの内容の短いサマリーを含めてください。
- 顧客コールで提起された質問を他の GitLab チームメンバーに尋ねることがよくあります。会話をそのままコピー&ペーストしないで、顧客に流れが通じるよう編集し、必要な情報だけが含まれるようにしてください。
- 校正をしてください!送信ボタンを押す前に、常にメールを(声に出して読むと効果的)再読して、意味が通っており誤りがないことを確認してください。顧客は私たちほどコンテキストを持っていないことが多いため、顧客の視点から読んでください。
- メールで Salesforce を BCC することを確認してください。重要なメールの場合は Gainsight を BCC することもできますが、タイムラインが煩雑になる可能性があるため、すべてのメールにはお勧めしません。
カデンスコールメモ
すべての顧客コールのメモは、次の形式に従って Google ドライブに保存してください: /Sales/Customers & Prospects/A/Acme/Acme - Meeting Notes。ミーティングメモの例はこちらをご覧ください。数年来の顧客など長いメモドキュメントを持つ顧客については、顧客フォルダ内で会計年度ごとに別々のドキュメントに分割することをお勧めします。その際、ドキュメントタイトルに会計年度を追加してください(例: /Sales/Customers & Prospects/A/Acme/Acme - Meeting Notes - FYXX)。また、現在のメモドキュメントの先頭に過去の年度のドキュメントへのリンクをすべて貼り付けて、簡単にアクセスできるようにしてください。
このようにコールメモを保存する理由は以下のとおりです:
- 命名規則「
顧客名- Meeting Notes」は Google Cloud Search for Work を使った高速検索を可能にします。 - コールメモには機密情報が頻繁に含まれており、必要とする可能性のある人全員が見つけられる場所に保管される必要があります。
- フォルダ構造により、カスタマーサクセス以外のエグゼクティブやサポートスタッフがエスカレーション時にメモを簡単に見つけられます。
- コールメモは健全性スコアと密接に関連しており、Gainsight の健全性スコアカードと同じ場所で参照できる必要があります。
- Gainsight へのアクセスは CSM に限られているため、Sales とカスタマーサクセス組織の他のメンバーは Google ドライブでメモを探します。
- Google Doc を作成したチームメンバーが GitLab を離れた場合でも、共有 Google ドライブフォルダに保存されているためメモは全員がアクセスできます。
- メモを会計年度ごとに別々のドキュメントに分割することで、ドキュメントの読み込みと入力の遅さを避け、データをより効果的に解析できます。
顧客コールメモは、アカウントの C360 の「サマリー」タブ「アカウント属性(編集可能)」セクションの「Google ドキュメントメモ」フィールドにも常にリンクしてください。
CSM が Gainsight のタイムラインにコールをログ記録する際には、Google ドキュメントへのリンクをコピー&ペーストする必要があります。コール日付へのディープリンクとするか、コールの簡単なサマリーと共にリンクを記載し、努力の重複を避けてください。
各顧客コールの終わりに、顧客の健全性への変更を顧客の Gainsight アカウントに反映させてください。CSM センチメントとプロダクトリスクの判断に記載されているように、アカウントの健全性スコアの CSM センチメントとプロダクトセンチメントを更新する方法はいくつかあります。最も簡単なのは、コールをログ記録する際に直接更新することです。
メモ取りのベストプラクティス
- アジェンダ(聞きたい質問を含む)を事前に書き留めておいてください。そうすれば特定のコンテキストのメモをすばやく追加できます。
- Markdown 形式で書くことが快適であれば、リアルタイムでメモをすばやく構造化するのに活用してください。
- コール直後にメモを整理する時間を確保してください。会議を連続して入れないようにしてください。
- コールの会話をゆっくりにする練習をしてください。数秒間話を止めて「書き留めます」と言うことは、顧客に彼らが言ったことが重要であることを伝えます。
- SAE/AE/SA に一緒にメモを取るよう依頼してください。ミーティング後にメモを合体させて詳細を追加してください。
- Chorus を使用してコールを録音し、すべてを書き留めるプレッシャーを軽減してください。
- アカウントチームの誰かが Chorus でコールをスクリプト化するために振り返ることが理にかなっている場合もあります。
- 最も書きやすい方法でメモを取り、常に正式なミーティングメモドキュメントにコピーしてください。最初からそこに直接書けば、より効率的で一貫性があり、アカウントチームがリアルタイムで追いかけられます。
カデンスコールのトピック
以下の非網羅的なリストはカデンスコールの提案にすぎず、他のトピックの方が重要な場合もありますので、状況に応じてご使用ください。
2 つのセクションがあります。一般的な提案はいつでも適したトピックで、一時的な提案はリリース固有のトピックや Product Manager からのリクエストなど一時的なトピックです。
一般的な提案
これらはいつでも顧客コールで使用できる提案です。
- 以前に議論した項目のフォローアップ
- 戦略的・ビジネスアウトカムに関する質問と進捗確認
- 定期的に(年に数回)近々生まれる新しい目標や目的について確認する
- 予定されている機能とリリースのレビュー
- ステージ導入に関連する質問
- 使用状況、ベストプラクティス、一般的なワークフローなどに関するディスカバリー質問
- 顧客が主に使用しているツール、インテグレーション、IDE、言語などを確認し、新しいリリースで何を強調するかを判断する
- ユーザーイネーブルメントやトレーニングが必要な領域について話し合う
- 地域での GitLab ワークショップ/イベントについて言及する(または他の地域のイベントも)
- 他のツールやインテグレーションの活用方法について確認する
- 顧客リクエスト機能の更新
- ユーザーにフィードバック、ペインポイント、ブロッカーがないかを話し合う
- CSM が解決に向けて支援できることを確認する(機能リクエスト、サポートチケットなど)
- Gainsight のギャップや古い情報について確認する(推奨事項については8 分の動画をご覧ください!)
- セルフマネージドの場合、現在のバージョン、計画されているアップグレード、アップグレードアシスタンスが必要かどうかを確認する
- セルフマネージドの場合、計画中、予定中、または進行中のデプロイの変更(例: Geo、HA など)がないかを確認し、サポートについて理解しているかを確認する
- セルフマネージドの場合、バックアップ/リカバリーの計画と最近バックアップからの復元をテストしたかを話し合う
- セルフマネージドの場合、サインアップ有効化について話し合う
- セルフマネージドの場合、GitLab セキュリティパッチの重要性を強調し、GitLab の使用状況/サービス ping レポートを有効にするための追加の論拠として使用する
- セルフマネージドの場合、セキュリティアラートへのオプトインの重要性を強調する
- コラボレーションプロジェクトを使用している場合、CSM は月次頻度でアジェンダ Issue を作成するスケジュールジョブを設定できます。手順は各コラボレーションプロジェクトのインストラクションファイルに記載されています。
一時的な提案
より時事的なディスカッショントピックについては、CSM ホットシート(GitLab 内部リンク)をご参照ください。
