Retaintive

    下一轮产品迭代执行逻辑(5 件事)

    这份是 backend-capability-productization-roadmap 的执行层。roadmap 回答「有什么、缺什么」;这份回答「每件怎么做、按什么顺序做」。所有「现状事实」来自 2026-07-01 跨 repo 代码实测(studio-website-monorepo / callytics-common / callytics-infrastructure / lead-tracking,当日 main)。

    排序原则一句话:便宜且无争议的先清(第一批,可并行),需要拍设计决策的单独拎出来(第二批),纯内部工具垫底(第三批)。

    执行批次总览

    批次内容前置
    第一批(low-hanging,互不依赖可并行)workstream 汇总端点 / unassigned 端点化 / AI 判断解释 read 端点无
    第二批(先拍设计再动手)Lead→Task 状态桥(拍方案 A/B)/ AI 解释 manager 面板状态桥要先验证 lead_status 及时性
    第三批(定义清楚了再做)zero-data 诊断 / 趋势线按 close result / legacy 端点清理 / AI 质量看板诊断规则、看板维度要先定义

    multi-tenant 机制线(部署 lead-tracking / NULL 告警 / sweeper 定时化 / 对账 job)与本文并行、互不阻塞,见 v1-gaps。

    1. Lead→Task 状态桥(最重要,第二批)

    为什么做:产品主线「lead 进来 → 建任务 → 员工跟 → 老板看结果」唯一断着的一环。Lead Tracker 现在回答不了老板每天最关心的问题:哪些 lead 没人管、哪些逾期了。这是 Lead Tracker 从报表变成工作工具的那一步。

    现状事实:

    • GET /v3/leads 返回 contacts.lead_status(AI 直接写入的 12 值枚举:new / attempted / connected / booked / showed / trialed / converted / unreachable / lost_contact / neglected / bad_timing / not_interested)+ 通话/短信计数,不 join tasks
    • lead 进来已通过统一任务系统建 follow-up task(lead-tracking → common applyTaskAction),数据是通的,只是读路径没接
    • 前端 leads-v3 有 lead_status 徽章、action_needed 提示、5 天 stale banner;没有 lead→具体 task 直达、funnel 各阶段不可点、无任务级 overdue
    • funnel(/v3/leads/funnel)已区分 Outreached(尝试过)/ Contacted(真接通,HUMAN_CONVERSATION 判定)

    关键设计点(先拍再动手):

    • 方案 A(推荐):复用 contacts.lead_status + 补 task 维度——聚合端点返回每个 lead 的 lead_status + 关联 open task(task_id / due_at / overdue)+ 最近一次跟进。便宜(一个端点),口径与 contacts 页一致
    • 方案 B:完全从 tasks + timeline 派生一套新状态(roadmap 原提案的 not_started/attempted/.../overdue 枚举)。更可控但要新建推导逻辑,且与 AI 维护的 lead_status 并存两套口径
    • 拍板前置验证:lead_status 由 AI 分析写入,要确认它的更新及时性够不够撑 funnel(验证思路:抽近 7 天有通话的 leads,对比 contacts.updated_at 与最近通话时间的滞后分布)。滞后可接受 → 方案 A;经常滞后几小时以上 → 方案 B 或混合

    要做什么:

    • 后端:lead 列表聚合端点加 task 维度(join tasks on contact_phone + store_id,取 open task 的 due_at 算 overdue;already_member 可从 customer_type 映射)
    • 前端:lead 卡挂任务状态徽章 + 点击直达 task detail;funnel 每个数字可点进人员清单;overdue 加过滤器和标识

    验收:老板能在 Lead Tracker 页回答「哪些 lead 逾期没人跟」并点进去看到具体任务;funnel 每个数字都能下钻到人。

    2. 任务工作台进度记录(已完成:studio#639/#641)

    为什么做:任务页必须从“看任务”变成“员工真的在这里工作”的地方。跟进过程要落进 timeline,否则 manager 只能看到 open/closed,看不到员工中间做了什么。

    现状事实:已落地。POST /v3/tasks/progress 对 callback_requested / follow_up_scheduled 强制要求 nextDueAt(progress.ts:68-78);前端 task-progress-actions.vue 已暴露 6 种进度记录:4 个 instant action(no_answer / left_voicemail / text_sent / customer_considering)+ 2 个 scheduled action(callback_requested / follow_up_scheduled),scheduled action 带时间选择器和可选 note。

    要做什么:从本轮待办移除。下一层如果继续增强任务工作台,重点不是再加按钮,而是从具体 call / message 直接记录 progress 并挂 evidence、补 instant action note、补更完整的 staff attribution。

    验收状态:6 种进度类型已可从任务页记录;scheduled action 会按所选时间更新下次跟进时间(due_at)并显示在 timeline。

    3. AI 判断解释(read 端点第一批,面板第二批)

    为什么做:AI 每次「建/关/保留任务」的判断和理由都写进了 ai_task_decision_assessments(含 prompt 版本、依据来源),但只写不读——客户问「系统为什么这么判」时 support 只能猜。这是信任和排错的基础设施。

    现状事实:表结构完备(disposition / keepReason / reason / sourceRefs / promptVersion / assessmentKey 幂等键),pipeline 持续写入;studio-api 全库 0 引用,前端零消费。

    要做什么:

    • 后端(low-hanging,纯读路径):GET 端点按 task / contact / run 查询,把 disposition(keep_open/close/create...)和 keepReason 翻译成展示文案;store 隔离沿用现有 guard
    • 前端(第二批):task detail 里加「AI 为什么这么判」折叠面板,先只对 internal / admin / manager 可见

    验收:support 对任意任务能查到「AI 看到了什么 → 判了什么 → 为什么」,不用查库。

    4. 聚合与健康检查小件(第一批 2 件 + 第三批 3 件)

    第一批(纯聚合/搬运,无设计争议):

    • workstream 汇总端点:Lead 获客 / Member Care / Revenue Growth 三类的任务汇总卡。分类常量已在 tasks/list.ts:47-55(member_care = cancellation_risk/retention/renewal,revenue_growth = win_back/upgrade/referral),现在只用于列表过滤,差一个聚合查询
    • unassigned 号码列表端点化:现在前端从 GET /v3/setup/suggestions 差集计算,下沉成后端端点,口径唯一

    第三批(要先定义规则):

    • per-store zero-data 诊断(「这家店为什么没数据」):要先枚举诊断规则(无 phone → 无 calls;未 activate → 不追踪;等),规则清单定了实现就简单
    • 趋势线按 close result 拆:task-trends 现在按 close type(AI/manual),结果维度(booked/converted/cancel_saved)只在表格卡片里
    • legacy dashboard/lead-tracker 端点清理:它还把 outbound 当 contacted,服务已隐藏的旧页面,随旧页面一起删

    验收:dashboard 出现三张 workstream 汇总卡且口径与任务列表一致;Setup 的 unassigned 列表来自后端端点。

    5. AI 质量看板(内部工具,第三批)

    为什么做:持续提升 AI 判断质量需要看得见的对照——但它是内部工具,客户不感知,排最后。

    现状事实:底座全部已部署——shadow engine 在跑(EventBridge → engine-run Lambda → 只写 engine_shadow_runs 表,含 tenantId / targetResult / recipeVersion,不碰 live 数据);contacts-analyzer 有 golden-eval 脚本;assessments 带 promptVersion。缺 read 端点和任何可视化。

    要做什么(维度先定义再做):shadow vs live 决策 diff 视图、assessment coverage(哪些 run 缺判断)、按 prompt version 的表现对比。先做最小版:一个内部页面 + 按 contact/run 的 diff 列表。

    验收:prompt 改版后能在看板上回答「新版和旧版在同批通话上的判断差异是什么」。

    相关文档