客戶下單了客服不知道客戶咨詢了客服沒看到。這類信息延遲是客服團隊最常見的痛點。這篇講怎么用企微 API 把訂單和咨詢事件實時推給客服。事件來源訂單系統和咨詢入口訂單事件來自你的業(yè)務系統電商后臺、ERP、CRM咨詢事件來自企微消息回調。兩個來源兩條鏈路最后匯到同一個提醒服務。訂單事件業(yè)務系統里訂單狀態(tài)變化待付款→已付款→已發(fā)貨觸發(fā) webhook 到你的提醒服務。咨詢事件客戶在企微里發(fā)消息回調推送到你的服務。兩條鏈路的處理邏輯一樣解析事件 → 確定接收人 → 渲染模板 → 發(fā)送提醒。確定接收人不是發(fā)給客服是發(fā)給誰給客服發(fā)提醒這個說法太模糊。實際場景里接收人可能是值班的客服排班表決定負責這個客戶的銷售客戶歸屬決定負責這個品類的運營訂單內容決定客服主管投訴類事件升級做法是用一張路由表按事件類型和業(yè)務屬性匹配接收人ROUTES { order_paid: {type: sales, field: customer_owner}, order_urgent: {type: role, value: on_duty_cs}, complaint: {type: role, value: cs_manager}, } def resolve_receiver(event): route ROUTES.get(event[type]) if not route: return default_receiver() if route[type] sales: return get_sales_of_customer(event[customer_uin]) elif route[type] role: return get_users_by_role(route[value])渲染模板信息密度決定響應速度提醒消息的內容決定客服要花多少時間理解發(fā)生了什么。好的模板讓客服一眼就能行動TEMPLATES { order_paid: ( 新訂單提醒\n 訂單號{order_no}\n 客戶{customer_name}{customer_uin}\n 金額{amount}\n 商品{items}\n 請及時處理發(fā)貨。 ), complaint: ( 客戶投訴\n 客戶{customer_name}\n 內容{content}\n 歷史訂單{order_count} 筆\n 請盡快聯系客戶處理。 ), }關鍵信息放前面輔助信息放后面?？头咭谎劬椭酪灰⒖烫幚?。發(fā)送單聊優(yōu)先群聊兜底提醒發(fā)給個人別發(fā)到群里。群里消息多容易被淹沒單聊消息有強提醒客服不會錯過。但如果值班客服沒設或者銷售離職了要有兜底策略發(fā)到客服群 所有人。def send_reminder(event): receivers resolve_receiver(event) if not receivers: # 兜底發(fā)到客服群 send_to_group(CS_GROUP_ID, render(event), mention_allTrue) return for uin in receivers: conv_id resolve_conversation(uin) send_text(conv_id, render(event))狀態(tài)跟蹤發(fā)出去不算完要確認收到提醒發(fā)出去客服沒看到等于沒發(fā)。要跟蹤已讀狀態(tài)發(fā)送后記錄messageId定時查getMessageReceipt確認已讀超時未讀升級到主管def track_receipt(message_id, event, timeout300): deadline time.time() timeout while time.time() deadline: resp call_api(message/getMessageReceipt, { appid: APPID, messageId: message_id }) if resp[code] 0 and resp[data].get(read): return True time.sleep(10) # 超時未讀升級 escalate(event) return False一個真實場景某電商團隊的訂單提醒之前靠客服每小時手動刷一次后臺平均響應 40 分鐘。改成實時推送后訂單支付成功 10 秒內客服就收到提醒平均響應降到 2 分鐘。關鍵是提醒要到人不是到群。接口路徑和字段在Eyun 開發(fā)文檔里能查到憑證在Eyun 控制臺開通實例后拿到。