Gmail 内に組み込まれた HubSpot 搭載 CRM が、ある営業チームのフォローアップの進め方を変えた
ある営業リーダーは Manus を使って、HubSpot の情報をチームがすでに業務で使っている場所、つまり Gmail と Slack に届けるカスタムワークフローを構築しました。目的はシンプルです。見込み客がチームにメールを送ってきたとき、担当者がその人物が誰なのか、会社がすでに HubSpot に登録されているか、その会話が進行中の商談に関係するのかを確認するために、受信箱を離れる必要がないようにすることです。
Manus を使って、この営業リーダーは適切な HubSpot の情報をメールにより近づけるワークフローを構築しました。完成したシステムは HubSpot、Gmail、Slack を 1 つのワークフローに統合します。HubSpot に情報が存在する場合は Gmail メッセージにラベルを付け、Gmail 内に役立つアカウント情報を表示し、エンタープライズリードに対応が必要な場合は Slack でチームに通知できます。
プロジェクトは日常的な営業の課題から始まった
プロジェクトは実践的な営業上の問いから始まりました：メールに返信する前に、担当者は何を知っておくべきか？
例えば、acme.com の Priya からチームにメールが届いた場合、担当者は彼女が既に HubSpot に存在するか、Acme がターゲットアカウントかどうか、進行中の商談があるか、そして関係性を誰が担当しているかを素早く把握する必要があります。これらのシグナルにより、返信を急ぐべきか、ルーティングするべきか、別の方法で扱うべきかが決まります。
Manus はその問いを実用的なデータレイヤーに変換するのに役立ちました。HubSpot はすでにこの情報をコンタクト、会社、商談、所有者レコードに保存しています。課題は、返信のタイミングで実際に重要なフィールドを特定し、それらを Gmail 内でアクセスできるようにすることでした。
これにより問題は、シンプルなシグナルのセットに整理されました：誰がメールを送ったか、その人がどの会社に属しているか、その会社が既知であるか、進行中の商談があるか、そしてアカウントを誰が担当しているか。これが Gmail ワークフローの基盤になりました。
Gmail 内のブラウザ拡張機能とラベル
小さなプロダクトの判断によって、このワークフローは担当者にとって理解しやすいものになりました。Gmail のラベルは複雑なスコアリングシステムとしてではなく、シンプルなシグナルとして使われました。
この架空のモックアップでは、ラベルがシグナルです。担当者がクリックすると、ブラウザ拡張機能が開き、返信前に必要な基本的なリードまたは顧客情報が表示されます。
例えば、Acme の Priya がチームにメールを送り、Acme がすでに HubSpot に存在していた場合、メールにはそれに応じたラベルが付けられます。送信者がすでに顧客である場合、担当者はより多くのアカウント履歴を踏まえて返信できます。送信者が進行中のエンタープライズ商談に関連している場合、担当者は返信を優先できます。送信者が所有者のいない会社に属している場合、チームは返信前に担当者を割り当てる必要があるかもしれません。
メールにラベルが付けられると、営業担当者はラベルをクリックして拡張機能を開き、受信箱内で関連する HubSpot の詳細を確認できます。
Slack でチームが重要なリードに対応できるように
Gmail は 1 人の担当者がより良い情報をもとに返信するのに役立ちました。Slack は重要なリードへの対応が必要なときにチームが連携するのに役立ちました。
このワークフローでは、Manus は HubSpot からのエンタープライズインバウンドリードについて Slack 通知を送信する Slack ボットを構築しました。Slack メッセージはチームに、適合度の高い企業から問い合わせがあったことを伝え、会社名を含め、想定される所有者を示し、メールスレッドや関連レコードへのリンクを提示できます。
例えば、ターゲットアカウントからエンタープライズの見込み客がメールを送り、所有者が割り当てられていない場合、Slack がチームに通知できます。これにより、リードが 1 人の受信箱に埋もれてしまうのではなく、グループ全体で見えるようになります。
Slack によって、同じリード情報がより広いチームに可視化されました。適合度の高いリードを、見過ごされる前に確認、割り当て、フォローアップすることができました。
このプロセスから他のチームが学べること
このプロジェクトが成功したのは、HubSpot、Gmail、Slack をそれぞれ独立したレイヤーとして扱ったからです。各レイヤーは個別に構築され、単独でテストされた後、チーム既存のセールス活動に適合するワークフローへと統合されました。
最初のレイヤーは HubSpot のデータモデルでした。チームは、フォローアップの瞬間に実際に有用なフィールド、たとえば連絡先のアイデンティティ、会社の照合、担当者、商談状況、リードソース、プラン、次のステップなどを決定する必要がありました。Manus は有用な HubSpot フィールドを特定し、ワークフローの他の部分で利用できる同期データベースを作成するために使用されました。
2 つ目のレイヤーはアクセスに依存していました。このケースでは、チームは Google Workspace を利用していたため、Gmail の認証は Google auth を通じて行えました。これは重要でした。なぜなら、ワークフローにはメッセージを読み取り、送信者を HubSpot 由来のデータベースと照合し、カスタムルールに基づいてラベルを適用する権限が必要だったからです。次に、Manus を使用してそれらのルールに従ってメールを自動的にタグ付けしました。
3 つ目のレイヤーは Gmail 側のエクスペリエンスでした。ラベルが機能するようになった後、Manus は HubSpot スタイルのアイコンを表示し、関連するリードや顧客の詳細を Gmail 内に読み込むブラウザ拡張機能の構築に使用されました。同じビルドには、ホストプラグイン、ログインウェブサイト、ユーザー認証フローなどのサポート要素も必要でした。これらの作業は Manus 内で別のレイヤーとして処理され、その後システムの他の部分と統合されました。
他のチームに向けた実用的な構築のヒントは、まずアクセスレベルを確認し、次に最小限の有用なフィールドを定義し、ラベルのロジックをテストして、可視化されたインターフェースを構築することです。いずれかのレイヤーが欠けていると、エクスペリエンスは担当者にとって信頼できないものになるか、チームが採用するには難しすぎるものになります。
