前段时间帮一个做客服SaaS的朋友接微信能力。他们的系统本来只接网页会话和电话客户咨询全靠人工响应慢、流失高。老板拍板要接微信理由很直接——客户都在微信上谁先接上谁就能抢客户。需求一抛出来团队第一反应是找套个人微信API就行。真上手才发现能发消息和能撑起一套客服系统是两码事。客服软件要的不是单点发消息而是从消息进来到处理完出去整条链路都要打通。我把消息流转从头到尾拆了一遍理出6个能力支撑点。接入前先把 Eyun开发文档 看一遍重点关注 Webhook 回调、wId 实例ID、Token 鉴权这几个概念下面的6个支撑点都绕不开它们。基础概念不搞清楚后面写到一半会发现回调字段对不上、发送权限没开返工很烦。消息流转的全链路先把整条链路画出来6个支撑点都在链路上有自己的位置看图比看字直观微信用户 ──消息── [Eyun实例] ──Webhook回调── 客服系统 │ ├─ 1.消息接入统一收口 ├─ 2.消息路由分发给客服 ├─ 3.消息回复API回用户 ├─ 4.会话管理多轮上下文 ├─ 5.转人工兜底机器人转人 └─ 6.质检监控记录回流分析链路清楚了6个支撑点就逐个看。支撑点1消息接入——把微信消息收进客服系统消息流转的第一步用户在微信上发了条消息怎么进到客服系统。Eyun 能力消息接收回调支持文本/图片/语音/视频实现要点配好 Webhook 回调地址Eyun 实例收到消息后会以 POST 方式推过来请求体是 JSON。要按消息类型分别处理文本直接取 content图片/语音/视频拿到 URL 再去下载落本地存储。坑点图片和语音要先下到自己的存储再给客服看直接用回调里的 URL 会过期。我们一开始图省事直接用回调URL客服同学打开消息全是404被吐槽半天回头老老实实做了附件下载服务才消停。支撑点2消息路由——分发给对的客服消息进来不能一股脑给所有人要按规则分发按客户来源、按业务线、按客服空闲状态。Eyun 能力回调数据里带 fromUser发送者wxid可以做路由判断实现要点拿 fromUser 做客户身份匹配关联到客户档案按预设规则路由。比如A客服负责华东客户B客服负责售后咨询从 fromUser 反查到客户标签就能分发到对应客服的工作台。路由这块的回调字段细节Eyun平台 上有完整说明fromUser、msgId、消息类型、时间戳这些字段含义一定要对齐不然后续路由逻辑全乱。我们把字段含义抄在内部wiki上团队对齐才开工。支撑点3消息回复——客服处理完通过API回用户客服在系统里把消息写好怎么发到用户的微信上。Eyun 能力sendText / sendImage / sendFile多种回复形式实现要点客服在系统里编辑回复内容点发送后端调 Eyun 的发送接口。文本用 sendText图片用 sendImage文件用 sendFile参数里带上 wId 指定哪个实例发toUser 指定发给谁。坑点发送接口要带 Token 鉴权Token 别硬编码用配置中心管理定期轮换。还有 toUser 必须用回调里拿到的 fromUser不能用微信号或昵称对不上就发不出去。早期我们图省事用昵称匹配发不出去排查了一下午。支撑点4会话管理——多轮对话上下文客服不是一问一答是多轮对话。用户问完价格又问发货客服得知道前情不能每条消息都从头问。Eyun 能力msgId 唯一标识 消息记录同步实现要点每条消息回调里都有 msgId做唯一键。同一客户fromUser的消息按时间排序存到会话表客服界面打开会话能看到完整历史。新客服接手也不用手动翻聊天记录上下文一目了然。坑点消息去重。Webhook 偶尔会重复推送同一条消息网络抖动重试用 msgId 做幂等不然客服界面看到重复消息特别尴尬。我们上线第一周就因为这问题被客服投诉加幂等后才消停。支撑点5转人工兜底——机器人处理不了的转人机器人能处理80%的常见问题剩下20%复杂咨询必须转人工不然客户体验崩盘。Eyun 能力消息回调 人工接管 消息转发实现要点机器人先处理命中知识库直接回没命中标记待人工进排队队列。客服空闲时从队列取消息接管后续该客户的消息直接路由到该客服不再走机器人。坑点转人工的瞬间要让用户感知到不然用户以为没人理。我们加了句正在为您转接人工客服前面还有N人请稍候简单粗暴但有效。还要处理超时未接——客服5分钟没响应自动转下一个不然队列卡死。支撑点6质检监控——对话记录回流做质量分析客服工作质量怎么评估光靠客服主管抽样看不靠谱样本太小。要把对话数据回流到分析系统做系统评估。Eyun 能力消息历史拉取 数据同步实现要点定期拉取消息历史或实时把回调消息同步到分析库做响应时长、解决率、满意度、关键词聚类分析给客服培训和话术优化提供依据。坑点分析库别和业务库共用高峰期查询会拖垮业务库。我们做了独立的分析库T1出报告实时性要求不高的场景够用了。6个支撑点能力一览把6个支撑点放一张表里对比接入时按这张表对照能力清单逐项落地支撑点在流转中的位置Eyun能力实现要点消息接入入口消息回调区分消息类型附件先落本地存储消息路由分发fromUser字段按客户身份和规则路由消息回复出口sendText/sendImage/sendFileToken安全、toUser对齐会话管理全程msgId唯一标识做幂等去重转人工兜底兜底人工接管转发转接要给用户反馈、超时自动转质检监控复盘消息历史拉取独立分析库别拖垮业务库怎么取舍小团队可能只要接入路由回复就够了大客户场景才需要会话管理、转人工、质检全套。别一上来就追求大而全先把核心3个支撑点跑通跑顺了再补齐。一段核心代码客服消息路由分发路由是6个支撑点里最关键的分发错了后面全乱。贴一下我们的简化版实际生产里加了权重和超时但骨架不变# 客服消息路由分发接收Eyun回调后路由 from flask import Flask, request app Flask(__name__) # 客服列表和负责范围 AGENTS { agent_001: {region: 华东, skill: 售前, status: idle}, agent_002: {region: 华东, skill: 售后, status: idle}, agent_003: {region: 华北, skill: 售前, status: busy}, } # 客户标签实际从CRM查 CUSTOMER_TAGS { wxid_abc: {region: 华东, type: 售前}, wxid_xyz: {region: 华北, type: 售后}, } app.route(/webhook, methods[POST]) def webhook(): data request.json from_user data.get(fromUser, ) content data.get(content, ) msg_id data.get(msgId, ) # 1. 幂等去重 if is_duplicate(msg_id): return {code: 0, msg: duplicated} # 2. 查客户标签 tag CUSTOMER_TAGS.get(from_user, {region: 默认, type: 通用}) # 3. 路由到匹配且空闲的客服 target_agent None for agent_id, info in AGENTS.items(): if (info[region] tag[region] and info[skill] tag[type] and info[status] idle): target_agent agent_id break if not target_agent: # 没匹配上或都忙进排队 enqueue(from_user, content, msg_id) send_wait_hint(from_user) # 给用户发前面还有N人 else: # 路由成功消息推给对应客服的工作台 dispatch_to_agent(target_agent, from_user, content, msg_id) return {code: 0} def is_duplicate(msg_id): # 用 msgId 做幂等避免Webhook重复推送 pass def enqueue(user, content, msg_id): pass def send_wait_hint(user): # 调 Eyun sendText 给用户发排队提示 pass def dispatch_to_agent(agent_id, user, content, msg_id): pass if __name__ __main__: app.run(port8080)代码骨架就这些。实际生产里加了客服负载均衡、技能组权重、超时自动转接、会话转移但核心路由逻辑不变——拿 fromUser 反查标签按标签匹配客服匹配不上进队列。这部分跑通6个支撑点就活了4个。写在最后6个支撑点串起来就是一套完整的客服消息流转。不是每个场景都需要6个全上量力而行。我们给那个SaaS朋友最终上线的方案是先上接入路由回复转人工4个会话管理和质检监控放到第二期。先让客服能干活再优化体验。接入过程中遇到的具体接口参数、回调字段含义、发送限制建议直接查 Eyun开发文档文档里写得很细比我转述靠谱。少走弯路多留时间打磨业务逻辑。
个人微信API能为客服软件提供什么支持？从消息流转看6个能力支撑点
前段时间帮一个做客服SaaS的朋友接微信能力。他们的系统本来只接网页会话和电话客户咨询全靠人工响应慢、流失高。老板拍板要接微信理由很直接——客户都在微信上谁先接上谁就能抢客户。需求一抛出来团队第一反应是找套个人微信API就行。真上手才发现能发消息和能撑起一套客服系统是两码事。客服软件要的不是单点发消息而是从消息进来到处理完出去整条链路都要打通。我把消息流转从头到尾拆了一遍理出6个能力支撑点。接入前先把 Eyun开发文档 看一遍重点关注 Webhook 回调、wId 实例ID、Token 鉴权这几个概念下面的6个支撑点都绕不开它们。基础概念不搞清楚后面写到一半会发现回调字段对不上、发送权限没开返工很烦。消息流转的全链路先把整条链路画出来6个支撑点都在链路上有自己的位置看图比看字直观微信用户 ──消息── [Eyun实例] ──Webhook回调── 客服系统 │ ├─ 1.消息接入统一收口 ├─ 2.消息路由分发给客服 ├─ 3.消息回复API回用户 ├─ 4.会话管理多轮上下文 ├─ 5.转人工兜底机器人转人 └─ 6.质检监控记录回流分析链路清楚了6个支撑点就逐个看。支撑点1消息接入——把微信消息收进客服系统消息流转的第一步用户在微信上发了条消息怎么进到客服系统。Eyun 能力消息接收回调支持文本/图片/语音/视频实现要点配好 Webhook 回调地址Eyun 实例收到消息后会以 POST 方式推过来请求体是 JSON。要按消息类型分别处理文本直接取 content图片/语音/视频拿到 URL 再去下载落本地存储。坑点图片和语音要先下到自己的存储再给客服看直接用回调里的 URL 会过期。我们一开始图省事直接用回调URL客服同学打开消息全是404被吐槽半天回头老老实实做了附件下载服务才消停。支撑点2消息路由——分发给对的客服消息进来不能一股脑给所有人要按规则分发按客户来源、按业务线、按客服空闲状态。Eyun 能力回调数据里带 fromUser发送者wxid可以做路由判断实现要点拿 fromUser 做客户身份匹配关联到客户档案按预设规则路由。比如A客服负责华东客户B客服负责售后咨询从 fromUser 反查到客户标签就能分发到对应客服的工作台。路由这块的回调字段细节Eyun平台 上有完整说明fromUser、msgId、消息类型、时间戳这些字段含义一定要对齐不然后续路由逻辑全乱。我们把字段含义抄在内部wiki上团队对齐才开工。支撑点3消息回复——客服处理完通过API回用户客服在系统里把消息写好怎么发到用户的微信上。Eyun 能力sendText / sendImage / sendFile多种回复形式实现要点客服在系统里编辑回复内容点发送后端调 Eyun 的发送接口。文本用 sendText图片用 sendImage文件用 sendFile参数里带上 wId 指定哪个实例发toUser 指定发给谁。坑点发送接口要带 Token 鉴权Token 别硬编码用配置中心管理定期轮换。还有 toUser 必须用回调里拿到的 fromUser不能用微信号或昵称对不上就发不出去。早期我们图省事用昵称匹配发不出去排查了一下午。支撑点4会话管理——多轮对话上下文客服不是一问一答是多轮对话。用户问完价格又问发货客服得知道前情不能每条消息都从头问。Eyun 能力msgId 唯一标识 消息记录同步实现要点每条消息回调里都有 msgId做唯一键。同一客户fromUser的消息按时间排序存到会话表客服界面打开会话能看到完整历史。新客服接手也不用手动翻聊天记录上下文一目了然。坑点消息去重。Webhook 偶尔会重复推送同一条消息网络抖动重试用 msgId 做幂等不然客服界面看到重复消息特别尴尬。我们上线第一周就因为这问题被客服投诉加幂等后才消停。支撑点5转人工兜底——机器人处理不了的转人机器人能处理80%的常见问题剩下20%复杂咨询必须转人工不然客户体验崩盘。Eyun 能力消息回调 人工接管 消息转发实现要点机器人先处理命中知识库直接回没命中标记待人工进排队队列。客服空闲时从队列取消息接管后续该客户的消息直接路由到该客服不再走机器人。坑点转人工的瞬间要让用户感知到不然用户以为没人理。我们加了句正在为您转接人工客服前面还有N人请稍候简单粗暴但有效。还要处理超时未接——客服5分钟没响应自动转下一个不然队列卡死。支撑点6质检监控——对话记录回流做质量分析客服工作质量怎么评估光靠客服主管抽样看不靠谱样本太小。要把对话数据回流到分析系统做系统评估。Eyun 能力消息历史拉取 数据同步实现要点定期拉取消息历史或实时把回调消息同步到分析库做响应时长、解决率、满意度、关键词聚类分析给客服培训和话术优化提供依据。坑点分析库别和业务库共用高峰期查询会拖垮业务库。我们做了独立的分析库T1出报告实时性要求不高的场景够用了。6个支撑点能力一览把6个支撑点放一张表里对比接入时按这张表对照能力清单逐项落地支撑点在流转中的位置Eyun能力实现要点消息接入入口消息回调区分消息类型附件先落本地存储消息路由分发fromUser字段按客户身份和规则路由消息回复出口sendText/sendImage/sendFileToken安全、toUser对齐会话管理全程msgId唯一标识做幂等去重转人工兜底兜底人工接管转发转接要给用户反馈、超时自动转质检监控复盘消息历史拉取独立分析库别拖垮业务库怎么取舍小团队可能只要接入路由回复就够了大客户场景才需要会话管理、转人工、质检全套。别一上来就追求大而全先把核心3个支撑点跑通跑顺了再补齐。一段核心代码客服消息路由分发路由是6个支撑点里最关键的分发错了后面全乱。贴一下我们的简化版实际生产里加了权重和超时但骨架不变# 客服消息路由分发接收Eyun回调后路由 from flask import Flask, request app Flask(__name__) # 客服列表和负责范围 AGENTS { agent_001: {region: 华东, skill: 售前, status: idle}, agent_002: {region: 华东, skill: 售后, status: idle}, agent_003: {region: 华北, skill: 售前, status: busy}, } # 客户标签实际从CRM查 CUSTOMER_TAGS { wxid_abc: {region: 华东, type: 售前}, wxid_xyz: {region: 华北, type: 售后}, } app.route(/webhook, methods[POST]) def webhook(): data request.json from_user data.get(fromUser, ) content data.get(content, ) msg_id data.get(msgId, ) # 1. 幂等去重 if is_duplicate(msg_id): return {code: 0, msg: duplicated} # 2. 查客户标签 tag CUSTOMER_TAGS.get(from_user, {region: 默认, type: 通用}) # 3. 路由到匹配且空闲的客服 target_agent None for agent_id, info in AGENTS.items(): if (info[region] tag[region] and info[skill] tag[type] and info[status] idle): target_agent agent_id break if not target_agent: # 没匹配上或都忙进排队 enqueue(from_user, content, msg_id) send_wait_hint(from_user) # 给用户发前面还有N人 else: # 路由成功消息推给对应客服的工作台 dispatch_to_agent(target_agent, from_user, content, msg_id) return {code: 0} def is_duplicate(msg_id): # 用 msgId 做幂等避免Webhook重复推送 pass def enqueue(user, content, msg_id): pass def send_wait_hint(user): # 调 Eyun sendText 给用户发排队提示 pass def dispatch_to_agent(agent_id, user, content, msg_id): pass if __name__ __main__: app.run(port8080)代码骨架就这些。实际生产里加了客服负载均衡、技能组权重、超时自动转接、会话转移但核心路由逻辑不变——拿 fromUser 反查标签按标签匹配客服匹配不上进队列。这部分跑通6个支撑点就活了4个。写在最后6个支撑点串起来就是一套完整的客服消息流转。不是每个场景都需要6个全上量力而行。我们给那个SaaS朋友最终上线的方案是先上接入路由回复转人工4个会话管理和质检监控放到第二期。先让客服能干活再优化体验。接入过程中遇到的具体接口参数、回调字段含义、发送限制建议直接查 Eyun开发文档文档里写得很细比我转述靠谱。少走弯路多留时间打磨业务逻辑。