insightureAI: 从通话分析到销售闭环¶

文档角色：统一叙事入口 -- 所有人先读这个，再按需深入 目标受众：Co-Founders（技术 + 非技术） 创建日期：2026-02-14 详细文档：现状诊断 · 分阶段路线图 · Phase 1 实施

一、60 秒了解 insightureAI¶

insightureAI 是一套面向健身工作室的 AI 通话分析 + 线索追踪系统。我们对接 RingCentral 录制每一通电话，用 Deepgram 将语音转为文字，再用 Amazon Bedrock AI 自动分析通话内容（分类、意向判断、Coaching 建议）。同时，我们从 Web 表单自动抓取新线索（Lead），并在 Dashboard 上向老板展示所有数据。一句话：让健身房老板不用听每一通电话，就知道发生了什么。

二、问题：三个优秀但互不对话的系统¶

系统由三个独立模块组成，每个模块各自优秀，但彼此之间没有持久连接：

graph LR
    subgraph "Island 1: Lead Tracking"
        LT["Web 表单线索<br/>phone: 10 位格式"]
    end

    subgraph "Island 2: Call Analysis"
        CA["AI 通话分析<br/>phone: E.164 格式"]
    end

    subgraph "Island 3: Studio Dashboard"
        API["展示数据<br/>运行时临时匹配"]
    end

    LT -.-|"无持久链接"| CA
    CA -.-|"无持久链接"| LT
    API -->|"读取"| LT
    API -->|"读取"| CA

核心断裂

Lead 的 phone 存为 10 位（7328561597），Call 的 phone 存为 E.164（+17328561597）
两张表之间没有 Foreign Key，每次展示都靠运行时临时匹配
AI 分析时完全不知道客户历史（prompt 有占位符但代码没实现）
AI 判断的结果不会自动回写到 Lead 状态

一个真实场景：Jane Smith 的故事¶

时间	发生了什么	系统知道什么
Day 0	Jane 在官网提交表单	Lead 表新增一条记录：Jane Smith, phone: 7328561597
Day 1	Sarah 打电话给 Jane，聊了 5 分钟	Call 表记录通话，AI 分析说 "intro_booking, attempted"。但不知道这通电话属于哪个 Lead
Day 2	Sarah 跟进 Jane，成功预约体验课	AI 分析说 "intro_booking, success"。但 Lead 的 outcome 仍然为空
Day 3	Jane 到店了吗？买了吗？	系统完全不知道

我们的系统像一个超级聪明但失忆的员工 -- 每次打电话都忘记上一次的内容。

核心问题一句话¶

系统告诉老板 "What happened"，但老板需要 "What should I do next"。

三、愿景：同样的 Jane，打通后的体验¶

时间	发生了什么	系统自动完成
Day 0	Jane 提交表单	Lead 自动去重，phone 统一为 E.164，标记为 Hot
Day 1	Sarah 打电话给 Jane	AI 知道这是 Jane 的首次联系，结合 Lead 信息分析对话
Day 2	Sarah 跟进，成功预约	AI 知道这是跟进电话，自动将 Lead outcome 设为 `INTRO_BOOKED`
Day 3	Jane 到店	老板在 Dashboard 点击 "Showed Up"
Day 3	Jane 购买会员 $159	老板输入金额，完整漏斗追踪完成

Dashboard 理想状态：老板登录 5 分钟就知道今天该做什么。

Dashboard 核心模块¶

老板登录后将看到四个核心模块：

Today's Summary — 今日通话数、预约数、待跟进数、平均响应时间
Follow-up Queue — 按紧急度排序的待跟进 Lead（一键拨打 / 标记完成）
Lead Tracker — Hot / Warm / Cold 温度标签 + 通话历史 + Outcome
Staff Performance — 每个员工的通话量、预约率、趋势

完整 Dashboard 设计，见分阶段路线图 → Phase 2。

四、路线图：4+1 Phase¶

总览图¶

graph LR
    P1["Phase 1<br/>数据链路打通"] --> P15["Phase 1.5<br/>客户档案 + SMS"]
    P15 --> P2["Phase 2<br/>老板体验升级"]
    P1 --> P3["Phase 3<br/>Prompt 升级"]
    P3 --> P2
    P2 --> P4["Phase 4<br/>收入归因闭环"]

每个 Phase 一句话¶

Phase	一句话	状态
Phase 1	让三个系统的数据互通	Code Complete — 待部署
Phase 1.5	建立客户档案 + SMS 持久化	计划中
Phase 2	让老板一登录就知道该做什么	计划中
Phase 3	让 AI 分析更精准（可与 Phase 2 并行）	计划中
Phase 4	让整个漏斗可量化：Lead → Call → Book → Show → $	计划中

老板每个 Phase 能回答什么问题？¶

举几个例子：

Phase 1 之后：Lead 和通话自动关联，Outcome 不用手动填了
Phase 2 之后：登录就看到"今天 12 通电话、3 个 booking、2 个待跟进"
Phase 4 之后：完整漏斗 — "这个月 Web Lead 带来 $4,800 收入，Sarah 贡献 33%"

完整的 10 个问题 × 5 个 Phase 对照表，见分阶段路线图 → 老板视角。

为什么这个顺序？ 像盖房子 — Phase 1 打地基（数据链路），1.5 通水电（客户档案），Phase 2 装修客厅（老板第一眼看到），Phase 3 升级家电（AI 更精准），Phase 4 加装车库（完整漏斗）。每一步都依赖前一步的基础。

五、关键指标¶

系统打通后，老板能追踪这些以前看不到的核心指标：

指标	一句话
Response Time	Lead 到达后多久才有人打电话？（影响转化率的第一要素）
Booking Rate	打了电话的 Lead 中，多少成功预约？（AI 自动统计）
Staff Conversion Rate	每个员工的 Lead → Booking 转化率是多少？

完整 7 项指标及当前/改进后对比，见现状诊断 → 核心 Metrics。

六、深入阅读¶

文档	适合谁	内容
现状诊断 — 八个数据断点	Product Owner	8 个断裂点逐一诊断、AI Agent Debate 记录、代码级发现
分阶段路线图	全团队	每个 Phase 的 Before/After 详细对比
Phase 1 — 数据管道打通	工程师	7 个 Task 的代码级实施细节
Phase 1.5a — SMS 消息持久化	工程师	SMS 数据持久化方案分析
Phase 1.5b — 客户电话本	工程师	PhoneBook 客户档案表设计
远期评估 — 迁移关系型数据库	架构师	DynamoDB → PostgreSQL 远期规划
客户分级策略	业务	A/B/C/D 分级模型 — AI 的 intent_level 和 Hot/Warm/Cold 标签是其技术落地
模块化服务策略	业务	面向不同业态的模块化 SaaS 设计