HubSpot Service HubとZendeskの比較｜サポートツールの選び方

HubSpot Service HubとZendeskを比較する際の分かれ目は、顧客情報を営業・マーケティング・サポートで共有する必要性と、サポート部門の対応手順をどこまで作り込むかです。同じ問い合わせを使い、受付から回答、担当変更、他部門への引き継ぎまで試して選びます。顧客の取り違え、回答根拠の不足、引き継ぎ先の不明が残る場合は、便利な機能の多さで補わず、解消してから次へ進みます。

「問い合わせの履歴がメールや表計算シートに分かれていて、担当者が変わると経緯を追いにくい」
「Zendeskを使っているけれど、営業やマーケティングが持つ顧客情報とサポート情報を一緒に見たい」
「サポート専用の機能を重視するか、顧客接点全体をつなぐか決めきれない」

HubSpot Service HubとZendeskは、どちらも問い合わせやチケットを管理するカスタマーサポートツールです。HubSpot Service HubはCRMを含む顧客情報のつながりを、Zendeskはサポート業務を中心とする処理の流れを比較の起点にすると、違いを業務に当てはめて考えられます。
ただし、顧客情報が同じ画面に見えることと、担当者がその情報を使って回答できることは別です。必要な契約情報が分からない、社内確認の担当が決まらない、回答後の記録が営業に引き継がれないといった問題が残るなら、情報の集約だけでは目的を満たせません。

本記事では、「既存顧客から利用範囲について質問があり、営業への確認中にサポート担当者が交代する」という場面を例に、比較の進め方を具体化します。自社の問い合わせに置き換え、どこで作業が止まり、何が揃えば再開できるかを確かめてください。
前提となる考え方はService Hub完全ガイドで解説しています。

この記事でわかること

カスタマーサポートの情報管理やツール選定を見直したい方に向けて、両製品の違いを業務上の判断につなげる方法を整理します。チケット管理、ナレッジベース、AI、自動化、CRM連携を比較し、実際の問い合わせを使った試行の組み立て方、合否の決め方、移行を進める条件まで扱います。

• 設計思想の違い — 回答に必要な情報がサポート部門内で揃うのか、営業やマーケティングの情報まで必要なのかを整理し、最初に試す業務を決めます。
• 機能と業務フローの比較 — 顧客を特定できない場合、担当者が変わる場合、社内確認が必要な場合に、処理を止める条件と再開する条件を確認します。
• CRM連携の考え方 — 項目ごとの参照元、更新担当、反映先を決め、古い情報や食い違う情報が表示されたときの確認手順を整理します。
• 選定と移行の進め方 — 必須条件と手順で補える条件を分け、試行結果から「進める」「修正して再試行する」「切り替えを見送る」を判断する方法を示します。

サポートツールを選ぶ前に業務の流れを整理する

ツール選定では、搭載機能を並べる前に、顧客情報がどこから来て、誰が対応し、その後どの部門に引き継がれるのかを確認します。表計算シートや個人のメールボックスを介した管理では、顧客情報と問い合わせの経緯が分かれ、引き継ぎに手間がかかる場合があります。

まず、実際の問い合わせを使って、以下を書き出します。

• 受付時に分かること：送信者、問い合わせ内容、対象の会社やサービスなど。
• 回答前に必要なこと：過去の説明、契約に関する情報、進行中の取引、社内確認の結果など。
• 回答後に残すこと：顧客へ伝えた内容、未解決の事項、次の作業、その担当者など。

例えば、既存顧客から「現在の契約で、この使い方はできますか」と質問が届いたとします。過去に同じ会社へ利用可能と回答した履歴があっても、今回の問い合わせと同じ契約についての回答か分からなければ、その履歴だけでは判断できません。

この場合は、次の順で対応を組み立てます。

1. 送信者と対象の会社を確認し、問い合わせがどの契約や取引に関係するかを特定します。
2. 現在の利用範囲を判断する参照元を確認します。過去の回答と内容が異なる場合は、そのまま回答せず営業へ確認します。
3. 営業へ渡す質問、確認先、結果を受け取るサポート担当者を記録します。
4. 確認中に担当者が交代しても、新しい担当者が記録から待っている情報を把握できるかを確かめます。
5. 確認結果を根拠に回答し、営業側でも顧客へ何を伝えたかを確認できる状態にします。

営業情報が見つからず止まるなら、顧客レコードとの関連付けと参照方法を優先して比較します。情報は揃っているのに担当が決まらないなら、分類と割り当てを先に試します。作業が止まる理由によって、最初に試す機能を変えることが大切です。

オールインワン型とサポート特化型

HubSpot Service Hubは、CRM・マーケティング・営業・カスタマーサポートを同じプラットフォーム上で扱う設計です。顧客の問い合わせを、コンタクトや会社の情報、営業やマーケティングとのやり取りに結び付けて管理する観点で検討します。

Zendeskはカスタマーサポートに焦点を当て、チケット対応の流れやサポートチームの業務を組み立てる製品です。サポート部門の処理方法を詳しく設計したい場合は、分類から担当割り当て、社内相談、回答までの流れを中心に比較します。

この違いだけで製品を決めず、受付時の情報と期待する対応結果を揃えて比較します。片方では営業情報を事前に登録し、もう片方では情報がない状態で試すと、製品の差と準備の差を区別できません。問い合わせ本文、参照資料、担当者の役割を揃え、日常業務で使う権限で試します。

回答できなかった場合は、次のように原因を切り分けます。

• 情報自体がない：営業やサポートが、いつ、どこへ記録するかを決めます。
• 情報はあるが見つけられない：関連付け、表示場所、閲覧権限を確認します。
• 情報は読めるが判断できない：何を回答根拠にするか、誰へ確認するかを定めます。
• 判断できるが次の担当へ渡らない：担当変更時に必要な記録と引き継ぎ方法を見直します。

修正後に同じ問い合わせを再試行し、止まっていた工程が進むかを確認します。設定を直したことではなく、担当者が期待する作業を完了できたことを比較結果に残します。

問い合わせと営業・契約情報の接点を決める

サポートツールにすべての顧客情報を集める前に、回答に必要な情報と、他部門が管理する情報の境界を決めます。HubSpotを使う場合は、コンタクト、会社、取引、チケットのうち、どのレコードに何を残すかを整理します。

利用範囲についての問い合わせなら、チケットには質問、確認中の事項、対応状況、顧客への回答を残します。

• 契約に関する判断 ── 社内で定めた参照元で確認します
• チケットへ契約内容を転記する場合 ── その文章だけが更新されずに残らないよう、何を参照して回答したかを追える形にします

営業への確認依頼は、例えば次のように記録します。

顧客から、問い合わせに記載された使い方が現在の契約範囲に含まれるか質問あり。対象の取引は確認済み。過去の回答が現在も適用できるか営業担当へ確認する。確認結果とその根拠を受け取り、サポート担当が回答する。顧客には確認中と案内済み。

「営業確認中」だけで終えず、営業が答えるべき質問と、サポートが対応を再開できる条件を残すのがポイントです。営業から「対応可能」と返ってきても、対象の契約や質問への回答であることが分からなければ、確認を続けます。

ZendeskとHubSpotを併用する場合も、同じ考え方で役割を分けます。顧客情報をどちらで確認し、対応結果をどちらへ残すのかを決めます。両方に記録が必要なら、同じ説明をそれぞれ編集するのか、判断元を定めて相手側から参照するのかを整理し、食い違ったときに確認する場所を明確にします。

優先課題から比較対象を絞る

優先課題を決めたら、「導入後にできていなければ困ること」を具体的な動作に置き換えます。

試行では、引き継ぎ先に次の点を記録から説明してもらいます。

• 何を待っているか
• 誰に確認するか
• 何が分かれば顧客へ回答できるか

説明できない内容があれば、記録不足か、記録場所の問題かを調べます。前任者がその場で補足して対応できた場合は、引き継ぎの条件を満たしたとは扱いません。

記録から再開できた場合も、別の管理表への転記や個別連絡が必要なら、その作業を残します。手作業があること自体で不合格にせず、担当者、実施する場面、完了の確認方法が決まっており、担当変更後も実行できるかで判断します。

チケット管理とナレッジベースを比べる

問い合わせ対応の品質は、チケットを登録できるかだけでは決まりません。受付、担当割り当て、社内相談、回答、再発防止までが無理なくつながる必要があります。この節では、顧客情報との関連付け、記事による解決支援、担当変更時の記録について、試行で見る箇所と修正の分かれ目を整理します。

チケットを顧客情報と関連付ける

HubSpot Service Hubでは、チケットをコンタクト・会社・取引などのレコードと関連付けて扱えます。比較では、関連付けが存在するかだけでなく、問い合わせに関係するレコードへ正しく結び付いているかを確認します。

以下の画面は、HubSpotのチケット一覧の表示例です。「全てのチケット」などのタブと、チケット名、パイプライン、ステータス、優先度の列が見えます。個別チケットの内容や処理結果を示すものではありません。

Zendeskでは、サポートチームのビューやグループ、マクロなどを使う運用について、問い合わせの処理方法に合うかを確かめます。両製品とも、順調に回答できる問い合わせだけでなく、次のような場面を含めて試します。

• 顧客を特定できない場合：追加で確認する情報と、その確認先を記録します。対象が確定するまでは、個別の契約情報を使う回答へ進まない条件にします。
• 関係する取引が分からない場合：会社が同じという理由だけで取引を選ばず、問い合わせ内容と契約の対応を確認します。
• 別部門への確認が必要な場合：確認先、質問内容、回答待ちの事項を記録し、確認結果を受け取った担当者が対応を再開できるかを見ます。
• 担当変更が生じた場合：顧客への説明と社内の検討内容を区別し、次の担当者が未解決事項を把握できるかを確かめます。

例えば、同じ会社に異なる取引の記録がある場面では、「会社の画面を開けた」だけでは確認完了にしません。問い合わせに関係する取引を特定し、対象を選んだ理由を担当者が説明できるかまで見ます。特定できなければ、必要な追加質問を残して保留します。

関連付けを修正した後は、正しいレコードが見えることに加え、修正前の情報を根拠にした回答案や社内依頼が残っていないかを確認します。誤った情報の参照を止め、対応に使う情報が揃ってから再開します。

ナレッジベースで繰り返し対応を整理する

ナレッジベースは、顧客が自分で解決方法を探したり、担当者が回答の根拠を共有したりするための情報基盤です。HubSpot Service HubとZendeskを比較するときは、記事を公開できるかに加え、実際の問い合わせから適切な記事へたどり着き、その説明を使って対応を進められるかを見ます。

試行には、繰り返し使う回答と、担当者が補足説明を加えることの多い回答を使います。

• 探し方 ── 記事のタイトルを教えてから探してもらうのではなく、顧客が問い合わせで使った言葉から探します
• 確認すること ── 対象者、前提条件、操作手順、解決しなかった場合の案内が読み取れるか

記事で解決できなかった場合は、原因を次の順で分けます。

1. 記事が見つからなかった：検索に使った言葉と見出し・分類が合っているかを見直します。
2. 記事は見つかったが、自分に当てはまるか分からなかった：対象者や利用条件を明示します。
3. 手順を読んでも操作できなかった：省略された操作や、途中で判断が必要になる箇所を補います。
4. 手順を実行しても解決しなかった：担当者へ渡す条件と、その際に伝えてほしい情報を明示します。

利用範囲についての記事なら、一般的な説明と個別の契約確認が必要な事項を分けます。記事を読んだ人が、自分の契約に適用できるか分からないまま利用可能と判断する状態なら、記事だけで完結させる範囲を見直します。

担当者への確認が必要な場合は、次の内容をチケットへ引き継ぐ手順にします。

• 顧客の質問
• 読んだ記事
• 試した内容
• 判断できなかった箇所

担当者が同じ説明を最初から繰り返す必要があるなら、記事の内容だけでなく、この引き継ぎ方法も修正対象です。

修正後は、記事の作成に関わっていない担当者に同じ問い合わせで試してもらいます。記事を読んで進めるか、個別確認が必要と判断して必要情報を渡せるかを確かめてから、その案内を標準化します。

対応履歴を引き継げる形にする

引き継ぎを担当者の記憶に頼ると、過去の質問、顧客への説明、次に行う作業が抜けることがあります。記録対象は、次の担当者が対応を再開するために必要な内容から決めます。

例えば、「営業へ確認中」という記録だけでは、何を待っているのか分かりません。次のように、確定したことと未確認のことを分けて残します。

• 顧客の質問：現在の契約で、問い合わせに記載された使い方ができるか。
• 確認済み：対象の顧客と取引。
• 未確認：過去の回答が現在の契約にも適用できるか。
• 確認先：対象取引の営業担当。
• 顧客への説明：利用可否は確認中と案内済み。
• 次の作業：営業の確認結果と根拠を受け取り、サポート担当が回答する。

試行では、記録を書いた担当者とは別の担当者へ渡します。引き継ぎ先が過去の回答を確定事項として扱った場合は、情報が欠けていなくても、確定・未確認の区別が伝わっていません。表現や記録場所を直して再試行します。

欄を増やしても記入されないなら、記録のタイミングが業務に合っていない可能性があります。受付時には質問と対象、確認依頼時には確認事項と再開条件、回答時には根拠と顧客へ伝えた内容を残すように分けます。引き継ぎ先が記録だけで次の作業を判断できてから、記録方法を標準化します。

AIと自動化の使いどころを見極める

AIや自動化を比較する際は、処理できる作業の種類だけでなく、誤りがあったときに担当者が気付き、処理を止めて修正できるかを確認します。この節では、分類・要約・回答案を照合する方法と、割り当てや通知の例外条件を試す順序を整理します。

AIの適用範囲を比べる

両製品で利用するAI機能について、参照する情報、生成する内容、担当者による確認方法を揃えて比較します。利用できる機能や条件は契約内容や製品仕様によって異なるため、試行は自社で利用する範囲に限定します。

分類、記録の要約、回答案の作成では、問い合わせ本文と正しい対応記録を用意し、何が含まれていれば業務に使えるかを先に決めます。

• 分類：問い合わせ内容に合った分類か、判断できない内容を無理に分類していないかを見ます。
• 要約：顧客への約束、未解決事項、次の担当者が省略されていないかを照合します。
• 回答案：参照情報にない条件を付け加えていないか、個別確認が必要な内容を確定事項として書いていないかを確認します。

例えば、利用範囲について営業へ確認中の記録から、要約が「利用可能と案内済み」になれば、文章として自然でも対応には使えません。「利用可否を確認中」「顧客には確認中と案内済み」という区別が保たれていることを採用条件にします。

試行では、似た文章でも判断が異なる記録を組み合わせます。

• 確認が完了した記録：確認結果と根拠を使い、回答案を準備できるか。
• 確認中の記録：利用可否を断定せず、未確認事項と確認先を残せるか。
• 過去と現在の情報が食い違う記録：どちらかを無条件に採用せず、担当者へ確認を戻せるか。

不適切な結果が出た場合は、参照情報が不足していたのか、情報はあるが読み取りを誤ったのかを分けます。情報不足なら参照元や引き継ぎ条件を見直します。情報が揃っていても判断を誤る作業は、人による照合を残します。

修正後は、問題が起きた記録と、判断が異なる類似の記録を再び試します。特定の文章だけを直して通過させず、確定・未確認の区別が維持できる範囲を確認してから適用を広げます。

ワークフローで手作業を減らす

• HubSpotのワークフローでは ── チケットの状態や条件に応じた通知、タスク作成、担当者への割り当てなどを検討します
• Zendeskでは ── トリガーや自動化を使う運用について、チケットの属性やグループに応じた処理を整理します

比較前に、「どの条件で動くか」「何を変更するか」「処理できないときに誰が確認するか」を文章にします。例えば、問い合わせ分類に応じて担当を決めるなら、分類が空欄の場合、条件が重なる場合、手動で担当変更した場合の扱いも決めます。

試行は次の順で進めます。

1. 通常の問い合わせを登録する：想定した担当者、通知先、状態になるかを確認します。
2. 条件が不足する問い合わせを登録する：担当未定のまま見落とされず、確認する人が分かる状態になるかを見ます。
3. 条件が重なる問い合わせを登録する：最終的な担当と通知先が意図した結果になるかを確認します。
4. 登録後に分類や担当を変更する：不要な再通知や割り当ての上書きが起きないかを見ます。
5. 処理対象から外した問い合わせを試す：対象外にも同じ処理が適用されていないかを確認します。

例えば、営業確認中のチケットを別のサポート担当者へ手動で引き継ぐ運用なら、その後の分類変更で以前の担当者へ戻らないことを確認します。担当者を戻す必要がある業務なら、その条件と理由を先に決めます。

通知が届いただけでは、引き継ぎが成立したとは判断しません。受け取った担当者が対象のチケットを開き、確認事項と必要な作業を把握できることまで確かめます。通知後に担当や状態が変わる可能性も含め、処理が終わった時点の記録を読み直します。

AIと人による確認を分担する

この表は業務上の分担を検討するための整理です。すべての作業を自動化する前提ではなく、必要な情報を参照でき、担当者が結果を確認できる範囲から適用します。

確認記録には、生成結果を採用したかだけでなく、修正した箇所と理由を残します。「文章を調整した」ではなく、「未確認の利用範囲を断定していたため、確認中の案内へ戻した」のように記録すると、表現の調整と判断の誤りを分けられます。

• 特定の問い合わせで情報が不足するなら ── 人へ引き継ぐ条件を見直します
• 同じ種類の誤りが続くなら ── 担当者による個別修正で済ませず、参照ナレッジや分類基準を修正します

CRM連携で顧客対応を一気通貫にする

サポート情報をCRMと結び付ける目的は、問い合わせの背景を確認し、必要な部門へ引き継ぎ、その結果を次の顧客対応に使えるようにすることです。この節では、項目の役割、更新経路、未反映時の対応を整理し、データが見える状態から業務で使える状態へ進める条件を示します。

部門ごとに分散した情報をつなぐ

メールや表計算シートで問い合わせを管理し、別のシステムで営業情報を持つと、顧客の同じ情報を複数箇所に入力することがあります。内容が食い違ったときに判断できるよう、項目ごとに参照元と更新担当を決めます。

例えば、営業担当と問い合わせ担当は、どちらも担当者の情報ですが役割が異なります。

• 営業担当が変わったからといって ── 対応中の問い合わせ担当まで変える必要があるとは限りません
• 項目名が似ていることではなく ── 誰が何のために更新するかを基準に対応付けます

試行では、変更の影響を分けて確かめます。

• 営業担当を変更する：次の社内確認が新しい営業担当へ渡り、対応中のサポート担当は意図せず変わらないか。
• サポート担当を変更する：未解決事項が引き継がれ、営業担当の情報は意図せず変わらないか。
• 対応状況を変更する：営業側から、何が解決し、何が残っているかを読み取れるか。

HubSpot Service Hubの試行では、顧客レコードとチケットの関連付けを使い、サポート担当者が回答に必要な情報を確認できるかを見ます。営業担当者側でも、サポート履歴から確認事項と対応結果を読み取れるかを確かめます。

必要な情報を閲覧できない場合は、権限の問題、関連付けの問題、記録不足を分けて直します。管理者が閲覧できただけで完了とせず、実際に回答や確認を担当する人の権限で再試行します。

顧客の声を次の改善につなげる

サポートで得た情報を改善に使うには、問い合わせ理由の分類に加え、顧客がどこでつまずき、どの説明で解決したかを残します。

例えば、「使い方が分からない」という分類だけでは、記事が見つからなかったのか、前提条件が伝わらなかったのか、個別の契約確認が必要だったのかを判断できません。対応結果を読み、改善先を分けます。

• 記事の場所を案内して解決した：検索に使われた言葉と記事への導線を見直します。
• 記事にない説明を補って解決した：その説明を共通の手順にできるか、ナレッジの管理担当が判断します。
• 営業の説明を確認して解決した：HubSpotの顧客情報や取引情報に、サポートが参照すべき内容を残す方法を見直します。
• 個別条件によって回答が変わった：共通の回答へまとめず、個別確認へ進む条件を明示します。

改善先を決めたら、変更後の問い合わせをHubSpot上の顧客情報や対応履歴と結び付けて確認します。同じ分類の問い合わせが続いていても、つまずく箇所が変わっているなら、同じ原因が残っているとは限りません。

記事を修正した場合は、以前に補足していた説明が引き続き必要かを見ます。営業情報の記録方法を変えた場合は、同じ質問を営業へ聞き直さず判断できるかを見ます。改善した対象と、確認する対応記録を対応付けることが見直しの条件です。

外部連携の範囲を確認する

ZendeskとHubSpotを別々に使う場合は、利用する連携方法で扱うデータについて、項目、方向、反映を確認する時点を整理します。「顧客情報を同期する」という表現だけでは、何をもって正常とするかを決められません。

まず、問い合わせ対応に必要な項目ごとに、次の内容を記録します。

• 参照元：値が食い違った場合に正しい情報として扱う場所。
• 更新担当：変更を入力する担当者と、その入力先。
• 反映先：相手側で確認する項目と、対応するレコード。
• 必要になる時点：受付時、回答前、担当変更時など、情報が揃っていなければ処理を進められない場面。
• 未反映時の対応：確認する人、参照する場所、保留する作業。

例えば、HubSpotの営業担当をZendesk側で参照する運用を検討するなら、その項目を扱える連携方法であることを確認したうえで、次の順に試します。

1. 変更前の営業担当と、対応する顧客レコードを記録します。
2. HubSpotで担当を変更し、保存された内容を読み直します。
3. Zendesk側で、同じ顧客の担当情報が更新されているかを確認します。
4. サポート担当者が、その情報を使って営業への確認依頼を準備します。
5. 情報が古いままなら、参照元を直接確認する手順へ切り替え、旧担当へ依頼しないことを確かめます。

反映の速さを比較するときは、「変更を保存した時点」「反映先で確認した時点」「その情報を業務で使おうとした時点」を記録します。担当情報なら社内確認の依頼前、利用範囲に関する情報なら回答を確定する前が判断点です。自社で回答期限を定めている場合は、その期限までに確認と回答準備を終えられるかを、実際の作業順序に沿って照合します。

• 参照元を直接確認でき、確認担当も決まっている：直接参照を正式な手順に含めて試します。担当交代時にも同じ手順を実行できれば、手順で補える条件として扱います。
• 参照元を確認できず、古い情報では回答できない：回答を保留して管理担当へ引き継ぎます。確認経路が成立するまで、その連携を前提とする運用開始を見送ります。
• 両方で同じ項目を更新して食い違う：判断元と更新担当を定め、更新経路を整理してから再試行します。

未反映が解消した後も、表示が戻っただけで復旧完了にはしません。保留していたチケットについて、現在の値、関連付け、確認先を読み直し、旧情報で作った依頼や回答案を修正してから対応を再開します。

自社に合うツールを選ぶ判断基準

どちらの製品が適しているかは、チームの規模だけでは決まりません。問い合わせの量やチャネル、CRMとの連携、ナレッジ運用、管理者が維持できる設定の範囲を合わせて考えます。企業様によって最適な形は異なります。自社の問い合わせを使って、優先課題が解消するかを確かめることが判断につながります。

HubSpot Service Hubを選ぶ条件

• HubSpot CRMを利用しており、コンタクトや会社、取引の情報をサポートでも参照したい
• サポートと営業・マーケティングの連携を重視している
• 顧客対応の履歴を同じ顧客レコードに集めたい
• フォームやチャットからの受付をチケットやワークフローにつなげたい

HubSpotのヘルプデスクで使える設定は、自社の契約内容と運用環境で確認します（出典：Create and respond to tickets in help desk）。試行では、問い合わせが必要な顧客レコードに結び付き、担当者が回答に必要な情報を確認できるかを見ます。

選定を進める条件は、CRMに情報が集まり、その情報を使って確認と引き継ぎが成立することです。次の流れを試します。

• サポートから営業へ質問を渡す
• 確認結果を受けて回答する
• 営業側でも顧客への説明を把握できる

例えば、営業情報の探索が主な課題だった場合は、チケットから対象の取引と回答根拠を確認でき、担当変更後も対応を継続できるかを重視します。その流れが成立したら、ナレッジや自動化の運用も含めて比較を進めます。

CRMとの統合後も別の管理表や口頭確認が欠かせない場合は、不足している情報と記録場所を調べます。

• 記録方法で解決できるなら ── 修正して再試行します
• 必須の対応手順を成立させられないなら ── 情報を集約できることだけで選定を進めないようにします

Zendeskを選ぶ条件

• サポートチームのチケット処理や管理を中心に製品を選びたい
• チケットの振り分けや定型処理、サポート内のコラボレーションを重視している
• ヘルプセンターやコミュニティをサポート業務と合わせて運用したい
• CRMを別に管理し、連携方式を決めて運用できる

試行では、次の点を見ます。

• 問い合わせの受け渡し ── 適切な担当者へ渡せるか、社内で確認した内容を回答に引き継げるか
• HubSpotの顧客情報が必要な問い合わせ ── 参照する項目と対応結果の戻し先を明確にします

選定を進める条件は、サポート部門内の処理が成立し、CRMとの間でも必要な情報を引き継げることです。サポート内の操作が扱いやすくても、営業情報を探す作業が残るなら、その作業を含めて比較します。

既存のZendesk運用で割り当てや担当変更が成立しており、課題がHubSpotの営業情報の参照に限られる場合は、併用でその課題を解消できるかを試します。必要な情報を使って回答し、対応結果を営業側へ戻せるなら、その運用を継続する判断につながります。

• 連携後も顧客の特定や対応履歴の確認が難しい場合 ── 項目の対応付けだけでなく、情報をどちらで管理するかから見直します
• 確認経路を増やすことで担当者が判断元を選べなくなるなら ── 役割分担を整理してから再試行します

比較の場で確認する項目

比較結果は、問い合わせごとに「どの記録を見て、どの作業まで完了したか」を残します。「対応できた」という感想ではなく、チケット、参照した顧客情報、実行した手順を確認できる形にします。

担当変更の試行なら、次の内容を記録します。

• 問い合わせの条件：営業へ利用範囲を確認中で、顧客には確認中と案内済み。
• 期待する結果：新しい担当者が確認先と未解決事項を把握し、確認結果を受けて回答準備を再開できる。
• 実際の結果：どの記録から何を読み取れたか。口頭説明が必要なら、何を聞き直したか。
• 残った手作業：転記や個別連絡の内容、実施担当、実施する場面。
• 修正する対象：記録項目、表示場所、権限、割り当て条件、社内手順のどれか。
• 再試行の結果：修正後に引き継ぎ先が対応を再開できたか。別の問い合わせに支障が出ていないか。

ここで、条件を次のように分けます。

• 運用開始に必須の条件 ── 満たさなければ正しい顧客対応を続けられないものです
  • 顧客を正しく特定できる、回答根拠を確認できる、未解決事項を引き継げる、担当不明の問い合わせを発見して引き受けられることを、試行対象ごとに確かめます
  • 未解決の不備が残れば、その業務の開始は保留します
• 手順で補える条件 ── 担当者が通常の権限で実行でき、担当変更時にも再現できるものです
  • 例えば、CRMの参照元を直接確認する方法が明確で、確認した内容をチケットへ残せるなら、手順として扱えます
  • 特定の担当者の記憶や、その場の口頭補足が必要な場合は、まだ手順が成立していません
• 後から検討する条件
  • なくても必須の対応が成立する表示の調整や追加の自動化などです
  • これらを先に整えるために、回答根拠や担当割り当ての問題を後回しにしないようにします

例えば、引き継ぎ先が過去の回答を見て「利用可能」と判断し、前任者の説明で確認中だと気付いた場合、試行結果は保留です。未確認事項を明示して再試行し、新しい担当者が営業への確認を継続できれば、そこで必須条件を満たしたと判断します。

時間や作業量を比べる場合は、受付から回答準備までを、次のように分けて記録します。

• ツールの操作
• 情報探索
• 社内回答待ち
• 転記

合計だけでは、製品の操作と社内手順のどちらが影響したか分かりません。片方だけ参照情報や担当者の習熟が異なる場合は、その違いを残し、結果を製品性能の差として扱わないようにします。

必須条件を満たした製品同士で、優先課題に関係する手作業と設定維持の負担を比較します。条件が重なるときは、通常の管理担当者が分類や担当変更の設定を更新し、確認まで行えるかを試すと、運用開始後の役割を具体化できます。

移行は小さく始めて運用を確かめる

ZendeskからHubSpot Service Hubへの移行を検討する場合、データの移し替えに加え、対応ルールや担当者の動き方を整理します。この節では、移行対象の決め方、件数と内容の照合、受付先の切り替え、運用開始後の見直しまでを扱います。

対象を限定して試し、必要な情報と作業が引き継げると確認した範囲から広げます。移行できた件数だけでなく、対応中の問い合わせを移行後も続けられることを判断条件にします。

先に移行対象を定める

まず、移行するチケット、顧客レコード、対応履歴、添付ファイル、ナレッジ記事を一覧化します。日々の対応に使う情報と、過去の参照用に保管する情報を分け、対象ごとに移行前後の参照先と確認担当を決めます。

試行対象には、日常的な問い合わせに加え、移行方法の違いが対応へ影響しやすいものを含めます。次のような条件で分けると、何を照合すべきかが明確になります。

• 営業確認中
• 担当変更済み
• 添付ファイルを回答根拠に使う
• 複数の取引から対象を特定する

移行前後で次の内容を照合します。

• 顧客とチケットが意図した組み合わせで関連付いているか。
• 誰が何を伝えたか、対応の順序を追えるか。
• 回答に必要な添付ファイルを参照できるか。
• ナレッジ記事内の案内先を使って次の操作へ進めるか。
• 対応中の問い合わせを、新しい担当者が記録から再開できるか。

件数は、あらかじめ定めた移行対象と突き合わせます。移行先の一覧だけを見て確認すると、移らなかった対象を見落とします。移行前後の識別情報を対応付け、未移行、重複、移行対象外の扱いを区別します。

件数が合っていても、次のような問題は残り得ます。

• 同じ会社の別の取引へ関連付いている
• 社内確認を顧客への回答として読めてしまう

そのため、内容の照合では、対応に使う情報の意味と順序を確かめます。

必要な情報が欠けた対象は、そのまま利用開始へ進めません。移行方法を直すか、元の参照先を残して確認する手順を定めます。参照先を残す場合は、移行後の担当者が通常の権限で開き、対象の履歴を特定して対応を続けられることまで試します。

ワークフローを再設計する

Zendeskのトリガーや自動化をそのままコピーするのではなく、HubSpotで実現したい状態から必要な条件を作ります。

既存ルールごとに、次の点を整理します。

• 何をきっかけに動くか
• どの項目を変更するか
• 誰へ知らせるか
• どの業務を成立させているか

目的が同じルールでも、参照する項目やチケットの進行段階が違えば、そのまま置き換えると結果が変わります。

試す順序は次のとおりです。

1. まず受付、顧客との関連付け、担当割り当て、対応結果の記録を試します。
2. その後、社内確認待ち、担当変更、解決後の追加問い合わせなど、途中で状態が変わる場面を確認します。

移行する履歴と新しく受け付ける問い合わせも分けて試します。履歴を取り込んだ際に、新規受付と同じ通知や割り当てを行うべきかを先に決め、意図しない処理が起きないことを確認します。

• 通知が重複した場合 ── 通知文だけを直すのではなく、どの条件が重なったかを調べます
• 担当者が決まらなかった場合 ── 分類の不足と割り当て先の未設定を分けます

期待する結果と実際の結果が一致し、例外の確認先も決まった段階で、次の自動化へ進みます。

運用を切り替える際は、対象ごとに受付先と更新先を明確にします。

• 切り替えの作業中に顧客から返信があった場合 ── どちらで受け取り、どこへ記録を引き継ぐかを確認します
• 移行処理の完了後 ── 追加された返信や担当変更も含めて照合してから、対応を再開します

切り替えを見送る場合は、継続して使うツールと、試行中に行った対応の戻し先を決めます。顧客への説明や未解決事項を引き継ぎ、担当者が作業を続けられる状態にしてから試行を終えます。

運用開始後に見直す

導入後は、登録漏れ、担当不明、未解決のまま止まっているチケット、ナレッジ記事で解決できなかった問い合わせを確認します。未解決という状態だけで判断せず、何を待ち、誰が次に動くのかを読み取ります。

• 受付された問い合わせがチケットにない：受付側の記録と登録結果を突き合わせ、抜けた問い合わせを特定します。
• 担当が決まっていない：分類の不足、割り当て条件、例外時の確認先を見直します。
• 担当はいるが対応が進まない：顧客からの回答待ち、社内確認待ち、必要情報の不足を分けます。
• 同じ補足説明が続いている：ナレッジ記事の対象者、前提条件、手順を見直します。
• CRMとチケットの情報が食い違う：参照元と更新経路を確認し、回答や確認依頼へ影響した範囲を調べます。

見直しのきっかけは、経過した期間だけで決めません。担当者の役割、問い合わせの分類、受付経路、CRMの項目を変更したときも、その変更が影響する手順を再確認します。

例えば、営業担当の変更後に確認依頼が旧担当へ渡ったなら、連携設定だけでなく、担当を確認してから依頼する手順が実行されていたかを調べます。設定の修正と手順の修正を区別し、問題が起きた問い合わせと、影響を受けるほかの問い合わせで再試行します。

よくある質問

HubSpot Service HubとZendeskはどう選べばよいですか？

まず、実際の問い合わせで担当者がどの情報を参照し、誰へ引き継ぐかを確認します。営業やマーケティングの情報が回答に必要で、サポート履歴も同じCRMに集めたい場合は、HubSpot Service Hubで部門間の引き継ぎを試します。サポートチーム内の振り分けや対応手順を重視する場合は、Zendeskでその流れが成立するかを確かめます。

両製品で問い合わせ本文、参照資料、担当者の役割を揃え、担当変更や社内確認が発生する場面も試します。顧客を特定できる、回答根拠を確認できる、引き継ぎ先が対応を再開できることを必須条件にします。その条件を満たした製品同士で、残る手作業と設定を維持する負担を比較します。

ZendeskとHubSpotを併用できますか？

併用する場合は、自社で利用する連携方法と対象データを確認します。顧客情報とチケット情報について、参照元、更新担当、反映先、情報が必要になる業務上の時点を決めます。

例えば、営業担当を確認してから社内依頼を出す運用なら、担当変更が相手側の正しい顧客に反映されるかを試します。必要な時点で確認できない場合は、参照元を直接確認する担当と手順を設けます。担当変更後もその手順を実行できれば、運用で補える条件として比較できます。正しい情報を確認できない場合は、該当する依頼や回答を保留し、確認経路を整えてから運用を広げます。

ZendeskからHubSpot Service Hubへ移行するときは何から始めますか？

移行対象のチケット、顧客情報、添付ファイル、ナレッジ記事を整理し、日々の対応に必要な情報と過去の参照用の情報を分けます。対応中の問い合わせでは、未解決事項、顧客への約束、確認先、次の担当者を引き継げることを優先します。

次に、移行対象の一覧を基準に件数と内容を照合します。顧客との関連付け、履歴の順序、添付ファイルの参照、担当割り当てを試し、移行後の担当者が対応を再開できるかを確かめます。切り替え中に届いた返信も照合し、受付先と更新先を決めてから利用を開始します。情報が不足する対象は、移行方法や参照手順を見直すまで分けて管理します。

AIに顧客対応を任せられますか？

問い合わせの分類、要約、回答案の準備など、担当者が結果を照合できる作業から試します。問い合わせ本文、対応履歴、参照ナレッジと照らし合わせ、顧客への約束や未解決事項が抜けていないか、未確認の内容を断定していないかを見ます。

確認が完了した記録だけでなく、確認中の記録や情報が食い違う記録でも試します。回答できない段階で確認へ回せることが判断点です。顧客への送信や例外的な判断は担当者が確認し、誤りがあれば参照情報の不足と読み取りの誤りを分けて修正します。修正後も正しさを判断できない作業は人による確認を残します。

まとめ

HubSpot Service HubとZendeskの比較では、顧客データを部門間で共有する必要性と、サポート業務の処理手順をどこまで整えるかを起点にします。HubSpot Service HubはCRM・営業・マーケティングとの情報のつながりを、Zendeskはサポート業務を中心とした運用を、自社の問い合わせに当てはめて確かめます。

まずは、現在の問い合わせ管理で手作業になっている工程を選び、次の順で確認します。

1. 問い合わせの受付から解決までをたどり、判断に使う情報、作業が止まる箇所、引き継ぎ先を洗い出します。
2. 「担当変更後も記録から対応を再開できる」など、運用開始に必要な条件を具体的な動作で決めます。
3. 両製品で同じ条件の問い合わせを試し、通常の対応に加えて、情報不足、担当変更、社内確認が必要な場面を確かめます。
4. 残った問題を、設定、情報の持ち方、業務ルール、製品の提供範囲に分けて整理します。
5. 必須条件を満たし、例外時の確認先と管理担当が決まった範囲から、連携や移行を進めます。

比較の記録には、次の内容を残します。

• 期待した動作
• 実際に完了した作業
• 残った手作業
• 再試行の結果

必須条件が未達なら修正と再試行へ戻り、条件を満たしたら設定維持の負担まで比較します。この順序を決めておくと、製品選定と導入後の改善を同じ業務上の基準で進められます。

相談時には、現在の問い合わせの流れ、回答に必要なCRM情報、引き継ぎで止まる箇所を整理してください。それらをもとに、次の内容を具体化できます。

• HubSpotへ集約する情報
• Zendeskとの役割分担
• 試行する問い合わせ
• 移行前に確かめる条件

CRMを活用した業務効率化やAIとの連携に関するご相談は、StartLinkまでお気軽にお問い合わせください。

あわせて読みたい

• HubSpotカスタマーポータルの活用法｜顧客セルフサービスで対応コストを削減する方法
• HubSpotチャットボットの設定ガイド｜フロー設計からAI切替・有人対応まで完全解説
• HubSpotリードスコアリング新機能｜AIベース予測スコアの設計と活用