セールス開発

GitLab のセールス開発組織へようこそ！私たちは、インバウンドとアウトバウンドの両方の戦略を通じて顧客のための結果を促進するために設計されたチームです。私たちの構造は、アウトリーチ活動における効率性、応答性、創造性を最大化するように設計されています。

私たちの組織のクイック Roadshow プレゼンテーションはこちらのスライドで確認できます。

1. Sales Development Representatives (SDR) — インバウンドフォーカス

主要属性: 迅速な応答時間 · グローバルカバレッジ · SLA とキャンペーンフィードバックのためのマーケティングとのアライメント · 定義された規定的なインバウンドプロセス · ラウンドロビン割り当てルール · BDR チームのタレントインキュベーター。

2. Business Development Representatives (BDR) — アウトバウンドフォーカス

主要属性: SAE/AE およびセールスリーダーシップとのアライメント · Field Marketing と ABM とのコラボレーション · 戦略的なアカウントプランニングと調査 · ターゲットを絞った創造的なメッセージング · セールスチームのタレントインキュベーター。

セールス開発インデックス

cmd+F を使ってこのページを検索してください。リードスコアリングを検索するなら、score、scoring、lead、MQL のように、複数の組み合わせを試してください。

探しているものが見つからない場合は、Sales Dev Ops チームのメンバーに連絡してください。それを見つけるお手伝いをするか、ハンドブックを更新して含めるようにします！

一緒に働くチームを通常どのように支援するか

私たちの Slack チャネル

ヘルプを得る場所

私たちの GitLab プロジェクト

私たちのダッシュボード

• 1:1 Account and Lead Level Dashboard Coaching Guidance
• Pipeline Dashboard Coaching Guidance

チームメンバー向けの Salesforce および Tableau ダッシュボード

リーダー向けの Salesforce および Tableau ダッシュボード

ダッシュボード/レポートテンプレート

頻繁に使用するページ

インバウンドおよびアウトバウンドプロセスの How-To

インバウンドおよびアウトバウンドプロセスを順を追って説明する前に、SLA と KPI を認識することが重要です。

SLA と KPI

インバウンド SLA と KPI

アウトバウンド SLA と KPI

注: Ultimate Parent Account または重複 Account を Actively Working に設定する必要はありません。Traction と SDR は、親アカウントと同じ名前を共有していれば、子会社が AW として設定されていることを確認できます。

リード、コンタクト、アカウントの場所

インバウンドリードは Sales および Marketing Operations チームによって自動的に Salesforce にインポートされます。アウトバウンドリードは BDR チームによって手動でインポートされます。

Domestic Parent Account RoE: 自分の国のリードのみを扱います。既存のアカウントがないリードを変換する前に、住所が完全であること（Country と Postal Code を含む）を確認してください。これにより、リードのローカルアドレスで新しいアカウントが作成され、正しい AE にルーティングされます。

リードへのアクセス

1. SFDC にログインします。
2. 以下の 3 つの方法のいずれかを使用してリードにアクセスします:
   • Views — 担当範囲とリードステータスに合わせて事前フィルタリングされたリスト。日々の優先順位付けに最適。
   • Reports — 標準ビューで表示されないデータが必要な場合に使用（例: 特定の日付範囲のソース別のリード、30 日間アクティビティのないアカウント）。
   • Dashboards — パイプラインの健全性、アクティビティ、SLA/KPI 遵守状況の視覚的サマリー。私たちのダッシュボードセクションを参照してください。

Lead Views

Lead views は、効率的にパイプラインを優先順位付けして管理できるよう、ユースケース別に事前フィルタリングされています。アクセスするには、トップナビゲーションバーの Leads タブをクリックします。

SLA: インバウンドリードを管理するための KPI と応答時間要件は、SLA ページで定義されています。

SDR Lead Views

BDR Lead Views

Contact Views

Account Views

リードデータベース管理の実施方法

SDR の責任の一部として、受け取った各リードに対してデューデリジェンスを実行することが求められます。これには、データベースで重複レコードをチェックすることや、私たちの RoE との照合が含まれます。

このプロセスの主要フィールド: Lead Status · Matched Account Info · BDR Prospecting Status · Account Type · BDR Assigned · Initial Source · Admin Company Override · Matched Opportunities Info

ステップ 1 — 重複を見つける

Lead レコードを開き、ページの上部にある Find Duplicates を押します。これを行うには SFDC Classic である必要があります。これは Lead、Contact、Account にまたがってクエリします。

ステップ 2 — 結果を評価する

すべての関連マッチを表示する画面に移動します。何も表示されない場合、またはデータが不完全だと感じる場合は、チェックボックスから選択し、再度 Search をクリックして Email Domain のみでマッチングを優先します。利用可能な他のデータポイントについても繰り返します。

次に、以下のルーティングロジックを進めます:

• 同じ人物または会社からの類似リードがすでに作業されているか？その場合、Lead Status と Created Date は何か？
• マッチしたアカウントが存在するか？その場合、Type（Customer または Prospect？）と BDR Prospecting Status（Actively Working または Worked in FY）は何か？
• 現在オープン中の Opportunity、または 90 日以内にクローズした Opportunity はあるか？

ステップ 3 — RoE に基づいたアクション

上記の状況を把握したら、以下の正しいアクションを適用します:

• Account Type = Customer かつリードが SMB セグメント → Convert を押します。既存のアカウントにリードを添付します。新しいアカウントを作成しないでください。注: ストレージのみが購入されている場合でもアカウントが Customer としてマークされる可能性があります — 真の Customer レコードとして扱う前に、まず Total_CARR__c > 0 を確認してください。

• Account Type が Customer でなく、かつマッチしたアカウントにオープン中の Opportunity がある場合 → Lead Status を Recycle に、Recycle Reason を Evaluating に設定します。Lead Lifecycle ルールに従ってリサイクルキューに残します。

• リードが大学または教育アカウントから、かつ US Public Sector ではなく、かつコンタクトが技術系の場合 → 通常のリードとして扱います。標準的な認定とシーケンスを進めます。

• Account BDR Prospecting Status = Actively Working → まず、過去 30 日間のアカウントレコードまたは関連リードレコードに対するアクティビティをチェックします。アクティビティが存在する場合、BDR Assigned フィールドのユーザーにリードを再ルーティングします。これは必須 — SDR はこれらのリードを保持してはいけません。アクティビティが存在しない場合、リードは SDR に残せます。

• アカウントが Public Sector としてフラグが立っている（ウェブサイトで .gov パートナーシップや政府契約を確認）→ PubSec マネージャーにルーティングします。リードを自分で扱わないでください。

• アカウントが BDR Prospecting Status = Restricted の Major テリトリーアカウントの場合 → リードをコンタクトに変換し、AE をチャタリングします。リードを扱わないでください。

• アカウントが Actively Working でない → そのアカウントで重複リードまたはコンタクトをチェックします（ステップ 1 の結果から）。重複が存在する場合、それらをマージし、生き残るレコードで最古の Initial Source 値を保持します。

• リードの Company Address が外部調査と一致しない → Lead/Contact Review Admin セクションの Admin Company Override フィールドを設定します。これはリード変換の必須前提条件です。

会社住所ベースのルーティング情報

誤った本社情報を発見した場合、Company Address ウォーターフォールフィールドは、アカウントルーティングと案件割り当てに使用される読み取り専用の数式フィールドです。リードを新しいアカウントに変換する前に、それらを検証する必要があります。ウォーターフォールは優先順位順に解決されます — 各レベルは、その上のレベルが空白の場合にのみ使用されます:

1. Account Demographic Fields — リードが既存のアカウントとマッチしたときに LeanData が自動入力。
2. Admin Company Override Fields — ZoomInfo データが間違っているか欠落している場合に Lead/Contact Review Admin セクションで手動設定。
3. ZoomInfo Company Address Fields — 自動エンリッチされたベースライン。

Admin Override Fields を使用するとき: ZoomInfo の住所が間違っているとき、または ZoomInfo マッチがなくウォーターフォールフィールドが空白のとき。

更新するには、Lead/Contact Review Admin に移動し、Street、City、Country、Postal Code を入力し、Admin Company Address Source フィールドを設定します — このフィールドは保存時に必須です。優先順位順の許容ソース: ZoomInfo → Cognism → Company Website / SEC Filing（URL を追加）→ Customer confirmation → LinkedIn（最後の手段 — 理由を含む必要があります）。

注: リード変換後、アカウント所有権の割り当ては約 4 時間間隔で実行されます — アカウントオーナーが即座に更新されない場合、それは想定どおりです。

完全なウォークスルーについては、この動画 を参照してください。

リードのマージ

同じ人物に対して重複レコードが存在する場合、マージが必要です。リードレコードで Find Duplicates を使ってマッチを表示します。

2 つのリードのマージ — 動画のウォークスルー

2 つのリードをマージする場合、1 つのレコードがマスター（生き残る）レコードになります。どの値を保持するかを決定するには、以下のルールを使用します:

リードとコンタクトのマージ — 動画のウォークスルー

これは、SFDC にすでにリードとして存在する人物に対して、ウェブ直接購入が新しい Contact と Opportunity を作成した場合に適用されます。システムは自動マージしません — 手動で行う必要があります。

1. リードレコードを開く → Convert を押す。
2. “Create Opportunity” チェックボックスのチェックを外します — そうしないと、重複した Opportunity が自動的に作成されます。
3. リードを既存の Account に添付します。
4. 新しいコンタクトを作成するのではなく、既存のコンタクトを選択してマージします。
5. Initial Source を、いずれかのレコードのうち Created Date が早い方の値（通常はリード）に設定します。
6. アカウントが SMB または Mid-Market で Customer の場合 → コンタクトのみに変換し、アカウントの AE をチャタリングして、リードの Last Interesting Moment や任意のトライアルやアウトリーチアクティビティについて通知します。

トラブルシューティング用 SFDC チャタリングガイド

質の悪いリードのクリーニング

時には、リードに GitLab にとっての価値がなく、データベースから永久に削除する必要がある場合があります。このプロセスは取り消せません — 開始する前に注意してください。

削除の基準:

• 一貫性がないか明らかに偽造された個人情報（名前、会社、肩書き）
• 一時的または自動終了するドメインからのメールアドレス

削除プロセス:

1. リードが上記の基準を満たし、プロスペクティングの価値がないことを確認します。
2. リードを SPAM DELETION Salesforce キャンペーンに追加します。キャンペーンメンバーシップのみが重要 — 選択するステータス値は削除に影響しません。
3. 削除は Marketo を介して毎日午前 12:05 PDT に自動的に実行されます。緊急の削除については #mktgops で支援を要請 — 控えめに使用してください。

⚠️ このプロセスで削除されたリードは回復できません。100% 確信がない場合は、このキャンペーンにリードを追加しないでください。

ドメインのブロック: 複数のリードが同じ低品質ドメインを共有する場合、Marketing Ops に Issue を作成してそのドメインをブロックリストに追加します。

リードを実行する方法

High Touch と Low Touch のリード

デフォルトは High Touch Sequence です。以下の 3 つのルックアップソースをすべて使い切った後でも電話番号を取得できない場合のみ、Low Touch を使用してください。

ステップ 1 — 電話番号をチェック:

• リードレベルの SFDC phone データをチェックします。
• 見つからない場合、エンリッチメントツール（ZoomInfo、Cognism、SalesNav）でその email を使って同じコンタクトを検索します。
• それでも見つからない場合は、手動調査（会社のウェブサイトなど）を試します。

ステップ 2 — 見つけた内容に基づいてシーケンスタイプを選択:

→ いずれかの段階で電話番号が見つかった → High Touch シーケンスを使用: マルチチャネル（メール + 電話 + LinkedIn）、約 2 週間、10 ステップ以上。これはほとんどのインバウンドおよびアウトバウンドリードに対する標準です。

→ 3 つのチェックすべての後でも電話番号がない → Low Touch シーケンス（最後の手段）を使用: 最大 4 つの自動メールステップ、短い期間。イベント招待や連絡先データが本当に不完全なリードに適切です。

上記のシーケンスタイプに基づいて、Outreach の対応するコレクションを選択します。

Do Not Call と Do Not Email の自動化

Do Not Call

通話を実施する前に、SFDC の Lead または Contact レコードの Do Not Call フィールドを確認します。

• Do Not Call = true → 通話しないでください。これを回避しようとしないでください。
• Do Not Call = false → 現地法と任意の Marketo 自動化に従って通話が許可されます。

見込み客が通話されないように求めた場合: Do Not Call を true に設定します。電話番号を削除しないでください — どの番号がこれ以上通話されないように求めたかの記録を保持する必要があります。

Do Not Call のチェックを外すには、以下の両方の条件が真でなければなりません:

• 個人がメールにオプトインしている（Do Not Email フラグが false）、かつ
• 通話または SFDC のログ記録されたメールで、通話されることを希望することを明示的に述べている。

フィールドのチェックを外す前に、オプトインメールを証拠として SFDC にログ記録してください。

⚠️ 通話されたいかどうかを尋ねるためにオプトインしていない連絡先にメールを送ることはできません。

メール、配信停止、Do Not Contact の自動化

BDR が送信するすべてのアウトバウンドメール（返信を含む）には、配信停止リンクが含まれている必要があります。正しい法的文言については、#privacy-team-help 経由で Privacy Team に連絡してください。

リードが作成された直後、Marketo は国、リードソース、ドメインタイプ、コンプライアンス基準（例: 特定の Cognism/ZoomInfo リード、カナダの個人ドメイン、競合またはスパムドメイン）に基づいて、Do Not Call および/または Do Not Email を true に自動設定する場合があります。

• Marketing Ops または Privacy Team から文書化された例外で明示的に指示されない限り、これらのフラグを上書きしないでください。
• リードがこれらのフラグのために連絡不能に見える場合、それを意図的なコンプライアンスの動作として扱ってください — データエラーではありません。

完全な基準: internal.gitlab.com/handbook/marketing/marketing-ops-and-analytics/marketing-operations/do-not-contact

White Glove イベントフォローアップシーケンス

Executive Roundtables などのハイタッチイベントの場合、リードレコードの Last Event Notes フィールドには、見込み客と対話した GitLab チームメンバーの名前など、特定の指示が含まれる場合があります。これらの状況にはwhite glove シーケンスが必要で、Outreach Collection の White Glove でフィルタリングすると見つかります。

目的は、迅速にフォローアップし、最初のタッチポイントから関連する SAE/AE を会話に参加させることです。

1. 見込み客を適切な white glove シーケンスに登録します。
2. Last Event Notes で指定された個人を参照および／または CC するように、最初のメールステップをカスタマイズします。SAE/AE がインプットを提供する時間が必要な場合は、アクティブ化する前に最初のステップを適宜遅延させます。
3. CC した SAE/AE にカスタマイズされた最初のメールのスクリーンショットを送信し、見込み客が応答しない場合により個別化されたフォローアップを可能にするために含まれていることを説明します。
4. Day 12 に、見込み客のエンゲージメントが発生していない場合に SAE/AE にフォローアップするよう促す内蔵タスクがあります。このタッチポイントを使用して、更新を共有し、次のステップについてアライメントします。

High Priority キャンペーンとリード

リードが SFDC で High Priority = true のキャンペーンのメンバーで、関連アカウントが BDR Prospecting Status = Actively Working の場合、リードに High Priority がマークされます。この分類は、リードの現在の Lead Status に関係なく適用されます。

High Priority のリードは、SFDC の B1 priority view に自動的に表示されます。

特定のリードがフラグ付けされた理由を理解するには、リードレコードの以下のフィールドを確認します:

• High Priority Timestamp — フラグが適用された時間。
• High Priority Reason — 分類を引き起こしたキャンペーンまたはトリガー。

リードに連絡することなく High Priority から外すには、このシーケンスを使用します。リードを Accepted ステータスに移動し、High Priority フラグを削除する 1 つのタスクを作成します。

Outreach シーケンスの作成と翻訳

新しいシーケンスは、以下の 4 段階のガバナンスフローに従う必要があります。開始するには BDR Sequence Creation Request Issue テンプレートを使用してください。

シーケンスの翻訳 — 上記のガバナンスプロセスを完了したシーケンスのみを翻訳します。Localization Issue Tracker で英語のシーケンスリンク、ターゲット言語、ゴーライブ日（少なくとも 2 週間先）、ペルソナ/モーションのコンテキストを含む Issue を開きます。Outreach で英語のシーケンスをクローンし、ステップを翻訳されたコンテンツに置き換え、ステップの順序、リンク、トラッキング、トークンを保持します。

メール署名の変更方法

署名は Okta プロファイルに基づいて自動的にプロビジョニングされます。署名を確認する方法については、OpenSense ハンドブックページ を参照してください。

First Order (FO) アウトバウンドプロセス

FO アウトバウンドは、親レベルで以前のコマーシャル関係がないアカウントをターゲットにします。主要な目的は FO SAO（First Order Sales Accepted Opportunities）を生成することで、これが主要な BDR パフォーマンスと報酬メトリクスです。BDR は、Actively Working (AWA) アカウントを選択し、戦略を構築するために SAE/AE と協力します。

BDR コメント — SFDC フィールド

これらの SFDC のアカウントレベルフィールドは、FO アカウントのステータス、戦略、タイミングの運用上の信頼できる情報源です。

6QA 注: 6QA アカウントが FO アカウントでない場合、BDR Prospecting Status はまず SDR Hold に 14 日間設定される場合があります。opp が作成されない場合、BDR 所有権で Actively Working / Showing Intent に自動遷移します。

FO アウトバウンドフェーズ 1 — プランニング

非常に戦略的なモーションとして、成功する BDR 戦略の最初のゴールは、KPI（実施したアクティビティ、設定したミーティング、作成した SAO、Stage 1 Net ARR）に紐づいた週次および月次のゴールを設定することです。

コンバージョン比（AWA アカウント → シーケンス化された見込み客 → 会話 → FO SAO）を把握し、パイプラインダッシュボード を使ってキャリブレートします。

真の First Order アカウントの検証 — 以下の 3 つの条件すべてが真でなければなりません:

条件 1 — 既存のコマーシャルライセンスがない

Account オブジェクトの Traction Hierarchies タブで、Domestic Parent Account がターゲットアカウントの DPA と一致するすべてのアカウントを確認します。Domestic Region 内のいずれのアカウントも、Customer Status が Customer であってはならず、CARR (This Account) の値がゼロより大きくてはいけません（コンピュート分のみを購入した場合を除きます。費用が $10 の整数倍なので簡単に識別できます）。

条件 2 — 過去 180 日以内に失われた更新がない

Domestic Region 内で Domestic Parent Account にリンクされた Former Customer アカウントのすべての opp を確認します。Closed-Lost opp の Close Date が過去 180 日以内であってはなりません。

条件 3 — オープンな opp がない

Traction Hierarchies タブで、同じ Domestic Parent Account にリンクされたアカウントの Number of open opportunities 列を確認します。

→ 3 つの条件すべてがパス → アカウントは First Order として認定されます。

→ いずれかの条件が失敗 → アカウントは FO ではありません。First Order として追求しないでください。

検証後、アカウントをコホート（例: FO: high 6Sense intent、FO: strategic logos、FO: Free users）にグループ化し、週あたり何アカウントを AWA に移動するか、アカウントあたり何見込み客をシーケンスするか（推奨: 5〜10）、ペルソナ、価値ドライバー、または組み合わせで集中するかを決定します。

FO アウトバウンドフェーズ 2 — アカウント調査

シーケンスの前に、各 FO アカウントは BDR Account Research フィールドに記録された文書化された調査が必要です。

調査すべき社内 SFDC シグナル:

調査すべき外部シグナル:

BDR Account Research テンプレート を使用して調査結果を文書化します。調査は Claude Sales Dev User Guide を使用して部分的に自動化できます。

Claude Sales Dev BDR/SDR ユーザーガイド

こちらのガイダンス と 動画ウォークスルー を参照してください。

• Prompt Library
• Business Development Prospecting Project
• Sales Development Personalisation Project
• AMER Calling Analysis Project
• EMEA Calling Analysis Project

ZoomInfo MCP

アクティブな ZoomInfo シートを持つチームメンバーは、ZoomInfo の MCP サーバーを Claude.ai で直接接続できるようになり、会話を離れることなく ZoomInfo の B2B インテリジェンスレイヤーに対して自然言語クエリを実行できます。これはオレンジに分類されるビジネス連絡先データ (氏名、勤務先メール、勤務先電話番号、役職、会社) について承認されています。これは既存の契約のもとで ZoomInfo がすでに処理しているのと同じ範囲です。

接続するには: Customize → Connectors → ZoomInfo → Connect を選択し、ZoomInfo (Okta) の認証情報でサインインします。

この統合の主なユースケースは Business Development Prospecting Project です。まずそこでアカウント調査プロンプトを実行し、次に自然なステップとして ZoomInfo を使用します。コンタクトのエンリッチ、インテントシグナルの表面化、アウトバウンドの準備などです。利用可能な機能の完全なリファレンスについては、ZoomInfo MCP ドキュメント を参照してください。

• うまくいっていること (およびうまくいっていないこと) を #sales_dev_claude_insights で共有してください。

制限事項: Claude は GitLab システムや CRM データに直接アクセスできません。会話間で記憶を保持しません。オレンジレベルまでのデータの共有が承認されています。

FO アウトバウンドフェーズ 3 — アカウントアウトリーチ

プロスペクトしたいアカウントを調査し特定した後、エンゲージメントプランの誰、何、どのようにを定義します。これにより、BDR Account Strategy と BDR Next Steps に入力する内容が駆動されます。

• ターゲットペルソナ: どの特定の肩書きや意思決定者をシーケンス化し、なぜか（例: VP Engineering、CISO、CTO）。
• メッセージング戦略: どの価値ドライバー、トラップ設定質問、プレイブックがアウトリーチをアンカーするか。どのシーケンスタイプを使用するか。
• マルチスレッディングプラン: AWA アカウントあたり 5〜10 見込み客、少なくとも 2 つのペルソナにまたがり、3 人の新規見込み客を含む。
• シーケンスと戦略ラベル: どの Outreach シーケンスを使用するか記載し、対応する BDR Account Strategy 値を設定します。

例: C レベルのみをターゲットにします。デリバリーペインとボトムラインへの影響でリードします。フックとしてパーソナライズされたキャンペーンアセットを使用します。BDR Account Strategy = FO General、ABM オーバーレイ付き。

アウトバウンドアカウントランキングマトリックス

追加のスコアリング修飾子:

• 現在の Community Edition (CE) 使用
• 250 人以上の従業員
• 高成長、テクノロジー、金融サービス、ヘルスケア、または規制対象業界
• 早期 DevOps 採用者: Kubernetes、コンテナ、マイクロサービス、マルチクラウド、CI/CD、SAST/DAST、デジタルトランスフォーメーション
• スタッフ上の複数の DevOps 役割または積極的に採用中

成長戦略、ランキング、RoE

純粋な FO プロスペクティングに加えて、BDR は既存のアカウント内および隣接する成長機会を特定し追求することが求められます。

既存顧客アカウント内の成長: 追加のビジネスユニットを特定するために AE と戦略的にパートナーを組みます。更新日を購買判断を促すきっかけとして活用し、会話を広げます。

親/子/子会社への拡張:

子または子会社のアカウントが ZoomInfo を介して特定されるがまだ SFDC にない場合、ステップ 1 はそのアカウントの SFDC で Lead を作成すること、ステップ 2 は最初のリードを認定するときに Contact に変換して Account を作成することです。

Free から Paid へのアップグレード: 既存の無料 Core/CE ユーザーは GitLab の有料バージョンへのアップグレードのターゲットにできます。コマーシャルライセンスなしでの高い使用量は、利用可能な最も強力な FO トリガーの 1 つです — これらのアカウントを優先します。Self-Managed Instances Dashboard を使用して特定します。

ランキングと優先順位付け:

プロフェッショナルサービス機会: PS Opportunity は、別途販売され、別途請求される任意の統合、コンサルティング、トレーニングをカバーします。PS の opp は Sales Development にクレジットされません — アカウント AE に直接渡します。

エンゲージメントルール (RoE)

これらのエンゲージメントルールは、Traction ルーティングが割り当てた後、SDR と BDR のリードと案件を誰が所有して扱うべきかを記述します。FY27 リード/コンタクトルーティングロジック（BDR、SDR、AE、キュー）は Lead & Contact Routing (Traction) ハンドブックページで定義されています - この RoE はそのルーティングロジックと一緒に読むべきです。

SDR インバウンド RoE

インバウンドリードを実行する前に、上記の ISR 基準を満たすかを確認します。満たす場合は、実行しないでください — ISR キューに保留します。

SMB (0〜250 従業員)

→ 顧客 → 実行しないでください。あなたにルーティングされた場合は SMB チームに渡します。更新の必要性がある場合は、コンタクトに変換して更新ケースを作成します。

→ 見込み客 → SDR が実行できます。

Mid-Market (250〜4,000 従業員)

→ 顧客 → 実行しないでください。BDR Assigned（Actively Working の場合）、AE Account Owner（AWA でない場合）、Base BDR（Base テリトリーの場合）、または Account Owner（パートナーアカウントの場合）にルーティングします。

→ 見込み客 → アカウントが Actively Working でなく、オープンな Opportunity がなく、Base テリトリーの一部でない場合、実行できます。

Large / Enterprise (4,000+ 従業員)

→ 顧客 → アカウントが Actively Working、Base テリトリーの一部、またはオープンな Opportunity がある場合、実行しないでください。AWA の場合は BDR Assigned に渡します。顧客を実行する場合は、まず AE とアライメントします。

→ 見込み客 → アカウントが Actively Working でなく、Base テリトリーの一部でない場合、実行できます。

ISR インバウンド RoE

Inside Sales Representative (ISR) チームは、プロダクトレッドグロースと従来のセールスの交差点に位置します。ISR は、見込み評価済みのトライアルリードの最初の窓口で、Field Sales と複雑な案件でパートナーを組みながら、トランザクションの案件を直接クローズしてトライアルユーザーを顧客に変換することにフォーカスします。

ISR ルーティングは他のすべての RoE ステップより優先されます。 SDR または BDR ルーティングロジックを適用する前に、リードが以下のすべての基準を満たすかを確認します。満たす場合は、ISR チームに属します。

リードは、以下のすべてが真の場合に ISR チームにルーティングされます:

• Last Interesting Moment Desc に “Auto-MQL from a valuable MM+ account signing up for a trial” が含まれる
• Last Interesting Moment Date が ISR チームのゴーライブ日以降
• Is First Order Person = True
• Account Demographics: Sales Segment が SMB でない
• Matched Account BDR Prospecting Status が Actively Working または Queued でない
• Person Address: Country = CA または US
• Matched Account Owner Role が AE_FO_AMER で始まる、または Matched Account Owner Role が空白（アカウントオーナーが割り当てられていない）

→ すべての条件を満たす → ISR チームにルーティング。ISR がまだ割り当てられていない場合は、ISR キューに保留します。SDR または BDR にルーティングしないでください。ここで停止します。

→ いずれかの条件を満たさない → 適用する SDR インバウンド RoE または 標準 BDR RoE を続行します。

注: この RoE は積極的に開発中です。ISR チームが成熟するにつれて、クレジットの帰属、Field Sales への引き継ぎ、エッジケースに関する追加ガイダンスがここに追加されます。上記でカバーされていないシナリオに遭遇した場合は、Sales Dev Ops チームに連絡してください。

標準 BDR RoE

すべてのインバウンドリードに対して、以下のステップを順番に進めてください:

**ステップ 1 — リードは金融サービス (AMER) からですか？

→ はい → すべての標準 RoE をバイパス。FinServ BDR にルーティング。ここで停止。

→ いいえ → ステップ 2 に進む。

ステップ 2 — リードは既存のアカウントからですか？

→ いいえ → リードが ISR 基準 を満たすかを確認。はいの場合 → ISR キューに保留。ここで停止。いいえの場合 → SDR チームがこのリードを実行。ここで停止。

→ はい → ステップ 3 に進む。

ステップ 3 — アカウントは顧客ですか？

→ いいえ → ステップ 4 に進む。

→ はい → ステップ 4 に進む（更新 opp を確認）。

ステップ 4 — 既存の更新 Opportunity がありますか？

→ はい → 更新の Sales RoE とアライメント。SDR/BDR は更新 opp でクレジットを受け取りません。例外が必要だと考える場合は Sales Ops に連絡してください。ここで停止。

→ いいえ → ステップ 5 に進む。

ステップ 5 — アカウントは Actively Working ですか？

→ いいえ → リードが ISR 基準 を満たすかを確認。はいの場合 → ISR キューに保留。ここで停止。いいえの場合 → SDR チームがこのリードを実行。ここで停止。

→ はい → ステップ 6 に進む。

ステップ 6 — BDR は過去 30 日以内にアカウントでアクティビティを行いましたか？

SFDC のアカウントレベルで確認するか、このレポートを使用 — 会社名とメールドメインでフィルタし、過去 30 日のアクティビティを探します。

→ はい → BDR Assigned がこのリードを実行。ここで停止。

→ いいえ → SDR チームがこのリードを実行。SDR は BDR Assigned とそのマネージャーをチャタリングして通知します。BDR マネージャーは BDR Prospecting Status を適宜更新します。ここで停止。

ステップ 7 — アカウントの BDR Prospecting Status は何ですか？

→ Queued または Worked in FY → SDR チームがこのリードを実行。ここで停止。

→ Restricted → BDR Assigned にルーティング。BDR は SAE をチャタリング: SAE は BDR にアウトリーチを希望するか、それとも SAE が自分で管理するか？SAE は 48 時間以内に応答する必要があります。BDR が承認された場合 → リードレコードを進めます。AE が所有することを希望する場合 → リードをコンタクトに変換。ここで停止。

ステップ 8 — 新しい MQL は同じ会社の既存の MQL と関連していますか？

会社名またはメールドメインでマッチ。

→ いいえ → ラウンドロビン経由で受け取った SDR がこのリードを実行。ここで停止。

→ はい → ステップ 9 に進む。

ステップ 9 — 既存の MQL は過去 30 日以内のアクティビティ、または未来のタスクがスケジュールされた Accepted または Qualifying ステータスですか？

→ はい → 既存の MQL のオーナーに割り当て。ここで停止。

→ いいえ → ラウンドロビン経由で受け取った SDR がこのリードを実行。不明な場合は関連 SDR と再確認。ここで停止。

ステップ 10 — リードは UserGems によって自動生成されましたか？

Initial Source フィールドを確認 — UserGems が含まれていますか？

→ はい + SMB リード → インバウンド SDR チーム。ここで停止。

→ はい + MM またはエンタープライズリード → 他のすべての RoE ステップに関係なく、テリトリーに割り当てられた BDR にルーティング。ここで停止。

テリトリー移動 RoE

テリトリーが 1 つの BDR から別の BDR に移動し、出ていく BDR が同じチームに留まる場合、出ていく BDR は特定のアカウントの所有権を一時的に保持できる場合があります — マネージャーの承認次第です。保留時に Issue が作成され、30 日後にレビューされます。

双方向のエンゲージメントアカウント: 出ていく BDR は、IQM と新しい opp につながる可能性のある双方向のエンゲージメントを実証できる任意のアカウントを保持できます。30 日後に IQM が設定されておらず、Stage 0 opp が存在しない場合 → アカウントは新しい BDR に移動します。新しい opp が作成された場合 → opp が認定されるかされないまで、アカウントは出ていく BDR に留まります。

既存の Stage 0 案件アカウント: 出ていく BDR は、これらを 30 日間保持できます。30 日後に opp が認定されない場合 → アカウントは新しい BDR に移動します。

自発的に戻ってきた見込み客: アカウントが再割り当てされ、見込み客が新しい BDR からの事前アクティビティなしで戻ってきた場合 → マネージャーのチームが SAO クレジットを受け取ります。

紛争 → BDR の Manager と Director にエスカレート。

認定中のテリトリー発見

認定の途中で、アカウントが異なるセグメントに属していることを発見した場合（従業員数、本社所在地、親アカウント関係による）、SAO クレジットはケースバイケースで決定されます:

→ デューデリジェンスが実行され、情報を以前に明らかにできなかった場合、かつアカウントが AWA でなく、過去 30 日以内に関連する SDR アクティビティがない場合 → SDR または BDR とそのチームが SAO クレジットを受け取ります。

→ アカウントが AWA または過去 30 日以内に SDR アクティビティがある場合 → クレジットは AWA の BDR またはリードを担当する SDR に行きます。

→ 情報が以前に見つかったはずだった → クレジットは正しいテリトリーのマネージャーに行きます。

→ テリトリー情報が矛盾している → 各テリトリーの AE Manager をチャタリングし、進める前に Sales Support と所有権を解決してもらいます。

案件を作成し SAO クレジットを取得する方法

このプロセスの主要フィールド: Initial Engagement Channel · Qualification Questions · Next Steps · Next Steps Date · Stage Name · BDR/SDR field · Sales Qualified Source

認定基準は、Sales Accepted Opportunity (SAO) としてセールスに渡される前に、リードが満たさなければならない最小限のしきい値を定義します。完全な基準: Inbound and Outbound。

SFDC 案件を作成するための完全なウォークスルーはこちらです。Sales Dev のすべてのメンバーは、Lead の Lead/Contact Review Admin セクションで見つけられる Initial Engagement Channel フィールドも、Opportunity を作成する前に入力する必要があります。

IQM のスケジュール

このプロセスの主要フィールド: Company Address · Company Address Checked · Related To · Next Steps Date

Opportunity が SAO になるとき

AE/SAL は、Next Steps Date フィールドに反映されたミーティング日から 48 時間以内に IQM の後に Opportunity を Stage 1 Discovery に移動します。Opportunity の Close Date はデフォルトで四半期の最終日になります — ベストプラクティスは作成日から少なくとも 90 日先に設定することです。

Opportunity が Stage 1 に移動した後に誤ったデータがある場合 → マネージャーをチャタリング → 彼らが Sales Dev Operations の誰か（Ramona または Sam）をチャタリング。Sales Dev では他の誰も Stage 1 以降の Opportunity を編集できません。

Opportunity が既存の中央 Opportunity を持つ Large アカウント内の新しいユーザーグループに対するものである場合 → あなたの Opportunity はそれにマージされるべきです。Stage 8 ガイダンスを参照してください。

Opportunity を作成するとき

シナリオ A — AE/SAE と IQM がスケジュールされた:

→ Stage 0 (Pending Acceptance) で Opportunity を作成。

→ Qualification Questions のすべてのフィールドを完了。

→ Next Steps Date と Next Steps の詳細を設定。

→ すべての当事者からカレンダー確認を受け取ったら → Ownership を AE/SAE に移し、自分を BDR/SDR フィールドに追加。Opportunity は Stage 0 に留まります。

シナリオ B — 見込み客は会話の継続を約束したが、完全には認定されていない:

→ パイプライン追跡とチームコラボレーションのために自分の名前で Opportunity を作成。

→ 一部の Qualification Questions フィールドは未完成のままで構いません。

→ Next Steps Date と Next Steps の詳細は必須。

→ 注: 自分を Opportunity Owner と BDR/SDR Representative の両方としてリストすることはできません — 検証ルールでブロックされます。

シナリオ C — 新規アカウントからのリード:

→ 見込み客の会社の従業員数と本社所在地を、メールまたはログ記録された通話ノートで確認。

→ ZoomInfo、Cognism、Sales Navigator とクロスリファレンス。

→ 従業員数が 250 に近い場合は特に注意してください。SMB/MM のカットオフは 250 人の従業員です。

Opportunity 作成ワークフロー

Opportunity の命名規則

トライアル延長と Ultimate から Premium へのダウングレード

トライアル延長を申請するには、Zendesk で L&R Support Internal Requests フォームを開き、What category of request? で GitLab.com Trial Related > Extend a GitLab.com trial を選択します。SaaS のみ — self-managed では機能しません。

トライアルを Ultimate から Premium にダウングレードするには、同じフォームで GitLab.com Trial Related > Change existing GitLab.com Trial plan を選択します。

引き継ぎミーティングと AE への Opportunity の引き継ぎ

BDR-AE 引き継ぎプロセスには 3 つのゴールがあります: 見込み客に最高の体験を提供する、BDR が AE チームとコラボレーションする構造化された方法を提供する、AE が初日から適切な情報で成功できるようにセットアップする。

すべての引き継ぎの最低要件:

• IQM は少なくとも 48 営業時間前に予約する。
• アウトバウンド SAO 認定基準を完全に満たすか、相互のコマンドプランを構築するために AE と協力する。
• AE は IQM から 8 営業時間以内に SAO を受け入れ、認定と引き継ぎフィードバックを伴って BDR と AE マネージャーをタグ付けしたチャタリングノートを残す必要があります。
• AE は引き継ぎ後に見込み客の関係を所有 — 再スケジュールや衝突の管理を含む。

1. BDR Qualified Meeting

BDR Qualified Meeting は、BDR が Discovery コールで完全に認定したリードです。CoM の原則が適用され、Before/After シナリオ、PBO、要件、メトリクスが特定され合意されています。明確なニーズと意思決定者への明確なパスがあります。

Discovery コール後の BDR のステップ:

1. コール中に明らかになった CoM 原則を要約。
2. コール中に Outreach を介して次のステップをスケジュール — 45 分のコール、招待本文を見込み客のニーズに合わせて調整。
3. AE 紹介メールを送信。難しい引き継ぎの場合は、顧客向けのアジェンダを添付。
4. 必要な SFDC フィールドにログ記録し、Notes フィールドを入力。
5. スケジュールの衝突がない限り、Evaluation Orchestration Call に出席: 認定の会話を要約し、Before/After シナリオを見込み客と検証し、見込み客が状況が変わっていないことを確認したら AE に引き継ぎます。

2. Joint IQM

Joint IQM は、事前に合意された Actively Working アカウントから予約されたミーティングで、BDR と AE が共同で出席し主導します。

コール前の BDR のステップ:

1. AE のカレンダーに直接 Outreach を介してスケジュール — 15 分の Discovery Call 形式。
2. SFDC opportunity を作成し、事前決定された調査をログ記録。
3. AE とアライメントし、相互のコマンドプランを構築。キックオフ時に、BDR の調査と購買判断を促すきっかけを要約。見込み客が彼らの状況を認めた後、事前に合意された発見構造を続行。

IQM のスケジュール — チェックリスト

1. コミュニケーションをログ記録して関連付ける → SFDC で、各関連アクティビティレコードを選択 → Related To を押す → Opportunity にリンク。

2. Sales Organisation RoE を検証する → ZoomInfo または他の承認されたソースで親/子のセグメンテーションと本社所在地を確認。不一致がある場合は、進める前に関連チームとコミュニケーションを取ります。

3. 必要なら誤ったアカウント割り当てを上書き → SFDC の Lead/Contact Review Admin に移動 → Company Address フィールドを更新 → Company Address Checked チェックボックスにチェック。これが完了しないと、SFDC はリード変換をブロックします。

4. IQM をスケジュール → AE に最低 24 時間前の通知を提供。通話中に見込み客に招待を受け入れるように依頼。

5. AE レビュー → AE はコール前に Opportunity をレビューすることが期待されます。具体的な情報を簡単に説明し、必要に応じてリマインダーを送信。

6. 時間通りに出席 → AE と BDR/SDR の両方が 5 分前にカメラオン、静かな屋内の場所で出席すべきです。

7. 24 時間以内に振り返り → ゴール: AE と BDR/SDR が opp がフリップされたか、認定されなかったかについて振り返り。書面でのフィードバックを Slack またはメール経由で、AE が SFDC に追加。

8. IQM ノートをログ記録 → opportunity の Initiative セクションに追加: 出席者、生のノート、質問、要約、Next Steps。

9. ノーショーの再予約 → BDR/SDR が構造化された Outreach シーケンスを介して再予約を所有。最大 2 週間アウトリーチ。IQM を再スケジュールできない場合、AE は opportunity を認定解除します。

リセラーとの作業

エンドユーザーアカウントが BDR/SDR のアライメントを決定します。サードパーティリードに割り当てられた SDR である場合、ステップ 1 の情報を集めて、正しく割り当てられた BDR（エンドユーザーアカウントに合わせて）に渡します。BDR はステップ 2〜5 を完了します。

ツール

Outreach

Outreach は、Sales および Sales Dev 向けのアウトバウンドエンゲージメントプラットフォームで、メール、通話、ソーシャルケイデンスをスケールで実行しながら、アクティビティを Salesforce にログ記録します。完全な構成、ガバナンス、ルールセットについては、Outreach ハンドブックページを参照してください。

自動登録の取り組み

• MM+ Valuable Trials – Auto-MQL & routing

すべての MM+ “valuable” trials（ビジネスメール + トライアル開始、SaaS および self-managed）は、Marketo スコアリングを介して auto-MQL するよう構成されており、追加で週あたり 160〜180 件の FO MM+ MQL を生成し、それらは FY27 リード/コンタクトルーティングルールに基づいて Traction 経由で Sales Dev (BDR/SDR/ISR) にルーティングされます。Scoring Change: Auto-MQL all MM+ Trials、Scoring Change: Valuable MM+ ICP SaaS Trials update to auto-MQL、MM+ Trials – Route to SDR、Marketo MQL & Lead Scoring ドキュメント を参照。

• MM+ Trial English Auto-Sequence Pilot (Sequence 1495)

MM+ trial の実験の一部として、English pilot コホート（AMER/EMEA、優先言語なし）からの MM+ valuable trial リードは、以前は単一の SDR にルーティングされていましたが、現在は SDR に代わって Outreach シーケンス 1495 に自動シーケンス化 され、よりクローズ指向のメッセージングをテストし、今後の ISR モーションに情報を提供します。Create automation for English pilot trials to automatically be sequenced（上記の MM+ trial auto-MQL ワークアイテムに関連）を参照。

• FO MM+ Valuable Free SaaS Signups – XDR Outreach Sequence

FO MM+ valuable free SaaS signup イニシアチブは、認定された無料グループ namespace のサインアップ (MM+ FO) を Marketo/SFDC にロードし、それらを XDR が所有する Outreach シーケンスに追加し始めます。これにより、オプトインされた product-qualified の無料ユーザーがナーチャーだけでなく構造化されたフォローアップを受け取れるようにし、トリガー、キャンペーン、ナーチャー除外のための支援ワークアイテムも備えます。Begin to add FO MM+ Valuable Free SaaS Signups to XDR Outreach Sequence、Build Email for MM+ Valuable Free Users Signup、Marketo & SFDC Campaign Creation – FO MM+ Valuable Free Users を参照。

追加の Outreach 駆動の自動化（トリガー、ルールセット、シーケンス、レポート）については、メインの Marketing Operations Outreach ページを参照してください。

Claude Sales Dev BDR/SDR ユーザーガイド

Claude Sales Dev BDR/SDR ガイダンススライドと Claude Sales Dev 動画ウォークスルーを参照してください。

1. プロンプトライブラリ
2. Business Development Prospecting Project
3. Sales Development Personalisation Project
4. AMER Calling Analysis Project
5. EMEA Calling Analysis Project

成果やプロンプトは Slack の #sales_dev_claude_insights で共有してください。

制限事項: Claude は GitLab システムや CRM データに直接アクセスできません。会話間で記憶を保持しません。オレンジレベルまでのデータの共有が承認されています。

RelevanceAI

RelevanceAI は、GitLab の Sales Development 向け AI ワークフォースプラットフォームです。Salesforce と Outreach にわたって、リサーチ、優先順位付け、重複排除、見込み評価中のフォローアップ、シーケンスへの登録、アカウント情報の収集・分析を連携させます。Salesforce が引き続き正式な記録システムです。エージェントは関連する CRM データや補完データを読み取り、SDR と BDR が確認できるよう、指定された Relevance フィールドに結果を書き込みます。エージェントの出力はアクションを支援するもので、担当者の判断に代わるものではありません。

現在のエージェント一覧

この一覧と状態は、Relevance プログラムの報告資料と運用ノートで管理されています。ユースケースが試験運用から本番運用に移るにつれて、名前や自動化の範囲が変わる場合があります。

Mona: インバウンド MQL のトリアージ

Mona は、インバウンドリードが MQL ステータスになり、SDR にアサインされると実行されます。繰り返し発生する事前作業の代わりに、リードレコードにアクションにつながる要約を提供します。Mona は次のことができます:

• Salesforce、キャンペーンとエンゲージメントの履歴、企業リサーチ、公開ウェブのリサーチ、利用可能な補完データを組み合わせます。
• 本人確認の信頼度、企業の適合性、ペルソナ、購買シグナル、電話番号の有無、過去の活動、ルーティングの状況を評価します。
• 見込み評価済みのウェブチャットの内容をリードのリサーチに取り込みます。
• Relevance Priority と営業活動のコンテキストを割り当てます。
• Relevance Summary、完全な Relevance Research、Relevance Next Action、Relevance Last Updated のタイムスタンプを Salesforce に書き込みます。
• 重複検出には Doope、対象となる初回アプローチの実行には EMA を使用します。

まず、Relevance Priority と Relevance Next Action が表示される SDR の Z-lead ビューまたは BDR の B-lead ビューを確認します。リードレコードを開いて Relevance Summary を確認し、見込み客に連絡する前に Relevance Research を使って、本人情報、企業の状況、購買意欲のシグナル、重複の検出結果、ルーティングの推奨内容を検証してください。

Mona はルーティングに関する懸念を特定したり、別の所有者を推奨したりする場合がありますが、通常のルーティングプロセスや担当者の判断に代わるものではありません。ルーティングの推奨に従って行動する前に、Salesforce の所有者、テリトリー、地域、アカウント階層、対応言語、商談の状況を確認してください。

Doope: 重複検出

Doope は、Mona のインバウンド MQL ワークフロー内と、より広範な BDR のデータ品質ワークフローで使用されます。メールアドレス、氏名、企業、アカウント情報などのシグナルを使って、一致する Salesforce の Lead と Contact レコードを確認します。検索対象から元のレコードを除外し、一致なし、一致する可能性のあるレコードが 1 件、または確認が必要な複数のレコードのいずれかを示す結果を返します。

Doope は重複の可能性をフラグ付けしますが、Salesforce のレコードを自動でマージすることはありません。フラグが付いたレコードをシーケンスに登録する、または対応する前に、次を行ってください:

• 一致するレコードが同一人物および現在の購買状況を表していることを確認します。
• 現在の所有者、アカウント、商談の状況、最近の活動を確認します。
• 一致するレコードが複数見つかった場合は、シーケンスへの登録を保留し、通常の Salesforce および RevOps のプロセスを通じて関係を整理します。
• 一致するレコードが 1 件あることを、重複の決定的な証拠として扱わないでください。

EMA: 購買意欲の低いトライアルのシーケンス登録

EMA は、承認済みの低意欲トライアルのワークフローに対応する Mona のサブエージェントです。リード、トライアル、Mona のリサーチのコンテキストを使って、対象に合わせた最初のメールを作成し、アサインされた SDR に代わって初回アプローチのメールを送信し、対象リードを承認済みの Outreach シーケンスに登録します。その後のステップは、設定された Outreach ワークフローに従います。

現在の EMA の対象は、条件を満たす購買意欲の低い Trial リードで、主に、PTP スコアが 0–3 の非 PTP トライアル、または PTP スコアのない非 PTP トライアルです。スコアが 4–5 の PTP トライアル、Conference または Virtual Event リード、Contact Form リード、Qualified Web Chat リードは、現在の EMA ワークフローの対象ではありません。他の AI 支援シーケンスは Outreach AI や別のワークフローを使用している場合があり、EMA だと決めつけないでください。

EMA が管理するリードについては、次に従ってください:

• EMA がリードを登録した後に、最初のメールを重複して手動送信しないでください。
• シーケンスを監視し、通常の SDR ワークフローを通じて見込み客の返信に対応します。
• 返信を受け取ったときに、テリトリーと所有者を確認します。特に、自動シーケンス登録によって通常の登録前チェックが省略された場合は確認してください。
• 誤ったパーソナライズ、古いトライアル日付、宛先の間違い、シーケンス登録の失敗は、#wg-relevance-ai-xdr-ext またはエージェントフィードバックフォームで報告してください。

Quali: 見込み評価段階のフォローアップ

Quali は、Qualifying に移行したリードを監視します。見込み客とのやり取りが始まった後の状況把握の抜けを埋め、担当者の明確なアクションがないまま有効なリードが停滞することを防ぐのが目的です。Quali は、アサインされた担当者の現地時間に合わせて毎日監査を行い、Salesforce の活動と見込み客の返信を確認し、リードレコードにレビュー結果を書き込みます。また、Slack を通じて担当者への通知と、マネージャー／ディレクター向けの集計を送信します。

現在のレビュー結果には次があります:

• Immediate Action: 見込み客から返信があった、または時間的制約のある別のアクションが必要です。
• Needs Recycle: リードの関心が薄れているか、有効な見込み評価キューに属する状態ではなくなっています。
• Ghosted by Prospect: 以前やり取りのあった見込み客から 3–29 日間返信がありません。自動的なリサイクルではなく、ナーチャリングと継続対応の状態として扱ってください。
• Done by SDR: 担当者が返信に対応済み、またはミーティングが予約済みです。

返信がない状態が 30 日以上続くと、現在のリサイクルロジックでは Needs Recycle - No response に分類される場合があります。

担当者は Immediate Action を最優先として扱い、Quali が示す理由を確認し、Salesforce の活動とステータスを最新に保ってください。Needs Recycle の場合は、リサイクルする前に理由を確認します。Ghosted By Prospect の場合は、承認済みの継続対応を続けるか、適切なときに承認済みの再アプローチのワークフローを手動で開始します。重複して連絡しないでください。Done by SDR の場合は、活動やミーティングが完了していることを確認し、情報整理が必要でなければ追加のアクションは行いません。

Relevance Qualifying Review または Relevance Qualifying Notes は編集しないでください。これらのフィールドは Relevance が入力・更新します。返信、将来のタスクの作成、ステータス変更、リサイクルプロセスに従った処理など、リードレコード上でアクションを行い、次回の監査に実際の状態が反映されるようにしてください。

Atlas: アウトバウンドのアカウントリサーチ

Atlas は、BDR のアカウントプランニングとプロスペクティングを支援します。アカウントが積極的に対応するワークフローに入ったとき、またはアカウントレコードの Request Relevance Research チェックボックスを使用したときに実行されます。稼働中のトリガーは BDR Prospecting Status フィールドを監視し、現在の 90 日間の保護期間内に Atlas のリサーチが行われたアカウントの再実行を避けます。通常、リサーチ結果は約 10 分以内に反映されますが、未処理分を処理するロジックにより、処理時間がさらに長くなる場合があります。

Atlas は、アカウント階層、顧客と商談の履歴、エンゲージメント活動、6sense のインテント、企業とウェブのリサーチ、採用とテクノロジーのシグナル、補完データ、コンタクトの発見、関連する GitLab の顧客事例を組み合わせます。アカウントリサーチを Salesforce に書き戻し、次のものを作成します:

• すばやく優先順位を付けるための短い概要。
• アカウントを詳しく確認するための完全なリサーチ概要。
• 利用可能なシグナルに基づく優先度または購買傾向スコア。
• ペルソナと根拠を付けた推奨見込み客。
• 経済的な意思決定者、技術評価者、チャンピオンなど、異なるペルソナに合わせた訴求の切り口。

BDR は最初に短い概要を確認し、その後、完全な概要、アカウント階層、推奨コンタクト、スコア、購買意欲のシグナル、訴求の切り口を検証してください。リサーチが First Order、Community Edition、Customer Upgrade など、アカウントの営業活動に合っていることを確認します。Atlas はアカウント戦略とコンタクト選定の参考に使用してください。BDR の判断に代わるものではありません。

Atlas が推奨した見込み客であることだけで、シーケンスに登録すべきだと判断しないでください。所有者、既存の活動、アカウントの状況、コンタクトの質、その人物がまったく新しい対象なのか、すでに対応中なのかを確認してください。

Prose と今後のアウトバウンド自動化

Prose は、Atlas が推奨した見込み客向けのメール作成機能として計画されています。現在の設計では、Atlas のリサーチから見込み客ごとの下書きを作成し、BDR が確認できるよう Outreach に配置します。Prose を完全に自律的な送信機能として説明しないでください。BDR は、送信前に下書きの確認、編集、削除、却下ができなければなりません。

Ghosty: 連絡が途絶えた見込み客へのフォローアップ

Ghosty の機能

Ghosty は SDR 向けにバックグラウンドで動作し、GitLab からのアプローチ後に反応がなくなった見込み客への最初のフォローアップメールを作成します。

Ghosty は現在、SDR 向けにのみ稼働しています。SDR が起動したりプロンプトを送ったりする必要はなく、メールの送信も行いません。SDR が確認し、送信するかどうかを判断するための下書きを作成します。

Ghosty による反応のない見込み客への対応

Ghosty は反応がないことを、フォローアップを省略する理由ではなく、検討する理由として扱います。次の両方の状況に対応します:

• 見込み客が返信した後、応答しなくなった場合。
• 見込み客がアプローチに一度も返信していない場合。

Ghosty はやり取りを読み取り、見込み客のトライアル、GitLab に関心を持った理由、前回のアプローチで取り上げた話題など、具体的な事柄に基づいた、短くパーソナライズされたメールを作成します。

Ghosty が作成する内容

Ghosty は、件名を GitLab との次のステップの最終確認 としたメールを 1 通作成します。このメールは:

• 評価やアプローチがどこまで進んでいたかを見込み客に思い出してもらいます。
• 見込み客が返信している場合は、その人の状況を軸にします。
• 見込み客が返信していない場合は、GitLab やアプローチに関する具体的な事実を使います。
• 明確な質問を 1 つするか、簡単に応答できる方法を 1 つ示します。
• 90 語未満に収めます。
• 自動生成らしく聞こえる表現ではなく、自然でパーソナライズされた口調を使います。

見込み客が返信している場合、Ghosty は実際に起きたことを記述し、合意や次のステップを作り上げることはありません。

見込み客が返信していない場合、Ghosty は会話が行われたような表現をしません。前回お話しした際、お話ししたとおり、前回のお話を受けて、おっしゃっていた、ご予定だったといった表現を避けます。

Ghosty はメールをよろしくお願いいたしますで締めくくり、本文には SDR の名前や署名を追加しません（署名は OpenSense が処理します）。

言語に関する要件

Ghosty は、スレッドで使われている言語でメールを作成します:

• 見込み客が返信している場合は、その返信の言語を使います。
• 見込み客が返信していない場合は、SDR が実質的なアプローチに使った言語を使います。
• 言語を特定できる明確な手がかりがない場合は、英語を使います。

Ghosty は、冒頭の挨拶と結びの言葉を含むメール全体を翻訳します。丁寧な呼びかけとくだけた呼びかけを区別する言語では、丁寧な呼びかけを使います。

Ghosty がフォローアップを作成しない場合

見込み客が次のいずれかに該当する場合、Ghosty はフォローアップを推奨しません:

• 断った、関心がないと伝えた、または連絡しないよう求めた場合。
• 価格、資料、空き状況、その他の回答を求めたものの、GitLab が回答していない場合。
• 適切な担当者ではない、購入する立場にない、誤って登録した、または別の人を紹介した場合。
• 将来の日付や意思決定の後に再度連絡するよう求めており、その時点にまだ至っていない場合。
• GitLab を評価しているのではなく、サポート、アカウント、ログイン、移行、請求の問題に対処している場合。

Ghosty は、トライアル中の GitLab の使用やテストに関する質問をサポートの問題として扱いません。評価の一環として認識します。

SDR が把握しておくべきこと

Ghosty が下書きを作成しても、最終確認と送信の判断は引き続き SDR が担います。SDR は、下書きが今も適切であること、宛先が正しいこと、トライアルの日付やタイミングが今も正確であることを確認してください。

Ghosty は、見込み客が経緯を思い出し、会話を再開するかどうかを判断できるようにすることにメッセージの焦点を絞ります。リンク、予約 URL、電話番号、メールアドレス、社内プロセス用語、今日、明日、来週といった古くなった相対的な日付表現は使いません。

WALL-E: リサイクル対象かどうかの確認

WALL-E は、Quali エージェントによるリサイクルのタグ付けを基に、スケジュールに従って実行する Relevance AI のチェックです。Salesforce で Needs Recycle から Recycle に移行できる可能性があるリードを特定します。

リードが対象となる条件

次のすべてを満たすリードが対象です:

• Needs Recycle の状態になってから少なくとも 7 日間が経過している。
• 現在の Salesforce ステータスが Qualifying である。
• アクティブ、一時停止中、保留中の Outreach シーケンスに含まれていない。
• Needs Recycle に移行した後に、判定対象のメール活動がない。

WALL-E は、今回の適格性確認の実行対象となったリードのみを評価します。リードを作り上げたり、順位を付け直したり、手動で選択したりしません。

WALL-E による Quali の活用

• Quali エージェントは、リサイクルが必要なリードを特定し、Needs Recycle - <reason> の形式で Needs Recycle の値とリサイクル理由をタグ付けします。
• WALL-E は Quali のタグと理由を出発点として、リードの現在のステータス、Outreach の活動、判定対象のメール活動を確認します。
• 対象のリードをリサイクルすると、Salesforce の Status に Recycle が入力され、Recycle Reasons フィールドには Needs Recycle - の接頭辞を除いた Quali の理由が設定されます。

BDR が知っておくべきこと

• アクティブ、一時停止中、保留中の Outreach シーケンスに含まれるリードを WALL-E がリサイクルすることはありません。シーケンスの終了時に Outreach がリサイクルを処理します。
• Outreach の見込み客が見つからない場合も、可能性は低いものの、リードが対象となることがあります。実行時には、これらのリードに Outreach の見込み客がいないことを示すラベルを付けます。
• 最近のメール活動によって、リサイクルの対象外となる場合があります。Needs Recycle のタグが付いた後に、見込み客からのメール返信や担当者からのメール送信があると、そのリードはリサイクルリストから除外されます。
• 通話や LinkedIn の活動だけでは、対象のリードのリサイクルは妨げられません。
• 引き続き Qualifying の状態にあるリードのみを検討します。コンバート済み、キューが所有、すでにリサイクル済み、またはその他の理由で対象外になったリードは除外します。

マネージャーが知っておくべきこと

実行のたびに、次の内容を含む実行結果レポートを作成します:

• 実行時刻。
• 対象リードの総数と、それらを担当するマネージャーの数。
• マネージャーごとの件数。配下の担当者全体のリード数として表示します。
• Outreach シーケンスに含まれるためスキップした対象リードの数。
• Outreach の見込み客がいない対象リードの数。
• その他の除外されたリード。対応済み、または Qualifying でなくなったものに分類します。

Salesforce のフィールドと日常のワークフロー

インバウンドリードの主要なフィールドは次のとおりです:

• Relevance Priority: トリアージに使う、表示された優先度またはリードの分類。
• Relevance Summary: 主要なシグナルと注意点の簡潔な表示。
• Relevance Research: 詳細なリサーチ、根拠、本人情報と企業の状況、重複の検出結果。
• Relevance Next Action: 担当者に推奨される最初のステップ。
• Relevance Last Updated: 出力が最新かどうかを判断するためのタイムスタンプ。
• Relevance Qualifying Review と Relevance Qualifying Notes: 見込み評価段階のフォローアップ用に Quali が管理するフィールド。担当者は編集しないでください。

アカウントの場合、Atlas は積極的に対応する状態、または Request Relevance Research チェックボックスを使用し、アカウントリサーチの出力と最終実行情報を Salesforce に書き戻します。Outreach 対応のワークフローでは、Relevance が生成したコンテンツは、Salesforce ではなく、承認済みの Outreach フィールドや下書きに書き込まれる場合があります。

実際のワークフローは次のとおりです:

1. 関連する Salesforce ビューまたは Slack 通知から始めます。
2. 短い優先度フィールドまたはレビューフィールドを使って、最初に対応すべきものを判断します。
3. レコードを開き、根拠となるリサーチ、活動、所有者、タイミングを検証します。
4. Salesforce または Outreach で、人が行うべき適切なアクションを実行します。
5. 自動送信と重複する送信や、エージェントが管理するレビューフィールドの編集は行わないでください。
6. 繰り返し発生する問題や重大な問題は、調査に十分なコンテキストを添えて、#wg-relevance-ai-xdr-ext またはエージェントフィードバックフォームで報告します。

フィードバックとガバナンス

不正確なリサーチ、誤ったルーティング、重複のフラグ、フォローアップの漏れ、Quali の誤分類、古いパーソナライズ情報、シーケンスの失敗、わかりにくい出力など、エージェントに関するすべてのフィードバックは、#wg-relevance-ai-xdr-ext またはエージェントフィードバックフォームで報告してください。次を含めます:

• Salesforce の Lead、Contact、または Account のリンク。
• 関係するエージェントとフィールド。
• 生成された出力。
• 期待される動作。
• 関連する活動、所有者、タイミング、言語、テリトリーのコンテキスト。

議論には #wg-relevance-ai-xdr-ext を使用し、問題の追跡が必要な場合はエージェントフィードバックフォームを使用してください。

ZoomInfo

ZoomInfo は、コンタクト情報、テックスタック、収益、ファーモグラフィクスなどの見込み客と会社のデータへのアクセスを提供します。レコードは、Export to CRM ボタンを介して個別または一括で SFDC にエクスポートできます。完全な詳細は ZoomInfo ハンドブックページ を参照してください。

トレーニングリソース: 40 分の紹介動画 · GitLab Edcast 紹介 · 上級トレーニング

LinkedIn Sales Navigator

Sales Navigator は、プロスペクティングと LinkedIn ネットワークの拡張リーチに使用されます。Okta の Lumos アプリ経由でアクセス — プロスペクティング役割の場合は Sales Navigator Advanced Plus を選択。

Sales Navigator 経由でのリード/コンタクトの更新は許可されていません — それは私たちのデータの信頼できる情報源ではありません。

トレーニングリソース: 70 分のチュートリアル · Peer tips 動画

6Sense

6Sense は、私たちのインテントデータと ABM プラットフォームです。購買シグナルと ICP への適合性に基づいて、購入を検討中のアカウントを表示します。新しいセグメントやアラートをリクエストするには、MktgOps リクエストフォーム を使用してください。

6QA 自動化

アカウントが 6Sense で 6QA ステータスに達すると、以下が自動的に発生します:

→ BDR Prospecting Status が Actively Working に設定。

→ BDR Account Strategy が Showing Intent に設定。

→ アカウントがレビューのために BDR の 1:1 ダッシュボードでフラグ付けされます。

BDR は次に当日中に行動する必要があります:

→ 6QA Acceptance Status を Accepted または Disputed に設定。

→ Disputed の場合 → 6QA Dispute Reason を入力（例: Account in open opportunity または Low LAM Dev Count）。

→ Accepted の場合 → ZoomInfo ワークフローが自動的にトリガーされ、関連する意思決定者を B6 リードビューに追加します。

6QA アカウントが First Order でない場合、BDR Prospecting Status はまず SDR Hold に 14 日間設定されます。14 日以内に opportunity が作成されない場合、BDR の所有権で Actively Working / Showing Intent に自動遷移します。

完全な自動化の内訳: internal handbook。

UserGems

UserGems は、私たちが関心を持つアカウントでの転職や新規採用を追跡し、ウォームリードを自動的に表示します。

ユースケース 1 — Contact tracking（転職）

追跡対象の人が転職すると、更新された詳細で新しい Lead が SFDC に作成されます。Initial Source フィールドには UserGems Contact Tracking と表示されます。

ルーティング: アカウントは MM かつ FO ですか、または Focus Account ですか、または Actively Working ですか、または PubSec/FINS/Telco/Base/APJ ですか？はいの場合 → テリトリーに割り当てられた BDR にルーティング。いいえの場合 → SDR ラウンドロビン。

ユースケース 2 — 新規採用と昇進

追跡対象の会社で関連する新規採用や昇進があった場合、Initial Source = UserGems - New Hires and Promotions で新しい Lead が作成され、専用の AI 駆動 Outreach シーケンスに自動登録されます。これらはダッシュボードでインテントシグナルとしてもフラグ付けされます。

→ 無関係な肩書きが作成されている場合 → #usergems-feedback でフラグを立ててください。

→ または Lead Status を Disqualified に、Disqualified Reason を No Authority にマーク。

ユースケース 3 — オープン案件のコンタクト

オープンな opportunity のあるアカウントに誰かが参加または離脱した場合、Stage 3+ opp → Sales チームのみ、Stage 0–2 opp → Sales と Sales Dev の両チームに通知されます。

これらのリードをレビューするにはこのレポートを使用してください。特定のシーケンスは存在しません — シナリオに基づいてテンプレートメッセージを Outreach で検索します。

Gem-E FY26 自動登録

認定 UserGems リードは、AI 生成のパーソナライゼーションで UserGems Outreach シーケンスに自動登録されます。SMB レポート と MM/ENTG レポート で進捗を追跡。

Gem-E Meeting Assistant: Initial Source = UserGems - Meeting Assistant を使用して、SFDC にまだないミーティング出席者のリードとコンタクトを自動的に作成します。マルチスレッディングを続けるために既存のアカウントまたは opportunity に割り当てます。

その他のツール

一般リソース

コールドコールとメールチェックリスト

コールドコールは 4 つの中核要素に従います: パターン中断、エレベーターピッチ、必要に応じて反論/トラップ設定質問、Up-Front Contract (UFC)。これらは、地理的なビジネス文化、DISC パーソナリティタイプ、個人の役割、会社の目的に基づいてカスタマイズする必要があります。

• BDR 101 Level Up Course — コールドコールスクリプト
• メインのコールドコール用ドキュメント
• リソースライブラリ
• Up-Front Contract ドキュメント

意思決定者の発見質問:

• “[company] でツールを評価する際、誰が関与しますか？”
• “あなたの取り組みに異議を唱えそうな人はいますか？ ほかの関係者につなぐお手伝いはできますか？”
• “[title] の立場で GitLab を購入する場合、社内でどのようなプロセスを踏む必要がありますか？ また、その進行をどう支援できますか？”
• “この変更を社内で提案するとき、どのような課題が予想されますか？ 誰に発言権があり、その人たちは何を最も重視しますか？”

メール作成は Command of the Message フレームワークに従います。完全な構造については完全なチートシートを、ソース別（LinkedIn、会社のウェブサイト、Google など）に使用するデータポイントの個別化マトリックスについては同じドキュメントを参照してください。

月次監査プロセス

毎月、Sales Dev のメンバーにクレジットされたすべての opportunity に対して、BDR Manager による完全な監査が実施されます。

必須 SLA: 監査と XDR の応答は翌月の初日までに完了。ルーリングは 2 日目の終わりまでに完了。

何を探すか:

典型的な赤旗:

• 文書化されたソーシングケースなしで Sales Qualified Source が SDR Generated でない
• 説明なしで AE が作成した opportunity
• 事前アクティビティなしで同日に IQM が設定され完了した
• 重複した opportunity
• Net ARR が欠落またはゼロ

SAO クレジットを保護するベストプラクティス:

1. アウトリーチするすべてのリードを Outreach シーケンスに追加します。
2. 意味のあるエンゲージメントをどう推進したかを示すすべてのアクティビティをログ記録します。
3. すべての Qualification Questions フィールドを入力します。
4. 後ではなくコール時にコールノートをログ記録します。
5. ミーティングが行われる前に Stage 0 opp を作成します。
6. LinkedIn または WhatsApp のエンゲージメントについては、スクリーンショットを撮ってチャタリングまたは opp に添付します。
7. イベントからのソースされたミーティングについては、イベント直後に Stage 0 opp を作成し、会話を要約するフォローアップメールを送信します。

SAO レポート: SDRs · BDRs

Field Marketing と BDR コラボレーションプロセス

私たちの FM/BDR コラボレーションプロセスは、クロスファンクショナルコラボレーションを最大化する精神で従う方法です。Field Marketers が入力する Issue テンプレートを作成しており、これは順番にこちらのカンバンボードから管理されます。Issue テンプレートは、各特定のイベントが必要とするだけアドホックなコラボレーションのためのスペースを残しつつ、すべての次のステップを明確に表現します。

BDR Director として、最初に主要 DRI としてタグ付けされます。BDR Manager として、地域の Director によってケースバイケースで関与します。すべての次のステップはテンプレートで明確に言及されています — 各ステップを順番に従ってください。Sales Dev Operations チームもタグ付けされており、進捗を監視し、必要に応じてヘルプを提供します。

プロスペクティングレポート

Status 関連の 6Sense レポート

テンプレートは 6Sense セグメントリストの #5 フォルダにあります。チーム用にクローンして編集します。

Currently Actively Working Accounts Template

チームの AWA を 6Sense インテントデータとクロスリファレンスします。現在パイプラインにある最良の ICP アカウントを強調表示します。編集: BDR Assigned フィルターにあなたの名前を追加します。

CE/SFDC Accounts not in Actively Working Status

既存のデータベースで現在積極的に追求されていない最良の ICP アカウントを強調表示します。編集: BDR Assigned フィルターにあなたの名前を追加します。

Greenfield Accounts not in Actively Working

現在 SFDC データベースにない最良の ICP アカウントを強調表示します。注: 私たちの TAM の約 15% が SFDC にあります — これは他の 85% からアカウントを表示します。編集: フィルター #8 (Address) に地域、都市、または国を追加します。テリトリー特定のフィルターのヘルプは Sales Dev Ops に連絡してください。

Short Sales Cycle のアカウント

これらのレポートは、より短いセールスサイクルを持ち、SAO により早く変換する可能性が高いアカウントを特定します。

6Sense Short Sales Cycle Accounts

SFDC Short Sales Cycle Accounts

Churn と Expand 機会レポート

これらのレポートは、次の更新でチャーンリスクまたは拡張性向のあるアカウントを特定します。

これらのテンプレートを使用する際は、テンプレートをクローンし、Account Demographics: Territory フィールドをテリトリーに変更します。アカウント健全性メトリックと Propensity to Churn データを使用して結果をソートします。これらのデータポイントに関するガイダンスはこちらを参照してください。BDR Account Strategy を Growth - Upgrade または Risk Of Churn に設定して、どのアカウントをターゲットにしているかを示します。

Expand Prospect Accounts

Churn Prospect Accounts

Sales Dev テリトリーと役割レポート

Sales Dev by Salesforce Profile and Role

役割別の主要権限: Sales Dev Ops プロファイルは、Stage 0 を超えて opp にメンバーを追加できる唯一のプロファイルです。Team Lead 役割はリードを転送できます。Director 役割はアカウントの住所と従業員サイズを更新できます。テリトリー可視性は、役割名（AMER、APAC、EMEA）の地域によって決定されます。

Sales Dev Territories by Team Role/Member

これを使用して、各テリトリーにどのメンバーと役割が関連付けられているかを確認します。BDR の割り当て変更をリクエストする際は、アカウント名ではなく、テリトリー名を Sales Dev Ops と共有してください。

新規アカウント AE レポート

新規アカウントに対する適切な AE を見つけるには、ステップ 1 はこのレポートを使用してテリトリー名を見つけることです — cmd+F を使用して zip/state/country で検索します。ステップ 2 はこのレポートを使用すること — ステップ 1 のテリトリー名を入力して正しい AE を見つけます。新しいアカウントを作成するためにリードを変換する前に、リード上のすべての所在地情報が正しいことを確認してください。

Sales Development クレジットマトリックス

注: アカウントが CI 分のみを購入した場合、SDR/BDR は、アカウントが後で Premium または Ultimate ライセンスを購入する場合、First Order Opportunity のクレジットを取得します。

Sales Development 組織の報酬内訳

クレジットを取得するには、Opportunity の Contact で双方向のコミュニケーションが文書化されている必要があります。この文書化が欠けている Opportunity は、報酬の検討対象になりません。

セグメントに応じた完全なクォータ構成要素については、ARR in Practice ハンドブックページを参照してください。

Sales Dev キャリアパス

資格の要件は、対象となるためには月の第 3 金曜日までに満たされる必要があります。たとえば 2 月の昇進要件を満たすには、1 月の第 3 金曜日までに要件を満たす必要があります。

昇進検討の場合、Hybrid/Growth PubSec BDR の Stage 1 Net ARR 達成率は 200% でキャップされ、チームメンバーが他のクォータ構成要素でも期待を満たしていることを確実にします。

Sales Dev President’s Club 基準

President’s Club への資格と立場は、各チームメンバー個別の報酬プランとクォータ構成要素ウェイトに対するパフォーマンスを使用して決定されます。President’s Club 検討の場合、Hybrid/Growth Pubsec BDR（およびそのリーダー）の Stage 1 Net ARR 達成率は 200% でキャップされ、チームメンバーが他のクォータ構成要素でも期待を満たしていることを確実にします。

Sales Dev パフォーマンス管理プロセス

ランプアップしたチームメンバーが連続 2 か月で 80% 未満の達成率の場合、または常態的に期待を下回る成果の場合、非公式パフォーマンス管理が開始されます。パフォーマンス管理検討の場合、Hybrid/Growth PubSec BDR の Stage 1 Net ARR 達成率は 200% でキャップされ、チームメンバーが他のクォータ構成要素でも期待を満たしていることを確実にします。

FY27 の本ページの変更について現在 NL WC と協議中です。このプロセスの間、このガイダンスはオランダを拠点とするチームメンバーには適用されません。

チームメンバーに通知された後の期待:

→ 月 1: 80% 達成 + 私たちの三つの柱の遵守

→ 月 2: 90% 達成 + 私たちの三つの柱の遵守

→ 月 3 以降: 100% 達成 + 私たちの三つの柱の遵守

継続的な不足 → 正式な警告 → 解雇を含む懲戒処分の可能性。

私たちの三つの柱

現在、これらの国における Nooks の使用について Netherlands/Germany Works Councils と協議中です。このプロセス中、オランダおよびドイツを拠点とするチームメンバーと、まだ Nooks へのアクセス権がないその他のチームメンバーについては、通話目標を 1 日 50 件のままにします。

KPI、SLA、ランプ期間

ランプ期間とリードルーティング

Expert レベルの BDR は、承認を待って自分自身の Outreach シーケンスを作成できます。

マネージャーは Traction で MQL ラウンドロビンプールを更新できます。動画: チームと MQL ラウンドロビンの管理 · 担当者の可用性の更新。

月 0〜4 の BDR/SDR クォータ

月の最初の月曜日に参加: 月 1 = 25% · 月 2 = 50% · 月 3 = 75% · 月 4 = 100%

16 日以降に参加: 月 0 = 0% · 月 1 = 25% · 月 2 = 50% · 月 3 = 75% · 月 4 = 100%

完全にランプアップした BDR/SDR が新しいチームに転送される場合: 月 1 = 50%、月 2 = 100%。

PTO とフレキシブル勤務

Time Off Policy に従い、予定された休暇についてはマネージャーに早めの通知をしてください。PTO Territory Planning リクエストをログ記録するには、SDR GitLab プロジェクトに移動し、PTO_Coverage_Template を選択します。

Sales Development の見込み客対応の役割では、見込み客との通話やメールの際に以下を念頭においてください: 通話するベストタイミングはビジネス日の早朝と夕方。Outreach では早朝と夕方の配信向けにメールをスケジュールできます。昼食時間はアウトリーチに適しています。地域の見込み客の通常のビジネス時間にスケジュールを合わせるべきです。

よく使われる用語

よくある質問 (FAQ)

一般的な Sales Dev トラブルシューティング

Q: 特定の Outreach コレクションを表示できません。 A: Outreach で誤った Sales Dev Team に追加された可能性が高いです。Sales Dev Operations に連絡してください。

Q: 私の Salesforce バージョンが非常に基本的です。 A: Sales バージョンを使用していることを確認してください。右上隅 → 青いドロップダウンボタン → “Sales” を選択。

Q: 私はすべてのツールへのアクセスを受け取っておらず、1 週間経っています。 A: マネージャーに通知し、Onboarding Role Entitlements Issue にコメントしてもらいます。

Q: SFDC ZoomInfo Lead View に表示されているよりも多くのリードを ZoomInfo からアップロードしました。 A: これらのリードはおそらくすでに SFDC にコンタクトとして存在します。Leads ビューではなく、ZoomInfo Contacts ビューに表示されます。

Q: この人が MQL としてスコアされた理由がわかりません。 A: SFDC レコードの Last Interesting Moment を確認し、次にリードページの Marketo Sales Insight ウィジェットの Scoring タブを確認します。行動スコアなしでデモグラフィックポイントのみが割り当てられている場合は、Marketing Ops に Slack で連絡し、新しいアクションが取られていないことを認識させます。

Q: 見込み客から個人データ主体のリクエストを受け取りました。 A: Personal Data Subject Request フォーム にリダイレクトします。

Q: なぜ BDR は SFDC で Account Owner ではなくなったのですか？ A: すべての見込み客とアカウント（PubSec を除く）にわたって Sales Dev と Sales の可視性を向上させるためです。BDR Assigned フィールドを使用してアカウントをフィルタリングします。

Q: 見込み客は私たちのウェブサイトから購入するつもりだと言いました。彼らがそうしたかどうかをどうやってわかりますか？ A: SDR は、ウェブ直接購入の前に 60 日以内に見込み客と意味のある双方向のコミュニケーションを持っていた opportunity でクレジットを取得します。このレポート を使用 — 日付範囲を設定して、見込み客のアカウントに紐づいた opportunity を見つけます。次に、以下のウェブ直接 SAO クレジットリクエストプロセスに従います。

Q: ウェブ直接 opportunity のクレジットをどうやってリクエストしますか？ A: opportunity レコードでチャタリング: (1) Ramona Elliott、Sam Bradley、または Brian Tabbert にタグ付け — Sales Support に直接タグ付けしないでください。(2) 過去 60 日以内の双方向のアクティビティを示す SFDC レコードへのリンク。コールノートは、後ではなくコール時に Qualification Notes フィールドに入力されている必要があります。(3) 購入決定に影響を与えた方法を説明します。担当者がウェブ直接評価の結果について質問や懸念を持つ場合は、まず Manager に相談する必要があります。

RoE のよくある質問

Q: BDR は重複アカウントをフラグすべきですか？ A: はい。BDR は自分でアカウントをマージできません — 関連する SFDC レコード内の Request Support ボタンを直接使用し、関連するすべてのアカウントリンクを提供してください。

Q: SAO クレジットの紛争をどう解決しますか？ A: SDR と BDR が最初に話し合います。合意しない場合: マネージャーが決定します。マネージャーが同意しない場合: シニアリーダーシップにエスカレートします。ダブルクレジットとダブル報酬は与えられません。

Q: アカウントが Actively Working でなくなった後に見込み客が BDR に直接戻ってきた場合はどうしますか？ A: 彼らがメールを送る、LinkedIn で返信する、または BDR に直接電話する場合、BDR はリードがキュー所有権にあることを確認し、アカウントを Actively Working に戻してリードを彼らの所有権に移せるようにする必要があります。

Q: なぜ私のリードが Inquiry Queue に再割り当てされていますか？ A: Marketing Ops が毎日午後 10:30 EST に Lead Status = Inquiry を Inquiry Queue に更新するクリーンを実行します。これを防ぐには、リードを Accepted ステータスに更新するか、Outreach シーケンスに追加します。

Q: 見込み客が連絡を受けることに異議を唱えた場合、BDR はどうすべきですか？ A: すぐに #privacy-team-help を介して Privacy Team に連絡し、コンタクトからのメールを [email protected] に転送します。

Q: リードがパートナーによって担当されているかどうかをどう知りますか？ A: リードレコードの Impartner Partner Account フィールドを確認します。入力されている場合、リードは Partner Queue に割り当てられています — アウトリーチを進めないでください。

Q: パートナーリードはいつリコールできますか？ A: パートナーリードは、joint marketing キャンペーンのためにパートナーに受け入れられない場合、設定期間後にリコールされます。Recycle ステータスで SFDC に再入力され、MQL になると BDR または SDR に割り当てられます。Impartner ハンドブックページを参照してください。

アナウンスのよくある質問

Sales Dev FYI チャネルの投稿命名規則

形式: オーディエンス | タイプ | 緊急度

#sales_dev_fyi の投稿はこの形式を使用する必要があります。投稿があなたに関係する場合は、読んだことを確認するために 👀 絵文字を残してください。

• オーディエンス: All of Sales Development / All SDRs / All BDRs / Specific team（例: AMER Large Land East）
• タイプ: Enablement (Mandatory / Optional) · Operations (Process Change / Tools / Sequence / Reports / System Updates) · New Event/Initiative/Resource · Survey · Org Wide Announcement
• 緊急度: 🚨 Action Required（緊急、期日付き）· 🧠 Need to Know（緊急、ワークフローに影響）· 📊 Feedback Requested（緊急度低）· 👀 Review（情報提供）

投稿タイトルの例:

• [All of Sales Development] | [Enablement - Mandatory] | [🚨 Action Required]
• [All BDRs] | [Operations - Sequence Process Cleanup] | [🧠 Need to Know]
• [EMEA Enterprise Land] | [Operations - New Outreach Event Sequences] | [🚨 Action Required]

マネージャーリソース

Sales Dev Operations チームの地域別対応

私たちの共有現実 を維持するために、以下の DRI を #sales_dev_global でタグ付けしてください。彼らの空き状況に基づいて誰にでも自由に連絡してください — EMEA で営業時間外で誰かが急ぎで必要な場合、AMER の Sam が支援できます。

Sales Dev Operations 定期的なチーム訪問

Sales Dev Ops チームは月に 1 回各チームのミーティングを訪問することを目指しています。プランニングとフィードバック Issue はこちらを参照してください。

Sales Dev Operations ワーキングセッション

毎週の定期ワーキングセッション — 月の運用テーマに合わせて、セッションあたり最大 4 人の参加者。主要な運用トピックとイニシアチブで協力するように設計されています。

Sales Dev Research Desk

Sales Dev Ops チームは、AWA アカウントリストの管理を支援するために、データベーススイート（Sales Nav、ZoomInfo、Cognism、6Sense）の調査を支援できます。通常、現在データベースにないアカウントに焦点を当てます。BDR_Research_Request テンプレートを使用して、私たちのボードに Issue をログ記録してください。

Sales Dev Housekeeping Issue

私たちのチームボードでの月次 Monthly Housekeeping Issue — 月次の TODO と次のステップを計画できるフィードバックセクションを統合します。フィードバックは、現在の月の Issue に直接ログ記録してください。

マネージャーツール認定

エンドツーエンドのプロセスとツールウォークスルーで、マネージャーに期待されるすべてのインバウンドとアウトバウンドのテックスタック知識をカバーします。完全な動画プレイリストは Unfiltered プレイリスト。略式ノートはこちら。期待されるマネージャー知識の質問と合格基準はこちら。

一般的なリーダーシップ原則

すべての Sales Development Manager は、ハンドブックに記載されている一般的なリーダーシップ原則に従う必要があります。

• 1-1
• 定期的なフィードバックの提供
• パフォーマンス不足への対処
• コールコーチングガイドライン

マネージャーオンボーディング

Becoming a GitLab Manager Issue は、マネージャーが入社または昇進した際に各マネージャーに対して作成されます。

アウトバウンド BDR プロセスマネージャーオンボーディング

BDR プロセスは、実証済みで繰り返し可能な一連のステップです — 新しいマネージャーがすぐにアライメントすることが重要です。完全なプロセスはこちらで説明されています。

Manager Attention Needed ボードを、チームが BDR プロセスにどうアライメントしているか、どこで助けが必要かを理解するための主要ツールとして使用してください。このドキュメントは、最初の月の主要な参照リソースです。新しいチームメンバーをオンボーディングする際は、新人オンボーディングドキュメント(こちら)と新人向けのオンボーディングチェックリストを参照して、次のステップを構造化できます。

1:1 アカウントとリードレベルのダッシュボードコーチングガイダンス

以下の表は、SFDC と Tableau の 1:1 ダッシュボードをどう知覚し実行するかを構造化するのに役立ちます。これらは アウトバウンド SLA とこちらの動画、こちらの動画に接続します。この 5 分の動画はこれらのダッシュボードの目的を説明し、この 3 分の動画は実用的なユースケースを順を追って説明します。

Pipeline Dashboard コーチングガイダンス

一般的な Sales Development リーダーシップリソース

リードルーティングとアライメントリソース

GitLab リソース

Sales Development オンボーディング

BDR および SDR として、オンボーディングはマーケティングとセールスのトレーニングをブレンドします。これには、一般会社全体のオンボーディング Issue、Sales Development 特定の Issue、Sales Quick Start (SQS) (セールス開発またはセールスの役割の新人向けの 3 日間対面ワークショップ) に備えるための Google Classroom コースが含まれます。

Sales Development オンボーディングプロセス

1. People Team が一般的な GitLab オンボーディング Issue を開始します。初日に、特定のオンボーディング Issue へのリンクが含まれたウェルカムメールを受け取ります。
2. 3 日以内: Command of the Message (CoM) e ラーニング教材へのアクセス。
3. 2 週目: Sales Enablement Team が SQS のカレンダー招待と、Google Classroom の Sales Quick Start learning pathへのアクセスを送信。
4. SQS 参加後 1 週間以内: 13 週間の CoM Fast Start プログラムへのアクセス。
5. 最初の数週間: Sales Development Technical Development トレーニングへのアクセス。最初の 180 日以内に完了する必要があります — SDR の進行 に直接結びついています。

Sales Development オンボーディングの卒業

• GitLab 一般オンボーディング Issue を完了
• BDR/SDR 特定オンボーディング Issue を完了
• Google Classroom SQS 準備作業を完了
• SQS ワークショップに参加
• 13 週間の Command of the Message Fast Start プログラムを完了

Sales Development オンボーディングリソース

• チームページに自分を追加する
• ハンドブックの変更/編集を行う
• ハンドブック編集に関する質問？Slack の #handbook または #mr-buddies を使用。
• オンボーディングに関する質問？Slack の #new_team_members に入れてください。

マネージャーオンボーディングチェックリスト

初日前:

• オンボーディング Issue の ‘Manager’ タスクを完了（注: 一部のタスクは新人が開始する前に完了する必要があります）。
• 新人の初日の開始にウェルカムコールをスケジュール: オンボーディングの優先事項、カレンダー招待の洪水を管理する方法、ツールアクティブ化メール、SDR オンボーディングから期待されることをカバー。

新人が開始した後:

• オンボーディング Issue の残りの ‘Manager’ タスクを完了。
• 1:1をセットアップ。

新人の初日

新人の初日に、約 06:00am（現地時間）に GitLab にアクセスしてオンボーディングを開始する方法を詳細に説明したウェルカムメールを受け取ります。

マネージャーの責任

• SDR New Hire 1:1 Template
• BDR New Hire 1:1 Template

組織変更 Issue

組織変更 Issue は、こちらの基準に従って、People Operations チームによって移行日に開始されます。質問がある場合は Compass 経由で People Operations に連絡してください。

以下のいずれかが真の場合、People Operations は組織変更 Issue を開きます: 部門に変更がある（例: SDR/BDR が SMB Sales Team に移動）、Individual Contributor から Manager に変わる、Manager から Individual Contributor に変わる、チームを変更する。

休職

XDR が長期にわたって不在になる場合は、適切なプロセスに従ってください:

• Parental Leave
• Emergency Situations
• Unpaid leave

オフボーディング

完全なオフボーディングプロセス（自発的および非自発的）はオフボーディングハンドブックページで確認できます。

マネージャーオフボーディングチェックリスト: People チームのオフボーディング Issue のすべての ‘Manager’ タスクを完了。質問？#managers Slack チャネルを使用するか、Compass 経由で People Operations チームに連絡してください。

Sales Dev 引き継ぎ Issue: チームメンバーが GitLab を離れる、Sales Dev 組織を離れる、または別の BDR チームに転送される場合、そのチームメンバーの所属元チームのマネージャーは、Sales Dev Handover Issueを作成する必要があります。

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