AI SDRの失敗が送信ボタンの下で始まる理由
この1年、自律型AI SDRのベンダーは、ARRの水増しや顧客の解約をめぐって公に批判を受けてきました。ここで特定のベンダーの是非を論じるつもりはありません。ひとつには、彼らの帳簿を見ることができないためです。お話しできるのはパターンについてです。買い手側から見ても、同じことが起きているからです。
エージェントは送信します。大量に、速く、しかもそれなりに自然な文章で送ります。送信は最初から難しい部分ではありませんでした。AI SDRの失敗は、オペレーティングレイヤーで起こります。つまり、パイプライン定義、CRMのフィードバックループ、除外ロジックといった、何が良い成果なのかをエージェントに教える部分です。これらがなければ、エージェントは自分に見える唯一のもの、つまり活動量を最適化してしまいます。
そこでこの記事では、この3つの要素に名前を付け、それぞれが壊れる例を挙げ、私ならどう対処するかをお伝えします。扱うのは戦略レベルで、手順書ではありません。実際の構築は、社内に入り込んで一緒に進める人がいてほしい部分です。
AI SDRの下にあるオペレーティングレイヤーとは何か
オペレーティングレイヤーとは、何をリードと呼ぶのか、何をミーティングと呼ぶのか、何を行き止まりと見なすのかを決める、人が作ったルールとデータの集まりです。ここではこれを「下敷き(アンダーレイ)」と呼びます。SDRエージェントはその上に載っています。
構成要素は3つあります。
- パイプライン定義:何を有効なミーティング、商談、ステージ変更と見なすか。
- CRMのフィードバックループ:成果がどのように戻り、エージェントが何がうまくいったかを学べるか。
- 除外ロジック:決して連絡しない相手や、最初のシグナルが出た時点で外す相手を決めるルール。
人間のSDRは、下敷きが薄くても何とかなります。足りない部分を、朝会や案件レビュー、廊下での立ち話の中で吸収できるからです。エージェントには廊下がありません。
パイプライン定義:エージェントは与えられた数字を達成する
あるBtoB SaaSのチームが、エージェントにミーティングを獲得するよう指示したとします。ところが、ミーティングとは何かを誰も書き出していません。インターン相手の15分の通話は数えるのでしょうか。再設定されたドタキャンは2回と数えるのでしょうか。
エージェントは1か月で120件のミーティングを獲得します。ダッシュボードは見事な数字です。AEがそれらを引き受けると、3分の1は予算の決裁権もなく、現在取り組むべき課題もない相手です。契約上の指標がミーティング数だったため、ベンダーは成功と報告します。そして買い手は、パイプラインが動かなかったため、2四半期後に解約します。
私の実感では、これが多くのAI SDRの失敗の始まり方であり、公に取り沙汰される数字水増しの話の一部が生まれる経緯でもあります。誰かが嘘をつく必要はありません。数字が間違った階層で定義されていただけです。
解決策は地味です。定義を書き出し、CRMに選択肢が管理されたフィールドとして保存し、予約の時点ではなく、その後のステージでエージェントを評価します。HubSpotであれば、自由記述のメモではなく、選択肢を定義したプロパティにあたります。
CRMのフィードバックループ:成果がなければ学習もない
エージェントが改善できるのは、成果が戻ってくる場合だけです。良くも悪くも、ほとんどのCRMには古いステージや中途半端にしか埋まっていないフィールドが溢れています。私たちが話を聞く買い手は、SalesforceでアカウントとコンタクトのリレーションをSDRが更新する際に手作業のミスが起きると語ります。人間でも間違えるなら、同じレコードを読むエージェントはノイズから学ぶことになります。
例を挙げます。エージェントが、半年前にそのアカウントを離れたコンタクトにメールを送ります。リレーションが更新されていなかったためです。メールはバウンスするか、あいまいな返信が来ます。レコードには何も書き戻されません。翌週、エージェントはまた同じことを試みます。このループこそ、AI SDRの失敗の縮図です。自信満々の活動があり、学習はゼロです。
同じ隙間はAE側にもあります。あるお客様は、自社のアカウントエグゼクティブは契約時期と予算に注目し、課題の背景まで十分に掘り下げないと話してくれました。その結果、受注・失注の理由が薄くなり、どの課題が受注を予測したのかをシステムが知る手がかりがありません。誰も記録していないデータでターゲティングを学習させることはできません。
私ならまず、何かを購入する前に書き戻しの経路を監査します。どの成果が、どのフィールドに、誰によって、どれくらいの時間で入力されるのか。答えが「担当者による」であれば、それが最初のプロジェクトであり、エージェントのプロジェクトではありません。
除外ロジック:誰に連絡しないかを決めるルール
これが最も飛ばされやすい部分だと感じています。チームはICPを定義しても、除外条件を忘れがちです。既存顧客、進行中の商談、競合、チームがフォローできない地域、支払い能力のない小規模企業などです。
あるお客様は、EMEAへのアウトリーチは難しく、担当者も電話が得意ではないと話していました。別のお客様は、キャンペーンのワークフローに組み込まれた電話タスクをSDRが実行しないのではと懸念していました。こうした状況で除外ロジックのないエージェントを投入すると、チームが対応できないEMEAのアカウントに次々と送信し、誰もかけ直さないコールバックを予約してしまいます。ボリュームは増え、コンバージョンは下がり、全員がエージェントのせいにします。
ここでの経験則は手軽です。ICPの条件を1つ書くたびに、その隣に除外条件を1つ書いてください。包含条件が5つで除外条件がゼロなら、エージェントは指示の半分だけで動いています。そしてその半分の指示は、AI SDRの失敗の一般的な根本原因です。
AI SDRの失敗を避けるには、どの順序で導入すべきか
3つのフェーズがあり、順序こそが要点です。
- まず定義です。パイプラインのステージ、ミーティングの基準、除外条件を書き出し、CRMに実装します。無駄のない進め方なら2〜3週間です。
- 次にフィードバックです。成果フィールド、必須の書き戻し、そして失注理由が実態を反映しているかの週次チェックを整えます。
- 最後にエージェントです。対象を絞ったセグメントで始め、送信数ではなく作成された商談数で評価します。
この順序で進める理由は、後になって誰かがエージェントの行動の理由を尋ねたときに、人が書いたルールまでたどれるようにするためです。それがなければデバッグはできず、できるのは電源を切ることだけです。
これが、この問題がツールの問題ではなくRevOpsの問題である理由でもあります。RevOpsを仕事にしているなら、あなたは専門領域を持つプロジェクトマネージャーであり、これはひとつのプロジェクトです。定義に合意し、それを実装し、成果を計測できるようにします。ベンダー選びはその後であり、SalesforceやHubSpotのようなCRMであれば、そのすべてを保持できます。
AI SDRの失敗について、私にはわからないこと
自律型エージェントがいずれこれらのルールを自力で推論できるようになるのかについて、確かな答えは持っていません。そうなるかもしれません。ベンダーはそう言っていますし、モデルも進化し続けています。ただ私の経験では、優秀な新入社員でも定義は必要です。そしてエージェントは、上司のいない、動きの速い新入社員です。
また、私はどのベンダーの売上も監査できません。ですから、私の見方は評決ではなくパターンとして受け取ってください。言えるのは、AI SDRの失敗は下敷きが欠けている場所に現れること、そしてそれは半日あれば確認できることです。
いまエージェントの導入を検討しているなら、デモの前に自社のチームへ3つの質問をすることをお勧めします。何をミーティングと見なすのか、成果はどこに書き戻されるのか、誰には決して連絡しないのか。これらの答えに1分以上かかるなら、そこから始めてください。こうした取り組みへの私たちのアプローチについては、インサイトライブラリでさらに紹介しています。