要解决的问题
不做这个功能会遇到什么
先说清楚问题，再说我们的做法。
多后台切换成本高
坐席同时开五个后台，漏看消息、回复延迟、错误率高。
客户重复描述问题
换个渠道就得从头再说一遍，���客体验差，也增加处理时长。
客户画像割裂
同一个客户在不同渠道被当成不同的人，重复注册、重复识别。
实现原理
具体是怎么做的
面向技术评估的需求，不讲营销话术。
- 01
渠道适配器
每个渠道作为一个适配器接入，负责处理该渠道特有的协议（消息格式、回调、鉴权）。业务层不感知渠道差异。
- 02
统一会话模型
所有渠道的会话归一化成同一个数据模型。客户身份按手机号、邮箱、OpenID 等可识别信息跨渠道合并。
- 03
跨渠道时间线
同一客户在不同渠道的对话按时间顺序连成一条完整线，坐席打开就能看到「之前问过什么、我们答过什么」。
- 04
统一分配规则
分配规则作用于合并后的客户视角。比如「VIP 客户无论从哪个渠道来，都分给专属顾问」。
设计决策
为什么这样做，而不是另一种做法
每个关键取舍都列出来。技术评估时最该问的就是这些。
Q: 要不要为每个渠道单独开发？
我们的选择
不单独开发，做适配器抽象
原因
每个渠道都单独开发一套会失控。抽象出统一接口后，新增渠道的成本被压到最低，业务代码完全不用改。
Q: 国内和海外用同一套渠道代码吗？
我们的选择
同一套，按区域启用不同渠道
原因
国内可启用微信/企业微信，海外可启用 WhatsApp/Telegram，均需完成供应商授权与底座配置后开通。核心逻辑一致，只是启用哪些适配器不同。
Q: 客户身份怎么跨渠道合并？
我们的选择
按可验证标识合并，不做模糊匹配
原因
模糊匹配（按姓名等）会把不同客户合并到一起，是数据污染的高发区。只按手机号、邮箱这类可验证标识。
可调项
这些参数你们可以自己调
不需要联系我们改代码，改配置即可生效。
| 参数 | 默认值 | 调整影响 |
|---|---|---|
| 渠道启用开关 | 按区域配置 | 按部署区域启用对应渠道 |
| 非工作时间策略 | 智能体全接待 + 留资 | 可配置为仅留资或完全不接待 |
常见问题
多渠道接入的常见疑问
接入新渠道要多久？
有适配器框架后，主要工作是处理该渠道的协议对接与鉴权，多数渠道 1-2 周可以完成。特殊渠道（需要深度定制交互的）另议。
支持微信哪些形态？
微信客服与企业微信在完成授权与底座配置后支持。个人微信不在支持范围内 —— 这既是因为技术限制，也是因为存在合规风险。
海外版支持哪些渠道？
网站挂件与开放平台/API 接入已可用；WhatsApp、Telegram、LINE、Facebook Messenger、邮件需完成供应商授权与底座配置后开通。海外版与国内版是同一套代码，只是启用的渠道适配器不同。