客户咨询进来五分钟没人理等客服想起来回复时客户已经去问竞品了。咨询分配要解决的就是这个时间窗咨询进来立刻找到对的人、通知到位、没人接再升级。分配算法不难难的是分配之后的提醒链路——没提醒的分配等于没分配。这篇把分配策略和提醒升级一次讲透。我们用的是Eyun 平台开放的企微 API统一 POSTJSON请求头带Authorization: Bearer eyk_xxxx响应封套{code, data, detail, message, time}code 为 0 成功。咨询入口先识别再分配咨询消息经 Webhook 进来回调头X-Eyun-Event标 message。分配前先过一道轻量识别——纯咨询转分配投诉和退款走独立通道不占客服队列。识别用关键词规则就够退款投诉这类词命中即转主管剩下进入分配流程。分配的第一原则是归属优先。客户档案调 contact/getUserProfileDetail 查标签和历史归属客户本来就归某个客服带的咨询直接分给他——接手的客服有上下文客户不用自我介绍。归属客服不在线才走第二策略。分配策略三种模式怎么选策略逻辑适用归属优先分给客户历史归属客服老客户有上下文负载均衡分给当前待处理量最少的客服咨询量大的通用队列技能匹配按咨询类型分给对应技能组售前售后分线三种策略组合成决策链归属优先 → 不在线或超出接待上限 → 负载均衡 → 都忙则排队。接待上限每个客服一个满了就不再进人防止忙的越忙、闲的越闲。def assign(appid, uin, inquiry_id): owner get_owner(uin) # getUserProfileDetail 查归属 if owner and owner_online(owner) and not owner_full(owner): return assign_to(owner, inquiry_id) candidate min_by_load(svc_group.online_members()) if candidate: return assign_to(candidate, inquiry_id) enqueue(inquiry_id) # 全忙排队有客服空闲时再分 return None接单状态机分配不算完接单才算咨询分出去只是待接单客服确认接了才是处理中。状态机三个状态pending已通知未接→ serving已接单→ timeout超时未接。客服回复咨询即视为接单状态翻 serving。超时阈值分两档普通咨询 5 分钟VIP 咨询 2 分钟。到点没人接进入提醒升级链路——这是分配系统里最值钱的部分。提醒升级三级递进第一级提醒本人。分配成功调 message/sendRichText 给接单客服发工单卡片客户档案摘要、咨询内容、剩余时限都在卡片上。卡片链接点进去是会话页客服不用切系统。第二级提醒组内。5 分钟没接先给本人再推一次 sendText 短信级提醒同时把咨询在客服群内广播——客户 X 的咨询 5 分钟未接单让同组人知道有个单悬着。第三级升级主管。10 分钟还没人接调 message/sendText 通知客服主管消息里带客户等级和等待时长。主管有权直接改派或自己接。三级升级跑下来我们组的超时未接率从 7% 降到 0.8%——不是客服变勤快了是悬着的单藏不住了。def check_pending(): for t in pending_over(TIMEOUT_L1): send_text(t[assignee], f工单 {t[id]} 即将超时请尽快接单) if pending_over(t, TIMEOUT_L2): broadcast_group(t) if pending_over(t, TIMEOUT_L3): notify_manager(t)升级检查用定时任务每分钟扫一遍 pending 表别依赖消息事件驱动——事件驱动在提醒丢失时就断了轮询兜底才可靠。排队与改派全忙排队的咨询要有位置感——客服空闲释放时按队列先进先出补分。排队超过 15 分钟的调 message/sendText 给客户回一句当前咨询较多已为您排队第 N 位有回音的等待比无回音的沉默留存率高得多。改派也是日常操作。客服请假、离职挂着他的单要批量转移调库改 assignee调 sendText 通知新客服客户侧无感。归属表是唯一事实源改派只改表消息通知是表变更的下游动作别反过来。分配质量的两个数分配系统上线后盯两个数首次响应时长咨询进来到客服首次回复和超时升级率走到第三级升级的单占比。前者衡量分配速度后者衡量接单纪律。首次响应做不快查分配链路耗时升级率降不下来查客服接待上限是不是设高了。分配是算法提醒是纪律咨询自动分配的完整闭环识别分流、归属优先分配、接单状态机、三级提醒升级、排队回执。算法部分一天写完提醒升级链路决定这套系统是看起来自动还是真没人接的单不存在——把升级做到位超时才真正绝迹。 客户咨询进来五分钟没人理等客服想起来回复时客户已经去问竞品了。咨询分配要解决的就是这个时间窗咨询进来立刻找到对的人、通知到位、没人接再升级。分配算法不难难的是分配之后的提醒链路——没提醒的分配等于没分配。这篇把分配策略和提醒升级一次讲透。我们用的是Eyun 平台开放的企微 API统一 POSTJSON请求头带Authorization: Bearer eyk_xxxx响应封套{code, data, detail, message, time}code 为 0 成功。咨询入口先识别再分配咨询消息经 Webhook 进来回调头X-Eyun-Event标 message。分配前先过一道轻量识别——纯咨询转分配投诉和退款走独立通道不占客服队列。识别用关键词规则就够退款投诉这类词命中即转主管剩下进入分配流程。分配的第一原则是归属优先。客户档案调 contact/getUserProfileDetail 查标签和历史归属客户本来就归某个客服带的咨询直接分给他——接手的客服有上下文客户不用自我介绍。归属客服不在线才走第二策略。分配策略三种模式怎么选策略逻辑适用归属优先分给客户历史归属客服老客户有上下文负载均衡分给当前待处理量最少的客服咨询量大的通用队列技能匹配按咨询类型分给对应技能组售前售后分线三种策略组合成决策链归属优先 → 不在线或超出接待上限 → 负载均衡 → 都忙则排队。接待上限每个客服一个满了就不再进人防止忙的越忙、闲的越闲。def assign(appid, uin, inquiry_id): owner get_owner(uin) # getUserProfileDetail 查归属 if owner and owner_online(owner) and not owner_full(owner): return assign_to(owner, inquiry_id) candidate min_by_load(svc_group.online_members()) if candidate: return assign_to(candidate, inquiry_id) enqueue(inquiry_id) # 全忙排队有客服空闲时再分 return None接单状态机分配不算完接单才算咨询分出去只是待接单客服确认接了才是处理中。状态机三个状态pending已通知未接→ serving已接单→ timeout超时未接。客服回复咨询即视为接单状态翻 serving。超时阈值分两档普通咨询 5 分钟VIP 咨询 2 分钟。到点没人接进入提醒升级链路——这是分配系统里最值钱的部分。提醒升级三级递进第一级提醒本人。分配成功调 message/sendRichText 给接单客服发工单卡片客户档案摘要、咨询内容、剩余时限都在卡片上。卡片链接点进去是会话页客服不用切系统。第二级提醒组内。5 分钟没接先给本人再推一次 sendText 短信级提醒同时把咨询在客服群内广播——客户 X 的咨询 5 分钟未接单让同组人知道有个单悬着。第三级升级主管。10 分钟还没人接调 message/sendText 通知客服主管消息里带客户等级和等待时长。主管有权直接改派或自己接。三级升级跑下来我们组的超时未接率从 7% 降到 0.8%——不是客服变勤快了是悬着的单藏不住了。def check_pending(): for t in pending_over(TIMEOUT_L1): send_text(t[assignee], f工单 {t[id]} 即将超时请尽快接单) if pending_over(t, TIMEOUT_L2): broadcast_group(t) if pending_over(t, TIMEOUT_L3): notify_manager(t)升级检查用定时任务每分钟扫一遍 pending 表别依赖消息事件驱动——事件驱动在提醒丢失时就断了轮询兜底才可靠。排队与改派全忙排队的咨询要有位置感——客服空闲释放时按队列先进先出补分。排队超过 15 分钟的调 message/sendText 给客户回一句当前咨询较多已为您排队第 N 位有回音的等待比无回音的沉默留存率高得多。改派也是日常操作。客服请假、离职挂着他的单要批量转移调库改 assignee调 sendText 通知新客服客户侧无感。归属表是唯一事实源改派只改表消息通知是表变更的下游动作别反过来。分配质量的两个数分配系统上线后盯两个数首次响应时长咨询进来到客服首次回复和超时升级率走到第三级升级的单占比。前者衡量分配速度后者衡量接单纪律。首次响应做不快查分配链路耗时升级率降不下来查客服接待上限是不是设高了。分配是算法提醒是纪律咨询自动分配的完整闭环识别分流、归属优先分配、接单状态机、三级提醒升级、排队回执。算法部分一天写完提醒升级链路决定这套系统是看起来自动还是真没人接的单不存在——把升级做到位超时才真正绝迹。