多渠道接入：把客诉入口“收拢到一张桌子”
门店客诉最怕两件事：入口太散、责任不清。用Zendesk或腾讯云工单的思路一样：把微信/小程序、电话记录、邮件、门店POS备注、抖音/外卖平台截图这类信息，统一进工单队列。
- Zendesk：把“Support工单”作为唯一处理入口，接入邮件、网页表单、社媒/聊天渠道；门店可用表单提交，强制填“门店ID、订单号、客诉类型、金额、图片/视频”。
- 腾讯云工单：用多渠道受理+自定义字段做同样的事，重点是把门店端提交流程做成模板，减少“描述不清”导致的来回追问。
建议字段别贪多，7个就够：渠道、门店、订单号、问题分类、影响范围（单客/多客/全店）、期望诉求、证据附件。
SLA时限：把“多久必须响应/解决”写死在系统里
SLA不要只写在制度上，要让系统自动计时、自动催办。常见做法是按严重度分3档：
- P1（疑似食品安全/人身风险/舆情扩散）：10分钟内响应，2小时内给处理结论或升级。
- P2（退款纠纷、服务态度、配送延误）：30分钟内响应，24小时内闭环。
- P3（体验建议、小问题报修）：4小时内响应，3天内闭环。
在Zendesk里用SLA策略绑定“优先级+标签”，再配合自动化规则：临近超时前15分钟提醒负责人，超时立刻@主管并升级队列。腾讯云工单同理，核心是“计时+升级链”。
自动分派与处理闭环：让系统替你盯进度
分派别靠人工喊人。用门店ID→所属区域→责任组的映射最稳：门店客诉先进“门店一线组”，触发条件命中“退款/赔付”再自动转“客服赔付组”，命中“设备/环境”转“运维组”。
闭环要有硬标准：工单状态建议固定成新建-处理中-待客户确认-已解决-已关闭，并要求“已解决”必须填写原因码、处理动作、补偿金额。比如某连锁30家店，日均200单客诉，用这套规范后，返工率从18%降到9%，主要是因为“原因码+动作”逼着大家把话说清楚。
报表配置：老板要的不是数据，是能追责的答案
报表别堆指标，盯住这4个就够用：
- SLA达标率（按P1/P2/P3拆开）
- 首次响应时长、解决时长（按门店/区域/责任组排名）
- Top5客诉类型（带趋势线，方便抓“连续3天上升”的问题）
- 重复客诉率（同门店同类型7天内出现≥2次就要预警）
Zendesk用Explore做仪表盘；腾讯云工单用内置统计或导出到BI都行。数据口径一定写进看板说明：比如“解决时长按工单创建到解决计算，暂停时间是否剔除”。
你现在就能照着做的动作清单（适用于2026年3月11日之后上线）：
- 把入口收敛到1个表单：强制7个字段，门店不填完整不让提交。
- 定3档SLA，把“超时升级链”写进系统规则，不靠群里催。
- 做一张映射表：门店ID→区域→责任组，开自动分派；再配10条常用宏回复，减少打字。
- 上线第7天就开复盘会：只看SLA达标率、Top5类型、重复客诉率，抓一个问题做流程改造。
