美洽熟客优先怎么设置？

美洽的“熟客优先”本质上就是把曾经和你沟通过的访客，在下一次来访时优先分配给原来的客服或优先排入接待队列。要实现它，通常有两条路径：一是直接在美洽后台的会话分配或接待规则里开启“熟客优先”并配置判定窗口、优先策略和适用渠道；二是用访客标签/自定义属性+接入规则或API来手动标记“老客”，再让分配规则识别这个标签并按优先级分配。设置时要注意判定口径（cookie、visitor_id、手机号）、坐席在线状态、回溯时间和容错策略，测试不同场景（跨端、群聊、离线）并通过日志验证效果。下面我一步步把原理、操作流程、常见问题和优化建议讲清楚，照着做就行。

先把概念讲清楚：什么是“熟客优先”以及它为什么重要

有时候大家把复杂的事情看得太玄乎，先拆成最简单的两句来理解。*熟客优先*，就是“把曾经聊过的人优先给他们熟悉的客服”或者“在等待队列中给他们更高的优先级”。为什么要这样？因为熟悉感可以提升效率和满意度：客服不需要从头问背景，访客也觉得被记住，更容易成交或解决问题。

熟客优先常见的几种实现形式

• 会话粘性（sticky session）：访客回访后自动分配给上次接待的坐席。
• 优先排队：把老客在排队时放在更靠前的位置，但不一定回到原坐席。
• 指定坐席或优先小组：把老客分配给特定客服或客服组。
• 标签/属性驱动：通过给访客打标签或写入自定义属性，然后按标签规则分配。

准备工作：你需要了解和准备的东西

在动手之前，先确认下面几件事，否则设置后会遇到“明明是老客户却没被认出”的尴尬。

• 你有管理员或相应的设置权限（只有管理员或运营才看到分配规则）。
• 确认公司在美洽里的接入方式：网页端、H5、移动SDK、第三方渠道（WhatsApp/LINE/Telegram）是否都接入并能传 visitor_id 或 phone。
• 明确“熟客”的判定口径：以 cookie/访客ID、手机号、账户ID、还是自定义visitor_tag为准。
• 了解当前的会话分配策略：是否存在优先级、轮询、技能路由等，会影响熟客规则的生效顺序。
• 制定回溯时间窗口：比如7天、30天或90天，太短会漏掉回访，太长会把已经变更需求的老客户也当熟客。

在美洽后台通过配置实现（常见步骤）

不同版本的后台界面名字会有差异，但流程大致一致。下面把每一步拆开讲清楚，按着做就不会出错。

步骤一：登录并打开会话分配或接待规则页面

登录美洽企业后台，找到“设置”或“接待设置/会话分配/智能路由”之类的入口。核心目标是找到能编辑分配规则（routing rules）或者“熟客优先”这一项的地方。

步骤二：启用“熟客优先”或新增一条分配规则

• 如果后台有直接的“熟客优先”开关，开启它并进入配置界面。
• 如果没有，则新建一条分配规则，规则条件里选择“访客为曾接待用户/访客标签=老客/visitor_id命中历史会话”等条件。

步骤三：配置判定条件（关键）

这一步很关键，决定谁被认定为“熟客”。常见配置项：

• 回溯时间窗口：例如最近7天、30天或90天内有会话记录。
• 判定字段：visitor_id、cookie_id、手机号码或企业客户ID（如果是登录用户，优先用账号ID）。
• 渠道限制：是否只对站内会话有效，还是也适用于WhatsApp/LINE/Telegram等第三方渠道。

步骤四：选择优先策略

这里你要决定“认出熟客之后怎么办”。常见选项：

• 分配给历史接待坐席（首选）：如果历史客服在线且未超负载，则优先指派给他/她。
• 优先进入队列（不指定坐席）：老客在队列中位置优先，但不保证是同一人接待。
• 分配到特定客服组：比如把所有老客发给有经验的小组处理。

步骤五：设置并发/超时与兜底策略

考虑到坐席可能不在线或已达上限，要设置兜底规则：

• 当历史坐席不在线或接待量饱和时，是否转到普通队列或转给主管坐席。
• 超时未接入的会话是否撤回重排。

步骤六：保存并逐步投产（分阶段上线）

先在灰度环境或指定小组试运行1-2周，观察是否提升满意度和效率，然后再全量启用。

如果后台没有现成功能：用标签或API来实现

有些企业的需求更复杂，或者美洽套餐里没有开“熟客优先”，这时候可以用自定义属性或API手动实现判定和分配。

思路一：给访客打标签或写入自定义属性

• 在每次会话结束时，用API或后台工单把访客标记为“is_returning=true”或写入最后接待坐席ID和时间。
• 新会话到来时，接入层（或美洽的接入规则）读取这个标签并按照分配规则优先处理。

思路二：使用API主动分配会话

部分场景可以在接入端判断访客是否为老客（如从后端数据库比对手机号），如果是则调用美洽的会话分配API，把会话直接指派给历史坐席或某个组。

测试和验证：别忽视这一步

很多问题不是设置错了，而是测试不够。下面给你一套测试清单，照着跑一遍，就知道系统到底行不行了。

基本测试用例

• 新访客首次会话：确认不被当成老客。
• 同设备回访（cookie未清）：确认被识别为熟客并按规则分配。
• 不同设备但同手机号回访：如果判定口径包含手机号，应该被识别。
• 跨渠道回访（例如以前在WhatsApp，后来在网页）：确认渠道策略生效。
• 历史坐席离线或已满：确认兜底策略触发。
• 并发大流量下的优先队列效果：是否影响总体响应时长。

日志与指标要看哪几项

• 老客识别率（回访中被判定为老客的比例）。
• 老客的首次响应时长 vs 新客对比。
• 老客会话成功率和客服满意度（CSAT）。
• 坐席负载分布：是否出现某些坐席被“绑死”。

常见问题与解决办法（会碰到的坑）

我把实际操作中常见的坑列出来，连带解决办法写清楚，别走弯路。

问题：老客没被认出

• 检查判定字段是否一致：visitor_id在不同设备会变，优先用账号ID或手机号。
• 查看cookie或本地storage是否被清除，或第三方渠道是否传递访客标识。
• 确认判定时间窗口没有被误设过短。

问题：历史坐席不在线，系统还一直等待

• 设置合理的超时和兜底：例如等待10秒后自动回退到普通队列或转主管。
• 考虑负载限制：给单个坐席设置最大并发，避免“绑定”导致等待积压。

问题：隐私与法规顾虑

如果使用手机号或个人账户ID作为判定依据，要确保符合隐私政策和当地法规（如GDPR），并在用户隐私声明/同意中写明会话数据的用途。

优化建议与运营小技巧（让功能发挥最大价值）

技术实现只是基本功，真正能提升业务的是和运营配合的一些细节。

• 分层定义“熟客”：把熟客分为高价值老客（近期有购买行为）、普通老客（只聊过）和潜在老客（有点击或收藏行为），然后按不同等级给予不同优先级或脚本。
• 限时优先：比如只在回访24小时内优先分配，过久则改为普通排队。
• 坐席技能与历史信息结合：历史坐席不一定最适合解决问题，能把老客优先分配给既有历史又具备相关技能的坐席效果更好。
• 建立回访脚本：让接待老客时，坐席查看历史会话摘要，避免重复询问，同时主动推荐相关服务。
• 定期清理判定规则：比如把长期未回访的用户标签过期，避免误判。

举例说明：两种常见场景与配置样板

场景A：电商售后，优先回到历史售后客服

• 判定字段：订单号 + 客户手机号
• 回溯时间：90天（订单维度决定）
• 策略：优先分配到历史售后客服，若该客服离线或超并发，转到售后专组
• 兜底：超时30秒转人工主管或工单

场景B：跨渠道营销客服，优先快速响应老访客但不强制同人接待

• 判定字段：visitor_id + 渠道ID
• 回溯时间：30天
• 策略：老客优先进入队列，但按技能路由分配到最合适坐席
• 兜底：队列等待超过60秒转电话或自动回呼

权限、版本与付费门槛要注意

有一点别忘了：平台不同版本（免费、基础、企业）功能差别大，某些“熟客优先”高级策略可能只在企业版或需要额外付费模块中才有。如果在后台找不到，就联系你的客户经理或查看权限说明。

结束语——其实就是照着做并不停调优

说实话，这个功能看似简单，但细节决定成败。最稳妥的路径是：先在后台找有没有内置“熟客优先”，有就按上面步骤配置并灰度验证；没有就用标签/自定义属性或API实现；测试覆盖各种设备和渠道；最后根据数据不断调整回溯窗口、并发策略和兜底方案。过程里多和坐席、运营沟通，听一线的意见——他们会告诉你哪些规则是真的有效，哪些只会增加工作量。