上个月接了个电商客户的项目对方一句话把我问住了我们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种方式对比对比项方式一主动推送方式二自动应答方式三售后跟踪触发方式业务系统主动触发客户消息回调触发流程节点变更触发核心APIsendText/sendImageWebhook 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: fBearer {token}, Content-Type: application/json } self.redis redis.Redis.from_url(redis_url) def on_status_change(self, order): 订单状态变更时调用 # 幂等同一订单同一状态只发一次 cache_key forder_notice:{order[id]}:{order[status]} if not self.redis.set(cache_key, 1, nxTrue, ex86400): 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}, headersself.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开发文档 文档里写得比较全照着改基本不会出错。