プログラムリソースとワークフロー

このページには、プログラムの認知拡大、エンゲージメント、リテンション、アドボカシーを推進するために使用するツールとワークフローが含まれています。

コミュニケーションチャンネル

Slack

チームでは次の Slack チャンネルを使用しています:

メール

アドレス

チームでは、プログラムメンバーや興味のある人がチームに直接連絡できるよう、次のお問い合わせ用 メールを使用しています。メールは GitLab Service Deskで処理され、これにより受信ボックスを共同で管理できます。

プログラムの メール:

1. [email protected]: GitLab for Open Source プログラム
2. [email protected]: GitLab for Education プログラム
3. [email protected]: Co-create および Notable Contributor プログラム用（コントリビューターのリクエストを共有する受信ボックス）
4. [email protected]: チームへの直接コミュニケーション用（内部・外部）

アウトリーチキャンペーン

Developer Relations Program Manager は、プログラムメンバーへのメールアウトリーチキャンペーンを担当します。

1. Marketing Operations Issueを作成し、既存のデータベース内の既知のプログラムメンバー全員のリストを作成します。データベースのセグメンテーション制約があるため、このリストはコンバート済みのリードと、GitLab for Education プログラム、GitLab for Open Source プログラム、GitLab for Startups プログラムなど、既存のプログラムにすでにサインアップしている機関、コミュニティ、企業に直接関連付けられたコンタクトから生成する必要があります。
2. 一回限りのメールリクエスト Issue を作成して、上記のリストに最初のプログラムメールを送信します。最初のプログラムメールは、メールが正しくステージングされ、既存のプロトコルに従っていることを確認するため、キャンペーンマネージャーが送信する必要があります。
3. リストが生成され、最初のプログラムメールが送信されると、アウトリーチメール用の Developer Relations DRI は、Marketo へのアクセス権と、上記の指定リストにメールキャンペーンを送信する権限を受け取ります。Developer Relations DRI は、最初のメールをテンプレートとして使用し、今後のすべてのアウトリーチメールをステージングおよび送信します。

次のプロトコルに従う必要があります:

1. Developer Relations プログラムのアウトリーチメールは、最初のプログラムメールをテンプレートとして使用して DRI のみが送信します。
2. Developer Relations プログラムのアウトリーチメールは、最大頻度として月に 1 回までしか送信されません。
3. Developer Relations プログラムのアウトリーチメールには、Developer Relations プログラムに直接関連するコンテンツのみが含まれます。コンテンツには次のようなものが含まれます: エンゲージメントへの行動喚起、プログラム要件や条件に関するアナウンス、ニュースレタータイプのコンテンツ。

ソーシャルメディア

GitLab のソーシャルメディアチャンネルを通じてプログラムコンテンツを投稿するようリクエストするには、このフォームを使用します。

EveryoneSocial では、GitLab チームメンバーが個人チャンネルを通じてコンテンツを共有することによってリーチを拡大できます。EveryoneSocial の Developer Relations チャンネルやその他関連チャンネルにコンテンツを追加してください。

ニュースレター

現在、いずれのプログラムもニュースレターを持っていません。 PM は次のニュースレターを活用して、社内外でプログラムの認知度を高めています:

• Company Newsletter: GitLab チームメンバー に向けて、関連する更新を 月 2 回 伝えます。プログラム関連のコンテンツを追加するには、これらの手順に従って、現在の Issueにコメントを追加してください。
• Customer Newsletter。顧客 に向けて 月の第 4 木曜日/金曜日 に送信されます。プログラム関連のコンテンツを追加するには、プロセスに従って、FY26 エピックに紐づく現在の Issue にコメントを追加してください。

コンテンツ

GitLab ブログ記事

Content Marketing チームは GitLab ブログを管理しており、ブログピッチをレビューし、編集フィードバックを提供し、公開およびアウトリーチのために投稿をスケジュールできます。 ブログ記事のピッチを送信するには、GitLab ブログハンドブックページの手順を参照し、関連する ブログピッチテンプレートを使用してください。

新規アセットの作成

Brand Creative チームは、デザイン、tanuki tab、スワッグなどのアセットの設計、作成、サポート、レビューを支援できます。クリエイティブリクエストを送信するには、関連する テンプレートを使用してください。

Developer Advocacy チームは、開発者向けにカスタマイズされたコンテンツを作成します。コンテンツ依頼テンプレートを使って Issue を作成することで、リクエストを送れます。

GitLab のブランドガイドラインとの整合性を確保しながら、独自のコンテンツを作成することもできます。アセットを作成するには、GitLab チームアカウントの Canvaを使用します。これは Business 機能へのアクセスを提供し、ブランドキットが含まれています。すべてのアセットは少なくとも Brand Creative チームによってレビューおよび承認される必要があります。

アセットライブラリ

各プログラム固有のリソースについては、プログラムページを確認してください。一般的に:

• Canva アセットは Developer Relations Programs フォルダにあります。WIP リソースまたは未承認の場合はドラフトとしてタグ付けしてください。
• プログラムのデザインアセットは、Corporate Marketing Projectで「ファイルを検索」機能を使用してプログラム名で検索することで見つけられます。

測定

エンゲージメントトラッキング

私たちの活動を通じて共有されるリンクや QR コードはすべて追跡される必要があります。これにより、クリック/スキャンの測定や、レポート用に生成されたトラフィックを測定できます。

チームでは Hovercodeを使用してリンクを短縮し、QR コードを作成し、エンゲージメント分析を生成します。プラットフォームへのアクセス用のユーザー/パスワードは、Marketing 1password vault に保存されています。

GitLab Support

プログラムメンバーに代わって GitLab Support にチケットを作成するには、Customer Support Internal Requests フォームに記入し、What is this request concerning? で Create a support ticket on behalf of a prospect or customer を選択してください。

受信者はプログラムメンバーであるため、ハイライトされたフィールドの情報を見て、チケットの返信を直接受け取ります。

このプロセスは次のために使用します:

• プログラムメンバー向けの手動クレジットカード認証

Developer Relations Engineering リクエスト

Developer Relations Programs チームは、Developer Relations Engineering チームに特定のタスクをリクエストします。 gitlab-org グループ内の新規または既存の Issue に ~"strategy-engineering-request" ラベルを適用し、@gitlab-org/developer-relations/contributor-success をピングして Developer Relations Engineering チームに通知します。 Developer Relations Engineering チームは Developer Relations Engineering Attention Required Issue でリクエストを監視します。

ライセンス付与

自動申請ワークフロー

1. 申請: 申請者が Customer ポータルで適格性検証プロセスを開始します。
2. 検証: Proxi.id、Customers ポータル、および/または Developer Relations Programs チームが申請者の適格性を検証します。
3. 注文: 検証に成功した申請者は、無償の GitLab ライセンスをアクティベートする手順を含むメールを受け取ります。申請者はクーポンコードを受け取り、GitLab Customers Portal のプログラム固有のチェックアウトページでチェックアウト時にこのコードを入力します。
4. プロビジョニング: GitLab Customers Portal の Web 直接販売プロセスを通じてサブスクリプションライセンスがプロビジョニングされます。
5. コンプライアンス: Sales-Support および Billing Ops チームが処理するステージです。
6. 更新: プログラムメンバーは、サブスクリプションが期限切れになる際に通知を受け取ります。また、サブスクリプションを更新するための手順も受け取ります。
7. サポート: 新規申請者と更新中のメンバーは、申請プロセスの問題やその他のプログラムリクエストに関するサポートを求めることができます。

Salesforce

Sales チームへのチャッター

Chatter は、Salesforce のユーザーとグループ間の主要なコミュニケーション方法です。Chatter は、Account または Opportunity レベルで行えます。Chatter 通知は、Salesforce の個人のホームタブにあります。

• 個人にチャッターすると、メッセージは Chatter が開始されたオブジェクト（Account または Opportunity）の上部と、Salesforce の Chatter タブの両方に表示されます。
• 誰かを直接チャッターするには、Chatter ウィンドウで @{NAME} と入力し、チャッターしたい人またはグループの名前を選択できます。
• EDU-OSS ワークフローに関連する質問のほとんどでは、@Sales-Support にチャッターしてください。たとえば、重複アカウントをマージする必要がある場合（ドメインとアカウント名が同じであることを確認してください）

期限切れの更新をクローズする

営業チームは、処理されなかった期限切れの商談 で Program Manager をタグ付けすることがあります。

1. 商談ページで Edit をクリック
2. Close Date を今日の日付に更新
3. Stage を 8- Closed Lost に変更
4. Closed Lost/Unqualified Detailed セクションを other に更新し、詳細「Educational Institution did not move forward with renewal」を追加
5. 商談の詳細を保存
6. Case Queue でケースをクローズ

住所を編集する

1. Salesforce で Account ビューに移動します。下にスクロールして Address Information、Billing Address に進みます。Billing Address は Contact ビューからもアクセスできます。

2. 編集ボタンをクリックして住所を編集します。OK をクリックして変更を保存します。Account、Contact、Opportunity に対して住所が更新されます。

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