机场热线最怕的不是咨询本身，而是航班一延误、一取消、一临时调整起飞时间，改签和退票电话就瞬间打爆。传统 IVR 是线性菜单，用户逐层按数字听提示，碰上高峰连第一层都未必点得进去；有些机场英文服务只有一条固定播报，外籍旅客听不懂菜单、国内旅客找不到英文入口，两边都堵。要解决这个问题，不能靠“再加几路人工”，而是要让语音机器人在入口层先把电话按业务方向分流，把航班号听准、方向找对、接口跑通，再把那些真的不该由机场处理的问题——比如第三方平台退票规则、航司内部舱位限制——直接送出去。
一、机场热线的真正痛点不是缺坐席，而是方向没分、号没认、接口没连
机场客服中心通常面对的不是单一问题，而是多种业务混杂在一条热线里：进港航班动态、出港航班动态、值机柜台变更、行李查询、失物招领、特殊旅客服务、中转衔接、改签退票咨询，以及外籍旅客的英文来电。每一个问题背后连接的系统都不一样，人工坐席需要先花几十秒判断来电者想干什么、航班号是什么、是国内还是国际，再去查系统、再回传结果。
这个判断环节一旦被延误，高峰期的连锁反应很明显：
热线排队：航班大面积延误时，改签退票咨询量可能在几小时内翻倍，人工坐席只能逐通接听，即使有人也在反复回答同一个航班的延误原因；
方向混乱：用户通过 IVR 按错层级、听不懂菜单、或者外文服务没有独立入口，导致本应是进港查询的来电被接进了出港坐席，坐席再转接；
航班号误识别：口语化表达的航班号（如“春秋 8816”“CZ 1234”）如果语音识别不准，查询结果直接跑偏，用户反复来电；
国际热线缺双语：外籍旅客和英语入境咨询服务往往只能在固定时段接入，非工作时间无人承接。
这些都不是“坐席不够”的问题，而是入口层的分流、识别和接口连接没有做通。
二、通话 Agent 先做业务方向分流，再跑查询，而不是替代全部服务
机场语音机器人应该做三件事，而不是去“代替机场客服中心”。
1. 用一句话分清方向：进港、出港、改签退票，还是英文服务
通话 Agent 在接听后，先用自然语言提问让用户说明来电目的。例如：“您好，请问您要查询进港航班还是出港航班？”用户回答“我接机的”“到达的”“降落时间”等表达，Agent 识别为进港查询；回答“我要飞北京”“起飞时间”“登机口”等，识别为出港查询。同时通过关键词识别或语言检测，将中英文来电分流到不同服务链路。
这一步取代的不是人工坐席的“判断能力”，而是取代传统 IVR 的多层按键导航。用户不用再听“按 1 查询出港，按 2 查询进港，按 3 英文服务……”，而是直接说出需求，Agent 在 1-2 轮内完成方向判断。
2. 用语音采集航班号并完成标准化接口查询
方向确定后，Agent 引导用户报出航班号或城市对。这里的难点不是让 AI “听懂航班号”，而是让语音识别在复杂场景下保持对字母+数字组合的识别准确率。实际落地时，需要把航班号识别作为一个专门的业务词库模块处理，包括：
字母+数字的连续读法：如“CZ3510”可能被读成“南方航空 3510”“CZ 三五幺零”“see zee three five one zero”；
航司名称的口语化简称：如“国航”“东航”“海航”“春秋”“吉祥”；
城市对替代航班号：如用户只说“北京飞上海”，Agent 需要追问具体航班或按时间排序。
识别到航班号后，Agent 通过 API 调用航班实时动态接口，获取航班状态、预计起飞/到达时间、登机口或到达口信息，再以语音播报形式反馈。如果接口返回航班已取消或延误，Agent 可以同时播报最新状态，并提示“如需改签请联系所乘航司客服热线”。
3. 复杂诉求自动转人工，保留上下文减少重复沟通
通话 Agent 不是万能的。改签退票规则涉及航司政策、舱位等级、OTA 平台退改规则、保险理赔，这些不是机场客服中心的标准服务范围；失物招领、特殊旅客服务、投诉建议则需要人工核实和跟进。Agent 的职责是：把能标准化查询和播报的先做完，把不属于机场服务范围的直接提示转接，把需要人工介入的连同已采集的航班号、问题方向、用户联系方式一并推送给人工坐席。
这样既减少了用户重复描述，也降低了人工坐席在“信息采集”环节的时间消耗。
三、国内国际双链路+中英双语不是多做一个 IVR 层，而是独立的识别和知识库配置
机场服务的中英文分流比菜单翻译更复杂，因为中英文来电的业务意图、查询习惯、知识库内容完全不同。
中英文识别的实际难点
英文来电的典型表达是“Arrival information for Flight MU518”“When does the flight from Beijing to Shanghai depart”，而中文来电常说“MU518 几点到”“北京飞上海那班飞机现在什么情况”。Agent 需要同时具备中英文 ASR 能力，并且把识别结果送到对应语言的知识库和航班查询链路中。
双语场景的配置思路
语言检测：在首轮回话中通过关键词和语法特征判断来电语言；
独立知识库：中英文分别配置航班查询话术、机场服务说明、转人工提示语；
接口复用：航班查询接口本身不区分语言，Agent 只需要把查询结果用对应语言播报；
人工技能组映射：英文来电转人工时，应直接路由到具备英文服务能力的坐席组，而不是进入通用队列再二次分配。
一个常被忽略的细节是：很多外籍旅客来电时中英混杂，或者先用中文说“你好”再切换到英文。Agent 的语言检测需要支持一次通话内的语言切换，而不是在入口层就硬切。
四、通航起飞申报场景更考验多字段采集和表单自动推送
与枢纽机场不同，通用航空公司的客服需求不是“查询信息”而是“采集信息”。通航公司需要向民航或军方空域管控单位报送起飞信息，来电内容包含公司名称、航空器呼号、飞行航线或空域、申请起飞时间、飞行高度等多个字段，且每个字段都可能出现遗漏或不规范表达。
这类场景对通话 Agent 的要求更高：
字段级多轮追问：当用户漏报飞行高度或航线描述不清时，Agent 需要追问“请确认本次飞行高度层”或“请说明飞行航线经过的空域名称”；
缺失项自动补全：Agent 根据已采集字段和常见模板，判断还缺哪些信息，在通话结束前逐项复核；
通话结束自动生成表单：采集完成后，Agent 将结构化数据推送至业务系统，生成标准起飞申报表单，供后续向空域管制单位报送。
某通航公司仅 2 个坐席、日均接近 200 通呼入呼出，如果把起飞申报这类标准化信息采集交给 Agent，人工坐席可以集中到紧急协调、异常处理和外部沟通上。通话 Agent 的核心价值不是“省人”，而是把重复性高、字段明确、流程固定的通话任务从人工手里释放出来。
五、让通话 Agent 真正跑通机场场景，需要三项前置条件
从真实项目经验看，机场和航空类热线的语音机器人落地，常见失败点不是技术本身，而是以下三个前置条件没满足：
1. 航班系统接口必须能支持实时查询和状态回传
Agent 再聪明，如果航班实时动态接口延迟超过 1 分钟，或者返回的数据字段不完整（缺少登机口、行李转盘、延误原因），播报结果就会让用户觉得“机器人说的和屏幕上看的不一样”。落地前需要确认：接口数据源是机场 A-CDM 系统、空管系统还是航司自有系统，更新频率是多少，字段覆盖是否完整。
2. 航班号识别准确率需要在部署前做方言和口音测试
机场服务的来电者来自全国各地，口音差异大。航班号包含字母和数字，字母在方言中的发音容易混淆（如“B”和“D”、“G”和“J”）。部署前建议用实际录音做一轮方言口音测试，对高频混淆项做业务词库强化，而不是上线后再补丁修复。
3. 知识库需要区分“机场能回答的”和“机场不能回答的”
很多用户打进机场热线问的不是机场服务，而是航司退改规则、OTA 平台操作、签证政策、天气导致的航班取消赔偿。Agent 的知识库必须明确边界：哪些问题可以查询并播报，哪些问题需要转人工，哪些问题应该引导用户联系航司或购票平台。如果 Agent 试图回答超出能力范围的问题，反而制造更多投诉和重复来电。
六、企业选型时该怎么评估通话 Agent 的能力
不同厂商的语音机器人能力差异很大，选型时建议重点看以下几个维度：
语音识别是否针对行业词做了优化：航班号、航司简称、机场代码、城市对等是否是内置词库，还是只能依赖通用 ASR；
是否支持中英文混杂识别和语言切换：机场场景中语言切换是常态，不是特例；
能否对接既有航班系统或业务系统：不是只做 FAQ 问答，而是能调用 API、返回结构化结果；
是否保留 IVR 兜底：建议保留原有 IVR 菜单作为用户可选路径，而不是完全替换，降低老年旅客等群体的学习成本；
转人工时是否携带上下文：已识别的航班号、问题方向、用户联系方式是否能自动推送给人工坐席，减少重复询问。
放到具体方案类型上看，如果机场已经建有呼叫中心，需要的是在原有通信底座上叠加通话 Agent 能力，重点解决语音入口分流、航班号识别、API 查询和双语适配。如果同时还涉及工单流转、投诉闭环、多机场统一客服中心，则需要评估 Agent 与工单系统、CRM 的联动能力。
在这类场景中，合力亿捷的相关方案更适合作为电话入口智能化的一类参照。合力亿捷 SYNEROW 通话 Agent 支持在保留原有 IVR 菜单的基础上新增智能咨询入口，ASR 普通话识别准确率在 98%～98.5%，含口音场景核心业务词识别准确率不低于 95%，支持 20 余种方言。某地市级气象热线曾采用类似方案，将 12121 气象热线从单向播报升级为互动式实时数据查询，通话 Agent 通过 API 调用预报、预警、实况三个数据接口。某家电品牌在 400 热线场景中实现了安装预约的自动化处理，通话 Agent 完成电话确认、信息登记、表单生成和业务系统推送，将接线人力从 20 人降至 0 人。这些案例的共性在于：标准化通话流程、接口对接和多字段采集一旦跑通，Agent 就能在语音入口层稳定承担高频任务。
七、落地建议：先做高峰分流，再逐步扩展中英双语和工单闭环
对于已有客服系统、本次重点做航班动态查询改造的机场来说，建议分阶段推进：
第一阶段（2-4 周）：在现有 96 热线或 400 热线基础上，部署通话 Agent 承接进港/出港航班动态查询，先做中文服务，保留 IVR 兜底和人工转接；
第二阶段（4-8 周）：接入英文服务链路，配置独立英文知识库和航班查询播报模板；
第三阶段（视需求）：将改签退票咨询中属于机场服务范围的部分（如值机柜台变更、登机口调整）纳入 Agent 知识库，超出范围的设置明确转人工或引导语；同时打通工单系统，把投诉、失物招领等需要后续跟进的问题自动建单。
通用航空公司则可以从起飞申报场景切入，先让 Agent 承担信息采集和表单生成，人工坐席负责复核和异常处理，逐步把通话 Agent 从“辅助录入”推进到“独立采集+自动推送”。
企业自查清单：
当前热线高峰期接通率是否明显下降，排队时长是否超过可接受范围？
人工坐席是否花大量时间在信息采集和方向判断上，而不是解决问题？
航班动态查询是否有稳定的实时接口，更新频率和字段完整性是否满足服务要求？
机场热线是否覆盖中英文双语服务，非工作时段是否有服务断档？
通航起飞申报是否依赖人工逐通记录，信息采集完整性和标准化程度是否足够？
投诉、失物招领等需要后续跟进的问题是否有工单闭环机制？
现有呼叫中心是否支持在保留 IVR 的基础上叠加通话 Agent，还是需要整体替换？
