日期:2026-08-15
某连锁品牌门店几百家,差评和客诉散在点评平台、短视频评论、官方私信和社群里,总部根本看不过来。等公关或运营刷到的时候,经常已经发酵成小舆情,店长还不知道自己店里出了什么。我们进场时,这家企业最痛的不是没有渠道收集反馈,是反馈收集了没人跟、跟了没闭环,一条差评从出现到处置平均要拖两三天,期间还在持续扩散。更被动的是,负面往往先在短视频上起量,等总部看到时已经几百播放,这种靠加人盯是盯不过来的,人也盯不住所有平台和所有门店。
我们搭了一套多智能体协同的舆情处置系统。舆情采集 Agent 定时扫各平台关键词和门店提及,情感分级 Agent 把内容分成正负中三档并打紧急度,客诉分派 Agent 按门店和品类把负面自动派给对应店长和区域经理,处置跟进 Agent 跟踪每一条的处理状态和客户回复,总部舆情看板把全局态势和未闭环项实时拉出来。整个链路从发现到派单到跟进,尽量自动跑,人只在关键节点确认,省下来的人力用在真正要安抚的客户身上。
第一个难点是多平台舆情聚合。各平台接口和格式不一样,我们统一成一套事件模型,同一个客户的多次提及归并成一条事件,避免重复派单把店长烦死。第二个难点是情感误判与漏报,负评里有很多反讽和隐晦表达,模型容易放过,我们宁可多推几条让店长确认,也不为降噪把真负面拦在门外。第三个难点是客诉分派时效,派错了门店或者卡在没人认领,闭环就断,我们设了升级机制,超时未认领自动上提到区域。第四个难点是处置跟进的真实闭环,很多店长标记"已处理"其实没联系客户,我们加了客户回复回执才算真正闭环,否则一直挂账。我后来觉得,舆情系统别追求零误报,误报最多浪费店长几分钟,漏报一条真负面付出的代价大得多,这个取舍要想清楚,别被误报率指标带偏。
还有一块是跨平台的采集频率,短视频和点评更新快、私信慢,我们用不同轮询节奏,快的几分钟一扫、慢的半小时,既不全靠实时烧资源,也不让紧急负面漏在间隙里。早期统一频率,要么烧钱要么漏报,分节奏之后平衡多了,成本也跟着下来。
另外,处置话术也要沉淀,店长接到派单往往不知道怎么回,我们在系统里配了分级话术模板,负面紧急的给安抚口径、普通的给标准回复,店长照着改改就能发。这层做好,闭环率才上得去,否则店长卡在怎么回这句话上,事件就一直挂着,复盘也难看。系统不能只负责发现,还得帮人把处置这一步迈出去,否则发现得快也白搭。
上线后,舆情发现时效从平均约一天半缩短到约两小时,客诉闭环率(处置并完成客户回复)从约六成提升到约九成二。负面发酵拦截数(在扩散前处置)每月约两百条,情感误报率控制在约一成以内,其中漏报占比极低。一个季度重大舆情事件数量环比下降约五成。店长用于刷各平台找差评的时间几乎归零,系统主动推过来的才处理,运营团队从救火变成预防。客户侧感知是投诉有人管了,复购意愿的调研分值也有小幅回升。
系统跑顺之后,品牌公关从被动删帖变成主动沟通,几次潜在危机在门店层面就被安抚掉,没升级到总部,公关负责人说这是几年来第一次能睡安稳觉,因为处置进度系统实时推给他,不用再挨个店长问。
舆情系统最怕漏报,阈值宁松勿紧,多推几条让店长确认,比为了干净把真负面拦门外强得多,这个原则我们定下来后再没动摇过。事件归并别省,同一个客户刷屏式投诉如果每条都派单,店长会被同一件事烦死,归并后才是真工作量,也才看得清事态。升级机制要硬,超时未认领自动上提,否则闭环永远断在"没人看到"这一环,系统再聪明也没用。说到底,舆情处置的价值不在发现得多全,在处置得多快、闭得了环,慢一步就全白费,那条短视频起了量才被看到的教训,够我们记很久。
我们踩过的坑是太在意误报率指标,一度把阈值收得很紧,结果漏了一条真负面在短视频上起了量,之后才把原则钉成宁多推勿漏报。指标会骗人,真负面扩散的代价不会,这条是用一次翻车换的,现在谁也改不动这个原则,店长也认这个理。
舆情这东西,发现能力容易堆,闭环能力难建,我们真正花力气的不是算法,是把人拉进处置链路里,让人愿意动起来。
案例片段(已脱敏): 情感分级与客诉分派策略:
yaml sentiment: levels: [neg, mid, pos] urgent_neg_threshold: 0.8 policy: push_more_not_less # 宁多推勿漏报 dispatch: by: [store_id, category] escalate: unclaim_timeout_min: 30 to: region_manager dedup_window_h: 24 # 同客户24h内归并舆情事件日志节选:[2026-08-02 19:40] event=E_33021 store=M_205 情感 neg 0.91 紧急, 归并 3 条提及 派单店长 U_1203, 30min未认领->上提区域 处置完成 21:05, 客户回复已安抚, 闭环