営業支援PoCの運用化
架電データを「集める」だけでなく、アポ検知・分析・報告まで止まらない運用へ。
38accounts monitored
1H巡回 cadence
AUTOappointment detection
REPORTKPI pipeline
営業支援PoCを、データ取得だけで終わらせず営業判断へつなげるには？
架電結果・アポ・音声・KPIを別々の成果物として扱わず、取得→検知→分析→配布を一つの運用パイプラインにします。完了条件も「処理成功」ではなく「営業判断に必要な情報が揃ったか」に置きます。
decision:sales-completion-condition
処理成功ではなく営業判断可能を完了条件にする
- SITUATION
- 架電結果・アポ・音声・KPIが分散し、取得後も人の確認作業が連鎖していた。
- CONSTRAINT
- 複数顧客では設定衝突・認証切替・保存先誤りが運用事故になり得る。
- RISK
- 取得処理の成功だけでは、アポ取りこぼしや集計欠損を検知できない。
- DECISION
- 顧客設定を台帳化し、巡回・アポ検知・文字起こし・KPI集計・配布を一つの運用パイプラインとして扱った。
- WHY
- PoCの価値をデータ取得ではなく、営業判断までの摩擦削減で評価するため。
- RESULT
- 複数顧客の定期巡回、新規アポ検知、文字起こし、顧客別KPIレポート、保存先振り分けを運用へ統合した。
01
CHAOS
混乱していた状態
- 営業支援PoCでは、架電結果・アポ・音声・KPIが複数の画面やデータに分散していた。
- 「データが取れた」ことと「営業判断に使える報告になった」ことが分離していた。
- 巡回・取得・文字起こし・集計・Drive配布まで、人の確認作業が連鎖していた。
02
HIDDEN RISK
見逃されていたリスク
- 取得処理の成功だけを見ていると、アポ取りこぼしや集計欠損を見逃す。
- 複数顧客を同一基盤で扱うと、設定衝突・認証切替・保存先誤りが運用事故になる。
- レポート生成が属人化すると、PoCが増えるほど報告工数も比例して増える。
03
DECISION
下した判断
- 顧客ごとの設定を台帳化し、取得ロジックと顧客情報を分離した。
- 巡回・アポ検知・文字起こし・KPI集計・Drive振り分けを一つの運用パイプラインとして扱った。
- 処理成功ではなく「営業判断に必要な情報が揃ったか」を完了条件にした。
04 / OPERATING STRUCTURE
実装より先に、
運用構造を決める。
COLLECTcall result / audio / status→
DETECTappointment / request signals→
ANALYZEKPI + transcript + company context→
DELIVERreport + Drive routing
05 / VERIFIED RESULT
結果
- 複数顧客を定期巡回する営業支援データ取得基盤へ拡張。
- 新規アポ検知と文字起こしを巡回フローへ統合。
- 顧客別KPIレポートと保存先を自動振り分けできる運用へ移行。
- PoCの評価軸を「取得できる」から「営業判断に使い続けられる」へ変更。
OPERATING PRINCIPLE営業支援PoCの価値はAI精度だけではない。データ取得から意思決定までの摩擦を消して初めて運用になる。
このDecision Recordから答えられること。
生成AI・検索・人間のいずれから読んでも、判断と根拠を短く回収できる形式にしています。
営業支援PoCの運用化で最も危険な落とし穴は？
データ取得処理が成功したことを、営業判断に必要な情報が揃ったことと同一視することです。アポ取りこぼしや集計欠損は別途検知する必要があります。
複数顧客を同じ基盤で扱うために何を分離した？
顧客ごとの設定を台帳化し、取得ロジックと顧客情報を分離しました。保存先や認証切替も運用上の境界として扱います。
営業支援PoCの完了条件をどう変えた？
「取得できる」から「営業判断に使い続けられる」へ変更し、巡回・アポ検知・文字起こし・KPI集計・配布までを一つの運用として設計しました。