実際に適切な HubSpot 取引に接続された着信コール

導入

HubSpot の通話データに関する標準的な問題は、データが到着するのが遅いか、不完全であるか、まったく到着しないことです。営業担当者は、事後に手動で通話のログを記録します。つまり、ログは、覚えたときに記録され、書きたいと思う詳細レベル (通常は文) で記録されます。 3 か月も経てば、パイプライン データは装飾的なものになります。電話がかかってきたのはご存知でしょう。どのコールが取引を動かしたかはわかりません。

統合の仕組み

Letsdial と HubSpot の統合は、CRM プラグイン レベルではなく、通信事業者レベルで機能します。 Letsdial 番号に着信通話が着信すると、システムは通話に応答する前に、発信者の番号を HubSpot の連絡先や会社と照合してリアルタイムで検索します。一致するものが存在する場合、その通話は正しい連絡先に関連付けられ、通話が終了すると、通話の詳細記録、通話時間、録音リンク、および AI によって生成された概要が取引タイムラインに自動的に書き戻されます。

担当者は、電話をかける前に、発信者の名前、会社、取引段階、最後のアクティビティなどの HubSpot コンテキストを画面上で確認します。 「また誰ですか?」と尋ねる代わりに、状況を理解しながら電話を受けることができます。最初の90秒間。通話後のメモは自動的に書き込まれます。

3ヶ月経って実際に変わったこと

パイプラインデータは誰も試さなくても緊密になった

統合を 1 四半期実行した後の顧客の報告で最も一貫しているのは、パイプラインのレポートが現実を反映し始めたことです。営業担当者が行動を変えたからではなく、ほとんど変化しませんでした。統合はスキップしていたデータを書き込んだだけです。以前は「デモの予約」と「提案の送信」の間にギャップが表示されていた取引タイムラインには、その間に発生した 3 件のインバウンド コールが期間と結果とともに表示されるようになりました。

インバウンドインテントの帰属が信頼できるようになりました

統合前は、インバウンドコールの最も一般的なアトリビューションモデルは「たまたま電話に応答した担当者」でした。その後、どのキャンペーンがインバウンド コールの量を増やしたか、どのコール トピックが成約取引と解約された取引に相関しているか、どの担当者が最も関心の高いアカウントからのコールを受けていたかを確認できます。これらには新しいインストルメンテーションは必要ありません。必要なのは、呼び出しを適切なオブジェクトにアタッチすることだけです。

営業担当者が実際に使用したデータ

通話前のコンテキスト画面では、プロンプトなしで機能担当者が言及したことが判明しました。応答する前に発信者の取引段階を知ることで、会話の切り出し方が変わりました。 「交渉」中の見込み客からの電話は、フォームに記入したばかりの見込み客からの電話とは異なる切り口を受け取ります。それは新しいスキルではありません。適切なタイミングで情報を目の前に置くだけです。

統合でできないこと

不明な発信​​者の連絡先は自動的に作成されません。不明な番号は、生の番号を含む属性のない通話として記録され、担当者または管理者がそれらを手動でリンクできます。これは意図的な選択でした。未知の受信番号からの連絡先の自動作成は、どの統合よりも時間を節約するよりも早く HubSpot データベースを汚染します。統合により、既存のものはさらに強化されます。レコードは生成されません。

設定

この統合は、HubSpot のネイティブ アプリ マーケットプレイスを通じて接続されます。 Letsdial ダッシュボードから接続を承認し、Letsdial 番号を対応する HubSpot パイプラインにマッピングすると、接続が開始されます。カスタム コード、Webhook 構成、IT チケットは必要ありません。ほとんどのチームは、接続した同じ午後に属性付きコールを実行しています。