试点上线后没人负责，问题积压
答错了没人记、没人改，小问题攒成不信任。
PAIN POINTS
上线之后的三种常见落差
系统没坏、没人负责，用着用着就"不好用了"。
业务和资料变了，AI 答案还是旧的
知识不更新，助手就成了"过期公告栏"。
效果好坏全凭感觉，说不清优化什么
没有抽检和记录，优化全靠"我觉得"。
HOW WE DELIVER
我们怎么做持续运营
以问题管理与效果抽检为抓手，让优化有记录、可复盘。
-
运行问题管理
问题按"收集-分派-解决-回访"闭环流转。
-
知识更新协同
业务资料变化时，协同对应知识条目的更新。
-
效果抽检
按约定比例抽检问答质量与来源引用。
-
策略与配置调整
依据问题与抽检结果，调整回复口径与配置。
-
版本记录
知识条目与配置的每次调整留有记录。
-
月度复盘
每月一份运营报告，回顾问题、效果与下月重点。
MONTHLY REPORT
每个月，您会收到这样一份报告
"效果看得见"不靠口头承诺——把每月做了什么、发现了什么摆出来。
演示数据
本月概览
- 问题处理
- 12 件演示
- 知识更新
- 34 条演示
- 抽检合格率
- 92%演示
运行问题抽检
| 抽检项 | 数量 | 结果 |
|---|---|---|
| 问答质量抽检 | 20 条（演示） | 合格 19 条 / 待复核 1 条 |
| 来源引用抽检 | 10 条（演示） | 全部附出处引用 |
月度复盘要点
- 高频问题集中于报销流程，已补充 3 篇相关知识（演示）
- 两个场景建议调整回复口径，待业务方确认（演示）
- 下月重点：新成立部门的知识资料入库（演示）
以上为演示数据，非真实运营数据；实际报告字段与统计周期按服务约定配置。
USE CASES
这些场景需要持续运营
-
已上线但无人运营
给"放养"状态的 AI 应用配上责任人。
-
知识频繁更新场景
制度、产品、政策常变，知识需要跟着换。
-
多部门共用一套 AI
跨部门的问题收集与口径统一需要专人协调。
-
效果下滑需要调优
从抽检记录找原因，而不是凭印象调参数。
-
准备扩大使用范围
推广前先把问题闭环与复盘机制跑顺。
OPERATION LOOP
每月都在转的运营闭环
-
收集问题
输出：当期问题清单（含来源与场景）
-
分派与解决
输出：问题处理记录与回访结论
-
知识更新
输出：知识条目更新日志
-
效果抽检
输出：问答与引用的抽检记录
-
策略调整
输出：配置与口径调整的版本记录
-
月度复盘
输出：月度运营报告与下月重点
DELIVERABLES
您将获得的交付成果
-
月度运营报告
本月问题、更新与抽检结果，一页看全。
-
问题处理记录
每个问题的收集、分派、解决与回访留痕。
-
知识更新日志
知识条目的新增、修订与下线记录。
-
优化建议清单
基于问题与抽检结果的下阶段优化方向。
具体交付物以合同约定为准。
HONEST BOUNDARY
我们先说清楚：不承诺什么
-
不承诺 SLA 与可用率
服务指标取决于具体场景与约定内容，不写在页面上当卖点。
-
不承诺固定响应时限
响应方式与时限在合同中按贵司场景约定，而非通用口号。
-
不对业务经营效果负责
AI 应用是经营工具之一，业务成果由业务本身决定，我们不越界揽责。
作为替代，我们用月度复盘与抽检记录把效果摆在明面上：做了什么、发现了什么、改了什么，每个月都有据可查。
FAQ
关于持续运营的常见问题
出了问题多久响应？
响应方式与时限按贵司场景在合同中约定；页面上不写通用数字，避免承诺兑现不了。
运营人员是我们出还是你们出？
常见两种模式：由我方按周期代运营，或由贵司指定人员、我方提供机制与培训。怎么分工在沟通时按人力与预算确定。
知识更新的内容由谁提供？
业务内容以贵司各部门提供的资料为准——最了解业务的永远是业务方；我们负责整理、入库与口径把关，并在复盘中提示需要补充的部分。
效果不好怎么算？
先看抽检与问题记录定位原因：是知识缺失、口径问题还是场景本身不合适，再决定调整方向。改进过程全部留档，双方都能看到变化曲线。
