%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png?width=130&height=39&name=%E6%9C%80%E7%B5%82Start%20Link%20(500%20x%20150%20px)%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png "StartLink"){kind=logo}
この記事の結論
HubSpotとIntercomは、顧客対応をどこに結び付けるかで選び方が変わります。顧客情報の一元管理か、チャット体験の設計かを先に整理することが比較の出発点です。
HubSpotとIntercomは、顧客対応をどこに結び付けるかで選び方が変わります。顧客情報の一元管理か、チャット体験の設計かを先に整理することが比較の出発点です。
「問い合わせの履歴が営業やマーケティングの情報とつながらず、担当者が毎回確認している」
「Webチャットは運用できているが、アプリ内の問い合わせにも同じように対応したい」
「AIボットを使いたいものの、回答の品質や費用をどう評価すればよいかわからない」
——こうした課題があると、機能表だけでは自社に合うサービスを判断しにくくなります。
HubSpotとIntercomのカスタマーサポートは、顧客対応を他部門の顧客データと結び付けるか、メッセンジャーを起点に設計するかという考え方に違いがあります。機能を比較するときは、問い合わせの受付からチケット対応、顧客情報の更新、その後の営業やCSへの引き継ぎまでを一続きの流れとして見ることが大切です。
本記事はHubSpotの「HubSpot完全ガイド」関連記事です。
この記事でわかること
HubSpotとIntercomの導入や見直しを検討するときに、機能名だけでなく現在の運用との適合性を整理できます。比較表を使い、問い合わせから顧客対応後の情報活用まで確認する観点を紹介します。
- 両サービスの基本的な違い — 顧客データを中心に据える考え方と、メッセンジャーを中心に据える考え方を比べます。
- チャット、AI、チケットの見方 — 機能の有無に加え、顧客対応の流れにどう組み込むかを整理します。
- 費用を見積もる観点 — シート費用とAI利用にかかる費用を分けて、自社の問い合わせ量に当てはめる方法を確認します。
- 選定と試行の進め方 — 先に課題を絞り、限定した業務から試して広げる手順を説明します。
HubSpotとIntercomは顧客対応の起点が異なります
両サービスは、問い合わせへの対応を支援する一方で、設計の起点が異なります。HubSpotはCRMとつながる顧客情報を軸にし、IntercomはWebサイトやアプリのメッセンジャーを軸にコミュニケーションを組み立てます。現在の問い合わせ管理が表計算や複数のツールに分散している場合は、まず情報の受け渡しがどこで発生するかを洗い出すと比較しやすくなります。
HubSpotはCRM上の顧客情報と対応を結び付けます
HubSpot Service Hubは、CRMを基盤にしたサービス機能です。チケット、ナレッジベース、ライブチャット、フィードバック収集、カスタマーポータルなどを通じて、顧客対応を管理できます。Marketing HubやSales Hubを利用している場合、マーケティングの接点や営業上の情報とサービス対応を同じ顧客レコードに関連付けて確認できます。
問い合わせが来たとき、担当者が別の表計算ファイルやメールを探して過去の経緯を集めているなら、情報の保管場所をまとめる価値があります。コンタクトや会社に対応履歴を結び付けると、誰がどの内容を確認し、次に何をするかをチームで追いやすくなります。入力項目を必要な範囲に絞り、チケットの分類や担当の決め方を定めておけば、個人の記憶に頼る運用を減らし、引き継ぎや新人の対応にも使える仕組みになります。
Intercomはメッセンジャーを中心に顧客との接点を設計します
Intercomは、Webサイトやアプリに設置するメッセンジャーを起点とした顧客コミュニケーションを特徴とします。顧客がサービスを利用している場面で質問を受け付けたり、行動をきっかけに案内を表示したりする使い方ができます。プロダクト内のコミュニケーションがサポート業務の中心なら、チャット体験の作り込みを比較軸にできます。
メッセンジャー上で対応できることと、営業やマーケティングの情報まで一元的に扱えることは、別の評価項目です。Intercomを選ぶ場合は、コンタクト情報や会話履歴をどこに保管し、他の担当者がどの手順で確認するのかを決めます。連携を検討する際には、顧客情報をどちらで管理・更新するかを明確にし、同じ項目を複数の場所で更新する手間が生じないようにします。
起点の違いを業務フローに当てはめて比較します
サービス選定では、機能単体ではなく問い合わせが顧客関係全体のどこに位置するかを見ます。リードの問い合わせから商談、顧客化、サポート対応、請求に関する問い合わせまでを並べ、情報が必要な部門と記録場所を明らかにします。
| 比較する視点 | HubSpotを中心にする場合 | Intercomを中心にする場合 |
|---|---|---|
| 問い合わせの起点 | CRMと関連付いた顧客情報や会話 | Webサイトやアプリのメッセンジャー |
| 対応履歴の活用 | マーケティングや営業の情報と一緒に参照 | Intercom内の顧客コミュニケーションを軸に活用 |
| 向いている優先課題 | 部門をまたいだ顧客情報の把握 | チャットを通じたリアルタイム対応 |
| 導入前に決めること | 顧客情報、チケット分類、担当ルール | メッセージ条件、履歴保管、連携先 |
HubSpotは問い合わせを顧客ライフサイクルの一部として追いやすく、Intercomはチャット接点を細かく設計しやすいという違いがあります。どちらを選んでも、チケットが解決した後に顧客情報を更新し、その情報を営業やCSが利用できる流れを定義します。
チャットとメッセンジャーは接点の種類で評価します
チャット機能の比較では、Web上で会話できるかだけでは判断できません。アプリ内にも窓口を置く必要があるか、顧客の行動に合わせた案内が必要か、対応履歴をどこに集約するかを確認します。機能表を読むときは、各機能が問い合わせの受付や対応後の記録にどう関係するかも合わせて考えます。
Webチャットとアプリ内メッセンジャーの違い
両サービスはWebサイトのチャットウィジェットに対応しています。アプリ内の窓口については、IntercomがiOSとAndroidのSDKに対応し、HubSpotはWeb向けとして説明されています。アプリ内にサポート窓口を埋め込みたい場合は、アプリの開発・運用と合わせて必要な対応を確認します。
| 機能 | HubSpot | Intercom |
|---|---|---|
| Webサイトチャットウィジェット | 全プランで利用可能 | 全プランで利用可能 |
| アプリ内メッセンジャー | 未対応（Webのみ） | iOS / Android SDK対応 |
| プロアクティブメッセージ | ワークフローで設定 | 行動トリガーで柔軟に設定 |
| チャットのカスタマイズ | 基本的なカスタマイズ | 高度なカスタマイズ（カラー、位置、アニメーション） |
| チャット → チケット変換 | 対応 | 対応 |
| チャット履歴の保存 | CRMタイムラインに統合 | Intercom内に保存 |
| 複数チャネル対応 | チャット、メール、フォーム | チャット、メール、SMS、WhatsApp、SNS |
製品仕様は契約プランや提供条件によって変わる場合があります。特にアプリ対応や連携方法は、導入時点で必要なチャネルと契約内容を公式の製品情報で照合し、必要な窓口が含まれている場合に候補として残します。
プロアクティブメッセージは表示条件まで設計します
顧客の行動に応じて先にメッセージを表示する運用では、配信できるかどうかだけでなく、何をきっかけに誰へ表示するかが重要です。HubSpotではワークフロー、Intercomでは行動トリガーを使った設定が挙げられています。オンボーディング案内や利用中の問い合わせ誘導を検討する際は、対象の行動と表示する情報を対応付けます。
| 設計項目 | 決める内容 |
|---|---|
| 対象者 | 顧客の状態や利用状況のどれを条件にするか |
| 表示の契機 | どのページ閲覧や行動をきっかけにするか |
| メッセージ | 案内、質問受付、有人窓口のどれを提示するか |
| 対応後の記録 | 会話や問い合わせをどの顧客情報に関連付けるか |
チャットの表示が増えすぎると、顧客が必要な案内を見つけにくくなることがあります。まず問い合わせが多い場面や案内が必要な手順に対象を絞り、対応状況を見て条件を調整します。
受信トレイで顧客情報と対応状況を確認します
以下の画面は、HubSpotの受信トレイの例です。左に受信箱のメニューと会話一覧、中央に選択中のウェブチャット履歴、右にコンタクト概要が表示されています。
この画面のように顧客情報が会話と同じ場所で参照できると、担当者が過去の経緯を別ファイルから探す場面を減らせます。問い合わせの種類、担当、対応状況を揃えておけば、チーム内で未対応案件を見つけやすくなります。
AIチャットボットは回答根拠と引き継ぎで比べます
AIチャットボットは、問い合わせへの回答を自動化するための機能ですが、導入するだけで応対品質が決まるわけではありません。参照するナレッジの内容、回答できない場合の対応、有人チームへの引き継ぎ方を一緒に設計します。製品の優劣を一つの解決率だけで決めず、実際の問い合わせで回答と引き継ぎを確認します。
HubSpotのカスタマーエージェントは既存のコンテンツを使って質問に自動回答し、初回設定時には14日間の無料利用を選べます出典。
| 機能 | HubSpot（Breeze Customer Agent） | Intercom（Fin AI） |
|---|---|---|
| AI自動応答 | ナレッジベースに基づく自動回答 | ナレッジベース + 学習データに基づく回答 |
| 回答精度 | 中〜高（設定次第） | 高い（GPT-4ベース） |
| 多言語対応 | 対応 | 43言語以上に対応 |
| 人間へのエスカレーション | 自動エスカレーション対応 | シームレスなハンドオフ |
| 料金モデル | プランに含まれる | 解決あたり$0.99（従量課金） |
| セットアップの容易さ | ナレッジベース接続で即座に利用可能 | コンテンツ設定後すぐに利用可能 |
ナレッジベースの品質が回答の土台になります
HubSpotのBreeze Customer Agentはナレッジベースの記事に基づいて回答し、IntercomのFin AIもナレッジベースや学習データに基づく回答として比較されています。回答品質を比べるときは、よくある質問への答えが記事に明記されているか、内容が更新されているか、顧客が使う表現で検索できるかを確認します。
| 機能 | HubSpot | Intercom |
|---|---|---|
| 記事の作成・管理 | Professional以上 | 全プランで利用可能 |
| カテゴリ・セクション分類 | 対応 | 対応（コレクション機能） |
| 検索機能 | 全文検索対応 | AI搭載検索 |
| 多言語対応 | 多言語記事の管理 | 多言語対応 |
| AIによる記事提案 | Breeze Assistantで補助 | Finが自動で関連記事を提案 |
| 分析・効果測定 | 記事閲覧数、問い合わせ削減率 | 記事のパフォーマンス分析 |
まず代表的な問い合わせを選び、回答に使われた情報が社内の正しい案内と一致するかを人が確認します。誤りがあればボットの指示だけを調整するのではなく、参照元の記事の不足や古さも見直します。ナレッジが整っていない段階では、有人対応を残しながら限定した問い合わせで試す方法が現実的です。
人が判断する範囲とAIに任せる範囲を分けます
AIは、ナレッジに基づく定型質問への回答や、問い合わせ内容の整理を支援できます。一方で、例外対応、契約や請求に関わる判断、顧客との重要な調整をどこまで自動化するかは、組織側が決める必要があります。最初は回答案や分類を担当者が確認する形にし、問題なく処理できる範囲を把握してから自動応答の対象を見直します。
| 業務 | AIに任せる候補 | 人が確認する内容 |
|---|---|---|
| よくある質問 | ナレッジに基づく回答案 | 参照内容が現行の案内と一致するか |
| 問い合わせ分類 | 内容の要約や種別の振り分け | 担当部署や優先度が適切か |
| 対応の引き継ぎ | 会話情報の整理 | 顧客への説明や個別判断が必要か |
ナレッジにない回答をAIに補わせる運用は避けます。回答できない場合に有人窓口へ移る条件を定め、担当者が引き継いだ会話と顧客情報を確認できる流れを作ります。
公表された解決率だけで比較しないようにします
IntercomはFin AIの解決率に関する数値を公表していますが、対象条件や測定方法を示す出典URLはありません。そのため、特定の数値を自社の期待値として置くのではなく、同じ問い合わせ例を両サービスで試し、回答の正確さ、有人への引き継ぎ、顧客情報への記録を確認する方法が適しています。
比較時には、AIが回答したかどうかだけでなく、回答後に顧客が解決したと判断できるか、担当者への引き継ぎが滞らないかを記録します。問い合わせの種類ごとに結果を分ければ、どの業務から自動化を広げるかを判断しやすくなります。
チケット管理とナレッジは運用ルールまで比較します
問い合わせをチケットとして記録することは、対応の進捗を管理し、顧客とのやり取りを組織の情報として残す手段です。機能の有無だけでなく、どの分類やステージを使うのか、担当の割り当てとレポートをどうつなぐかを確認します。小さく始める場合は、まず問い合わせの受付から解決までの一つの流れを定義し、運用できてから分類を増やします。
| 機能 | HubSpot | Intercom |
|---|---|---|
| チケットの作成・管理 | 全プランで利用可能 | 全プランで利用可能（Tickets機能） |
| チケットパイプライン | 複数パイプライン対応 | カスタムワークフロー |
| SLA管理 | Professional以上 | 全プランで利用可能 |
| 自動割り当て | ワークフローで設定 | ルールベースの自動割り当て |
| レポート・分析 | 詳細なサービスレポート | Intercomレポート |
| CRM連携 | ネイティブ統合 | API / サードパーティ連携 |
問い合わせ種類に合わせてチケットを分けます
HubSpotでは複数のチケットパイプラインを使い、「技術サポート」「請求関連」「機能リクエスト」のように問い合わせの流れを分ける方法があります。Intercomではカスタムワークフローやルールベースの割り当てが挙げられています。どちらの場合も、分類が担当者の判断に委ねられすぎないように、問い合わせ種別と次の対応を対応付けます。
| 問い合わせ種別 | 管理する情報の例 | 次の対応 |
|---|---|---|
| 技術サポート | 対象サービス、発生状況 | 技術担当へ割り当て |
| 請求関連 | 対象の契約や請求内容 | 請求担当が確認 |
| 機能リクエスト | 要望の内容、関連する顧客情報 | CSや製品担当へ共有 |
分類項目を増やしすぎると、入力の負担が上がり、実際に使われる情報が限られる可能性があります。最初は担当の振り分けやレポートに必要な項目を優先し、使われ方を見て追加します。
チケットのステージと担当条件を決めます
契約内容によって利用できる機能や条件が異なるため、導入時は必要なパイプライン設定が自社の契約範囲に含まれるか確認します（出典：Set up and manage object pipelines）。
ステージは、受付、調査中、顧客への回答待ち、解決のように、現場が次の行動を判断できる状態にします。ステージごとに担当と必要情報を決め、更新が止まったチケットを誰が確認するかも定めます。営業の取引パイプラインと同様に、状態の意味が担当者ごとに変わらないように定義を共有すると、レポートを見たときに対応状況を揃えて把握できます。
ナレッジベースを問い合わせ対応の循環に組み込みます
ナレッジベースは記事を公開するだけでなく、顧客が自己解決できなかった理由を次の改善に使う仕組みとして考えます。問い合わせ内容をチケットに記録し、繰り返し発生する質問や説明不足を見つけたら、記事を更新します。更新後は記事への案内やボットの回答を見直し、同じ問い合わせがどのように扱われたかを確認します。
| 運用段階 | 確認すること | 次に行うこと |
|---|---|---|
| 問い合わせ受付 | 顧客が検索した情報、質問の分類 | チケットに内容を記録 |
| 対応 | 既存記事で解決できたか | 不足情報を特定 |
| ナレッジ更新 | 説明が正確で検索しやすいか | 記事を追加または修正 |
| 効果確認 | 類似問い合わせの内容に変化があるか | 分類や記事の案内を調整 |
問い合わせから得た情報をナレッジに戻し、営業やCSにも必要な内容を共有すると、サポートを顧客ライフサイクルの中で活用できます。単にチケットを閉じるのではなく、解決理由や顧客の要望を次の顧客対応に生かす流れを作ります。
料金はシート費用と利用量を分けて試算します
ツールの費用は、月額のシート料金だけでは比較しきれません。掲載されている価格は出典URLと基準時点が示されていないため、本記事では金額を再掲しません。見積もりでは、必要な利用者、AI機能の課金条件、連携や運用にかかる作業を分けて確認します。
料金表は比較項目として読み直します
HubSpot Service HubとIntercomの料金を比較する際は、プランの提供条件やAIボットの課金方法を、各社の公式料金ページで確認してください。
| 項目 | HubSpot Service Hub | Intercom |
|---|---|---|
| 無料プラン | 基本的なチケット管理 + チャット | なし（14日間トライアル） |
| エントリー | Starter: 月額$20/シート〜 | Essential: 月額$39/シート〜 |
| 中間 | Professional: 月額$100/シート〜 | Advanced: 月額$99/シート〜 |
| 上位 | Enterprise: 月額$150/シート〜 | Expert: 月額$139/シート〜 |
| AIボット料金 | プランに含まれる | Fin: $0.99/解決 |
| 従量課金要素 | データエージェント（クレジット） | Fin AI（解決あたり課金） |
費用を見積もる際は、利用者数、必要な機能、AIの利用条件を別々に整理します。シート単価が低く見えても、必要な上位機能や追加利用があれば総額は変わります。反対に、問い合わせ量に応じた課金があっても、有人対応の工数が変わる可能性を含めて評価する必要があります。
AIの課金方法と問い合わせ量を分けて考えます
HubSpotのAIボットはプランに含まれる形、IntercomのFin AIは解決あたりの従量課金として比較されています。実際の条件が契約やプランで異なる可能性を踏まえ、導入時にはAI機能の対象、課金が発生する条件、利用状況を確認できるレポートの有無を公式情報で照合します。
試算表には、現在の月間問い合わせ量、AIに任せる候補の問い合わせ、有人への引き継ぎが必要な割合を自社の実績から記入します。仮定を置いた場合は実績値と分けて記録し、試行後に置き換えます。費用だけで決めず、削減できた対応工数や顧客への回答の質も同時に見て、業務効率化につながるかを判断します。
総コストを同じ条件で比較します
二つのサービスを比較する場合は、同じ利用者数と同じ問い合わせパターンを前提にします。必要な連携設定、ナレッジ記事の整備、担当者の運用時間も含めて比較すると、料金表だけでは見えない導入後の負担を把握できます。
| 比較項目 | 試算に使う情報 |
|---|---|
| 利用者 | 対応に参加する担当者と必要な権限 |
| 問い合わせ | 現在の件数、チャネル、問い合わせ種別 |
| AI利用 | 自動回答候補、引き継ぎ条件、課金の仕組み |
| 初期運用 | 顧客データの整理、ナレッジ整備、設定作業 |
| 継続運用 | 記事更新、チケット分類、結果確認にかかる作業 |
問い合わせ量の増加だけを根拠に将来費用を断定するのではなく、実績と試行結果を分けて計算します。見積もり条件が揃わない場合は、差額の結論を急がず、先に必要機能と利用者を確定させます。
自社に合うサービスは優先課題と運用範囲から選びます
サービスの選択は、企業規模だけでは決められません。顧客情報を部門間で共有する課題なのか、アプリ内のチャット体験が必要なのか、AIによる回答をどこまで任せたいのかを整理します。導入後の業務フローに沿って候補を比べ、必要な機能だけを試すと、設定や運用の負担を抑えて判断材料を得られます。
HubSpotを中心に検討するケース
HubSpotをすでにマーケティングや営業で使い、顧客対応を同じ情報基盤につなげたい場合は、Service Hubを候補にできます。コンタクトや会社の情報にチケットと会話を関連付け、顧客がリードから顧客になった後のサポート履歴も追いやすくなります。
| 優先課題 | HubSpotを候補にする理由 |
|---|---|
| 営業、マーケティング、CSの情報が分散 | CRM上の顧客情報と問い合わせを関連付けて扱える |
| 問い合わせと営業履歴を同時に確認したい | 顧客のタイムラインを対応時に参照できる |
| チケットの分類やレポートを整えたい | チケット管理とCRM情報を合わせた運用を検討できる |
| AI利用の費用条件を管理したい | 契約プランとAI機能の条件を含めて比較できる |
顧客数の規模だけで適否を決めることはできません。既存のHubSpot環境でどの情報が管理されているかを確認し、重複登録や履歴の分断を減らせる見通しがあるかを評価します。
Intercomを中心に検討するケース
チャットを通じたリアルタイムサポートが業務の中心で、Webサイトやアプリの利用中に顧客とコミュニケーションを取りたい場合は、Intercomが候補になります。行動に合わせた案内やメッセンジャーを使う体験を重視し、顧客がどこでサポートを必要とするかを設計します。
チャット上での対応情報を営業やCSがどのように利用するかは、別に決めておきます。HubSpotとの連携を含めて検討する場合は、同期対象、更新元となるシステム、履歴を確認する担当者を整理します。顧客データを二重に更新する状態が残るなら、連携の運用負担も選定評価に含めます。
両方を候補にする場合は役割と記録先を決めます
CRMや営業管理をHubSpot、チャット対応をIntercomに分けて使う方法もあります。併用すると各サービスの得意な部分を使える一方で、同じ顧客情報を両方で扱う可能性があります。どちらを問い合わせ窓口にするかだけでなく、対応履歴やコンタクト情報の基準となる記録先を定めます。
| 設計項目 | 決めること |
|---|---|
| 顧客情報の基準 | コンタクト情報を更新する主なシステム |
| 会話履歴 | どの履歴をどの担当者が確認するか |
| チケット運用 | 問い合わせの受付、割り当て、解決の管理先 |
| 同期対象 | 連携する項目と更新方向 |
| 例外対応 | 同期できない情報を誰が補うか |
併用を前提にせず、まず一つの問い合わせ種類でデータの流れを確認します。顧客情報が重複せず、担当者が履歴を追えて、対応後の情報が関係部門へ届くことを確認できたら対象を広げます。
実名事例は自社の優先課題と照らして読みます
AtlassianがIntercomを、Suzukiのヨーロッパ法人がHubSpotを採用した事例があります。Atlassianの事例はプロダクト内の顧客コミュニケーション、Suzukiの事例はマーケティングから営業、アフターサービスまでの一貫管理という観点で紹介されています。
これらの事例は、自社と同じ条件で効果が出ることを示すものではありません。採用企業名だけを選定理由にせず、自社で解決したい課題がチャット接点なのか部門間の顧客情報なのかを照らし合わせます。自社の問い合わせ経路や記録の流れに当てはめて、必要な要件を具体化することが判断につながります。
よくある質問
HubSpotとIntercomを併用できますか？
併用する構成は可能です。CRMや営業管理をHubSpot、カスタマーサポートのチャットをIntercomに分ける案があります。導入時は同期する情報と更新元を決め、コンタクトや会話履歴を二重管理しない流れを設計します。
IntercomからHubSpotへ移行するとき、どのデータを引き継げますか？
コンタクト、チャット履歴、チケットデータをエクスポートしてHubSpotへインポートする方法があります。一方、会話履歴やカスタム属性をすべて同じ形で移せるとは限りません。移行前に必須データ、参照用データ、移行対象外の情報を分け、実データの一部で項目対応を確かめてから進めます。
AIボットはどちらの回答精度が高いですか？
解決率に関する記述は、条件を確認できる出典URLがないため、現在の性能を比較する根拠としては扱えません。両サービスで同じ問い合わせ例を試し、回答の根拠、内容の正確さ、有人への引き継ぎを確認します。ナレッジの記事が古い場合は、ボットの設定だけでなく記事も更新します。
日本語サポートはどちらが充実していますか？
HubSpotは日本語のサポート、ドキュメント、トレーニングがあり、Intercomは日本語での製品利用やFin AIの応答が可能と説明されています。ただし、サポート窓口の言語や提供範囲は契約や時期によって変わる可能性があります。契約前に問い合わせ窓口、対応言語、利用できるドキュメントを各社の公式情報で確認し、自社の支援要件と照らし合わせます。
カスタマーサクセスの観点ではどちらを選べばよいですか？
顧客の営業履歴やサービス対応を同じ顧客情報に結び付けたい場合は、HubSpotを候補にできます。チャットでのサポート体験やプロダクト内の案内を中心に改善したい場合は、Intercomを候補にできます。どちらの場合も、顧客の状況をどのデータで判断し、対応結果を誰が次のアクションに使うかを先に定義します。
まとめ
HubSpotとIntercomの比較では、顧客情報を営業やマーケティングと一元管理するか、チャットを起点に顧客との接点を設計するかを最初に整理します。チケット、AI、ナレッジベースは機能表だけで選ばず、問い合わせの受付から顧客情報の更新、関係部門への共有までつながるかを見ます。AIの回答はナレッジの品質と人への引き継ぎを含めて評価し、料金はシートと利用量を分けて試算します。
まずは問い合わせの現状整理から始めます。自分たちで進める次の行動は、次の通りです。
- 現在の問い合わせをチャネルと種類ごとに分け、対応履歴の保存先を書き出します。
- 顧客情報を誰が更新し、営業やCSがどの情報を参照するかを決めます。
- 代表的な問い合わせを選び、候補サービスでチケット、ナレッジ、AIの回答と引き継ぎを試します。
CRMを活用した業務効率化やAIとの連携に関するご相談は、StartLinkまでお気軽にお問い合わせください。
あわせて読みたい
関連記事として、次の記事も参考にしてください。
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
