前言
家政行业订单管理长期依赖人工在微信群里喊单、截图确认、电话回访,高峰期漏单、错派、回访遗忘是三大顽疾。如何把散落在数十个微信群和私聊里的预约请求自动收集、智能派单,并在服务完成后自动触发回访消息?本文结合 WechatApi 个人微信API 的实际调用范式,给出一套可落地的技术方案。
一、家政派单场景的核心痛点与技术路径
1.1 人工派单的三大瓶颈
家政公司通常有两类微信触点:客户侧(预约下单)和阿姨侧(接单执行)。人工流程大致是:客户在公众号或私信留言 → 客服手动记录到表格 → 早会口头/群消息通知阿姨 → 服务完成后人工发回访问卷。
这条流水线有三个断点:
| 环节 | 人工痛点 | 出错率 |
|---|---|---|
| 预约收集 | 多群私聊同时涌入,容易遗漏 | 高峰期约 8-15% |
| 派单确认 | 阿姨回复"收到"后无二次确认,临时爽约无感知 | 约 5% |
| 服务回访 | 依赖客服记忆,漏发率高且时效不稳定 | 约 20-30% |
技术路径:用 微信二次开发 把个人微信账号接入 HTTP API,让业务系统作为中间层,实现消息监听→解析→入库→自动回复→定时触发回访的完整闭环。
1.2 为什么选择个人微信而非企业微信
很多家政公司的阿姨群、老客户群早年沉淀在个人微信,迁移成本极高。企业微信对外消息存在"外部联系人"限制,而客户习惯加私人号聊天。因此基于 iPad 协议的个人微信 API 是更贴近现实的方案——微信账号照常使用,API 层透明接管消息读写。
二、系统架构设计
整体系统分为四层:
微信消息层(客户群/私聊/阿姨群)
↓ WechatApi Webhook 推送
业务网关层(消息路由 + NLP 意图识别)
↓
核心服务层(订单库 + 阿姨排班库 + 派单引擎)
↓
回调执行层(派单通知 / 定时回访 / 异常预警)
WechatApi 作为微信消息的进出口,把所有收到的消息通过 Webhook 实时推送到业务网关,业务网关再把需要发送的消息通过 API 写回微信。整个过程对微信账号本身完全无感。
三、预约消息的自动接收与解析
3.1 Webhook 接收消息
在 WechatApi 控制台配置 Webhook 地址后,每条收到的微信消息都会以 JSON 形式 POST 到你的服务器。一条典型的预约私信 payload 如下:
json{
"appId": "wx_device_001",
"fromUser": "wxid_abc123",
"toUser": "wxid_mybot",
"msgType": "text",
"content": "我想预约明天下午2点钟点保洁,两居室,地址杨浦区XX小区",
"createTime": 1718265600
}
字段说明:
appId:当前登录设备的设备 ID,多设备部署时用于区分账号fromUser:发送人 wxid,用于回复时定向发送content:原始文本,需要 NLP 解析出「服务类型、时间、地址」三要素
3.2 意图识别与结构化
推荐用轻量级规则 + 大模型双层解析。规则层覆盖高频模板("预约X月X日X点XX服务"),大模型兜底处理口语化表达。
pythonimport re
import requests
def parse_order(content: str) -> dict:
"""
简单规则提取预约三要素,生产环境建议接 LLM 兜底
"""
time_pattern = r'(明天|后天|\d+月\d+日|\d+号).{0,3}(\d+点|\d+:\d+)'
service_pattern = r'(保洁|月嫂|育儿嫂|钟点工|搬家|家电清洗)'
area_pattern = r'(\d+居室|\d+平)'
time_match = re.search(time_pattern, content)
service_match = re.search(service_pattern, content)
area_match = re.search(area_pattern, content)
return {
"service_type": service_match.group(0) if service_match else None,
"appt_time_raw": time_match.group(0) if time_match else None,
"area": area_match.group(0) if area_match else None,
"raw_text": content,
"need_confirm": not all([time_match, service_match])
}
# 测试
result = parse_order("我想预约明天下午2点钟点保洁,两居室")
print(result)
# {'service_type': '保洁', 'appt_time_raw': '明天下午2点', 'area': '两居室', ...}
解析失败时,系统自动回复引导话术,让客户补充信息,而不是丢单。
3.3 自动回复确认消息
解析成功后立刻通过 WechatApi 发送预约确认,HTTP POST 示例:
bashcurl -X POST https://api.wechatapi.net/v1/message/sendText \
-H "VideosApi-token: YOUR_TOKEN_HERE" \
-H "Content-Type: application/json" \
-d '{
"appId": "wx_device_001",
"toUser": "wxid_abc123",
"content": "您好!已收到您的预约申请:\n服务类型:保洁\n预约时间:明天下午2点\n户型:两居室\n\n我们将在30分钟内为您确认阿姨安排,请稍候。"
}'
返回体格式:
json{
"ret": 200,
"msg": "success",
"data": {
"msgId": "msg_20240613_001",
"status": "sent"
}
}
ret: 200 表示消息已进入发送队列,data.msgId 可用于后续消息状态查询。
四、智能派单:从订单到阿姨通知
4.1 派单引擎核心逻辑
派单引擎根据订单的「服务类型 × 预约时间 × 服务区域」在阿姨库中匹配最优人选。匹配优先级建议如下:
| 优先级 | 条件 | 说明 |
|---|---|---|
| P1 | 该客户的历史服务阿姨 | 提升复购体验 |
| P2 | 同区域 + 该服务类型认证 | 减少通勤时间 |
| P3 | 当日已有订单但时间不冲突 | 提高阿姨出勤效率 |
| P4 | 空档期阿姨(兜底) | 保证接单率 |
匹配到候选人后,系统向阿姨的微信发送派单通知,要求阿姨回复"接单"或"拒单"。这里关键点是:必须监听阿姨的回复消息,不能只发不等。
4.2 派单通知与接单确认
发送派单通知:
pythonimport requests
import json
WECHAT_API_BASE = "https://api.wechatapi.net/v1"
TOKEN = "YOUR_TOKEN_HERE"
HEADERS = {
"VideosApi-token": TOKEN,
"Content-Type": "application/json"
}
def send_dispatch_notice(device_app_id: str, nanny_wxid: str, order: dict) -> dict:
"""
向阿姨发送派单通知
"""
content = (
f"【新订单通知】\n"
f"服务类型:{order['service_type']}\n"
f"预约时间:{order['appt_time']}\n"
f"地址:{order['address']}\n"
f"户型:{order['area']}\n\n"
f"请回复【接单】或【拒单】,30分钟内无响应将自动转派。"
)
payload = {
"appId": device_app_id,
"toUser": nanny_wxid,
"content": content
}
resp = requests.post(
f"{WECHAT_API_BASE}/message/sendText",
headers=HEADERS,
data=json.dumps(payload)
)
return resp.json()
# 调用示例
result = send_dispatch_notice(
device_app_id="wx_device_001",
nanny_wxid="wxid_nanny_007",
order={
"service_type": "保洁",
"appt_time": "2024-06-14 14:00",
"address": "杨浦区XX小区3号楼",
"area": "两居室"
}
)
print(result)
# {"ret": 200, "msg": "success", "data": {"msgId": "msg_dispatch_001", "status": "sent"}}
阿姨回复"接单"时,Webhook 收到该条消息,业务层将订单状态更新为"已确认",并同步通知客户:
好消息!王阿姨已接受您的预约,她将于明天下午2点准时上门,如需调整请提前1小时联系我们。
若30分钟内无响应,定时任务自动触发次优候选人的派单通知,循环直到接单成功或进入人工介入流程。
4.3 群内公开播报(可选)
对于"阿姨互助群"这类场景,也可以在群内广播订单,由阿姨抢单。WechatApi 同样支持向群聊发送消息,只需将 toUser 换成群的 chatRoomId 即可。微信群管理机器人 功能可以进一步管理群内抢单秩序,例如限制同一阿姨在同一时段只能抢一单。
五、服务完成后的自动回访
5.1 回访时机的设计
回访不是越快越好,也不是越晚越好。根据家政行业实践,建议的回访时机窗口如下:
| 服务类型 | 推荐回访时间 | 原因 |
|---|---|---|
| 钟点工保洁 | 服务结束后 2 小时内 | 客户印象最新鲜 |
| 月嫂/育儿嫂 | 首周每3天一次,后续每周一次 | 长期服务需持续跟进 |
| 搬家/大件清洗 | 次日上午 10-11 点 | 当天疲惫,次日最合适 |
5.2 定时任务驱动的回访发送
系统在订单状态变为"服务完成"时,写入回访任务队列(Redis Sorted Set,score 为回访时间戳)。定时任务每分钟扫描到期任务:
pythonimport redis
import time
import requests
import json
r = redis.Redis(host='localhost', port=6379, db=0)
WECHAT_API_BASE = "https://api.wechatapi.net/v1"
TOKEN = "YOUR_TOKEN_HERE"
HEADERS = {"VideosApi-token": TOKEN, "Content-Type": "application/json"}
def send_followup(device_app_id: str, customer_wxid: str, order_id: str):
"""发送回访消息"""
content = (
"您好!您于昨天预约的家政服务已完成,"
"希望服务质量让您满意 😊\n\n"
"请问阿姨的服务您满意吗?\n"
"回复【满意】【一般】【不满意】即可,"
"您的反馈是我们改进的动力!"
)
payload = {
"appId": device_app_id,
"toUser": customer_wxid,
"content": content
}
resp = requests.post(
f"{WECHAT_API_BASE}/message/sendText",
headers=HEADERS,
data=json.dumps(payload)
)
result = resp.json()
if result.get("ret") == 200:
# 标记回访已发送
r.hset(f"order:{order_id}", "followup_sent", int(time.time()))
return result
def process_followup_queue(device_app_id: str):
"""每分钟执行,处理到期回访任务"""
now = time.time()
# 取出所有 score <= now 的任务
tasks = r.zrangebyscore("followup_queue", 0, now, withscores=False)
for task_bytes in tasks:
task = json.loads(task_bytes)
send_followup(device_app_id, task["customer_wxid"], task["order_id"])
r.zrem("followup_queue", task_bytes)
# 每分钟调用一次
process_followup_queue("wx_device_001")
5.3 回访反馈的自动归档
客户回复"满意/一般/不满意"后,Webhook 再次触发,业务层解析关键词并写入阿姨评价记录。不满意反馈自动升级为工单,推送给运营人员的微信,形成闭环管理。
利用 微信客服机器人 的能力,可以在不满意场景下自动追问:"能告诉我们哪里不满意吗?方便我们跟进改善",收集更细粒度的差评原因,而不是只记录一个负面标签。
六、多设备部署与稳定性注意事项
6.1 appId 与设备管理
WechatApi 采用 iPad 协议模拟登录,每个微信账号对应一个 appId(设备 ID)。家政公司通常有多个业务微信号:
- 客户服务号(接预约)
- 阿姨管理号(发派单)
- 运营监控号(接异常预警)
三个号的 appId 各不相同,在调用 API 时必须准确传入对应的 appId,否则消息会从错误的账号发出。建议在配置文件中维护一张 role → appId 的映射表。
6.2 消息发送频率控制
微信对高频消息发送有风控机制。在派单峰值期(如早 8-9 点),可能同时向数十位阿姨发送通知。建议:
- 同一账号每秒不超过 1 条消息
- 使用消息队列(如 RabbitMQ)做限速,而非直接循环调用
- 对同一
toUser避免短时间内重复发送相同内容
6.3 Webhook 的幂等处理
网络抖动可能导致同一条消息 Webhook 被推送两次。业务层在处理预约消息时,必须以 msgId 做幂等判断,防止同一客户的预约被录入两次、触发两次派单。
6.4 断线重连与消息补偿
iPad 协议账号偶尔会掉线(如手机端异地登录踢出)。WechatApi 提供账号在线状态查询接口,建议每5分钟主动巡检,发现离线立刻告警。掉线期间到达的消息会在重连后由平台批量补推,业务层需要能处理历史消息的批量入库。
七、实际落地的配置检查清单
在上线前,逐项核对以下配置:
| 检查项 | 标准 |
|---|---|
| 微信账号正常登录,appId 已获取 | 控制台可见"在线"状态 |
| Webhook 地址已配置且可公网访问 | 用 curl 模拟 POST 能收到 |
| 消息发送 TOKEN 已写入环境变量 | 不硬编码在代码里 |
| 回访队列 Redis 已部署 | 重启不丢任务 |
| 不满意工单通知渠道已测试 | 运营微信能收到推送 |
| 消息幂等表(msgId 去重)已建立 | 防止重复派单 |
| 发送限速(≤1条/秒)已实现 | 压测验证 |
小结
本文从家政预约的核心痛点出发,设计了一套基于 WechatApi 的完整技术方案,涵盖预约消息接收与解析、智能派单与接单确认、定时回访与差评闭环四个核心环节。关键技术点是:Webhook 驱动的消息事件模型,结合业务状态机管理订单流转,通过 appId + VideosApi-token 的调用范式实现多账号管理。
对于想快速验证方案的团队,可以先用单个微信账号跑通"收预约→回复确认→通知阿姨"这三步最小闭环,再逐步接入派单引擎和回访模块。WechatApi 提供完整的 开发文档 和控制台,注册后即可获取 appId 和 TOKEN 开始调试。
