机场停车的服务从旅客出发前开始，一直延续到返程接机、取车。我们为航逸搭建连接企业微信与小程序订单系统的智能客服，让常规咨询、行程确认和订单通知沿着同一笔订单持续推进，也为人工客服保留接手复杂问题的空间。

配图与视频画面依据项目资料与代码逻辑制作，不是线上产品截图。

以上数字描述项目覆盖与交付周期，不代表运营效率提升比例。完成时间与周期采用客户提供的首期项目口径。

1.先看一笔停车订单如何被跟进

视频从机场停车的业务背景讲起，展示人工跨系统跟进的困难，再呈现订单核验、返程信息确认和主动通知如何衔接。画面为脱敏流程示意。

2.一次停车，为什么需要好几天的服务

航逸提供机场停车与接送服务。旅客开车到停车场，按指引前往航站楼；返程后，再确认接机安排并取车离场。客服需要知道旅客何时出发、订了哪种服务，以及返程航班、同行人数和行李情况。

一笔订单会经过多个时间节点。出发前，客户询问价格和入场路线；旅途中，订单等待返程；飞机落地后，服务重点转为等候位置、接机安排和司机信息。需要补款的订单还要提示客户回到小程序处理，最后才能结束本次服务。

这家企业同时经营停车接送、自助停车和班车三条业务线。它们面对的客户问题相近，处理规则却不同。班车需要预约指引，自助停车更关心取车安排，部分专属服务需要人工继续跟进。客服必须同时判断客户订了什么、现在走到了哪一步。

3.聊天、订单和调度分开，客服就得反复核对

客户主要通过企业微信沟通，订单记录在小程序里，司机派单由后台人员处理。回答一条接机咨询，客服往往要先找到订单，核对行程和状态，再确认调度结果，把相关信息发回聊天窗口。

这种工作方式带来三类压力。

• 信息重复整理。客户在聊天中发送截图、航班和同行信息，客服还要查询后台，把确认后的内容同步到订单中。
• 跨日提醒依赖人工跟进。一笔订单服务尚未结束，新的咨询又不断进入。出行、返程、接机和完单提醒容易被其他消息打断。
• 不同服务容易混用口径。同一个问题放在停车接送、自助停车或班车业务中，可能需要不同答案，通用话术难以覆盖全部情况。

部分主动跟进服务原先还没有开展。项目既要承接已经存在的重复操作，也要补齐这些服务节点，让旅客在需要行动时得到相应指引。

4.核心需求，把对话接到真实订单上

我们与客户梳理的重点，是让智能客服在现有业务流程里办事。旅客继续使用熟悉的企业微信，订单仍在原有小程序中管理，客服无需要求客户迁移到一个新的沟通入口。

系统需要理解文字和图片消息，查询价格与订单，关联客户会话；返程信息收齐后，先请客户确认，再更新订单。小程序状态变化时，系统要找到对应客户并发送通知。遇到专属服务、信息冲突或需要人工判断的情况，还要能把对话交给客服。

这些要求决定了方案的组织方式。我们以订单标识关联用户、会话和业务状态，并按履约阶段推进对话。客户重新发来消息时，系统结合已有信息继续处理，减少反复询问同一组资料。

5.从看懂截图，到核验订单、确认后回写

客户不一定会按表单格式描述问题。有人发送订单截图，有人提供车牌或航班图片，也有人分几条消息补充同行信息。智能客服先从文字与图片中提取查询线索，再通过小程序接口核验真实订单和服务类型。

截图识别和订单核验各有职责。图片帮助系统理解客户在说哪笔订单，订单是否有效、目前处于什么状态，仍以订单系统返回的信息为准。信息不完整或存在歧义时，系统继续确认，不用模型推测替代业务记录。

返程阶段，系统收集航班、人数和行李等必要信息，整理后请客户确认，再回写小程序。这样，聊天中的信息可以进入后续接机流程，后台人员也能依据同一份订单记录继续工作。入场路线视频与班车预约图片作为服务指引发送给客户，帮助旅客完成入场或预约。

6.订单状态变化后，主动把下一步告诉客户

项目接通了小程序订单事件与企业微信消息。小程序发出出行、返程或完单事件后，系统根据订单定位会话，再发送该阶段的通知。需要补款时，客户收到提示并回到小程序支付。

接机阶段保留了原有人工调度。后台人员完成司机派单后，系统同步派单结果，将司机信息及业务后台提供的定位链接告知客户。AI 不选择司机，也不生成司机位置或代替付款。

这些通知让服务从被动回答延伸到按订单主动跟进。客服少了一部分查询后再转发的工作，原先尚未提供的主动提醒也有了系统承接的方式。通知能否到达，仍依赖订单事件、客户绑定和渠道发送等环节正常工作。

7.三条业务线各有规则，复杂情况由人工接手

系统为停车接送、自助停车和班车分别配置流程与规则，增值服务在所属业务中继续分流。班车客户可以收到预约指引，自助停车客户按取车规则处理，部分专属返程服务保留人工负责。

需要人工判断的诉求会通知员工。人工接管通知成功后，系统暂停 AI 回复，避免客户同时收到两套答复。处理结束且满足恢复条件时，再结合会话摘要继续服务。监控告警与人工接管分开处理，发出告警不等于已经有人接手。

人工客服因此保留对复杂订单和特殊服务的控制权。系统承接规则清楚、信息可核验的常规跟进，司机调度和需要现场判断的工作继续由人负责。

8.首期约 12 周，围绕现有业务完成接入

首期建设从需求与流程梳理开始，明确每条业务线需要哪些信息、由谁确认、在哪个节点通知客户。随后设计企业微信接入、用户与订单绑定及小程序接口，推进订单查询、信息回写和事件联调，再完成阶段对话、媒体指引、人工接管与生产部署。

按客户提供的项目口径，首期约 12 周，于 2026 年 6 月完成，之后依据真实运营反馈持续迭代。交付重点覆盖业务规则、系统接口与客服分工，而不仅是配置一组问答话术。

技术方案采用业务服务与 AI Agent 两层架构。业务服务负责消息接入、多业务路由、媒体收发及订单事件；AI Agent 负责分阶段对话，通过限定的工具查询和更新订单。核心技术包括 FastAPI、LangGraph、PostgreSQL、企业微信渠道接入与小程序 API，配套对象存储、容器部署和运行观测。

9.项目带来的改变

目前项目覆盖三条业务线，具备八个会话阶段的管理能力，并将咨询、订单核验、行程收集和事件通知连接到原有订单系统。客户可以在聊天中完成必要的信息确认，后台保留业务记录与调度职责，客服能够在需要时接管对话。

这次交付包含两部分价值。已有的常规跟进获得系统支持，一些此前未开展的主动服务也得到补齐。项目尚无可用于公开比较的响应时长、人工成本或漏发率统计，因此本文不把新增能力换算为效率提升百分比。

对于同样通过企业微信接待客户、在另一套系统管理长周期订单的企业，这个案例展示了一种可参考的接入方式。先理清订单节点与人工职责，再让 AI 在可核验的信息和明确规则内持续跟进，业务人员仍然掌握现场服务与复杂问题的处理。