[返回全部案例]() 客户案例智能客服2026 年 6 月 · 首期完成 # 航逸，用 AI 持续跟进机场停车订单 机场停车的服务从旅客出发前开始，一直延续到返程接机、取车。我们为航逸搭建连接企业微信与小程序订单系统的智能客服，让常规咨询、行程确认和订单通知沿着同一笔订单持续推进，也为人工客服保留接手复杂问题的空间。 配图与视频画面依据项目资料与代码逻辑制作，不是线上产品截图。 项目概览 | 交付范围 | 客户行业 | 机场停车与接送、本地生活出行服务 | 业务覆盖 | 停车接送、自助停车、班车 3 条业务线及多类增值服务 | 对话管理 | 8 个会话阶段，不同业务采用适用阶段 | 落地周期 | 首期约 12 周 | 完成时间 | 2026 年 6 月，后续持续迭代 | 以上数字描述项目覆盖与交付周期，不代表运营效率提升比例。完成时间与周期采用客户提供的首期项目口径。 # 1.先看一笔停车订单如何被跟进 ![图片]() 60 秒了解机场停车的业务背景、客服痛点与智能客服接入方式。脱敏流程示意，非线上产品截图。 [视频]() 视频从机场停车的业务背景讲起，展示人工跨系统跟进的困难，再呈现订单核验、返程信息确认和主动通知如何衔接。画面为脱敏流程示意。 # 2.一次停车，为什么需要好几天的服务 航逸提供机场停车与接送服务。旅客开车到停车场，按指引前往航站楼；返程后，再确认接机安排并取车离场。客服需要知道旅客何时出发、订了哪种服务，以及返程航班、同行人数和行李情况。 一笔订单会经过多个时间节点。出发前，客户询问价格和入场路线；旅途中，订单等待返程；飞机落地后，服务重点转为等候位置、接机安排和司机信息。需要补款的订单还要提示客户回到小程序处理，最后才能结束本次服务。 这家企业同时经营停车接送、自助停车和班车三条业务线。它们面对的客户问题相近，处理规则却不同。班车需要预约指引，自助停车更关心取车安排，部分专属服务需要人工继续跟进。客服必须同时判断客户订了什么、现在走到了哪一步。 # 3.聊天、订单和调度分开，客服就得反复核对 客户主要通过企业微信沟通，订单记录在小程序里，司机派单由后台人员处理。回答一条接机咨询，客服往往要先找到订单，核对行程和状态，再确认调度结果，把相关信息发回聊天窗口。 这种工作方式带来三类压力。 - **信息重复整理。**客户在聊天中发送截图、航班和同行信息，客服还要查询后台，把确认后的内容同步到订单中。 - **跨日提醒依赖人工跟进。**一笔订单服务尚未结束，新的咨询又不断进入。出行、返程、接机和完单提醒容易被其他消息打断。 - **不同服务容易混用口径。**同一个问题放在停车接送、自助停车或班车业务中，可能需要不同答案，通用话术难以覆盖全部情况。 部分主动跟进服务原先还没有开展。项目既要承接已经存在的重复操作，也要补齐这些服务节点，让旅客在需要行动时得到相应指引。 # 4.核心需求，把对话接到真实订单上 我们与客户梳理的重点，是让智能客服在现有业务流程里办事。旅客继续使用熟悉的企业微信，订单仍在原有小程序中管理，客服无需要求客户迁移到一个新的沟通入口。 系统需要理解文字和图片消息，查询价格与订单，关联客户会话；返程信息收齐后，先请客户确认，再更新订单。小程序状态变化时，系统要找到对应客户并发送通知。遇到专属服务、信息冲突或需要人工判断的情况，还要能把对话交给客服。 这些要求决定了方案的组织方式。我们以订单标识关联用户、会话和业务状态，并按履约阶段推进对话。客户重新发来消息时，系统结合已有信息继续处理，减少反复询问同一组资料。 ![图片]() 以标准停车接机订单为例。图中服务节点与系统的 8 个会话阶段不是同一套划分；补款仅在需要时发生。流程示意，非线上产品截图。 # 5.从看懂截图，到核验订单、确认后回写 客户不一定会按表单格式描述问题。有人发送订单截图，有人提供车牌或航班图片，也有人分几条消息补充同行信息。智能客服先从文字与图片中提取查询线索，再通过小程序接口核验真实订单和服务类型。 截图识别和订单核验各有职责。图片帮助系统理解客户在说哪笔订单，订单是否有效、目前处于什么状态，仍以订单系统返回的信息为准。信息不完整或存在歧义时，系统继续确认，不用模型推测替代业务记录。 返程阶段，系统收集航班、人数和行李等必要信息，整理后请客户确认，再回写小程序。这样，聊天中的信息可以进入后续接机流程，后台人员也能依据同一份订单记录继续工作。入场路线视频与班车预约图片作为服务指引发送给客户，帮助旅客完成入场或预约。 ![图片]() 图片提供线索，接口核验订单，客户确认后更新信息。系统理解文字和图片，路线视频用于发送指引。流程示意，非线上产品截图。 # 6.订单状态变化后，主动把下一步告诉客户 项目接通了小程序订单事件与企业微信消息。小程序发出出行、返程或完单事件后，系统根据订单定位会话，再发送该阶段的通知。需要补款时，客户收到提示并回到小程序支付。 接机阶段保留了原有人工调度。后台人员完成司机派单后，系统同步派单结果，将司机信息及业务后台提供的定位链接告知客户。AI 不选择司机，也不生成司机位置或代替付款。 这些通知让服务从被动回答延伸到按订单主动跟进。客服少了一部分查询后再转发的工作，原先尚未提供的主动提醒也有了系统承接的方式。通知能否到达，仍依赖订单事件、客户绑定和渠道发送等环节正常工作。 ![图片]() 提醒由小程序订单事件触发，系统负责定位会话与发送消息。现场履约、派单和支付仍由既有系统与人员完成。流程示意，非线上产品截图。 # 7.三条业务线各有规则，复杂情况由人工接手 系统为停车接送、自助停车和班车分别配置流程与规则，增值服务在所属业务中继续分流。班车客户可以收到预约指引，自助停车客户按取车规则处理，部分专属返程服务保留人工负责。 需要人工判断的诉求会通知员工。人工接管通知成功后，系统暂停 AI 回复，避免客户同时收到两套答复。处理结束且满足恢复条件时，再结合会话摘要继续服务。监控告警与人工接管分开处理，发出告警不等于已经有人接手。 人工客服因此保留对复杂订单和特殊服务的控制权。系统承接规则清楚、信息可核验的常规跟进，司机调度和需要现场判断的工作继续由人负责。 ![图片]() 三条业务采用各自适用流程。人工接管、暂停回复和恢复对话都有相应条件。流程示意，非线上产品截图。 # 8.首期约 12 周，围绕现有业务完成接入 首期建设从需求与流程梳理开始，明确每条业务线需要哪些信息、由谁确认、在哪个节点通知客户。随后设计企业微信接入、用户与订单绑定及小程序接口，推进订单查询、信息回写和事件联调，再完成阶段对话、媒体指引、人工接管与生产部署。 按客户提供的项目口径，首期约 12 周，于 2026 年 6 月完成，之后依据真实运营反馈持续迭代。交付重点覆盖业务规则、系统接口与客服分工，而不仅是配置一组问答话术。 技术方案采用业务服务与 AI Agent 两层架构。业务服务负责消息接入、多业务路由、媒体收发及订单事件；AI Agent 负责分阶段对话，通过限定的工具查询和更新订单。核心技术包括 FastAPI、LangGraph、PostgreSQL、企业微信渠道接入与小程序 API，配套对象存储、容器部署和运行观测。 # 9.项目带来的改变 目前项目覆盖三条业务线，具备八个会话阶段的管理能力，并将咨询、订单核验、行程收集和事件通知连接到原有订单系统。客户可以在聊天中完成必要的信息确认，后台保留业务记录与调度职责，客服能够在需要时接管对话。 这次交付包含两部分价值。已有的常规跟进获得系统支持，一些此前未开展的主动服务也得到补齐。项目尚无可用于公开比较的响应时长、人工成本或漏发率统计，因此本文不把新增能力换算为效率提升百分比。 对于同样通过企业微信接待客户、在另一套系统管理长周期订单的企业，这个案例展示了一种可参考的接入方式。先理清订单节点与人工职责，再让 AI 在可核验的信息和明确规则内持续跟进，业务人员仍然掌握现场服务与复杂问题的处理。 ## 继续探索 [全部案例]() [!\[图片\]() ### 水里有鱼 AI 漫剧生产平台 从剧本策划、素材管理到分镜制作与后期输出，水里有鱼为个人创作者和专业团队提供统一的 AI 漫剧工作空间，让不同岗位围绕同一个项目有序交接。]() [!\[图片\]() ### 叮咚找房智能服务方案 在40 万套真实房源中，找到适合一个人的家，往往要理解筛选条件以外的需求。到家了与 Tokenmap 词元映射共同打造叮咚找房，将自然语言找房、房产业务咨询与经纪人客户服务连接起来，让用户从一句话开始寻找合适的房子。]() [!\[图片\]() ### 法普 AI 法律咨询小程序 法普AI是一款面向日常法律问题的领域AI助手。我们围绕客户的法律知识库与既有业务，搭建微信小程序中的知识检索与AI问答方案，将专业内容、场景提示词和分段回答结合起来。用户可以从自己的具体情况出发，获得有法律知识参考的初步说明，再沿着延伸问题了解相关事项，查看后续法律方案入口。]()