No matter how well you understand Service Hub's functions, the site will not work unless you have an operational design that considers who should do what, with what authority, and in what order. In this chapterTeam structure, role definition, authority design, 90-day implementation roadmap, and long-term governance structureThis book provides a final guide to use the knowledge learned in all 12 chapters to launch an organization that actually works.
When implementing Service Hub, the most avoidable mistake is ``I bought a tool, but no one is taking responsibility.'' Ticket management settings, workflow construction, KB updates, AI learning data management—all of theseWithout a clear owner, configurations are left in limbo and teams revert to previous operations.. The four roles required for Service Hub operation are defined below.
HubSpot の権限設定は「ユーザー & チーム → 権限セット」から行う。権限を「何でもできる管理者」と「何もできない閲覧者」の2択で管理すると、設定変更のたびに管理者に依頼が集中し、日常業務がボトルネックになる。役割に合わせた適切な権限セットを作ることで、各担当者が自律的に動ける環境を整える。
| 機能・設定 | HubSpot admin | マネージャー | エージェント | CSM | KB 担当 |
|---|---|---|---|---|---|
| チケット（担当分）の閲覧・返信 | ✓ | ✓ | ✓ | ✓（担当分） | ✗ |
| 全チケットの閲覧 | ✓ | ✓ | ✗ | ✗ | ✗ |
| CRM コンタクト・会社の編集 | ✓ | ✓ | △（担当分） | ✓（担当分） | ✗ |
| ワークフローの作成・編集 | ✓ | ✗ | ✗ | ✗ | ✗ |
| KB 記事の作成・編集・公開 | ✓ | △（閲覧のみ） | △（閲覧のみ） | △（閲覧のみ） | ✓ |
| レポート・ダッシュボードの閲覧 | ✓ | ✓ | △（個人分） | △（担当分） | △（KB 分） |
| ユーザー・権限の管理 | ✓ | ✗ | ✗ | ✗ | ✗ |
| SLA・パイプラインの設定変更 | ✓ | ✗ | ✗ | ✗ | ✗ |
① 最小権限の原則——役割に必要な最小限の権限だけを付与する。「とりあえず管理者権限」は設定変更の事故やデータの誤削除のリスクを高める。② チーム単位で権限を管理する——個人ごとに設定するのではなく「サポートエージェント」「CSM チーム」などのチームに権限セットを紐づけることで、メンバーの入退社時の変更が1箇所で完結する。③ 四半期ごとに権限を棚卸しする——退職者のアカウントが残ったまま、過去の担当者が引き続き顧客データにアクセスできる状態は情報セキュリティリスクになる。
Service Hub の導入を成功させるには「すべてを一度に完璧に設定しようとしない」ことが最大のポイントだ。最初の30日で動く基盤を作り・60日で品質を上げ・90日でチームに定着させる3フェーズ構造で進めることで、チームが変化に追いつきながら段階的に成熟できる。
「30日で基盤構築」は目安であり、チームのサイズや既存ツールからの移行難易度によって変わる。Phase 1 で最も重要なのは「正しいルーティングが動いていること」だけ——それ以外は後から改善できる。最初から完璧を目指してPhase 1 に3ヶ月かけるより、動く状態を素早く作ってチームに使わせ、フィードバックを元に改善するサイクルを早期に回す方が、長期的な定着率が高い。
90日間の導入が完了した後、Service Hub を「使い続けられるもの」にするためのガバナンス設計が必要だ。ツールは生き物であり、ビジネスの変化・チームの変化・HubSpot 自体のアップデートに合わせて設定を進化させ続けることが、長期的な価値を生む唯一の方法だ。
管理者・マネージャー・エージェント・CSM・KB 担当——それぞれが「自分の範囲で自律的に動ける」権限設計にすることで、すべての変更が管理者に集中するボトルネックを防ぐ。最小権限の原則とチーム単位の管理が長期的な保守性を高める。
個人ごとに権限を設定するのではなく、チーム単位の権限セットに紐づける。退職者のアカウント残存・過剰な管理者権限の付与はセキュリティリスク。四半期ごとに全ユーザーの権限を確認する習慣を持つ。
Phase 1 の完了基準は「自動ルーティングが動いていること」だけ。完璧を目指して着手が遅れるより、動く状態を素早く作ってチームに使わせ、フィードバックで改善するサイクルを早期に回す方が最終的な定着率が高い。
ワークフロー・プロパティ・パイプラインの変更は管理者承認制にする。「変えた人が誰かわからない」状態は設定の混乱と二重通知・メトリクス汚染の温床になる。変更の記録をワークフロー台帳とセットで管理する。
HubSpot は毎月数十の新機能をリリースする。What's New の確認を管理者の月次ルーティンに組み込み、Service Hub に関わる変更点をチームに共有することで、「使えるはずの機能を使えていない」状態を防ぐ。
CSAT 件数・AI 解決率・ヘルスアラート発火数・Revenue Alignment ミーティングの開催回数——これらが「実際に動いているか」を確認することで、導入の成功を感覚ではなくデータで判断できる。
本書では0章から12章まで、Service Hub の設計思想からチケット管理・Help Desk・SLA・ナレッジベース・Breeze AI・カスタマーポータル・フィードバック・Customer Success Workspace・自動化・分析・Sales & Marketing 連携・運用設計まで体系的に解説してきた。これらの機能は、それぞれ独立したツールではなく、「顧客を成功させることで会社を成長させる」という一つの戦略を実現するための連動した仕組みだ。本書を読み終えたあなたが次に取るべきアクションは、第12章の 90日間ロードマップの Phase 1 を今週から始めることだ。