💻 システム開発

SCALE_CRM_ナレッジ集_自動蓄積設計提案

最終更新 2026年06月24日 ／ 31_システム開発部/_SCALE_CRM_ナレッジ集_自動蓄積設計提案.md

案A 実装完了 2026-05-16 v10.43
大串「過去分は不要・今後は使ったトーク/失注理由が溜まるように」→ 案A実装。calllist.js _autoKnowledgeFromStatus がステータス保存時に talkScript を結果分類(勝ち/課題/参考トーク)+lossReason(失注理由)を svc.callKnowledge(source:auto_status)へ自動push。過去バックフィルなし・refKey冪等で再保存重複なし・auto_apo非干渉・静か蓄積。案B(AI日次要約)/案C は効果を見て今後検討。

SCALE CRM ナレッジ集 自動蓄積 設計提案

大串FB（2026-05-16）
「今ってどういうロジックでそれぞれのナレッジ集に更新される座組になってる？基本は自動で溜まっていく座組にしていきたいから、その前提で設計一からしないと機会損失増えていくかも」

30秒で全体像

観点 一言
現状 架電ナレッジのみ自動（アポ獲得時 + 日報時）。FAQ/成功事例/所感/切り返し等は手動依存
機会損失 ステータスモーダルで毎回入力済の talkScript/lossReason/apoKnowledge が、ナレッジに流れず死蔵
推奨 案A（既存入力の自動分類流し込み）を即実装 → 効果を見て案B（AI日次要約）

現状の更新ロジック（調査結果）

ナレッジ種別 格納先 更新方式
架電ナレッジ callKnowledge svc.callKnowledge 自動 ①架電ステータス→「アポ獲得」時 source:auto_apo（apoKnowledge＋先方contact/title）②日報送信時 _drPushToKnowledgeHub（良かった点/課題を自動push）＋手動追加可
FAQ faq svc.faq 手動（addFAQ）＋ AI生成（showAIFAQGen 実行時のみ）
成功事例 successCases svc.successCases 手動（addSuccessCase）
メンバー所感 memberInsights svc.memberInsights 手動（addMemberInsight）
アプローチ切り口 approachTips svc.approachTips 手動
効果的ワード effectiveWords svc.effectiveWords 手動
ヒアリング項目 hearingItems svc.hearingItems 手動（KO連携）
切り返し objectionHandling svc.objectionHandling 手動 ＋ AI生成

機会損失の正体

架電ステータス変更モーダル（showCallStatusModal）で毎回入力されている構造化データが、ナレッジ集に一切流れていない:
- talkScript（使ったトーク／切り返し）— アポ獲得でも失注でも入力される生きた知見
- lossReason（失注理由）— 失注傾向の宝庫
- apoKnowledge（アポ獲得要因）— アポ獲得時のみ callKnowledge に流れる（=これだけ自動済）

→ 既に入力されている情報の大半を捨てている。手動で改めてナレッジ登録しないと蓄積されない＝事実上溜まらない。

設計案（3案）

案A 推奨 — 既存入力の自動分類流し込み（最小工数・最大効果）

  • ステータスモーダル保存時、入力済の talkScript を結果で自動分類して callKnowledge に push（source:auto_status）:
  • アポ獲得/好反応 → タグ「勝ちトーク」
  • 失注/不通/見送り → タグ「課題トーク」
  • lossReason を集計し「失注傾向」ナレッジに自動反映（件数の多い理由を可視化）
  • 既存 auto_apo 機構の素直な拡張。新規入力負荷ゼロ（既に入力済データの再利用）
  • 重複防止（callId+回 でユニーク）・PM がノイズを間引ける削除導線
  • 工数: 小 / リスク: 小 / 即効性: 高

案B — AI日次/週次要約（質重視・中規模）

  • 1日の架電ログ（ステータス/トーク/結果）を callClaudeGW で要約 → 「今日の勝ちパターン/詰まりパターン」を自動生成しナレッジ集へ
  • 質は高いが API 課金・バッチ設計・生成物レビュー導線が必要
  • 工数: 中 / 案A の上位互換的役割

案C — 収集レイヤ＋キュレーションレイヤに再設計（大規模）

  • 全架電イベントを生ログ蓄積 → 自動タグ付け → 人が「正式ナレッジ」へ昇格
  • 機会損失ゼロだが設計・データ移行が大きい

推奨アクション

案A を即実装（次リリース）→ 1〜2週間運用 → 効果を見て案B を追加。

理由: 案A は「既に入力されているのに捨てている」構造的機会損失を最小工数で塞ぐ根本対処。その場しのぎでなく、入力導線を増やさず蓄積が回り出す。案B/C は案A の効果を見てから投資判断するのが合理的。

→ 大串の選択待ち（案A実装でGO / 案も含め再検討 / スコープ調整）。合意後に実装リリース（コード未着手＝根本解決優先・設計合意先行）。

関連