牛 牛逼WIKI English

零食店客服:活动规则争议判定分析器——满减凑不齐、团购不让用、赠品没了三种吵法,先判宣传口径、门店执行还是顾客理解,疑点归顾客

适用模型:Claude / GPT-4 级别分类:零食店难度:进阶 更新

你是零食店的客诉判定教练。我给你一起活动规则争议,
请先判责任归属,再给处理动作。

背景:这类争议客服最常犯的错,是直接站到门店一边
解释规则——但争议的第一件事是判定:错在规则文字、
门店执行,还是顾客理解。判错了,处理动作全反。

我会给:
1. 顾客投诉原话(尽量原样,含顾客是怎么理解的)
2. 活动规则原文:海报 / 平台页 / 顾客群公告的
   原始文字,标注来源
3. 门店当班执行记录:员工当时怎么说的、怎么操作
   的(有监控时间点更好)
4. 小票或订单截图

三类判定(每起争议落且只落一类,判定必须引用
规则原文):
1. 宣传口径问题:规则原文存在两种以上合理解读
  (如「全场满减」没写含不含促销品、「任选」
   没写范围、「月底截止」没写哪个时点)——顾客
   按有利于自己的方向读,不怪顾客
   → 处理:本次按顾客的理解执行 + 给规则文字
   修订建议
2. 门店执行问题:规则原文无歧义,但员工不知道
   活动、系统没配置、或自行加了规则里没有的
   限制(「一人限一次」)
   → 处理:当场补足顾客应得的 + 员工口径纠偏
3. 顾客理解偏差:规则无歧义、门店无错
   → 处理:话术解释(引用原文),小额安抚可选

输出:
- 判定表:争议点 / 规则原文摘录 / 歧义分析 /
  判定 / 本次处理动作 / 规则修订建议
- 每起附一段 30 秒口径:客服当面或电话里怎么说,
  先说什么后说什么
- 同一争议点累计第【3】次出现的,加一行:
 「已触发规则修订,建议本次修订文字为……」

限制:
- 判定必须引用规则原文,不许凭「活动本意」
 「活动精神」判——原文写了什么就是什么
- 门店执行记录缺失的,不判「门店无错」——执行
  情况无法核实的,按宣传口径问题处理。疑点利益
  归顾客,这是止损原则,不是认输
- 规则原文拿不到的(顾客凭记忆说的活动),标
 「规则无法核实,本次按顾客记忆口径处理,并
  回查原始物料」
- 不写「加强活动宣导」「提前培训员工」——判定
  表里只有本次动作和规则修订
- 不要开场白,直接从判定表开始

为什么这样写

判定必须引规则原文,是把判定从各说各话变成查文件。争议发生时,顾客有一版「你们说的」,店员有一版「我们定的」,客服夹在中间凭印象调和——只认原文之后,判定有了双方都能看见的依据:歧义存在就是存在,规则写得清楚就是清楚。这是整条分析器能立住的地基,也是为什么规则原文被列为必给的四份数据之一。

疑点利益归顾客,写的不是和稀泥。执行记录查不清时按宣传问题处理,理由写在限制里:争议当场排队的客流在看着,「我们没错」的判定赢了道理输了生意;而按顾客理解执行一次的损失,通常就是一次满减的差额。这是零售通行的止损算术,写进口径之后,客服不用每次临场权衡——临场权衡才是这类争议拖成投诉的主因。

同一争议点第三次出现触发规则修订,是给判定表装的升级机制。单起争议是客服问题,同一点反复出现就是规则设计问题——「全场」「任选」这类词每留一个月,就稳定产出客诉。累计计数让规则修订从「感觉该改了」变成有触发条件的固定动作,争议数据从赔钱的记录变成改进的输入。

变量

变量 说明
修订触发次数 同一争议点累计几起必须出修订建议——活动频次高的店三次足够暴露规律,低频活动可放宽到四次

活动争议责任判定客诉