セールス開発

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

アウトバウンド SLA

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

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

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

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

リードへのアクセス

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 です。以下の 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 かつ Compensation Target Account でない場合、BDR Prospecting Status はまず SDR Hold に 14 日間設定される場合があります。opp が作成されない場合、BDR 所有権で Actively Working / Showing Intent に自動遷移します。

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

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

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

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

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

Account オブジェクトで、Ultimate Parent Account がターゲットと一致するすべてのアカウントを確認します。それらのアカウントのいずれも、Customer Status が Customer または Former Customer であってはならず、Total CARR がゼロより大きくてはいけません。

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

Opportunity オブジェクトで、同じ Ultimate Parent Account にリンクされたすべての opp を確認します。以下のすべてが同時に成立する opp があってはなりません: Order Type = Renewal、opp がクローズしている、勝利しなかった、Close Date が過去 180 日以内にある。

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

Opportunity オブジェクトで、ステージや注文タイプに関係なく、同じ Ultimate Parent Account にリンクされたオープンレコードがないことを確認します。

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

→ いずれかの条件が失敗 → アカウントは 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 つのペルソナにまたがる。
• シーケンスと戦略ラベル: どの Outreach シーケンスを使用するか記載し、対応する BDR Account Strategy 値を設定します。

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

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

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

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

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

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

既存顧客アカウント内の成長: 追加のビジネスユニットを特定するために SAE/ISR と戦略的にパートナーを組みます。更新日を会話を拡大するための興味深いイベントとして活用します。

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

子または子会社のアカウントが 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、ISR のリードと案件を誰が所有して扱うべきかを記述します。FY27 リード/コンタクトルーティングロジック（BDR、SDR、ISR、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 のリーダーとシニアリーダーにエスカレート。

認定中のテリトリー発見

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

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

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

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

→ テリトリー情報が矛盾している → 候補となる各テリトリーから AE をチャタリングし、進める前に所有権を解決させます。

案件を作成し 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、Panos、Ed）をチャタリング。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 へのダウングレード

トライアル延長を提出するには: 社内リクエストフォーム → “GitLab L&R internal request for global customers” → “Extend a GitLab.com trial”。SaaS のみ — self-managed では機能しません。

トライアルを Ultimate から Premium にダウングレードするには: 同じフォーム → “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 は私たちの AI ワークフォースプラットフォームで、SDR および BDR チーム向けにリードのリサーチ、優先順位付け、重複排除を自動化するために使用されます。現在、2 つのエージェントが稼働しています。

Mona は MQL リサーチアシスタントです。Salesforce でリードが MQL ステータスに到達すると、Mona は企業リサーチ、本人確認、購買シグナルのコンテキストを自動的にまとめ、傾向スコアと推奨される次のアクションをリードレコードに直接書き込みます。

Doope は重複排除アシスタントです。一致するリードレコードとコンタクトレコードをチェックし、リサーチフィールドで競合をフラグ付けするとともに、重複レコードへのリンクを提示するため、担当者はシーケンス化の前にそれらを解消できます。

RelevanceAI エージェントの使用

Relevance Priority および Relevance Next Action フィールドは SDR の Z-lead ビューに表示され、個々のレコードを開かずにトリアージして対応できます。リードをクリックすると、本人確認の信頼度、企業コンテキスト、採用シグナル、評価の根拠を含む完全な Relevance Research フィールドを確認できます。Relevance Summary フィールドは、主要なフラグをコンパクトにまとめたものを提供し、すばやく参照できます。

Mona の出力は担当者の判断の代わりにはなりません — 出発点として扱ってください。リサーチが不完全に見える場合や評価が適切でないと思われる場合は、Relevance Last Updated タイムスタンプを確認し、パターンがあれば Slack の #sales-development-relevance-ai で提起してください。

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 は次に 48 時間以内に行動する必要があります:

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

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

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

6QA アカウントが非 FO かつ Compensation Target Account でない場合、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 ドキュメント

意思決定者の発見質問:

• “Who gets involved while evaluating a tool at [company]?”
• “Would you expect anyone to challenge your initiative — can I help by connecting with anyone else on your end?”
• “If you as a [title] wanted to purchase GitLab, what process would you need to follow internally, and how can we help you navigate it?”
• “What challenges do you expect to face when pitching this change internally? Who has a say, and what do they care about most?”

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

月次監査プロセス

毎月、Sales Dev のメンバーにクレジットされたすべての opportunity に対して完全な監査が実施されます。参加は必須です。SDR は SDR を監査し、BDR は BDR を監査します。ランプ四半期中のチームメンバーは監査者であることから免除されます。

必須 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 コラボレーションプロセスは、クロスファンクショナルコラボレーションを最大化する精神で従う方法です。フィールドマーケターが入力する 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% 達成 + Our Three Pillars の遵守

→ 月 2: 90% 達成 + Our Three Pillars の遵守

→ 月 3 以降: 100% 達成 + Our Three Pillars の遵守

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

Our Three Pillars

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、Ed Bao、または Brian Tabbert にタグ付け — Sales Support に直接タグ付けしないでください。(2) 過去 60 日以内の双方向のアクティビティを示す SFDC レコードへのリンク。コールノートは、後ではなくコール時に Qualification Notes フィールドに入力されている必要があります。(3) 購入決定に影響を与えた方法を説明します。

RoE のよくある質問

Q: BDR は重複アカウントをフラグすべきですか？ A: はい。BDR は自分でアカウントをマージできません — @Sales 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 の Ed が支援できます。

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 チームによって移行日に開始されます。質問がある場合は HelpLab 経由で People Operations に連絡してください。

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

休職

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

• Parental Leave
• Emergency Situations
• Unpaid leave

オフボーディング

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

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

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

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