不少城市上线95128电召平台之后，会遇到一个相似的反馈：电话能打通，市民却抱怨"叫了没人接单"。号码本身不是问题，问题多半出在系统与运营的衔接上——派单规则没配好、司机端没人用、数据没和地方监管平台打通。下面按一套完整电召系统的构成、调度规则、司机端运营、数据对接和验收指标逐项说明，供出租车公司的信息负责人和运管单位的项目经办人参考。

一、电召系统要解决的不只是"接电话"

热线如果只做到"记录地址、人工播报"，那它只是一个呼叫中心。电召的价值在于把路上分散巡游的运力变成随时可调度的资源。

真正需要被覆盖的场景通常有几类：老年人和不会用手机软件的乘客；机场、火车站、客运站的集中疏散；雨雪天气和夜间；医院、政务大厅这类固定出行点。这些场景的共同点是乘客不会提前很久规划行程，对"多久能来车"很敏感。

所以判断一套系统是否合格，先看它能不能回答三个问题：附近有哪些空车、按什么规则选车、司机不来怎么办。三个问题都有明确机制，才算电召；只回答第一个，只能算叫车热线。

二、一套完整系统由五部分组成

多渠道受理。95128热线是基础入口，通常还要配微信公众号或小程序、乘客端APP、站点自助终端，有的城市会向地图平台开放接口。受理端要能识别来电号码、自动带出历史地址，老人多次叫车时不用重复报门牌。

调度引擎。负责订单池管理、候选车辆筛选、派单或抢单、路径与距离计算、超时重派、预约单提前推送。这部分是系统的核心，后文单独展开。

司机端。接单、导航、状态上报、语音播报。车载环境下必须做到语音播报加超大按钮，司机在行驶中不能靠看屏幕操作。

企业管理端。车辆与司机档案、班次排班、接单考核、投诉流转、营收对账。没有这一层，调度只能靠电话喊，规模一上去就乱。

监管与数据。订单全量留存、GPS和营运状态上报、服务质量信誉考核数据。这块不是可选项，地方交通运输主管部门一般有明确的接口要求。

三、派单规则决定系统成败

派单策略通常有三种：距离优先、空驶里程优先、公平轮转。单一策略都有明显短板。距离优先会让热门区域的司机连续接单，郊区司机长时间无单；纯公平轮转又会出现派给三公里外的车，乘客等太久。

实践中比较稳妥的做法是分层筛选：先用"空载状态+直线距离"圈出候选车辆，再按司机当日接单量做公平修正，最后结合方向是否顺路。规则要能按区域、时段配置，机场和市区不该用同一套参数。

纯抢单模式要谨慎。司机天然会挑长途单，短途单在订单池里反复流转，最后乘客取消。如果做指派，必须给司机提供拒单理由选项——路堵、交接班、车辆故障、地址无法到达。没有理由入口，司机只能用挂断和关机来对抗，后台拿到的数据全是失真。超时重派建议做成阶梯，比如30秒未响应进入下一轮，60秒扩大范围，避免订单挂死。

预约单和实时单要分池处理。预约单提前15到20分钟推给司机，太早推送司机会忘，太晚推送来不及。

还有几个容易漏的边界：跨区订单怎么算、机场蓄车池的排队规则、交接班时段是否暂停派单。这些规则的细节往往在验收时才发现没定义。

四、司机装了不用，问题出在哪

司机端的实际使用环境比想象中差：手机型号杂、支架不稳、供电不足、流量不够，中老年司机对弹窗和授权提示没耐心。几个具体做法：语音播报必须能关闭重复播报；接单按钮放在拇指可及的位置；低版本安卓要能跑；首次使用由车队队长现场陪同接一单，比开大会培训有效得多。

更关键的是收益可见性。司机愿意用，通常是因为三件事清楚：这一单能挣多少、拒单会怎样、月底考核怎么算。系统里要把接单量、电召单占比、乘客评价放进司机能自己查的页面，而不是只在管理层报表里。

高峰期还要做限流。同一个司机同时收到多个渠道的推送，结果一定是全部忽略。

五、数据对接里最容易出问题的三条线

监管平台对接。订单、GPS、营运状态的上报字段和频率按当地要求执行，常见是10到30秒一次。有的地区要求订单号规则与监管平台一致，前期不确认，后期改造成本很高。

计价与发票。电召服务费收不收、收多少、怎么在计价器上体现，各地政策不一样，必须在项目启动阶段和当地运管部门确认清楚，不要等上线后被投诉再处理。

支付与对账。车载二维码、聚合支付、企业月结几种方式并存时，账目要和司机营收逐笔对上。对账逻辑不清楚，司机第一个月就会不信任系统。

如果接了地图或微信等第三方渠道，还要防止同一乘客的订单从两个入口重复进入调度池。

六、部署方式与硬件清单

本地部署适合数据不出本地、等保要求明确的项目；云部署上线快、扩容方便，但要确认当地对营运数据存储位置的要求。两种方式都要准备降级方案：断网时转人工坐席，断电时能靠短信回执兜底。

呼叫中心坐席数量按呼入峰值估算，不是按日均。一般可以参考每坐席每小时处理20到30通电话来测算，再留20%余量，具体还要看当地话务习惯。

硬件包括车载智能终端或行车记录仪、调度屏、通话麦克风、流量卡。老车改装要提前确认取电位置，避免接在点烟器上导致长期断电。

七、验收阶段看哪些指标

功能验收容易走过场，建议把下面这组指标写进验收文档：电话接通率、平均等待时长、派单成功率、司机接单率、订单完成率、取消率及原因分布、投诉率、司机周活跃率、乘客复叫率。

其中司机周活跃率最容易被忽略。注册司机数量说明不了任何问题，一周内实际接过单的司机占比，才是系统是否被真正使用的证据。复叫率则反映乘客体验，一个月内重复使用电召的乘客比例低，说明首次体验出了问题。

八、几个常见的坑

只验收功能不验收数据，上线后发现订单查不到、GPS漂移，追溯困难。号码宣传不到位，车身、发票、站点、社区都没有95128的提示，市民根本不知道有这个渠道。把电召按网约车的思路做，忽略巡游出租车的合规边界，比如车辆和驾驶员资质、揽客方式。计价和结算规则没提前谈，运营中期返工。最根本的一条是没有人负责运营——系统交付即闲置，是这类项目最常见的结果。

九、选型时可以问供应商的问题

• 在哪些城市跑过同等规模的项目，能否安排实地看现场
• 派单策略能不能按区域和时段配置，改规则是否需要停机
• 司机端对低版本安卓和老旧车载设备的支持情况
• 当地监管平台对接有没有现成模板，改造周期多久
• 断网、断电、服务器故障时的降级方案是什么
• 运营数据归属谁，能否完整导出
• 上线后的运维响应时间和驻场安排

这些问题问下来，基本能判断供应商是做过项目还是只做过演示。

电召系统本身不复杂，难的是把调度规则、司机习惯和监管要求捏到一起。项目启动前把边界条件列清楚，比上线后反复调参数省事得多。