%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チャットボットは、問い合わせの受付から担当者への引き継ぎまでをチャットフローでつなぐ機能です。最初に対応範囲と引き継ぎ条件を決めると、運用に沿った設計になります。
HubSpotチャットボットは、問い合わせの受付から担当者への引き継ぎまでをチャットフローでつなぐ機能です。最初に対応範囲と引き継ぎ条件を決めると、運用に沿った設計になります。
「サイトの問い合わせには気づいているが、その場で返せる人がいない」「チャットを置きたいが、質問を何段も設定すると更新が大変そう」「AIで回答できる内容と、人が対応する内容をどう分ければよいのか」
HubSpotのルールベースのチャットボットは、Webサイトの訪問者に質問と自動応答を表示し、情報収集やサポートチケットの作成に利用できます。Breezeを使うCustomer Agentは、コンテンツとCRMデータを使って質問に回答します。（出典：ルールベースのチャットボットを作成する）
チャットで得た情報をコンタクトに結び付け、その後の取引や顧客対応に引き継ぐには、設問・保存先・担当者の動きを合わせて設計します。チャット単体を設置して終わりにせず、問い合わせ受付から顧客対応までの流れに置くことがポイントです。前提となるService Hubの考え方はService Hub完全ガイドで解説しています。
この記事でわかること
チャットボットの導入や見直しを考える際に、問い合わせをどの経路へ進めるか、何を公開前に確かめるか、運用後にどの記録を見て修正するかを確認できます。
- チャットの種類と利用条件 — 訪問者の用件に応じ、ライブチャット、ルールベースのチャットボット、AI応答を選ぶ基準を説明します。
- チャットフローの作成手順 — 受付内容から質問と次の処理を決め、表示条件と各分岐を確認するまでの順序を整理します。
- 質問分岐とCRM連携 — 質問で得た情報の保存先と担当者の確認場所を対応させ、引き継ぎ時の抜けを防ぐ考え方を紹介します。
- AI応答と有人対応の使い分け — 参照情報で答えられる質問と、個別判断が必要な問い合わせの境界を決めます。
- 運用改善の進め方 — 会話ログと担当者の対応を照らし合わせ、質問を直すか、案内を追加するか、有人対応を維持するかを判断します。
HubSpotチャットボットの種類と役割
HubSpotでは、訪問者と担当者が直接やり取りするライブチャットと、設定したルールに沿って質問やアクションを進めるチャットボットを使い分けられます。
問い合わせの受付から解決までを考え、どの段階を自動化するか決めてから種類を選びます。AI応答の利用条件は、ルールベースのボットとは別に確認します。
選択に迷ったら、まず問い合わせの終わり方を確認します。
- 担当者が事情を聞いて判断する ── 有人対応へ進みます。
- 用件を選んでもらって担当先を決める ── 定型フローへ進みます。
- 整備済みの公開情報を参照して答える ── AI応答の検討へ進みます。
同じ窓口でも、受付は定型フロー、個別判断は担当者という組み合わせが考えられます。
ライブチャットとルールベースの違い
ライブチャットは担当者が訪問者と会話する窓口です。ルールベースのチャットボットは、事前に用意した質問や回答、分岐に基づいて案内し、情報収集やチケット作成、ミーティング予約へ誘導します。
| 種類 | 主な役割 | 向いている場面 |
|---|---|---|
| ライブチャット | 担当者が会話を受けて応答 | 個別事情を聞いて案内する問い合わせ |
| ルールベースのチャットボット | 決めた質問や条件に沿って進行 | 用件の分類、情報収集、定型案内 |
| AI応答 | 参照コンテンツに基づく回答を目指す | 公開情報を使う問い合わせ対応 |
ルールベースのチャットボットは全プランで作成できます。AI応答を組み合わせる場合は、利用する製品の設定要件を公式資料で確認します。
要件を満たしていても、回答に使う情報が古い、または担当者が内容を確認できない場合は、先に参照元を整えます。
チャットフローを業務のどこに置くか
チャットフローは、訪問者の問い合わせを受け、内容をコンタクト情報やチケットに結び付ける入口です。
- 営業相談 ── 用件を記録して担当者につなぎ、その後は取引として進捗を管理します。
- サポート問い合わせ ── チケットを作成し、担当者が対応状況を更新します。
例えば、相談の種類ごとに受付の経路を次のように決めます。
- 製品ページからの営業相談 ── 相談内容と連絡先を受け取り、営業担当が確認するところまでを受付の経路とします。
- 利用中の問題についての相談 ── 症状を受け取り、サポート担当がチケットで対応を続ける経路にします。
どちらも、チャットの最後に案内を表示しただけで終わらず、担当者が次に確認する場所を決めておきます。
以下の画面は、HubSpotのチャットフロー一覧の表示例です。作成したフローを確認する際は、名前だけでなく、対象ページと受付後の担当先が運用の想定に合っているかを見ます。
まず自動化する範囲を絞る
最初から全ての問い合わせに自動回答させる必要はありません。受付後に「営業相談」「サポート」「その他」を選んでもらい、担当先や次の行動を明確にするだけでも、情報が担当者に届く仕組みを作れます。
入力項目を増やしすぎると、訪問者が途中で離れたり、運用側が使わない情報まで集めたりする可能性があります。最初は担当者が振り分けに使う用件と、返信に必要な連絡先などに絞ります。
追加の質問が必要か迷ったら、その回答によって保存先、担当先、次の案内のいずれかが変わるかを確かめます。変わらなければ、担当者が引き継ぎ後に尋ねる方法も検討します。
チャットフローの作成手順
チャットフローは、訪問者との会話の順序と、それぞれの回答後に行う処理を組み合わせて作成します。
- HubSpotの管理画面からチャットフローを作ります。
- 目的に合うテンプレートまたはカスタムフローを選びます。
- 公開前に、表示場所と分岐の両方を確認します。
設定に入る前に、現在受けている問い合わせを用件ごとに並べ、それぞれについて次の項目を書き出します。
- 訪問者に尋ねること
- 担当者が確認する場所
- 担当者が取る次の行動
この対応が決まってから画面で分岐を作ると、質問だけ増えて処理先が決まらない状態を避けられます。
新しいチャットフローを用意する
HubSpotのチャットフロー画面を開き、新しいフローを作成します。
- Webサイト上で使うフローを選択します。
- ルールベースのチャットボットまたはライブチャットなど、用途に合った形式を指定します。
画面上のメニュー名や利用できるテンプレートは契約や画面更新で異なることがあるため、実際の画面に表示される選択肢を基準にします。テンプレートには、次のようなものがあります。
- 訪問者の用件を受けるもの
- 見込み客の情報を確認するもの
- ミーティング予約やチケット作成につなぐもの
どのテンプレートを選ぶ場合も、最初に問い合わせ後の担当者と処理を決めておくと、質問が目的のない情報収集に広がりません。
テンプレートの質問が自社の受付方法と合わない場合は、その質問の回答を誰がどう使うかを確認してから残すか決めます。
冒頭メッセージと質問を設定する
冒頭では、チャットでできることを短く伝え、訪問者が選びやすい質問を置きます。例えば「ご相談内容を選んでください」と案内し、次のような選択肢を示します。
- 「製品について」
- 「サポートについて」
- 「担当者に相談したい」
質問は回答を受けて次の処理が変わるものから作ります。使わない質問や後で活用先が定まらない質問は、初期フローから外しておくと保守しやすくなります。
選択肢に当てはまらない相談を受ける経路も用意し、自由記述を誰が確認するかまで決めます。
回答ごとに次のアクションを決める
各回答の後に表示する案内や処理を選びます。例えば、製品の相談なら関連情報を案内したうえで連絡先を尋ね、サポートなら問題の概要を受け取ってチケット作成へつなげます。
| 訪問者の用件 | 次の質問や案内 | 次の処理 |
|---|---|---|
| 製品について知りたい | 対象の製品や相談内容を確認 | 情報を記録し、営業担当へ引き継ぐ |
| サポートが必要 | 困っている内容を確認 | チケット作成またはナレッジ案内 |
| 担当者と話したい | 連絡先と相談概要を確認 | 対応可能な担当者へ転送 |
| その他 | 自由記述で内容を受け取る | 担当者が確認できる場所へ記録 |
| メッセージ送信 | チャット内のメッセージでリンクを案内 | 情報提供やリンク案内 |
| 予約リンク表示 | カレンダー予約画面を表示 | 商談予約 |
| チャットからワークフローを起動 | 回答後にワークフローを起動 | 回答に応じた後続処理が必要な場合 |
| 回答内容に応じてフォローアップメールを送る | ワークフローに登録して自動化ワークフローを起動 | フォローアップメール |
分岐が複雑になった場合は、同じ目的の質問をまとめられないか見直します。各経路について、次の順にたどります。
- 訪問者の回答
- 表示される次の質問
- 記録される情報
- 最後の担当先
たどった結果に応じて、経路をまとめるか分けるかを判断します。
- 最後の処理が同じ ── 異なる回答でも最後の処理が同じなら、途中の質問を共通化できるか確認します。
- 確認者や保存先が違う ── 営業とサポートで確認者や保存先が違うなら、途中で経路を分けておきます。
どの経路でも、訪問者に次の行動が示され、担当者が受付内容を確認できる状態を公開の条件にします。
CRMにつながる質問と表示条件を設計する
チャットボットが情報を集めても、保存先や担当者が決まっていなければ後続の対応にはつながりません。
コンタクト、チケット、取引のどこで情報を扱うかをあらかじめ定め、対応フローに沿った質問だけを置きます。表示対象もページや訪問者に合わせて制御します。
質問と保存先を対応させる
受け取った情報や相談は、種類ごとに扱う場所を決めます。
| 対象 | 扱う場所 |
|---|---|
| 名前やメールアドレスなど、後から連絡するために必要な情報 | コンタクト情報として扱う |
| 問い合わせの説明や対応状況 | チケットに結び付ける |
| 営業相談が商談化した場合 | 取引の管理へ移す |
この対応関係を決めると、担当者がチャットの会話を読み直して情報を表計算シートへ転記する負担を減らし、チーム内で引き継ぎやすくなります。利用者に必要な項目だけを提示し、入力された値がどの業務で使われるかを明確にします。
設定後は、テストの問い合わせを最後まで進め、担当者が実際に開くコンタクトやチケットから用件を把握できるか確認します。
会話を開き直さないと担当先が判断できないなら、質問を増やす前に、既に受け取った情報の保存先や見せ方を見直します。
表示するページとタイミングを決める
チャットフローは、サイト内のすべてのページに一律で表示する必要はありません。製品ページでは製品相談、サポート情報のページでは問い合わせ受付など、ページの目的とチャット内容を合わせます。
| 設定の観点 | 決める内容 | 判断の目安 |
|---|---|---|
| URL条件 | 表示するページや対象外にするページ | そのページの閲覧者に案内が役立つ場合に表示 |
| 訪問者 | 既存コンタクトなどの対象 | 識別情報に応じて案内を変える必要がある場合に利用 |
| 表示タイミング | ページ表示後の起動条件 | 閲覧を妨げず、問い合わせの入口が見つかるタイミングにする |
表示条件を決めるときは、そのページで読者が次に尋ねそうなことと、フローの冒頭の選択肢が一致するかを確認します。合わない場合は対象ページを絞るか、冒頭の案内を変えます。
公開前には表示させたいページと対象外のページをそれぞれ開き、意図した条件になっているかを確かめます。
公開前に各経路を確認する
プレビューで質問に回答し、分岐ごとの案内と最後のアクションを確認します。
- 経路 ── 回答を変えたときに意図した経路へ進むか
- 終端処理 ── チケット作成や担当者転送などの終端処理が設定されているか
確認には次のような想定を使い、それぞれで訪問者に何が表示され、どの情報が残り、誰が次に対応するかを追います。
- 製品相談
- サポート相談
- 選択肢にない相談
- 担当者への直接相談
営業時間外にも受付する設計なら、担当者が不在の経路を別にたどります。行き止まりや確認者のいない記録が見つかった経路は修正してから公開します。
表示条件もページごとに確認します。対象ページで表示され、対象外ページでは意図しない案内が出ないことを確認できたら公開し、運用開始後に実際の会話ログと担当者の処理状況を見直します。
BreezeのCustomer Agentと定型フローを選ぶ基準
Customer Agentは既存のコンテンツを使って顧客の質問に回答します。設定時は回答に使うコンテンツと担当者への引き継ぎ方法を整え、公開前に応答をテストします。（出典：Customer Agentを設定する）
定型フローとAI応答の選択基準
定型フローは、営業相談の分類、必要情報の入力、ミーティング予約の案内など、質問と次の処理を固定したい場合に向いています。AI応答を検討する際は、ナレッジベースやWebページなどの参照元を確認します。
| 問い合わせ | 適する方法 | 理由 |
|---|---|---|
| 用件を選択してもらう | 定型フロー | 選択結果ごとの処理を設計できる |
| 連絡先や相談内容を集める | 定型フロー | 必要情報と保存先を管理しやすい |
| 公開済み情報に関する質問 | AI応答を検討 | 参照元と回答範囲を確認する |
| 個別事情の判断や強い不満 | 有人対応 | 状況把握や判断を担当者が行う |
同じテーマでも、質問の形で経路は変わります。
- 公開済みの利用手順を尋ねる質問 ── 参照元を確認したうえでAI応答を検討できます。
- その手順を個別の契約や例外に当てはめてよいかという相談 ── 担当者の判断につなぎます。
分類しきれない問い合わせは無理に自動回答へ入れず、用件を受け付けて担当者へ渡します。
AIが回答する範囲を決める
AI応答の参照元には、読者に提示してよい情報のうち、現在の運用と一致しているものを選びます。手順が古い記事や条件が曖昧な説明が含まれていると、回答を確認する側にも負担が生じます。
導入時は、公開済みのナレッジやWebページなど、内容を担当者が見直せる範囲から試します。実際の質問で回答内容と参照元を確認し、適切な回答が得られたテーマを徐々に増やします。
質問への答えが参照元に書かれていない場合は、回答方法を調整する前に情報の整備が必要か判断します。
- 参照元の記述が曖昧な場合 ── 参照元を修正します。
- 個別事情がなければ答えられない質問 ── 有人対応へ回します。
人が判断する境界を残す
AIに任せるのは、既存情報に沿った初期案内や質問の整理など、根拠を確認できる範囲にします。次の判断は担当者へつなぎます。
- 契約条件の判断
- 個別の例外対応
- 顧客の事情を踏まえた提案
AI応答の契約条件はルールベースのフローとは別に確認します。契約上利用できる場合も、参照コンテンツと引き継ぎ先を整え、有人対応を含めて運用します。
回答を確認できない質問が出たときに誰が内容を見直し、訪問者の相談をどこへ引き継ぐかも決めておきます。
有人担当への引き継ぎを設計する
自動応答を用意しても、すべての問い合わせがチャット内で完結するとは限りません。次の場合に、次の対応へ進める経路を用意します。
- 訪問者が担当者との会話を希望する場合
- AIの参照情報だけでは個別の判断ができない場合
引き継ぎの条件と受け取る情報を決めると、顧客と担当者の双方が同じ説明を繰り返す場面を減らせます。
担当者へ渡す情報を決める
有人対応へ切り替える前に、用件、問い合わせの概要、連絡先など、担当者が初動に使う情報を集めます。チャット内ですでに入力された内容を引き継げる設定にし、顧客に同じ説明を繰り返し求めない流れを作ります。
情報を多く集めること自体を目的にせず、受け取った担当者が次の行動を決められる項目に絞ります。
例えば、次の項目を基本にします。
- 営業相談 ── 相談テーマと連絡先
- サポート ── 問題の概要と関連するコンタクト
引き継ぎ後に担当者が最初に尋ね直した内容を確認し、それが受付時に必要な情報なのか、担当者が個別に聞くべき内容なのかを分けて見直します。
営業とサポートの担当先を分ける
問い合わせの種類に応じて、例えば次のように引き継ぎ先を決めます。
- 営業に関する相談 ── 営業担当へ渡します。
- 製品の問題や利用上の質問 ── サポート担当へ渡します。
担当先が決まらない場合は、共有の受信先やチケットに集約し、次に確認する役割を設定します。
個々の担当者の記憶に依存した割り振りではなく、質問への回答を起点に担当先が決まるようフローを組みます。これにより、新しいメンバーが加わった場合も同じ基準で受付を進めやすくなります。
複数の担当先に当てはまる相談は、最初に確認する役割を決め、その担当者が必要に応じて引き継ぐ運用にします。
営業時間外の処理を用意する
有人担当が対応できない時間帯は、訪問者に状況を伝え、メッセージやチケットなど後から確認できる形で内容を受け取ります。営業時間内に折り返す運用なら、受付メッセージに次の対応について説明し、担当者が確認する場所を一本化します。
ただし、有人対応への転送先が不在のままだと訪問者は次の行動を取れません。営業時間の設定に合わせて、次のように経路を分けます。
- 担当可能な時間 ── 担当者につなぎます。
- 対応外の時間 ── 記録と後続連絡へ進む経路にします。
公開前には担当者がいる場合といない場合の両方を確かめ、どちらでも受付内容の確認先が残るようにします。
小さく始めて会話ログから改善する
チャットボットは、完成形を一度に作るより、受付から担当者への引き継ぎまでの基本経路を作り、実際の会話で確かめる方が運用に合わせやすくなります。
問い合わせを手作業で振り分けている場合も、最初はその作業のうちチャット受付と担当先の記録から置き換えます。運用データを基に、必要な分岐やナレッジを追加します。
最初のフローを限定する
最初のフローでは、次の内容を中心にします。
- 用件の分類
- 必要な連絡情報の取得
- 担当者への引き継ぎ
質問が少なくても、誰がどの情報を受け取り、その後どの処理に進むかが明確なら、改善の起点として機能します。
業務に合わせた例を挙げます。
- 営業相談 ── コンタクトの情報を確認して担当者へ渡し、商談化した場合に取引管理へ進めます。
- サポート相談 ── チケットを作成して担当者へ渡し、解決後は繰り返し出る質問をナレッジに反映します。
導入前の受付方法も残しておき、公開後には、同じ種類の相談で用件の確認や担当先の判断にどの作業が必要だったかを比べます。
会話ログを改善に使う
運用を始めたら、次の点を確認します。
- 回答されなかった質問
- 途中で離脱した場所
- 担当者へ引き継がれた理由
質問の意味が伝わっていない場合は選択肢を見直し、同じ質問が繰り返される場合はナレッジ記事や案内メッセージを整えます。
| 観察した内容 | 見直す対象 | 次の判断 |
|---|---|---|
| 回答の選択肢にない用件が続く | 質問と選択肢 | 新しい選択肢を加えるか、自由入力へ案内 |
| 同じ内容を担当者が繰り返し説明する | ナレッジや案内文 | 公開情報で説明できるなら記事化 |
| 途中で会話が止まる | 質問数や入力項目 | 不要な質問を削り、次の行動を明示 |
| 担当者が引き継ぎ情報を探す | CRMへの保存先 | コンタクトやチケットとの関連付けを修正 |
改善を決める際は、会話ログだけでなく、担当者がその後どう対応したかも確認します。
例えば途中で会話が止まった場合、次のどちらが原因かで修正内容が変わります。
- 質問文が分かりにくかった
- 回答に必要な情報を訪問者が持っていなかった
担当者への転送が多い場合も、公開情報で答えられる質問と個別判断が必要な相談を分けて見ます。
修正後は同じ種類の問い合わせを再確認し、訪問者が次の行動へ進めるか、担当者が必要な情報を受け取れるかを確かめます。
分岐やAIを段階的に追加する
基本経路が運用できてから、実際に多い問い合わせに応じて分岐を追加します。AIを使う場合も、対象となる質問と参照コンテンツを絞って動作を確かめ、有人対応が必要な条件を定義してから範囲を広げます。
問い合わせ件数が少なく内容も個別性が高い場合は、複雑なボットの維持が担当者の負担になることがあります。その場合は、チャットで要件を受け付けて担当者へ渡す構成を維持し、次の両方がそろったら自動案内を検討します。
- 対応の繰り返し ── 同じ質問について、担当者が公開情報を案内する対応を繰り返している
- 更新できる体制 ── その情報を担当者が更新できる状態になっている
追加後も個別判断が必要な相談まで自動案内に入っていないかを確認し、境界が曖昧になれば分岐を戻して見直します。
よくある質問
チャットボットの設定にプログラミングは必要ですか？
ルールベースのチャットボットは、HubSpotの画面上で質問や分岐、アクションを設定できます。外部Webサイトで利用する場合は、サイト側で必要な設定と表示条件をWebサイト管理の担当者と確認します。先に受付する用件と担当先を決め、画面上では各回答から次の処理までつながるかを確認してください。
チャットボットで集めた情報はCRMに保存できますか？
フロー内の質問や設定に応じて、コンタクト情報や問い合わせ内容を記録できます。公開前に、入力値の保存先と後続の担当者が確認する場所を対応させます。連絡先情報、問い合わせ履歴、対応状況を分けて管理すると、営業やサポートへの引き継ぎに利用できます。テスト時には、入力した内容を担当者の確認画面からたどり、不足する情報があれば質問と保存先のどちらを直すべきか判断します。
BreezeのCustomer Agentを利用する前に何を確認しますか？
ルールベースのチャットボットとは利用条件が異なります。設定前に公式の要件を確認し、チャネル接続や使用するコンテンツも合わせて準備します。利用可能な条件を満たさない場合は、ルールベースのフローで受付を整えます。利用できる場合も、参照元の内容を確認してから回答するテーマを決めます。
AIの回答内容は何を基準に確認しますか？
参照させるナレッジやWebページが質問に答えているか、回答が元の情報と一致しているかを見ます。情報が不足する質問や個別判断が必要な質問は、担当者へ引き継がれる設計にします。テストした質問と回答を記録し、誤解を招く表現があれば参照元を修正するか対象から外します。修正後は同じ質問で再確認し、参照元だけでは答えられない場合は有人対応を維持します。
有人担当につなぐ条件はどう決めますか？
担当者との会話を希望する場合、個別の契約や対応判断を求める場合、参照情報だけでは答えられない場合などを条件にします。営業相談とサポート相談の担当先を分け、営業時間外には内容を記録して後続対応へ進めます。引き継ぎ後に担当者が必要な情報を受け取れているかを確認し、足りない項目だけをフローに追加します。担当先が曖昧な相談は、最初に確認する役割を決めてから分岐を公開します。
まとめ
HubSpotのチャットボットは、問い合わせを受け付け、内容をコンタクトやチケットへ結び付け、営業の取引管理やサポート対応へつなぐ入口です。ルールベースのフローは情報収集や振り分けに使い、参照コンテンツに基づく回答が必要ならAI応答を検討します。担当者へ渡す条件と情報を決め、小さな構成から会話ログを見て広げることが運用のポイントです。
まずは、問い合わせを「営業相談」「サポート」「その他」に分ける受付フローから始めます。次の手順で、質問が必要な理由と受付後の処理を確認しながら設計を進めてください。
- 現在の受付方法を書き出し、チャットで置き換える作業を選びます。個別判断が必要な相談は担当者へ渡す経路に残します。
- 質問、CRM上の保存先、引き継ぎ先を対応させます。回答によって次の処理が変わらない質問は、初期フローに必要か見直します。
- プレビューで各経路と営業時間外の受付を確認します。公開後は会話ログと担当者の対応を照らし合わせ、質問、保存先、案内内容のどこを修正するか決めます。
企業様によって最適な形は異なります。問い合わせの内容、参照できる情報、担当者の対応方法を確認し、自動化する範囲を決めてください。CRMを活用した業務効率化やAIとの連携に関するご相談は、StartLinkまでお気軽にお問い合わせください。
あわせて読みたい
顧客が自分で情報を確認できる窓口、サポートツールを選ぶ観点、コンタクト管理の考え方も、チャット受付後の運用を考える材料になります。
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
