01 / CONTEXT

テレアポの「勘」は、なぜ共有できないのか。

Synayakaの営業現場では、毎日数十件のテレアポが回る。
うまくいく日とそうでない日が分かれるが、その差は「感覚」としか語られなかった。

結果として、成功の手順は属人的なまま、経験は次の人に渡らない。
採用のたびにゼロから始まってしまう。
そこに「可視化されていない不便」があった。

02 / CHALLENGE

成功と失敗の"型"を、文字の形で取り出す。

解くべき問題は、3 つに分けられた。

・通話内容を記録として残す（全員の学習素材になる形で）
・その記録から成功／失敗／断りの型を抽出する
・型をいつでも参照できる仕組みに置き換える

03 / APPROACH

録音 → 文字起こし → AI 分析 → 辞書化、の4段。

通話を録音するところまではどこにでもある。
sales_support はそこから先を組んだ：

① 自動文字起こし（OpenAI Whisper API）
② 会話内容の構造化（Claude API で「成功要因／失敗要因／断り文句」を抽出）
③ パターン辞書化（8 型 × 3 カテゴリでタグ付け）
④ スプレッドシート × ダッシュボード（営業チーム全員が閲覧・検索できる場所へ）

ポイントは、AI を「正解を出す装置」ではなく「問いを整理する装置」として使ったこと。
AI に判定させるのではなく、現場が読み返した時に気づきを得られる形で整理した。

04 / OUTCOME

導入先の営業チームの、日常に組み込まれた。

2026 年内に順次稼働し、Synayakaの営業チームが日常運用している。

現場のフィードバックは直接 UI 改善に還元される速いループが回っており、
"運用が止まらない"状態そのものが、初期段階の成果になった。

続けて開発中の「リアルタイム営業コーチ」では、過去データから学んだ型を商談中にリアルタイム配信する構想へ拡張している（ステップ A〜D）。

05 / REFLECTION

「正解を言う AI」より、「問いを整理する AI」の方が、現場に効いた。

sales_support を通して確信したのは、AI が一番役立つのは"判定"より"構造化"だという点だった。

現場の人は "この通話は成功／失敗" と AI に判定されたいわけではない。
「自分の癖」に気づける形で情報が並んでいることの方が、ずっと行動に効く。

可視化されていなかった属人的な勘が、毎週少しずつ「共有可能な辞書」へ変わっていく。
これは営業ツールという枠を超えて、「経験の属人化を解く」設計として Athenas の原型になっている。