上个月接了个电商客户的项目，对方一句话把我问住了："我们ERP里订单状态一变，能不能马上微信通知客户？短信打开率太低了，群发又怕被封号。"
我当时心想这不简单嘛，写个定时任务扫订单状态，变了就发微信。结果真动手才发现坑多得离谱——个人微信官方没开放API，第三方免费工具用了一周就被风控，公众号模板消息打开率不到8%。
熬了三个通宵，我把市面上能用的路子都试了一遍，最后整理出3种真正能落地的结合方式。今天把这3种方式的逻辑、消息设计、踩坑点都写出来，给做电商对接的朋友省点头发。
如果你还没把微信侧的接口跑通，建议先去 Eyun开发文档 把sendText、sendImage这些基础接口摸一遍，再看下面这3种结合方式会顺很多。
方式一：订单状态变更→微信主动推送
结合逻辑
这套逻辑的链路是：ERP订单状态变更 → 触发事件 → 调Eyun的sendText/sendImage把通知发出去。
关键在于"事件触发"而不是"定时轮询"。一开始我用定时任务每分钟扫一次订单表，结果客户体验是分钟级的延迟，订单都签收了通知才发出去。后来改成ERP在订单状态变更时主动推事件，延迟压到秒级。
Eyun API能力
这条链路主要用两个接口：
sendText：发文本通知，订单号、状态、物流单号这些都能塞进去sendImage：发物流截图、电子面单图片
请求头带Authorization做Token鉴权，body里wId标识登录实例、wcId标识接收方。wId和wcId千万别搞混，我第一次就把wId当接收方传，消息全发给了自己，调了一晚上才发现这个低级错误。
消息设计
模板不是越长越好。我踩过坑，把订单详情、商品清单、物流轨迹全塞一条消息里，客户嫌长根本不看。后来精简成四要素：订单号 + 当前状态 + 关键信息 + 客服联系方式。
比如发货通知就三行：
订单 SO20260817001 已发货 顺丰速运 SF1234567890，预计明日送达 有问题回复"售后"联系客服效果
上线后订单通知触达率从62%涨到94%，客户回询"我的货到哪了"的量降了七成。最大的收益不是触达率，是客服不用再手动群发通知了。
方式二：客户微信咨询→自动应答+转人工
结合逻辑
这条链路是反过来的：客户发微信消息 → Eyun通过Webhook回调推到我的服务 → 识别意图 → 查订单系统 → 回复或转人工。
核心是Webhook回调。客户一发消息，服务端主动把消息推到你的接口，你不用轮询。回调数据里有关键字段：wId标识实例、fromUser是发送方、msgType是消息类型、content是内容。
Eyun API能力
Webhook回调：实时接收客户消息，5秒内必须返回200，不然会重试
sendText：回复客户幂等必须做，回调可能重复推送，我之前没做幂等，客户收到两条一模一样的回复，被投诉过
消息设计
意图识别我先用关键词匹配兜底，"物流""快递"走查物流流程，"退款""退货"走售后流程，"发货"走发货查询。匹配不上再转人工。
这里有个坑：关键词匹配别太死。客户发"我的东西咋还没到"，没有"物流"两个字，但明显是查物流。后来我加了同义词词典和模糊匹配，准确率才上来。
想深入了解Webhook回调的配置和验签机制，可以去 Eyun平台 看看相关的接入说明，回调这块配置不对会收不到消息，排查起来特别费劲。
效果
高频问题（查物流、查订单状态）80%由机器人自动处理，客服只处理转人工的复杂问题。平均响应时间从8分钟压到1分钟内。
方式三：售后流程→微信全程跟踪
结合逻辑
这条链路是前两种的组合：售后工单创建 → 每个节点微信通知客户 → 客户微信确认 → 流程推进。
售后流程节点多：申请提交、审核通过、退货签收、退款到账。以前客户只能干等，打电话来问"我的退款到哪一步了"。现在每个节点变更都自动推微信，客户全程可见。
Eyun API能力
多步骤消息编排：每个节点触发不同的消息模板
sendImage：发退款凭证截图、退货签收照片客户回复确认：Webhook捕获客户回复，推进流程
消息设计
多步骤消息要分层设计。节点通知用简洁模板："退款已受理，预计1-3个工作日到账"。确认类消息要带操作引导："收到退货，请回复'确认'完成退款"。
最关键的踩坑：客户回复的"确认"要准确捕获。有客户回复"确认了""好的确认""嗯确认"，纯等值匹配会漏掉一大半。后来用包含判断加同义词扩展才解决。
效果
售后咨询电话降了60%，客户主动催进度的消息少了，因为每个节点都主动通知，客户心里有底。
3种方式对比
对比项 | 方式一：主动推送 | 方式二：自动应答 | 方式三：售后跟踪 |
|---|---|---|---|
触发方式 | 业务系统主动触发 | 客户消息回调触发 | 流程节点变更触发 |
核心API | sendText/sendImage | Webhook + sendText | 多步骤编排 + Webhook |
实现复杂度 | 低 | 中 | 高 |
客户体验 | 被动接收通知 | 主动咨询有回应 | 全程透明可跟踪 |
实施周期 | 1-2天 | 1周 | 2-3周 |
三种方式不是互斥的，电商业务完整对接通常三种都要上。建议从方式一开始，最简单见效最快，跑通再扩展。
代码：订单状态变更触发微信通知
这是方式一的核心实现，我项目里在用的，包含幂等、错误分类、重试这些实战细节：
import requests import redis import time class OrderNotifier: def __init__(self, base_url, token, redis_url): self.base_url = base_url self.headers = { "Authorization": f"Bearer {token}", "Content-Type": "application/json" } self.redis = redis.Redis.from_url(redis_url) def on_status_change(self, order): """订单状态变更时调用""" # 幂等：同一订单同一状态只发一次 cache_key = f"order_notice:{order['id']}:{order['status']}" if not self.redis.set(cache_key, "1", nx=True, ex=86400): return True # 已发过，跳过 content = self._build_msg(order) for attempt in range(3): resp = requests.post( f"{self.base_url}/sendText", json={"wId": order['wId'], "wcId": order['customer_wxid'], "content": content}, headers=self.headers, timeout=(5, 15) ) code = resp.json().get("code") if code == "1000": return True # 永久错误不重试：1001参数错误/1002鉴权失败/1004资源不存在 if code in ("1001", "1002", "1004"): self.redis.delete(cache_key) # 回滚标记，下次还能试 return False time.sleep(2 ** attempt) # 临时错误，指数退避重试 return False def _build_msg(self, order): status_map = {"paid": "已付款", "shipped": "已发货", "signed": "已签收"} status = status_map.get(order['status'], order['status']) msg = f"订单 {order['id']} {status}\n" if order['status'] == 'shipped': msg += f"{order['carrier']} {order['tracking_no']}，预计明日送达\n" msg += "有问题回复\"售后\"联系客服" return msg这段代码有几个细节值得注意：幂等用Redis的SET NX，防止重复发送；错误码分两类，1001/1002/1004是永久错误直接放弃，其他才重试；重试用指数退避避免压垮接口。这些都是踩坑后加上的，没经验的同行容易漏。
最后
电商业务接微信，本质上是用客户最熟悉的沟通工具，把业务流程的每个节点都暴露给客户。三种方式覆盖了"主动通知、被动响应、全程跟踪"三个维度，组合起来基本能撑起电商客服的核心场景。
落地的时候别贪多，先从最简单的订单状态推送跑通，把wId、wcId、Token鉴权这些基础概念吃透，再往上叠复杂的。具体接口的参数细节和错误码说明，可以翻翻 Eyun开发文档 ，文档里写得比较全，照着改基本不会出错。
