ServiceHub を「問い合わせ管理」で終わらせない― CRHが実践するカスタマーサポート設計・実装の考え方 ―

※本記事は、前回公開した「ServiceHub を『問い合わせ管理』で終わらせない設計方法」の続編です。
前回の記事では、ServiceHub を単なる問い合わせ管理ツールとして捉えるのではなく、カスタマーサポートの業務基盤として設計するための考え方（方法論）について解説しました。

ServiceHub は多機能であるがゆえに、「何ができるか」を追いかけ始めると、機能説明で終わってしまいがちです。前回はあえて機能の話を最小限にし、「どのような思想で設計すべきか」という前提を整理しました。

第2回となる本記事では、その設計思想を踏まえたうえで、株式会社クリエイティブホープが、実際の支援現場でどのように ServiceHub を設計・実装しているのかを具体的にご紹介します。

方法論を「絵に描いた餅」で終わらせないために

ServiceHub に限らず、HubSpot 活用においてよく聞くのが、「考え方は理解できたが、実際の設定にどう落とし込めばいいかわからない」という声です。

理想の姿や目指す方向性はイメージできている。
しかし、プロパティ設計、チケット設計、ワークフロー設計といった具体フェーズに入った瞬間、手が止まってしまう。
これは決して珍しい状態ではありません。

弊社のServiceHub導入支援では、前回の記事で解説した以下の思想を前提条件として置きます。

　・すべての問い合わせをチケットに集約する
　・チケットとCRMデータとを分断しない
　・チャネルではなく業務構造で考える

そのうえで、この思想を「考え方」で終わらせず、ServiceHub の構成・設定・運用設計まで一気通貫で落とし込むことを重視しています。

CRH支援の全体像：問い合わせを「一元管理」する構造

弊社のServiceHub導入支援では、最初に「ツール設定」から入ることはありません。
まず行うのは、問い合わせ全体の流れを構造として整理することです。

フォーム、チャット、メール、電話、社内チャットなど、問い合わせチャネルは企業ごとに異なります。しかし弊社では、チャネルの違いに関係なく、次の前提を置きます。

どのチャネルからの問い合わせであっても、最終的にはServiceHub の「チケット」に集約される。

この前提を置くことで、各チャネルは「個別管理の対象」ではなく、ServiceHub チケットへの入口として整理されます。

チャネル毎に担当者を配置し、対応している企業も多く、チャネル横断した対応履歴管理が難しい状態の打破にも繋がります。
上記のように整理することで、結果として、問い合わせ対応が分断されず、全体像を一つの画面で把握できる状態が作られ、抱えている課題解決の基礎となります。

チケット管理：ステータス設計と自動化で対応漏れを防ぐ

CRH の支援で行うのが、チケットパイプラインの設計です。
単に「新規／対応中／クローズ」といった状態管理ではなく、業務の流れがそのまま反映されたステータス設計を行います。

CRH では、ステータスを次のような観点で設計します。

　・今は初期対応が必要な状態なのか
　・顧客からの返信待ちなのか
　・社内確認・対応待ちなのか
　・何をもって完了とするのか

こうした観点を明確にすることで、「今、どこで何が止まっているのか」をチケット一覧を見るだけで把握できる状態を作ります。

さらに、チケット作成時にはワークフローを活用し、初期対応を自動化します。
自動返信メールの送信、担当チームや担当者の割り当て、Slack など社内ツールへの通知などを組み合わせ、対応の初動を安定させます。

ここで重要なのは、自動化そのものが目的ではないという点です。
初期対応を自動化することで、対応スピードを均一化し、対応漏れを防ぎ、人が判断すべきポイントに集中できる状態を作ることが目的です。

CRMとチケットを前提にしたサポート設計

CRH の ServiceHub 支援では、チケット単体での管理は行いません。
必ず CRM（コンタクト・会社）とチケットを一体で設計します。

チケット画面から、以下の情報を即座に確認できる状態を作ります。

　・同一顧客の過去の問い合わせ履歴
　・同一企業内での問い合わせ傾向
　・営業・CS など他部署との接点情報
これにより、「この問い合わせをどう処理するか」だけでなく、「この顧客に今どう対応すべきか」という判断がしやすくなります。
チケット単体で完結する対応ではなく、顧客との関係性の中でサポートを行う設計です。

ナレッジ・AI活用もチケット設計の延長線で考える

CRH では、ナレッジベースや AI エージェントを導入する際も、必ず「チケットとの関係性」を前提に設計します。

ServiceHubにはチケットの他にも、顧客や社内の課題解決に役立つ機能や、サポート担当者の業務効率をするための機能が備わっています。
それぞれ別の機能としてバラバラに設計・設定している状態も目にすることはありますが、本来であればしっかりとサポート業務全体を見据えた上で、それぞれの機能の役割や機能同士の関連を基に活用方針を見出すことが重要になります。

CRH の支援では、セルフサービスも含めて、チケットを中心とした一つのサポート業務フローとしてHubSpotを設計します。
有人対応と自動対応が分断されず、業務全体の中で自然に機能する状態を目指します。

社内問い合わせも同じ構造で整理する

CRH では、社外向けサポートだけでなく、社内問い合わせについても ServiceHub を活用します。
社内チャットでの依頼、メールでの問い合わせ、部署間の確認事項なども、構造的には「問い合わせ対応」です。

これらを ServiceHub のチケットとして管理することで、対応状況の可視化、対応負荷の偏り把握、属人化の防止が可能になります。
「社外用」「社内用」とツールや管理方法を分けるのではなく、同じ構造で整理することが、運用を複雑にしないポイントです。

CRHが目指すのは「ServiceHubを業務基盤にすること」

CRH の ServiceHub 支援のゴールは、ServiceHub を「問い合わせ対応ツール」として導入することではありません。

・問い合わせ対応が属人化しないこと。
・対応状況をチーム全体で把握できること。
・改善のためのデータが自然に蓄積されること。
・AI 活用が場当たり的にならないこと。

こうした状態を実現するための、カスタマーサポートの業務基盤として ServiceHub を設計・実装することを目指しています。

方法論 × 実装の両輪で支援します

第1回の記事では、ServiceHub を活用する上での設計思想・方法論を解説しました。
第2回となる本記事では、その思想を弊社がどのように実装レベルで支援しているかをご紹介しました。

ServiceHub は機能が豊富だからこそ、「何から手を付けるべきか」「どこまで設計すべきか」「どこを自動化すべきか」で迷いやすいツールでもあります。

株式会社クリエイティブホープでは、機能ありきではなく、業務構造を起点に設計し、それを ServiceHub に落とし込む支援を行っています。

HubSpotの初期導入や運用に関するお困りごとがありましたら、ぜひ一度、以下のボタンよりお問い合わせ・ご相談ください。