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

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

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

Slack

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

Eメール

アドレス

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

プログラムの Eメール:

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 epic に紐づく現在の 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 にチケットを開くには、内部リクエスト を提出し、“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 direct プロセスを通じてサブスクリプションライセンスがプロビジョニングされます。
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 にチャッターしてください。たとえば、重複アカウントをマージする必要がある場合（ドメインとアカウント名が同じであることを確認してください）

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

営業チームは、処理されなかった期限切れの opportunity でプログラムマネージャーをタグ付けすることがあります。

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

住所を編集する

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

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

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