Customer Programs コンテンツ＆スタイルガイド
CS Ops コンテンツガイド
このガイドでは、CS Ops およびその他の CS チームが送信するカスタマープログラムやその他の顧客コミュニケーション（ウェビナー、月次ニュースレター、メールを含む）に関する情報を示します。
ご質問は Slack チャンネル #cs_ops_and_programs をご利用ください。
コンテンツ作成 & レビュープロセス
新しいコンテンツの作成や、GitLab 内の既存コンテンツの応用には、Digital Customer Programs チーム以外でのレビューが必要です。コンテンツは正確性、GitLab スタイルへの準拠、可読性についてレビューされる必要があります。プロセス全体を完了するには、少なくとも 10 営業日（約 1 マイルストーン）を見込んでください。
| ステップ | タスク | 注記 | DRI | タイムライン |
|---|---|---|---|---|
| 1 | スコーピング - プログラムの目的を定義 | 回答: 何を達成したいか？既存の KPI や OKR とどう整合させるか | Program Manager | 1 ～ 2 日 |
| 2 | 既存コンテンツの特定 | メールコンテンツが GitLab ハンドブックや他のドキュメントにすでに存在するか？ | GitLab チームメンバー SME | 3 ～ 5 日 |
| 3 | コールトゥアクションの定義 | 回答: 各個別メールの意図したアクションは何か？ | Program Manager | 1 ～ 2 日 |
| 4 | メールコピーの作成 | 新しいメールコンテンツを書くか、既存コンテンツを 1 つまたは複数のメールに応用する | Program Manager または GitLab チームメンバー SME | 3 ～ 5 日 |
| 5 | メールコピーへのテンプレート割り当て | 既存のメールテンプレートを使うか、新しいものを作成してこのメールプログラムに適用する | Program Manager | 1 日 |
| 6 | マーケティングまたはサブジェクトマターエキスパートによるピアレビュー | 正確性と GitLab スタイルへの準拠について、メールコピーの SME レビュー | GitLab チームメンバー SME | 5 日 |
| 7 | メールデザインの最終化と Gainsight でのテスト | メールデザインを完成させ、最終レビューに向けて互換性を確認するため Gainsight でテストする | Program Manager | 1 日 |
サブジェクトマターエキスパート（SME）レビューのガイドライン
現在または新しいコンテンツのレビューを依頼されることがあります。このレビューは、ほとんどの場合 1 時間以上かかりません。
SME レビューのガイドライン
サブジェクトマターエキスパート（SME）レビュアーとして、技術的な正確性と完全性についてコンテンツのレビューを依頼されます。
レビュープロセス
- Google Doc のドラフト版が提供されるか、コンテンツの MR をレビューするよう依頼されます。
- ドキュメントをレビューし、提案、修正、追加事項をコメントとして追加するための時間が設定されます。何らかの理由でレビューを完了できない場合は、Issue にコメントしてください。
- レビューが完了したら、Issue にコメントします。
- すべてのレビューが完了した後、コンテンツのリクエスト元と作成者が最終レビューを行います。
レビュー時は、次のことを念頭に置いてください:
- タイポや文法エラーが存在する可能性が高いです。すべての修正が完了した後にこれらのドキュメントを修正します。
- ハンドブックや他の GitLab コミュニケーションとの一貫性を維持するために、メールには GitLab ライティングスタイルガイドラインを使用します。
- 追加は常に歓迎します！ドキュメントに含めるべきものがあれば、追加してください。
- ドキュメント内の情報の削除をリクエストすることを恐れないでください。そこに含まれるべきでないものがあれば、教えてください。
- コンテンツは簡潔に保つよう努めています。私たちが作成するコンテンツは、セールスやマーケティングのような説得力のあるものと、教育的で簡潔なものの境界線を歩む必要があります。
確認すべき点
- 顧客にとっての価値（What’s In It For Me / WIIFM）が明確に示されているか？SME として、この製品や機能が顧客にとってなぜ重要なのかを十分に理解しているはずです。それが明確に伝わっているか？顧客がそれが自分にとって何をしてくれるかを知らないかもしれない理由を考え、どう対処するかを検討してください。
- 提示された情報は技術的に正しいか？
- 該当する場合、各ステップは正しく、適切な順序で、期待通りの結果が得られるか？
- 使われている用語に不正確なものや古いものはないか？
- このドキュメントに含めるべき、または除外すべきコンテンツはあるか？
- リンク
- ブログ記事
- ビデオ
- 製品やプロセスの情報の順序は正しいか？
- 他のプロセスやステップの前に、何かを最初にリストアップしたり説明したりする必要があるか？
ルックアンドフィール
私たちのメールプログラムは、有料・無料、セルフマネージド・SaaS、AMER・APAC を含むさまざまな顧客に届きます。GitLab からの他のコミュニケーションと似ているが、私たちのチームとその目標にとってユニークな、一貫したルックアンドフィールを作るよう努めています。
スタイル
ベースとしてハンドブックスタイルガイドを使用しています。これは、句読点、大文字小文字、ブランディングなどをカバーします。たとえば、短縮形を使うかどうか、ブランド名の大文字小文字をどう書くかなどです。
また、私たち自身のブランド原則とトーンをガイドするために Pajamas Design System も使用します。
さらに、非包括的な言葉や、より広い読者にとって混乱を招く可能性のある地域固有のフレーズや言葉を避けるために、Documentation Style Guide のガイダンスも使用します。
言語とトーン
私たちのメールは一般的にフレンドリーですが、カジュアルではありません。これは通常、過度に親密な言葉を使わないことを意味しますが、温かく支援的なトーンを保つように努めます。主にポストセールス顧客向けに送信しており、説得的な言葉を多用しません。代わりに、より教育的で役立つトーンを選びます。
“I” と “we” を使うタイミング
考慮すべき良いルールは、メールが特定の個人から発信されているか、チームから発信されているかです。たとえば、メールが “Joe GitLab, CSM” によって送信され、個人的な意図がある場合は、メール全体で “I” や “my” を使うのが最適でしょう。メールが Customer Success Team から送信される場合は、“we” や “our” が良い選択肢になります。
Gainsight における HTML サポート
Gainsight には一部 HTML サポートがありますが、主にプレーンテキストメールアプリケーションです。この制限により、私たちのメールは一貫性と使いやすさを生み出すため、Gainsight 内でテンプレートとしてセットアップされています。
標準
Gainsight は Salesforce で見られる多くの同じフィールドを使いますが、すべてが 1:1 でマッピングできるわけではありません。ほとんどのメールに対して基本的な標準フィールドのセットを使いますが、必要に応じてフィールドを追加することもできます。
デフォルトでは、制限されたアカウントには送信しません。
私たちのメールプログラムで使用される基本的な標準フィールドと実践についての詳細はこちら。
トークン
Gainsight では、Gainsight および/または Salesforce のデータのプレースホルダとしてトークンを使用します。Google Document では {TokenName} として表示されます。
利用可能な地域
以下の地域にメールを送信できます:
- AMER
- APAC
- EMEA
メールプログラムは、現地相対時間で任意の地域に送信するように設定できます。
bfd74782)