1. エグゼクティブサマリー
ミラタップ様のご要件は「営業CRM」ではなく「カスタマーサポートCRM」であり、中核はCSC（カスタマーサービス課）のクレーム案件管理を、伝票目線から顧客軸・商品軸の管理へ刷新することと理解しています。
| 役割 | プロダクト | 位置づけ |
|---|
| 問い合わせ・クレーム案件管理（現行kintone「CSC」アプリの置き換え） |
Zoho Desk |
中核。チケット単位でクレーム案件を管理し、メール・LINE等のチャネルを集約 |
| 顧客マスタ・顧客担当者・商品マスタの管理 |
Zoho CRM |
顧客軸・商品軸の「台帳」。Deskと標準連携で双方向同期 |
| 多軸ピボット分析（購入者軸・ユーザー軸・商品軸） |
Zoho Deskレポート/ダッシュボード（一旦の提案） |
まずはDesk標準のレポート・ダッシュボードで顧客別・商品別の集計に対応。Desk＋CRMを結合した高度な横断分析が必要になった場合はZoho Analyticsを拡張採用 |
この構成を推す理由:
- Zoho DeskとZoho CRMは標準機能で双方向連携でき、取引先・連絡先・商品が同期され、CRMの顧客レコード上でその顧客のチケット（クレーム）履歴を、Deskのチケット上で顧客のCRM情報を相互に参照できます。「同じお客様から過去にどんな問い合わせがあったか」「同じ商品について他のお客様からどんな問い合わせがあったか」という現行kintoneの課題に直接応えられます。
- メールは標準チャネル、LINEはDeskの標準IMチャネルとして連携可能。連携の対象はLINE公式アカウント（Messaging API）と顧客とのやり取りであり、公式アカウント宛の会話が自動でチケット化されます（従業員個人のLINEは対象外）。将来拡張のご要望に合致します。
- Microsoft Teamsとの標準連携があり、Teams上でチケット通知の受信・コメント・返信・ステータス更新が可能。一方でクレーム対応の議論はDeskのチケットコメント（社内非公開コメント）に資産として残せるため、「チャット履歴を資産化しつつ、ツールを増やさない」という論点に両立解を提示できます。
- MA・リード育成・商談パイプラインといった営業CRM機能を持ち込まず、サポート業務に特化した必要最小限の構成にできます（CRMは顧客・商品台帳として利用）。
2. 提案アーキテクチャ
2.1 全体像（既存プロセスとの関係）
① コールセンター → kintone「オペレーショングループアプリ」 【現状維持・スコープ外】
│ クレームと判断
▼
② 販売管理システム（伝票入力・運送破損は代替品出荷で完結） 【現状維持】
│ 商品そのものの問題
▼
③ Zoho Desk（クレーム案件＝チケット管理） 【← kintone「CSC」アプリを置き換え】
├ メール / LINE / Webフォーム等のチャネル集約
├ チケットコメントで関係者チャット（社内非公開）
└ Microsoft Teams連携（通知・Teams上からの操作）
▼ 双方向同期（標準連携）
Zoho CRM（顧客マスタ・顧客担当者・商品マスタ）
▼ データ連携
Zoho Analytics（購入者軸・ユーザー軸・商品軸のピボット分析）
- ①②は現状維持の前提です。②→③の受け渡し方法（手入力継続か、伝票番号の参照連携か等）は要協議事項です。
- Desk⇔CRMの同期は取引先・連絡先・商品モジュールを対象に、一方向（CRM→Desk）/双方向を選択できます。
2.2 データモデル案（購入者とユーザーが分かれる商品特性への対応）
「購入したのは施工店、使用するのは家を建てたオーナー」という構造を、CRM側で次のように台帳化することを想定しています（詳細は要件定義フェーズで確定）。
| 概念 | Zoho CRM上の想定 | 備考 |
|---|
| 購入者（施工店・法人） | 取引先（Accounts） | 購入者軸の分析キー |
| 購入者側の担当者 | 連絡先（Contacts）※取引先に紐付け | 顧客担当者管理の要件に対応 |
| ユーザー（オーナー・個人） | 連絡先（Contacts）または専用カスタムモジュール | ユーザー軸の分析キー。持ち方は要協議 |
| 商品 | 商品（Products） | 商品軸の分析キー。Desk側チケットにも商品を紐付け可能。※商品点数が多い想定のため、保持範囲・更新方法・チケット紐付け方式は要確認（8章#5） |
| クレーム案件 | Zoho Deskのチケット | 購入者・ユーザー・商品への参照項目を持たせる |
- チケットに「購入者」「ユーザー」「商品」の参照を持たせることで、1件のクレームを複数の軸から集計できます。
- ユーザー（オーナー）情報をどこまで保有しているか（施工店経由でしか分からないケース等）は商談で確認が必要です。
- 商品マスタは点数が多い想定のため、(a) 全品番をCRMへ同期するか問い合わせ対象品番に絞るか、(b) 販売管理システムからの更新同期の要否・頻度、(c) チケットとの紐付け方式（商品ルックアップの検索性で運用に耐えるか、型番テキスト＋マスタ参照とするか）を要件定義で確定します。
- 購入者とユーザーの分け方は要検討です。特に、問い合わせを受け付けた時点で、連絡者を「購入者（施工店）」と「ユーザー（オーナー）」のどちらとして判定・登録するのか（受付時の確認項目・判定ルール・迷うケースの扱い）は、多軸分析の精度を左右するため要件定義で設計します（8章#3）。
3. 要件対応表
3.1 必須要件への対応
| # | 要件 | 対応 | 実現方法 |
|---|
| 1 | 顧客マスタ管理 | ◎ | Zoho CRMの取引先・連絡先で管理し、Zoho Deskと双方向同期（標準連携） |
| 2 | 顧客担当者管理 | ◎ | CRMの連絡先を取引先（施工店等）に紐付けて管理。Desk側でも同一情報を参照 |
| 3 | 問い合わせ履歴管理 | ◎ | Deskのチケットとして一元管理。顧客（連絡先/取引先）単位で過去チケットを一覧可能 |
| 4 | クレーム管理 | ◎ | Deskのチケットをクレーム用レイアウト・項目で構成。Blueprint機能で「受付→調査→対応→完了」等の状態遷移と担当・期限を統制可能 |
| 5 | メール連携 | ◎ | Deskの標準メールチャネル。サポート用アドレス宛のメールを自動でチケット化し、やり取りを時系列表示 |
| 5' | （拡張）LINE連携 | ◎ | DeskのIMチャネルとしてLINE公式アカウントを標準連携。対象はLINE公式アカウントと顧客とのやり取りで、会話は自動でチケット化（Messaging APIのチャネルID等が必要。公式アカウントの開設・運用が前提） |
| 5'' | （拡張）FAX連携 | △ | Deskにネイティブ機能はなし。インターネットFAX等でFAXをメール化し、受信メールの文面をWebhook（Zoho Flow）経由でDeskに取り込む構成を想定（メール文面をパースしDesk APIでチケット作成、要検証）。さらに、取り込み時にGemini等のAIでFAX文面を解析し、顧客名・商品型番等をデータ化（項目抽出）してチケットにセットする拡張も可能性として検討 |
| 6 | 添付ファイル管理 | ◎ | チケット・メール・LINEの添付ファイルをチケットに紐付けて保管 |
| 7 | 顧客ごとの時系列履歴 | ◎ | Deskは顧客とのやり取りを時系列で表示。CRM側でも顧客レコードの関連リストにチケット履歴を表示（標準連携） |
3.2 「欲しい機能」への対応
| # | 要件 | 対応 | 実現方法 |
|---|
| 8 | チャット機能（案件ごとに関係者と対応を進める） | ◎ | Deskのチケットコメント（社内非公開コメント）で、チケット＝クレーム案件単位に関係者が議論。@メンション・チームフィードも利用可。履歴はチケットに残り、クレーム対応の資産として蓄積 |
| 9 | Teams連携 | ◎ | Desk標準のMicrosoft Teams連携。Teamsチャネルへのチケット通知（新規・割当・更新等）、TeamsタブからのDeskチケット閲覧・コメント・返信・ステータス変更が可能 |
| 10 | 多軸ピボット分析（購入者軸・ユーザー軸・商品軸） | ◎〜○ | 一旦、Desk標準のレポート・ダッシュボード（顧客別・商品別集計等）をご提案。ただし購入者とユーザーが分かれるため、両者をどう分けて管理するか（受付時にどちらと判定するかを含む）の設計が前提（2.2章・8章#3）。より自由なピボット（Desk＋CRMのデータ結合、購入者×ユーザー×商品のクロス分析）が必要な場合はZoho Analyticsを拡張採用 |
3.3 不要要件との整合
MA・リード育成・インサイドセールス・商談パイプラインは本構成では導入対象外です。Zoho CRMは顧客・商品台帳としてのみ用い、営業向け機能の設定は行いません（将来営業側で活用したくなった場合に拡張できる余地は残ります）。
3.4 論点#1（チャット: CRM内 vs Teams）への提案
「対応の正史はDeskのチケットコメント、通知と即時性はTeams連携」の併用をご提案します。
- クレーム対応の判断過程・経緯は、案件（チケット）に紐付くコメントとして残すことで、後から誰でも文脈ごと追える「資産」になります。
- Teams連携により通知はTeamsに集約でき、簡単な確認・返信はTeams上から可能なため、日常的に開くツールは増えません。
- Teamsの自由なチャットだけに議論が散らばると資産化されないため、「決定事項・重要な経緯はチケットコメントに残す」という運用ルールをセットで整備します。
@メンション時の通知経路（調査結果）:
| 通知先 | 可否 | 論拠 |
|---|
| メール | ◎ | Deskの通知ルール（Notification Rules）に「チケットでのメンション（Mentioning in a ticket）」イベントが標準で用意されており、メンションされたエージェントへメール通知を送れる（公式ヘルプに明記。当社demo環境の通知設定画面でも、メンション通知の既定チャネルがメール/SMSのみであることを確認済み。SMSは外部パートナーのクレジット購入が必要） |
| Teams | △ | Teams連携の通知（チャネル通知・個人向けDesk Bot通知）は「チケットの作成・更新」をトリガーとするもので、@メンション単体をトリガーにしたTeams通知は公式ドキュメント上確認できず（要検証）。必須要件となる場合は、Deskのワークフロー＋カスタム関数からTeamsのIncoming Webhookへ投稿する追加開発で実装可能 |
→ 運用設計としては「メンション通知はメール（標準・確実）を基本とし、チーム全体への動きの共有はTeamsチャネル通知（チケット作成・更新）で補完」を推奨します。メンションのTeams直接通知が必要かどうかは、商談確認事項（8章#8）のTeams連携の具体像とあわせて確認します。
4. デモンストレーション（demo環境・実データによる実演）
上記の要件対応を、当社demo環境（Zoho Desk × Zoho CRM 連携設定済み）にミラタップ様の商材イメージへ合わせたデモデータを投入のうえ、実演します。
4.1 デモデータ
- 購入者=施工店（取引先）3社 / 施工店担当者・オーナー（連絡先）6名 / 商品（住宅設備品番）3点
- クレームチケット6件（分類=Problem、#127〜#132）＋ 一般問い合わせチケット5件（分類=Question、#133〜#137）
- チケットには社内非公開コメント（社内チャットのサンプル）を設定済み
4.2 実演フロー
| Step | 実演内容 | 対応要件 |
|---|
| 1 | クレーム受付と一元管理: 1クレーム=1チケットで対応履歴・添付・コメントが1画面に集約。メール/電話/Web等どのチャネルで受けても同じチケットになる | 要件#3・#4・#6 |
| 2 | 顧客軸の時系列履歴: 顧客（オーナー山田様）を開くと、クレームも一般問い合わせも時系列で全件見える。分類（Problem/Question）でクレームのみの絞り込みも可能 | 要件#1・#7／課題「同じお客様の過去の問い合わせ」 |
| 3 | 商品軸の横断検索: 商品型番（KV-100）で絞り込むと、複数顧客のクレーム3件＋問い合わせ2件が横断で並び、ロット不良の兆候に気付ける | 課題「同じ商品への他のお客様からの問い合わせ」 |
| 4 | 購入者/ユーザーの分離管理: 取引先（施工店）と連絡先（オーナー）を別レコードで管理し、CRM側の関連リストからDeskの問い合わせに辿れる。商品別・顧客別のレポートも提示 | 要件#2／欲しい機能#10 |
| 5 | 案件単位の社内チャット: チケットの社内非公開コメント（顧客には見えない）で関係者協議が案件に紐付いて残る＝チャット履歴の資産化 | 欲しい機能#8 |
| 6 | クレーム対応プロセスの統制: Blueprintによる「受付→調査→対応→完了」の状態遷移・必須項目・担当割当 | 要件#4（プロセス面） |
| 7 | Teams連携（オプション）: チケット更新のTeams通知と、Teamsタブからのチケット閲覧・操作 | 欲しい機能#9 |
| - | クロージング: 要件対応表（3章）に立ち返り必須7項目の充足を確認。LINE・FAX・Analyticsは拡張フェーズの位置づけを説明 | - |
4.3 所要時間目安
| 区分 | 時間 |
|---|
| Step 1〜5（コア: 課題解決の実演） | 15〜20分 |
| Step 6〜7（プロセス統制・Teams） | 5〜10分 |
| 質疑・確認事項のヒアリング | 15分 |
5. kintone「CSC」アプリからの移行
| 項目 | 方針案 | 備考 |
|---|
| 既存クレームデータ | kintoneからCSVエクスポート→Desk/CRMへインポート（またはAPI移行） | 移行対象範囲（全件/直近n年）は要協議 |
| 顧客・商品マスタ | 販売管理システム等の既存マスタからCRMへ初期投入 | マスタの所在・鮮度は商談で確認 |
| 移行時のデータ整備 | 伝票目線のレコードを「顧客・商品に紐付く形」へ変換 | 今回の課題解決の核心。名寄せルールの設計が必要 |
6. 概算ライセンス（参考）
※2026-08時点のZoho公式サイト（年間契約時）に基づく参考値。正式見積り前に最新価格・プラン仕様の確認が必要。
| プロダクト | プラン目安 | 参考価格（年間契約時/ユーザー/月） | 選定観点 |
|---|
| Zoho Desk | プロフェッショナル または エンタープライズ | ¥3,260 / ¥5,660 | LINE等IMチャネル・Blueprint・Teams連携等の利用範囲で決定。CRM連携・Teams連携は有料プランで利用可 |
| Zoho CRM | プロフェッショナル（一旦の提案） | ¥3,260 | 顧客・商品台帳＋Desk連携用途。検証ルール・在庫管理系機能等を含むプロフェッショナルで提案し、要件定義で過不足を確認して確定。必要ユーザー数も要確認 |
| Zoho Analytics | （分析要件により） | ?（要確認） | 標準レポートで足りるかを見極めてから追加判断も可 |
- ユーザー数（CSCの人数、閲覧のみのユーザーの有無）が費用に直結するため、商談で確認します。
- Zoho One（全社スイート）とする選択肢もあり、対象ユーザー数・利用範囲次第で比較提示可能です。
7. 進め方・マイルストーン（案）
※期間はいずれも概算。クレーム件数・移行データ量・ユーザー数・連携要件（②販売管理→③の受け渡し方法）が未確定のため、Phase 0完了時に確定計画を提示する。
7.1 フェーズ
| フェーズ | 内容 | 期間目安 |
|---|
| Phase 0 | 要件定義（データモデル確定・移行範囲・②→③受け渡し方法・チャット/Teams運用ルール） | 3〜4週 |
| Phase 1 | Desk/CRM初期構築（Desk基本設定・メールチャネル・クレーム用レイアウト・Blueprint・Desk⇔CRM連携・CRM台帳整備・Teams連携・レポート/ダッシュボード・運用ルール整備） | 4〜6週 |
| Phase 2 | データ移行（マスタ投入・kintone CSCデータ移行）・並行稼働・トレーニング | 3〜4週 |
| Phase 3 | 本稼働・定着支援（問い合わせ対応・設定チューニング） | 1〜2ヶ月 |
| Phase 4（拡張） | LINEチャネル追加・FAX取込（Webhook経由、AI解析によるデータ化含む）・Analytics高度分析 | 必要に応じて |
7.2 マイルストーン（契約後 約3ヶ月で本稼働）
| 月 | 週 | マイルストーン |
|---|
| 1ヶ月目 | W1〜W2 | キックオフ・現行kintone「CSC」/業務フローの詳細ヒアリング・データモデル確定 |
| W3〜W4 | 移行範囲・②→③受け渡し方法・運用ルールの合意（Phase 0完了） |
| 2ヶ月目 | W1〜W3 | Desk/CRM初期構築・お客様レビュー |
| W4 | 運用ルール整備・マスタ移行の準備（データクレンジング開始・Phase 1完了） |
| 3ヶ月目 | W1〜W2 | マスタ・kintoneデータ移行、並行稼働（新規クレームをDeskで受付開始） |
| W3 | トレーニング実施・最終調整 |
| W4 | 本稼働（kintone「CSC」新規登録停止） |
| 4ヶ月目〜 | - | 定着支援（Phase 3）。安定後、拡張フェーズ（LINE・FAX・Analytics）を協議 |
7.3 段取り上のポイント
- まずはメール＋手入力での最小構成で立ち上げ、LINE・FAX・Analyticsは拡張フェーズで段階導入する（リスク・コスト最小化）。
- 移行の核心は「伝票目線→顧客・商品紐付け」への変換（kintone CSCデータ移行）。ここはPhase 0での名寄せルール設計の品質に依存するため、要件定義に時間を割く。
- 並行稼働期間（3ヶ月目W1〜W2）は「新規はDesk・過去参照はkintone」と役割を明確化し、二重入力を避ける。
8. 未確定事項・商談確認事項
- CSCのユーザー数・クレーム案件の月間件数（プラン・費用の前提）
- ユーザー（オーナー）情報の保有状況と個人情報の取り扱い方針
- 問い合わせ受付時の購入者/ユーザー判定ルール: 連絡者を「購入者（施工店）」と「ユーザー（オーナー）」のどちらとして判定・登録するか。受付時に確認する項目、判定に迷うケース（施工店経由でオーナーの問い合わせを受ける等）の扱い
- 顧客・商品マスタの正データの所在（販売管理システムか）と、CRMへの投入・更新方法
- 商品マスタの保持・更新・紐付け方式（商品点数が多い想定）: 件数規模、保持範囲（全品番か問い合わせ対象品番のみか）、販売管理システムからの更新同期（手動/定期/API）、チケットへの紐付け方法（商品ルックアップか型番テキスト入力か）
- ②販売管理システム→③新システムの受け渡し方法（手入力継続か連携か）
- kintone「CSC」アプリの既存データ移行の要否・範囲
- メール運用の実態（共有アドレスか個人アドレスか）、FAX・LINEの現在の受付状況
- Teams連携に期待する具体像（通知のみで足りるか）
- 導入時期・予算・体制
9. 参考情報（調査ソース）