标准场景 分析决策 行业 · 互联网平台

DM-01 · 客诉工单分诊与优先级

群里 1,200 条消息,食安的那条不能沉底

痛点 督导实录:326 个群、每天 1,200 条消息,「群聊爬楼成了必修课」 · 食安投诉会直接触发监管介入

① 场景引入

一、这件事现在是什么样

客诉与判责 · 真实业务触发

周二一天,客服组收到 23 条用户消息:微信群 15 条、商家转发 5 条、App 内反馈 3 条。其中一条来自洛溪店订单:「昨晚在你们平台点的烧烤,我孩子吃完半夜吐了两次,现在在医院」——夹在「优惠券用不了」和「骑手提前点了送达」之间,上午 10 点发进群,到下午 2 点没人认领;另有一条 12315 转办件即将到回复时限。客服 6 个人,同时在线处理 40+ 商家的日常咨询。

二、痛点 · 每条都有来源

1小平台的工单系统就是微信:用户群里@运营、商家转发截图、骑手在骑手群喊——高危与低危混在同一条消息流里依据 · 连锁餐饮督导的自述:微信工作群 326 个、置顶 56 个、每天群消息 1200 多条,「群聊爬楼成了必修课」——与平台运营的工作生态完全同构2食安类投诉是监管介入的直通线:《网络餐饮服务食品安全监督管理办法》体系下,单起食安事件可触发平台责任审查依据 · 市监总局《网络餐饮服务经营者落实食品安全主体责任监督管理规定》:平台「未对入网餐饮服务提供者进行实名登记、审查许可证……依照食品安全法第一百三十一条处罚」——平台是法定审核义务主体3美团商户服务规范要求「在线咨询 5 分钟内解答」「对差评订单务必及时回复」——响应时效是被规则写死的,不是自觉依据 · 美团客诉处理规则:「平台将依据买家投诉的问题类型、现有系统数据综合判断」——判责的事实基础是时间线证据链,不是谁嗓门大412315 转办件是唯一有法定时限的客诉流,错过回复时限就是监管台账上的不良记录依据 · 杭州行政复议案:平台靠「举证入驻时已做资质审核并履行定期核验义务」的留档记录免于立案——审查记录在监管应对中的实证价值5客服 6 人管 40+ 商家的日常咨询,人均在办事项长期高位——分诊靠的是谁刚好看到依据 · 县域实测编制:饿了么岳池站点 42 名员工管 375 家入网餐饮单位、美团 256 人管 611 家——含骑手与管理层后,运营/审核/客服人均服务 15 家以上商家

三、换个做法之后

变化不在「快」,在「参与的角色」和「覆盖的范围」

✕ 现在的做法

  • 小平台的工单系统就是微信:用户群里@运营、商家转发截图、骑手在骑手群喊——高危与低危混在同一条消息流里食安类投诉是监管介入的直通线:《网络餐饮服务食品安全监督管理办法》体系下,单起食安事件可触发平台责任审查美团商户服务规范要求「在线咨询 5 分钟内解答」「对差评订单务必及时回复」——响应时效是被规则写死的,不是自觉12315 转办件是唯一有法定时限的客诉流,错过回复时限就是监管台账上的不良记录

✓ 交给 Agent 之后

  • 多来源文件一次读入,先做口径与完整性校验,再开始算
  • 每条结论绑定来源文件、字段或条号,可以被审
  • 产出是企业真会流转的正式件(带签批栏),不是一张展示用的表
  • 该拦的地方给出「现在还不能提交」,并给不用干等的替代方案

四、场景闭环

5 步 · 每一步的产出都是下一步的输入

  1. 全渠道消息归集与结构化群里、转发、App 的消息汇成当日工单池,诉求逐条结构化
  2. 分类与后果分级食安 / 时效 / 品质 / 服务 / 规则咨询五类,后果严重度分三级
  3. 真实性快查关联订单与核销记录快查——无订单的投诉走不同通道
  4. 优先级排序与认领时限压力 × 后果等级 × 商家历史加权,产出处置顺序与认领建议
  5. SLA跟踪与升级超时未认领自动升级,食安类直接进上报通道

要准备什么:当日全渠道用户消息(群聊/转发/App 反馈)未分诊的原始消息流订单与核销数据投诉关联订单的真实性核查历史客诉记录(按商家)同商家同类投诉的累计次数——加权依据监管时限件台账12315 等转办件的回复时限

为什么这个场景值得做

优先级评分:痛感 4 × AI 适配 4 ÷ 落地难度 2 = 9.6

最大差异点:普通工单系统按「先来后到」排队,这个场景按「后果严重度 × 时限压力」分诊:食安指控(有没有订单、有没有就医凭证)先于时效投诉,12315 时限件先于普通咨询,同一商家的第 N 次同类投诉自动加权。沉在群消息里的那条食安投诉,应该在发出的 30 分钟内出现在置顶——这是人肉爬楼永远做不到的事。

评分口径:痛感看「这事没做好谁会生气、生气到什么程度」;

AI 适配看「输入是否非结构化、是否要跨部门取数、错了能不能当场看出来」;

落地难度是分母 —— 需要客户先做数据治理的场景,分数会被压得很低。

五、会产出什么

判断标准只有一个:这份东西能不能直接进企业的流程

  • 正式件本体:当日客诉分诊与处置清单.xlsx 台账蓝 · 全量工单 × 分类分级 × 认领与时限 · 主管签字栏
  • 可派发清单:食安高危工单上报单.docx S 级工单 × 关联证据 × 上报路径 · 直达运营负责人
  • 可派发清单:非客诉消息剥离清单.xlsx 咨询/操作/误转分类 · 转出方向

这套东西不承诺什么:分诊结论是处置优先级建议,不是责任认定;食安类工单的升级与上报路径按监管要求执行,升级动作由运营负责人确认;赔付方案一律走 DM-02 判责流程,分诊阶段不做赔付承诺。

② Live Demo(演示逐步)

演示模式 · 可视化预演 本页展示的是「应该怎么跑、每一步看什么、交付什么」,用的是真实业务格式的脱敏构造数据, 不宣称已接入客户生产系统,也不承诺任何效率提升百分比。

案例设定:邻聚生活客服组长阿青周二分诊 23 条客诉——其中一条来自洛溪店订单「昨晚在你们平台点的烧烤,孩子吃完半夜吐了两次,现在在医院」夹在「优惠券用不了」与「骑手提前点了送达」之间,上午 10 点发进群、下午 2 点没人认领;另有一条 12315 转办件即将到回复时限。客服 6 人管 40+ 商家日常咨询。

今日客诉23 条 · 微信 15 · 商家转 5 · App 3食安高危1 条 · 沉 4 小时12315 时限件1 条 · 剩 2 小时非客诉消息8 条· 需剥离

输入本地生活平台手上能拿到的东西

不需要整理格式、不需要改文件名 · 直接拖进对话框

  • 01_今日23条客诉与群消息原文.xlsx 23 条客诉 + 8 条非客诉消息——微信群原文、商家转发、App 反馈客服组 · 当日累计
  • 02_12315转办件与时限清单.xlsx 12315 转办件清单与回复时限——倒计时已用红色标注客服组 · 每日
  • 03_食安高危工单历史处置对照表.xlsx 食安高危工单历史处置对照——分级规则与升级路径客服组 · 上次更新 2025-04
  • 04_非客诉消息剥离清单.xlsx 今日 8 条非客诉消息——运营咨询、商家自荐、群内广告客服组 · 每日

注意标橙色那一份 —— 01_今日23条客诉与群消息原文.xlsx。它客服组 · 当日累计,平时压根不在核对范围里。这个场景的价值,很大一部分就来自把它读进来。

提示词就说这么几句

没有模板、没有表单 · 专业规则由 Skill 兜底

这是今天所有的用户消息:微信群聊天记录、商家转发的截图、App 反馈,混在一起。这是订单核销数据、按商家的历史客诉记录、12315 转办件台账。 帮我分诊:

  1. 先把不是客诉的剔出去(咨询、操作问题、误转)。
  2. 真投诉按食安/时效/品质/服务/规则分五类,后果严重的标出来,关联订单快查一遍真假。
  3. 按时限压力和后果排处置顺序,谁认领、什么时候到点,列清楚。
  4. 食安类的直接进上报通道,12315 的把剩余时限算出来。
  5. 同一商家反复出现的同类投诉,历史次数给我标上。 排序原则告诉我,别只给结果。

分类分级规则、食安特征识别、历史加权逻辑在能力包里;现场只需把当日消息流、订单数据、历史记录丢进来。

123 条按「后果严重度 × 时限压力」分诊——P0/P1/P2/P3

分诊不是「先来后到」

紧迫度条数代表首响时限处置P0 食安2老广洛溪店 10:08 食安 · 老广市桥店 11:20 食安30 分钟运营负责人 + 商家立即同步P0 时限312315 三条 · 1 剩 4h · 1 剩 2h · 1 已超时立即客服组长直接处理P2 配送4骑手提前点送达 · 少了一瓶水2小时客服常规处理P3 咨询14优惠券 / 推荐位 / 发票 / 商家自荐当日客服常规 + 运营组转交合计23———该拦的排队陷阱 · 食安按先来后到就沉底老广洛溪店 10:08 食安投诉到 14:00 没人认领——4 小时。根因是:1 条食安夹在 22 条咨询和配送里,谁刚好看到谁处理。分诊机制把「后果严重度」前置,食安不再按「先来后到」排队。

2P0 食安 2 条——立即升级,运营负责人确认

食安升级不是建议,是动作

工单用户原文首响商家侧动作升级动作老广洛溪店 · 10:08孩子吃完半夜吐了两次,现在医院已 4 小时未认领查食材批次+ 监控 + 卫生记录上报运营负责人 + 当地市监老广市桥店 · 11:20吃拉肚子,要 2000 赔偿客服已 5 分钟内认领查同期订单 · 是否多点投诉暂不上报 · 评估踩过的坑 · 等就医凭证才动作食安升级不是「等用户提供就医凭证」——是先动作后补凭证。因为 12315 转办件时限是法定的、市监介入是有节奏的——「用户没给凭证前不动」等于把主动权交给用户,运营负责人一确认,食材批次 + 监控 + 卫生记录就到位。

3P0 时限 3 条——12315 转办件先处理完

12315 时限是法定的

编号剩余处理动作签字12315-0827-0089 · 茶里茶里剩 4 小时查财务流水 · 写回复函客服组长12315-0826-0034 · 川味小厨剩 2 小时立即处理 · 写回复函客服组长12315-0825-0056 · 潮味牛肉已超时 4 小时立即处理 · 写情况说明客服组长 + 运营总监可以排除的选项 · 超时件装没看见已超时的 12315 不要直接忽略——主动联系监管说明情况 + 提交情况说明 + 主动联系用户协商,比被监管追着问的代价小一个量级。

4P2 配送 + P3 咨询 + 非客诉 8 条剥离

客服的注意力是稀缺资源

类型条数去向首响时限P2 配送4客服常规处理2 小时P3 咨询14客服常规 + 运营组转交当日非客诉 · 商家自荐1转 BD 群—非客诉 · 广告1直接忽略—非客诉 · 运营咨询4转运营组 / 客服组长—非客诉 · 通知1归档—非客诉 · 群内1归档—把 8 条剥离翻译成钱 · 拿回 35% 工时客服 6 人管 40+ 商家日常咨询——8 条非客诉占去 35% 工时。剥离到 BD / 运营 / 归档,客服注意力回到 P0 与 P2。

5分诊清单 + 食安上报单 + 非客诉剥离清单

分诊是这一天的核心动作

交付物清单(表格原文)输出文件格式内容去向当日客诉分诊与处置清单.xlsxxlsx23 条分诊 · 4 级 · 责任人 · 时限客服组食安高危工单上报单.docxdocx2 条 P0 食安 · 升级动作 · 商家侧动作运营负责人 + 市监非客诉消息剥离清单.xlsxxlsx8 条非客诉 · 4 类去向客服组分诊机制的反向价值分诊不是「加快处理」——是「让对的人处理对的事」。老广洛溪店 10:08 食安 4 小时无人认领——不是客服不上心,是分诊机制缺位。分诊上线后,食安置顶、12315 倒计时、客服注意力只给 P0 与 P2。2 条 P0 食安升级 + 3 条 12315 时限件立即处理 + 8 条非客诉剥离(不放行)老广洛溪店 10:08 食安升级运营负责人 + 市监;老广市桥店食安同步动作;3 条 12315 立即处理;剩余 18 条按 P2/P3 派单;8 条非客诉转 BD / 运营 / 归档。方案一:按「先来后到」排队——老广洛溪店食安再沉 4 小时被用户主动 @ 媒体;12315 已超时件被监管追着问;客服注意力分散在 31 条消息里,P0 与 P3 用同一种节奏处理。方案二:分诊上线——2 条食安 30 分钟内升级、3 条 12315 在时限内处理、8 条非客诉剥离、客服注意力回到 P0 与 P2。P0 食安按时升级的合规价值是「按市监口径主动上报,避免被推定未履行义务」(按洪江案罚款 3 万起步);12315 不超时件按 1 件 5,000 元/件的隐性合规成本避免

之后这一次跑完,公司多了什么

不讲省了多久:讲少了几个隐患、沉淀了什么

  • ✓ 食安投诉从「沉在群消息里」变成「30 分钟内置顶认领」——监管问起来,平台的责任时间线是干净的
  • ✓ 12315 时限件不再靠人脑记,回复口径自动带历史处理记录
  • ✓ 非客诉消息剥离后,客服的真处理容量立刻回升
  • ✓ 同一商家的反复投诉累计可见,处置策略从「单次响应」升级为「模式应对」

追问现场可能被问到的

答不上来的问题,比答得漂亮的问题更能决定这场演示的结果

  • 分诊会不会漏掉不典型的食安投诉? 食安特征库按「症状词 + 订单时间邻近性 + 就医凭证」三信号识别,单信号只标黄不标红——宁可多一次人工确认,不漏一条 S 级。这条规则写在能力包第一页。
  • 消息源太多接不全怎么办? 先接最集中的两个源(用户群 + 商家转发),App 反馈和 12315 件本来就结构化——80% 的漏认领风险在群消息里,先把最堵的那段修通。

③ 能力沉淀(Skill / 提示词 / 预期输出 / 人工边界)

1. Skill 能力包

导入之后,同类任务会自动按这套规则走 —— 提示词才能写得那么短

客诉工单分诊与优先级 —— 群里 1,200 条消息,食安的那条不能沉底 · Skill

SKILL.md 主本 + references(输出骨架 / 判据 / 渲染脚本)· 符合 WorkBuddy Skill 规范

版本 v1.0

complaint-triage-and-priority.zip

在 WorkBuddy 里直接上传这个 zip 即可导入

包内结构

  • SKILL.md 主本 —— YAML 元信息 + 执行流程 + 硬规则 + 人工边界
  • references/output_template.md 输出骨架(sheet 名 / 分区顺序 / 列头)+ 可直接运行的渲染脚本
  • references/judgement_rules.md 判据与口径 —— 什么情况算异常、什么情况必须拦住

references 不会一次性全读进来 —— Agent 按需取用。所以 Skill 可以写得很细,不会拖慢每次对话。

2. 原始素材

这些就是本地生活平台手上真实能拿到的东西 —— 格式不统一是常态,不是问题

📁DM-01 · 演示素材

脱敏构造数据 · 真实业务格式 · 埋点可核验

共 4 份

XLS01_今日23条客诉与群消息原文.xlsx23 条客诉 + 8 条非客诉消息——微信群原文、商家转发、App 反馈下载

  • ↓XLS02_12315转办件与时限清单.xlsx 12315 转办件清单与回复时限——倒计时已用红色标注
  • 03_食安高危工单历史处置对照表.xlsx 食安高危工单历史处置对照——分级规则与升级路径
  • 04_非客诉消息剥离清单.xlsx 今日 8 条非客诉消息——运营咨询、商家自荐、群内广告

怎么用

  • 把素材全部拖进 WorkBuddy 对话框(不需要整理格式、不需要改文件名)
  • 粘贴下方提示词发送
  • 拿到正式件初稿 —— 签批栏留空,推荐意见留空,由你填

3. 提示词卡片

这是今天所有的用户消息:微信群聊天记录、商家转发的截图、App 反馈,混在一起。这是订单核销数据、按商家的历史客诉记录、12315 转办件台账。 帮我分诊:

  1. 先把不是客诉的剔出去(咨询、操作问题、误转)。
  2. 真投诉按食安/时效/品质/服务/规则分五类,后果严重的标出来,关联订单快查一遍真假。
  3. 按时限压力和后果排处置顺序,谁认领、什么时候到点,列清楚。
  4. 食安类的直接进上报通道,12315 的把剩余时限算出来。
  5. 同一商家反复出现的同类投诉,历史次数给我标上。 排序原则告诉我,别只给结果。

为什么这么短就够了:分类分级规则、食安特征识别、历史加权逻辑在能力包里;现场只需把当日消息流、订单数据、历史记录丢进来。

换成你自己的业务:把素材换成你手上的真实文件即可。导入 Skill 之后,

该走几步、什么口径、什么情况必须拦住,Agent 自己知道 —— 你只需要说清这是什么事。

自己组织输入的三步法

  • 用自然语言说清核心需求 —— 就按平时跟同事交代活的方式说:什么事、什么文件、什么要求。不用讲究格式。
  • 调用 Skill 补齐专业规则 —— 导入本页 Skill 后,流程、口径、硬规则 Agent 自己知道。
  • 用「增强提示词」补全遗漏 —— 输入框旁边有增强按钮,把随口说的话补成更完整的表述。

分工:自然语言负责「这是什么事」,Skill 负责「该怎么做」,增强提示词负责「别漏了什么」。

4. 预期输出

不方便现场跑的时候可以直接拿这份给客户看 · 与实跑结果同结构

📋正式交付物

带签批栏 / 冻结首行 / 开筛选 —— 判断标准是「能不能直接进企业的流程」

共 3 份

XLSDM-01_当日客诉分诊与处置清单.xlsx台账蓝 · 全量工单 × 分类分级 × 认领与时限 · 主管签字栏下载

  • ↓XLSDM-01_食安高危工单上报单.docx S 级工单 × 关联证据 × 上报路径 · 直达运营负责人
  • DM-01_非客诉消息剥离清单.xlsx 咨询/操作/误转分类 · 转出方向

Skill 里固化了什么:那条食安投诉在 10:04 就该被置顶12315 转办件的时限被算准了排除性结论把技术动作翻译成钱

输入清单:当日全渠道用户消息(群聊/转发/App 反馈)未分诊的原始消息流订单与核销数据投诉关联订单的真实性核查历史客诉记录(按商家)同商家同类投诉的累计次数——加权依据监管时限件台账12315 等转办件的回复时限

人工边界:分诊结论是处置优先级建议,不是责任认定;食安类工单的升级与上报路径按监管要求执行,升级动作由运营负责人确认;赔付方案一律走 DM-02 判责流程,分诊阶段不做赔付承诺。

升为客户真实案例还缺什么:客户当前真实输入文件(不要整理过的)岗位现行 SOP 与审批链(金额分档、谁签字)至少一次真实出过问题的案例客户当前正在用的正式输出模板客户确认的阈值口径(多少天算临期、多少金额算大额)

5. 同一角色下的其他场景

客诉与判责 · 产出即下一步输入

上下游串起来就是完整链路。每一步的产出都是下一步的输入,不用在不同工具之间来回复制粘贴。

场景内容基于 WorkBuddy 产品能力整理,演示中的企业、人物与数据均为虚构,不代表任何客户的实际成效;痛点引用的公开来源已做脱敏处理。网页版由原资料转换,部分演示表格以原文形式展示。

想把这个场景在你们企业跑通?

顾问会先看你们的数据和流程够不够,再决定从哪一步开始。