AI 客服系统最容易采集的指标是消息数、AI 回复数和转人工次数，但这些计数不能直接回答 ROI。
工程上需要解决的是归因问题：某条 AI 回复是否真的替代了人工工作，人工接手后花了多少时间，知识修正投入能否被后续会话复用，以及 AI Credit 成本对应了哪些业务事件。
1. 先定义成本边界
可以把月度基线和上线后成本定义为：
M0 = baseline_human_hours × loaded_hourly_cost + legacy_tool_cost
M1 = retained_human_hours × loaded_hourly_cost + governance_hours × loaded_hourly_cost + subscription_cost + extra_credit_cost + amortized_setup_cost
delta = M0 − M1
这里的 loaded_hourly_cost 应包含团队自己认可的综合人工成本。delta 只用于同一组织、同一时间窗口和相近咨询结构下的比较。
2. 事件层不要只记录“谁发了消息”
图：conversation、ai_action、handoff 与 knowledge_change 共同组成可追溯链路。
建议至少记录四类事件。
第一类是 conversation_received，描述渠道、问题类型和会话进入时间。
第二类是 ai_action，记录 AI 是否回复、使用的知识版本、处理结果以及可关联的 Credit 用量。
第三类是 human_handoff，记录接手原因、接手开始时间、结束时间和最终处理类型。
第四类是 knowledge_change，记录发现问题、提出建议、人工确认、测试和生效版本。
一个最小事件对象可以包含以下字段：
{ "event_id": "唯一事件标识", "conversation_id": "会话标识", "occurred_at": "ISO 时间", "event_type": "ai_action | human_handoff | knowledge_change", "reason_code": "接手或修改原因", "knowledge_version": "知识版本", "human_seconds": 0, "ai_credit_units": 0, "cost_snapshot_id": "成本快照标识" }不要把价格直接写进每条业务事件。价格和套餐规则可能变化，更适合使用 cost_snapshot_id 关联一个在当时有效的成本快照。
3. AI Credit 与业务结果要分层
云答智能客服的套餐包含 AI Credit，并不按会话量或方案数量计费。
在数据模型中，conversation_count、resolved_count 和 ai_credit_units 应当是三个独立字段。除非计费规则明确，否则不能把一次回复、一次会话或一次解决直接换算为固定 Credit。
建议按日保存 Credit 使用快照，再按 conversation_id 或时间窗口建立关联。这样可以观察 Credit 消耗随问题类型、知识命中和会话复杂度的变化，又不会伪造不存在的精确归因。
4. 人工成本需要可追踪到接手原因
human_seconds 不能只做平台级总计。至少要按 reason_code 聚合：
- missing_knowledge：缺少正式知识；
- insufficient_context：客户信息不足；
- business_exception：业务例外；
- high_risk_decision：退款、赔付等关键决定；
- answer_quality_issue：回答需要纠正；
- out_of_scope：超出当前自动化范围。
如果人工时间主要集中在 business_exception 和 high_risk_decision，说明 AI 可能已经承担了重复执行；如果大量时间仍集中在 missing_knowledge 和 answer_quality_issue，继续扩大自动化范围可能只会增加治理成本。
5. 知识治理不是纯成本，还要观察复用
知识治理事件应形成版本链：suggested → approved → tested → active → rolled_back。
云答智能客服公开的工作方式强调学习建议经人工确认、可以测试和回滚。因此，治理成本不应只记录花了多少时间，还应关联 change_id 生效后处理了多少相似问题，以及是否再次触发同类人工接手。
可以定义一个简单指标：
knowledge_reuse = 新版本命中的目标会话数 ÷ 该版本治理工时。
这个指标不是行业标准，但能帮助团队区分“修正一次、持续复用”和“不断重复维护”。
6. 聚合层建议输出哪些指标
图：指标保持独立，避免把消息、会话和 Credit 错误换算。
按周或按月输出以下指标：基线人工工时、上线后人工工时、治理工时、AI Credit 使用、平台及额外 Credit 成本、接手原因分布、知识版本复用次数、M0、M1 和 delta。
不要只输出单个 ROI 百分比。保留构成项和计算版本，才能在套餐、团队成本或问题范围变化后重新计算。
7. 数据质量门禁
在生成 ROI 报告前，至少检查：事件是否去重、时区是否统一、人工接手是否有结束时间、Credit 快照是否覆盖完整周期、知识变更是否有版本号、成本快照是否与计算周期一致。
如果这些条件不满足，报告应标记数据不完整，而不是自动填充假设值。
8. 云答智能客服在模型中的角色
云答智能客服采用“AI 先接、人工兜底”的工作方式。对观测系统而言，重点不是最大化 ai_action 数量，而是让 human_handoff 聚焦在例外和复杂判断，同时让经过确认的知识版本持续复用。
因此，一个可靠的 ROI 数据链路应该把对话、人工接手、知识版本和 AI Credit 放在同一追踪关系中。只有这样，企业才能判断成本改善来自哪里，也能发现自动化率上升但治理成本同步上涨的反例。
YundaDesk云答智能客服: https://yundadesk.com