eebus-docs/调研和需求/需求整理/第一阶段需求分析报告.md

title	mdate	mdevice	doc_id	date
第一阶段需求分析报告	2026-03-26 16:47:54	lazy的MacBook Air	47ee8ffd85b24aedb3269a8143104d1a	2026-03-18 20:27:00

第一阶段需求分析报告

1. 文档说明

该文档是在前两次业务调研的基础上，系统梳理了永东直巴业务中的票务、站务、客服及IT部门间的协作痛点，提出通过系统自动化升级、设备改进、权限管理重构和跨部门协作机制提升整体运营效率与服务质量，最终目标是减少人工依赖、增强系统稳定性，并改善乘客体验。

备注：该文档仅针对第一段的两次调研进行整理，主要包含线路排班、售票、检票、站务、客服等相关业务和工作任务进行。调研情况详见：《运营调研报告》和《站务调研报告》的内容。报告主要针对核心需求进行论述，细化需求和解决办法，请参看《第一阶段需求细化及建议》

2. 需求提取和分析

2.1 线路结构优化需求

2.1.1 线路结构优化需求

核心需求

• 多条线路在口岸实现精准客流统计，支撑排班调度决策 ；
• 支持灵活的线路制定，适应香港与内地两端的班次调配需求。
• 提升运营效率和线路检索效率，实现与互联网代理商的稳定对接 ；

改进办法

• 以口岸为枢纽重构线路结构，所有跨境线路必须包含口岸站点，禁止不经口岸的跨境站点设置 ；
• 在口岸实施二段检票，通过口岸客流日报表（含口岸至各地乘客数量）优化调度能力 ；
• 强化口岸平台属性，将口岸作为数据统计与调度决策的核心节点 。

2.1.2 线路查询优化需求

核心需求

• 解决港澳与内地用户在城市认知习惯差异导致的检索效率问题 ；
• 提供符合港人传统认知的湾区城市站点检索方式。

改进办法

• 采用多维度站点绑定策略：同时支持行政区域（如区号）、传统地区（如广州城区划分）和自定义地区绑定；
• 在操作界面增加热门线路快捷入口，并基于用户购票记录实现个性化推荐；
• 增加口岸检索功能，便于港人用户直接定位口岸换乘信息。

2.2 排班业务需求

2.2.1 排班操作优化

1) 降低排班的复杂程度，提升排班效率和准确度

• 采用排班模板的方式，对线路进行映射，并制作排班规则进行批量排班

2) 减少排班过程的重复操作

• 使用单班模板（针对线路设置参数）、单日模板（批量处理同一天班次）

3) 规范化排班流程，减少误操作

• 单班修改时提供明确指引，避免因参数错误导致的排班失误

4) 对排班工具进行改进

• 在票价策略中增加动态调整功能，根据实际运营需求自动更新票价

2.2.2 班次站点统计优化

1) 实现余票与售票的统计

• 通过后台算法自动统计余票和各站点售出票数，替代人工监测

2）提升查票效率

• 优化系统性能，减少刷新售票页面的等待时间

2.2.3 加班监测优化

1) 减少人工监测环节

• 减少站务人员人工监测的工作量或去掉人工统计，由系统后台进行统计

2) 优化调度与车务对接

• 完善车务系统，快速查询可用司机和车辆，减少【调度-车务】环节耗时

2.2.4 快速加班操作的需求

1）优化加班操作流程

• 增加【一键加班】功能，复制原班次参数并自动生成加班班次名称

2）建立加班班次命名规则

• 参考原系统规则（如“原班次+b”），由系统自动应用命名规则

3）增加操作提示

• 根据后台统计数据和统计规则，在操作界面加入加班提醒，并在原班次信息中标注【可加班】标识

2.2.5 增加口岸乘客统计

1）精准匹配两地乘客数量

• 通过口岸ID和到达时间进行匹配统计，输出目的地分类报表

2）动态调整运力和车型

• 建立规则自动提醒是否增减运力，司机端App加入动态跟踪功能，跟踪车辆运行节点

2.2.6 数据驱动的排班优化

1) 基础客流统计优化

• 加班班次智能触发：基于实时客流数据（如站点上车人数激增），系统自动建议或生成加班班次，减少人工判断。
• 客流预测集成：系统需接入历史客流、节假日、天气等数据，预测客流高峰，动态调整排班。(可结合排班模板实施)

2) 站务与调度协同

• 数据自动同步：系统需实时同步各站点上车人数至调度中心，自动触发下一班次或调整发车计划。
• 多站点协作机制：系统需支持跨站点数据共享，确保调度信息及时传递至相关站点。

以口岸作为跨站点统计的汇聚点，以口岸站点时间段内汇入/流出的数据作为依据，实施班次的动态调度。

2.2.7 票价定价策略需求

1）动态票价管理

• 支持常态调整（工作日/休息日）、高峰期调整、节假日/活动针对性调整，并实现调价后自动恢复原价

2）灵活放票策略

• 支持分时段、分站点、按比例放票，避免热门班次或站点被抢空 。

2.3 站务业务分析

2.3.1 设备与技术支持需求

1） 移动设备与网络覆盖

• 口岸站点需配备移动电源、热点设备（因缺电少网）
• 自动售票机部署需求（部分站点如葵芳、口岸因场地限制未安装）
• 支付终端需支持多渠道（八达通、微信/支付宝、信用卡等）

2）检票与支付终端优化

• TVM机需支持支付分类以及售票订单与支付系统单号对接（如信用卡、电子支付）；
• 检票App需简化操作流程（减少班次选择步骤、自动匹配当前班次）
• 加班班次需在自助机/检票App中明确标识（避免乘客混淆）

2.3.2 流程优化需求

1）调度与车辆管理

• 数字化调度支持：替代纸质Order表，实现班次与司机/车辆的实时绑定
• 实时车辆跟踪：支持站点监控车辆位置、发车时间（尤其需满足葵芳等站点进站时间要求）
• 末班车兜底机制：通过数据统计识别未检票乘客，确保服务完整性

2）统计与数据流转

• 自动化统计功能：替代手工记录和统计班次站点的实检/应检人数、实际乘车人数等，以及售票订单与支付单号对照等数据
• 实时数据共享：统计信息通过系统自动流转至下一站点（无需微信群传递）
• 埋数表格标准化：提供统一模板，减少人工填报错误

2.3.3 系统功能改进需求

1）检票与安全校验

• 强制校验机制：检票时自动匹配票面班次与当前班次，禁止异常上车
• 大型活动应急方案：支持临时检票模式（如演唱会散场时快速通道）

2） 退票与改签规则

• 明确退票规则：在购票界面突出显示退票政策（如来回票退票限制）
• 增加改签功能：允许乘客在行程变更时调整班次

2.3.4 权限与责任划分需求

1） 角色与部门权限

• 系统需支持角色（如站务、车务、财务）和部门（如门店、站点）划分
• 检票记录需绑定具体门店/站点及操作员信息（避免责任模糊）

2）关键操作日志

• 记录所有重大操作（如调度变更、退票处理）的执行人、时间及原因

2.3.5 用户体验提升需求

1）乘客服务优化

• 加班班次标识：在自助机、App、检票界面明确标注加班班次
• 选座功能：在内地段提供座位选择（目前仅香港段无选座）

2）站务人员操作简化

• 检票App初始化流程优化（减少重复操作），通过识别站点位置、时间日期自动处理
• 支付统计自动化：TVM机自动记录支付方式，无需人工埋数（需要支付系统支持）

2.3.6 系统集成与协作需求

1） 消息管理系统

• 内部即时通讯功能：替代电话、聊天软件等传统方式，实现信息实时同步

2） 多部门协作支持

• 车务、站务、票务数据联动：如站点班次列表与车务Order表的车辆、司机自动关联
• 班线站点数据联动：线路的班次数据能够在多个站点进行同步和联动

2.4 票务业务分析

2.4.1 购票流程需求

自助机购票优化

• 用户友好性：优化自助机界面，增加加班班次标识（如颜色/图标区分），避免乘客混淆正常班次与加班班次。 -** 简化购票流程**：自助机界面增加该站点关联的【线路】和【口岸】这些快捷购票入口，缩减操作步骤。

2.4.2 支付手段需求

1） 支付方式扩展

• TVM机升级：支持主流移动支付（微信、支付宝、银联云闪付）及八达通、信用卡，降低站务售票人员携带的设备数量。
• 自动埋数：站务售票自动记录支付方式、金额，无需人工二次对账和统计（需要支付系统支持）。

2） 支付终端整合

• 设备简化：减少站务人员携带设备数量（如整合TVM机与八达通机功能）。
• 增补网络设备：在口岸等网络不稳定场景，需要增补网络辅助工作人员售票或乘客购票。

2.4.3 退票/改签需求

1） 规则透明化

• 购票界面：明确标注退票规则（如退票手续费、不可退票场景），避免乘客因规则不清晰产生纠纷。
• 来回票逻辑：优化退票规则（如允许单程退票、改签），避免仅退回程票的不合理情况。

2） 改签功能

• 在线改签：支持乘客通过前端售票软件修改行程，减少人工干预。

2.4.4 检票流程需求

1）自动化校验

• 扫码验证：强制校验票面信息与当前班次匹配，防止异常票（如错班次）上车。
• 异常处理：系统自动拦截异常票，提示检票员处理，避免人工放行。

2）操作优化

• App简化：减少检票App初始化步骤（如自动加载当前班次、站点），避免选错班次。
• 大客流应对：在车门处设置快速扫码通道，提升效率。

3） 责任追溯

• 操作记录：记录检票员（或门店）信息，绑定检票行为，便于问题追溯。

加强权责跟踪后，有利于规范业务行为，能够杜绝大部分的异常操作和异常放行的问题。

2.4.5 系统权限

权限细化

• 角色/部门权限：按角色（如售票、检票）和部门（如门店）分配权限，避免越权操作。
• 操作日志：记录关键操作（如售票、退票、乘客班次调整等），与门店和操作员进行绑定，便于责任追溯。

2.4.6 技术改进方向

1）离线能力

• 在网络不稳定场景（如口岸）支持离线购票、检票、支付，数据后续自动同步。

2）设备整合

• 合并TVM机、八达通机、银行Post机功能，减少设备冗余。

2.5 客服业务需求

2.51. 退票规则透明化

退改规则清晰化需求

在购票流程中明确展示退票规则，确保用户知晓退改条款。

• 购票前弹出【购票注意事项】，醒目标识退改规则（5秒后可关闭）
• 在购票成功后的短信/邮件中附退改规则链接
• 用户订单页补充退改基础信息

2.5.2 来回票退程票支持

单程退票需求

支持回程票单独退票，并按规则计算退款金额

• 明确退票基数规则（如退票基数=双程票价-单程正价）
• 系统增加回程退票功能，退票前展示规则及退款金额计算

2.6 乘客服务优化

2.6.1 乘车提醒优化

1）信息主动推送

• 构建独立的消息服务系统
• 主动向订单乘客推送购票信息和班车信息
• 提供乘车指引和活动信息

2) 大型活动通知提醒

• 购票时关联提醒（及时打印或截取车票）
• 散场前信息提醒

2.6.2 服务评分系统

乘客评分服务评分

• 结合订单完成状态、下车时间及地理围栏判断评分时机
• 提供标准化评分选项

2.6.3 消息推送服务优化

降低运营商通信通信依赖（短信息），提升消息实时性和准确性

• 搭建永东消息服务系统，使用MQTT协议通过互联网流量推送，减少对短信依赖；
• 建立统一消息订阅机制，需用户端App（如旅游App）支持。

2.7 代理商管理优化

2.7.1 代理商分级管理

1）代理商层级关系

• 需支持主代理与子代理商的分级管理，并允许独立设定佣金率

2）代理商权限管理

• 主代理商账号由永东创建并赋予权限，主代理商可自行创建子代理商，系统默认赋子代理权限

2.7.2 网络代理商对接需求

1）网络代理商程序对接

• 后续票务系统需要与网络代理商对接

2）对接架构优化

• 需要考虑高并发查询
• 与运营系统隔离部署，包括计算资源隔离
• 同步推送+缓存机制降低对数据库的直接影响
• 可动态分配计算资源（云部署弹性调度）

2.7.3 其他需求

代理商的其他需求将在【财务调研】中进一步讨论

2.8 系统性优化

2.8.1 系统权限设置

建立以业务和部门为依据的权限体系

• 通过角色管理权限，规范用户权限并简化配置。
• 实现从后台系统到前端应用的权限控制。
• 系统管理员仅需管理用户与角色的关系。

2.8.2 消息推送服务

1）搭建消息服务系统（后台服务）

• 支援内部业务信息推送和流转
• 对乘客信息推送，降低对运营商的依赖

2）建立统一消息订阅机制

• 对内部业务进行统一的信息规范
• 对外提供统一的信息广播支持

2.8.3 提升查询和统计效率

提升查询和统计效率

• 优化数据库设计，合理分表并建立索引
• 实施数据归档制度，保留近期数据（如最近 3 个月），定期迁移至备份数据库
• 针对常用统计方式（如天/周/月）进行自动归口统计，减少重复计算

2.8.4 后台用户操作记录需求

1） 由系统管理员决定权限转为业务角色决定权限

• 由业务决定系统功能权限，规范每个用户角色。

2）关键操作跟踪

• 记录关键操作日志（如修改权限、线路、班次、票价等），包含操作用户、时间、IP 等信息

3. 业务关联分析

3.1 票务（含排班）与其他业务的关联及问题梳理

3.1.1 票务与排班 → 调度管理

• 关联点：排班信息直接影响车辆调度（司机、车辆匹配）和班次执行。
• 问题：
  • 调度依赖纸质Order表：车务部使用Excel和聊天软件分发调度信息，未与系统班次绑定，导致人工操作频繁。
  • 排班与调度脱节：直接映射到站务，需手工裁剪Order表信息，缺乏系统自动匹配功能，调度效率低。
  • 车辆跟踪缺失：无实时车辆位置追踪，站点无法预判车辆到达时间。

3.1.2 票务 → 检票与上车管理

• 关联点：票务数据（班次、乘客信息）是检票校验的核心依据。
• 问题：
  • 检票校验缺失：系统未强制校验票面班次与实际检票班次是否一致，导致异常扫票（如错班次）可以上车。
  • 检票操作复杂：检票App需手动选择班次、线路，步骤繁琐，易选错班次。
  • 加班车标识模糊：乘客无法区分正常班次与加班车，易引发误乘。

3.1.3 票务 → 支付与埋数统计

• 关联点：支付方式和埋数数据直接影响票务收入统计与财务对账。
• 问题：
  • 支付方式受限：TVM机仅支持现金支付，其他支付（八达通、信用卡）需额外设备，导致站务需手动埋数，增加工作量。
  • 埋数流程低效：站务需手工记录售票、金额、支付方式等信息，依赖纸质表格和微信群传递，易出错且难以追溯。

3.1.4 票务 → 退票与改签规则

• 关联点：退票规则与票务系统（如来回票、单程票）直接相关。
• 问题：
  • 退票规则不透明：购票界面未明确退票条件和责权，乘客易因规则不清产生纠纷。
  • 缺乏改签功能：系统未支持改签操作，乘客行程变更时需人工处理，效率低。
  • 退票回收问题：乘客退票有，已退的票无法重新释放进行再次销售，浪费票资源。

3.1.5 票务 → 代理商管理

• 关联点：代理商销售票务需与系统对账和资源分配。
• 问题：
  • 代理商权限缺失：代理商无法管理子代理，缺乏独立报表功能，影响对账效率。
  • 系统资源挤占：网络代理商接入导致系统崩溃，暴露架构不合理问题。

3.1.6 票务 → 系统权限与操作记录

• 关联点：票务操作需权限控制，关键操作需留痕。
• 问题：
  • 权限划分混乱：系统无部门/角色概念，权限配置针对个人，跨部门协作时责任归属不明确。
  • 操作记录缺失：关键操作（如调整票价、修改排班等）无日志记录，问题追溯困难。

3.17 票务 → 消息与协作管理

• 关联点：票务数据需在多部门（站务、车务、财务）间实时同步。
• 问题：
  • 信息传递依赖人工：调度、统计、埋数等信息通过微信群、纸质文档传递，即时性差且数据难以回归系统。
  • 缺乏内部消息系统：跨部门协作效率低，数据孤岛严重。

3.1.8 票务 → 站场设施与运维

• 关联点：票务系统依赖硬件设施（自助机、TVM、网络）正常运行。
• 问题：
  • 硬件覆盖不足：口岸站点因缺电少网无法部署自助机，依赖人工操作。
  • 设备功能局限：TVM仅支持部分支付方式，影响售票灵活性。用户订单无法关联支付单据。

3.1.9 总结：核心关联与改进方向

关联模块	关键问题	改进方向
调度管理	纸质Order表、人工裁剪、车辆跟踪缺失	系统绑定排班与调度，引入实时车辆追踪功能
检票管理	校验缺失、操作复杂、加班车标识模糊	强制班次校验、简化检票流程、明确加班车标识
支付与埋数	支付方式受限、埋数手工化	增加支付终端支持，自动化埋数数据采集
退票与改签	规则不透明、无改签功能	明确退票规则，增加改签操作入口
代理商管理	权限缺失、系统资源挤占	增加代理商子管理功能，优化系统架构
系统权限与日志	权限混乱、操作无记录	建立部门/角色权限体系，强制关键操作日志记录
消息与协作	信息依赖人工传递	搭建内部消息系统，实现数据实时同步
硬件设施	设备覆盖不足、功能受限	优化站点硬件部署，升级支付终端设备

3.2 站务与其他业务的关联及问题梳理

3.2.1 站务与票务业务

1）现场购票

• 关联模块：自助机系统、人工售票窗口
• 关联部门：车务部（提供班次信息）、电脑部（维护自助机设备）
• 问题：口岸站点无自助机（设备/电力限制），依赖人工售票（老年人群体为主）。

2）支付环节

• 关联模块：TVM机、八达通机、银行Pos机
• 关联部门：电脑部（支付系统维护）、财务部（支付数据统计）
• 问题：TVM机仅支持部分支付方式（现金、微信、支付宝），需额外设备处理八达通/信用卡支付，票务订单与支付票单需要人工关联处理，增加站务工作量。

3.2.2 站务与检票调度

1）检票流程

• 关联模块：手机App检票、现场人工检票
• 关联部门：车务部（提供班次信息）、电脑部（App系统维护）
• 问题：
  • 检票App操作复杂（需手动选择班次），易误选；
  • 大型活动（如演唱会）期间无法有效检票，存在漏检风险；
  • 检票异常（如票与班次不匹配）未强制拦截，依赖人工判断。

2）调度管理

• 关联模块：车务部Order纸、人工调度
• 关联部门：车务部（提供车辆/司机分配）、电脑部（系统对接需求）
• 问题：
  • Order纸依赖Excel和聊天软件分发，未与系统绑定；
  • 调度信息需人工传递（微信群），缺乏实时跟踪系统；
  • 末班车需统计未检票乘客，依赖人工兜底。

3.2.3 站务与统计埋数

1）数据统计

• 关联模块：上车人数统计、支付方式埋数
• 关联部门：班线门店、财务部（数据对账）、电脑部（埋数表格设计）
• 问题：
  • 手工统计依赖纸质记录和微信群传递，易出错；
  • 埋数需手动区分支付方式（如TVM仅记录现金），增加站务工作量。

2）加班车处理

• 关联模块：加班车标识、乘客识别
• 关联部门：运营部、调度部、车务部、电脑部（系统标识优化）
• 问题：
  • 售票系统没有明确的加班车信息区分（主要突出在自助机上）
  • 加班车无明确标识，乘客无法区分正常班次；
  • 口岸站点多辆加班车共存，易引发乘客误乘。

3.2.4 站务与代理商管理

代理商报表

• 关联模块：代理商对账、数据共享
• 关联部门：代理商、财务部
• 问题：
  • 代理商无子级管理功能，无法自主对账；
  • 网络代理商接入占用系统资源，曾导致系统崩溃。

3.2.5 站务与系统架构

1）权限与日志

• 关联模块：后台操作记录、角色权限
• 关联部门：电脑部（系统开发）、各业务部门（权限需求）
• 问题：
  • 系统无部门/角色概念，权限配置混乱；
  • 缺少关键操作日志（如调度、检票），责任追溯困难。

2）消息管理

• 关联模块：跨部门协作、信息传递
• 关联部门：车务部、财务部、电脑部
• 问题：
  • 依赖人工沟通（电话、聊天软件），缺乏系统化消息管理；
  • 调度信息传递延迟，影响车辆运行效率。

3.2.6 站务与站场设施

硬件设施

• 关联模块：自助机、电力/网络覆盖
• 关联部门：电脑部（设备部署）
• 问题：
  • 口岸站点因缺电/少网无法部署自助机；
  • 部分站点无空间放置设备（如葵芳站）。

3.2.7 关键问题汇总

系统依赖人工操作：调度、统计、信息传递均依赖人工，缺乏自动化支持。
设备与网络限制：口岸站点因硬件条件无法部署自助机，影响服务效率。
权限与日志缺失：系统无部门/角色管理，关键操作缺乏追溯能力。
代理商管理薄弱：代理商无法自主对账，系统资源占用问题突出。

建议后续优化方向：

• 引入自动化调度/统计系统；
• 升级口岸站点的服务设备，采用低功耗设备或者离线同步模式提供服务；
• 增加系统权限模块和操作日志；
• 优化代理商管理功能。

3.3 客服与其他业务的关联及问题梳理

3.3.1 客服与核心业务模块的关联

1）退票与改签规则

• 关联业务：票务管理、乘客服务
• 关联点：
  • 客服需解释退票规则（如来回票退票限制、退票代价）。
  • 现有系统无改签功能，客服需处理乘客改签需求（如引导至人工窗口或协商解决方案）。
  • 退票规则不明确可能导致乘客投诉，需客服协调退票流程。

2）支付异常处理

• 关联业务：支付系统、现场服务
• 关联点：
  • TVM机支付方式受限（仅现金、八达通），客服需协助乘客解决支付失败问题。
  • 支付统计需人工埋数，客服可能需处理支付数据与账单不符的投诉。

3）检票异常与乘客投诉

• 关联业务：检票流程、现场管理
• 关联点：
  • 检票App操作复杂、异常扫票允许上车，导致乘客投诉（如误乘加班车、检票失败仍被放行）。
  • 客服需处理乘客因检票问题（如无法扫码、系统故障）导致的行程延误。

4) 系统故障与服务中断

• 关联业务：系统运维、用户体验
• 关联点：
  • 系统崩溃（如代理商接入导致资源挤占）时，客服需向乘客解释服务中断原因。
  • 缺乏消息管理系统，客服需人工协调跨部门问题（如调度信息未同步）。

3.3.2 客服与跨部门协作的关联

1) 与车务部/调度的协作

• 关联业务：车辆调度、发车管理
• 关联点：
  • 客服需处理乘客关于末班车遗漏、车辆延误的投诉，需与车务部确认调度信息。
  • Order纸（纸质调度表）依赖人工传递，客服需协助乘客查询发车时间或车辆位置。

2) 与站务部的协作

• 关联业务：现场服务、数据统计
• 关联点：
  • 站务人员手工统计上车人数并通过微信群传递，客服需协助乘客查询实时客流信息。
  • 口岸站点缺电少网，客服需处理因设备故障导致的检票/支付问题。

3) 与代理商的协作

• 关联业务：代理商管理、对账
• 关联点：
  • 代理商无报表功能，客服需协助代理商处理账单核对或数据异常问题。
  • 网络代理商接入导致系统资源挤占，客服需协调代理商优化接入方式。

4) 与电脑部（IT）的协作

• 关联业务：系统权限、操作日志
• 关联点：
  • 系统缺乏角色/部门权限划分，客服需协助处理权限滥用或操作失误引发的问题。
  • 关键操作无日志记录，客服需依赖电脑部排查系统故障或追溯操作责任。

3.3.3 客服与用户需求的关联

1) 信息咨询与规则解释

• 关联业务：票务政策、支付方式
• 关联点：
  • 客服需频繁解释退票规则、支付方式限制（如八达通优先）、加班车标识缺失等问题。
  • 乘客因系统问题（如无法查询班次）需客服协助联系技术部门。

2) 投诉处理与应急响应

• 关联业务：服务质量、用户体验
• 关联点：
  • 道路临时管制，不能在原有站点上下车。
  • 突发灾害天气（如台风），班次取消。

3）服务优化建议反馈

• 关联业务：系统改进、流程优化
• 关联点：
  • 客服收集乘客反馈（如检票App操作复杂、加班车标识不清），推动产品优化。
  • 客服发现系统缺陷（如无改签功能、支付统计错误），需向IT部门反馈。

3.3.4 关键问题总结

问题类型	关联业务	客服角色
退票规则不明确	票务管理	解释规则、处理投诉
支付方式受限	支付系统	协助支付、解释限制
检票异常允许上车	检票流程	处理投诉、协调技术修复
系统崩溃与资源挤占	系统运维	向乘客解释、协调资源优化
调度信息未同步	车务调度	协助查询发车信息、协调部门
代理商报表缺失	代理商管理	协助对账、反馈系统需求
权限划分不清	系统权限管理	协助处理权限问题、追溯责任

3.3.5 优化和改进

1） 系统功能改进：

• 增加改签功能、优化检票App操作流程、明确加班车标识。
• 引入消息管理系统，实现调度信息自动同步。

2）客服流程优化：

• 建立标准化话术库（如退票规则、支付方式解释）。
• 客服与IT/车务部建立快速响应通道，提升投诉处理效率。

3）跨部门协作机制：

• 明确各部门权责（如车务部负责调度信息更新、电脑部负责系统权限划分）。
• 定期收集客服反馈，推动业务流程与系统功能迭代。

4. 核心改进与关键业务提升

4.1 核心改进方向

4.1.1 信息化协同升级

• 车务与排班协同：部门协作全面信息化。车务 Order 数据直接进入协同，参与直巴运营协同；车务部门直接在系统上将每天的 Order 直接与当天班次对照，避免人工操作电子文档和纸质文档。
• 站务与车务协同：站务与车务每天对接的 Order 纸将通过系统自动关联至对应门店/站点，门店/站点能在 App 内直接获得当天站点班次与车辆、司机对应信息。
• 线路站点协同：引入消息服务功能，在检票过程中自动统计站点的实检/应检人数、剩余座位等数据，并将次数据与班车数据（检票时间，进/出站时间等）自动同步到线路门店/站点，去除站务人工监测和统计的工作量，提升发车管理、客流统计的实时性与准确性。
• 排班与调度优化：所有的班次、客流信息统计均在系统后台完成，为固定排班和加班提供准确的数据依据；基于口岸数据的统计能为临时加班提供
• 客服工作优化：对于班车信息（准点/迟到/预计到站时间），客服能通过后台系统联动查看，无需人工联系司机（尤其在末班车情况）

4.1.2 系统架构与权限管理

• 权限划分与日志追溯：建立部门/角色权限体系，记录关键操作日志（如调度、检票），增强系统安全性与责任追溯能力。

明确权限和操作跟踪，能够对工作执行有严格的约束。以下是几个参考点：

• 操作跟踪到门店和个人：有效约束非正常检票操作，所有异常检票都会有检票门店和检票员的记录，后台可以定期跟踪异常的原因，责任到店/人，对随意操作具有威慑力；
• 异常检票放行操作，需要特殊的权限，并同样记录在后台，避免一线人员随时使用酌情权，扰乱排班和售票系统。

• 资源优化与稳定性提升：升级系统架构，避免网络代理商接入导致的资源挤占问题，提升系统抗压能力。

4.1.3 现场人工购票优化

• TVM 模式改进：用手机 App 替换 TVM，减少站务人员携带设备的数量，能够支持更灵活的支付记录（需要寻找替代的支付终端）
• 减少人工埋数工作量：通过 App 为乘客下单，可选择多种支付方式，在之后完成后通过技术手段（如相机拍照识别银行流水号）自动与乘客订单关联，减少人工埋数的工作量（方案需要进一步探讨）
• 降现金购票对账的工作量：如上述操作可行，能够大量降低财务现金对账的工作量
• 乘客退改订单跟踪：客服在面对人工购票的情况，能够有效的查询乘客的支付记录信息

4.1.4 代理商管理功能强化

• 子级管理与报表自动化：为代理商提供自主对账功能，减少人工干预，提升对账效率与数据准确性。

4.1.5 客服流程与跨部门协作机制

• 标准化话术库：建立退票规则、支付方式等高频问题的标准化响应流程，提升客服效率。
• 快速响应通道：打通客服与IT/运营/车务等部门的协作机制，缩短投诉处理周期。

4.1.6 乘客购票体验提升

• 快捷购票优化：自助机直接与门店关联，支持直选线路、口岸购票等交互，减少操作步骤；小程序/App 等方式，加入热门线路、历史购票等方式，让乘客快速选择线路
• 站点二维码： 为每个门店/站点增加【站点二维码】功能，扫码默认跳转至站点购票，减少操作；口岸站点可以张贴站点二维码，乘客可借助手机购票，避免人工购票时信息不佳需要等待的情况。

4.2 对关键业务的提升

4.2.1 运营效率提升

• 信息化协同减少人工成本：排班、调度、检票、统计等环节的自动化降低人力投入，减少人为错误。
• 资源利用率优化：系统稳定性提升后，网络代理商接入、硬件部署等资源占用问题得到控制，保障业务连续性。
• 运营数据真实可靠：系统在每个协同的环节均进行数据流转和自动统计，确保数据的实时性和真实性。

4.2.2 服务质量与用户体验改善

• 支付方式多样化、检票流程简化、加班车标识清晰，减少乘客投诉。
• 客服通过标准化话术与快速响应机制，提升问题解决效率。

4.2.3 系统安全性与合规性增强

• 权限管理与日志追溯：明确部门/角色权限，避免权限滥用；关键操作日志留存，满足合规审计需求。
• 系统稳定性保障：资源优化与架构升级后，系统崩溃风险降低，保障业务连续性。

4.2.4 代理商管理能力提升

• 对账效率与数据准确性：代理商自主报表功能减少人工对账需求，提升财务处理效率。
• 系统资源占用控制：优化代理商接入方式，避免资源挤占导致的服务中断。

4.2.5 跨部门协作效率提升

• 信息同步与责任明确：调度信息自动同步、权限划分清晰，减少跨部门沟通成本。
• 客服与IT/车务部协同：建立快速响应机制，缩短投诉处理周期，提升整体协作效率。

4.3 协同价值与长期效益

• 业务闭环优化：从票务管理、站务运营、车务协同到客服服务的全链路改进，形成高效、稳定的业务闭环。
• 数据驱动决策：自动化统计与日志系统提供精准数据，支持运营策略优化与资源分配。
• 可持续性提升：设备与系统优化后，长期运营成本降低，为业务扩展奠定基础。

5. 项目难点分析

5.1 支付系统对接

5.1.1 相关问题

支付系统处于安全考虑，有自己的一套安全闭环操作，在项目中主要有以下几方面：

• 网络平台支付：包括各类网银平台、微信/支付宝支付平台等，前端 API 可以随意调用，但后端服务必须认证。好处是能够通过前端返回支付信息，让后台系统进行数据对接。
• 收款终端机：如银联 Pos 机，自动适配各银行系统，具有联网、现场刷卡、凭证打印等功能。但终端必须银行认证和提前绑定，支付信息只能到银行后台和终端机器，无法析出与系统对接。（这就是 TVM 与 Pos 机为什么只能以现金方式支付，其操作实际上就是现金交易，只是现金直接通过收款终端进入银行账户）
• 进场交易终端：如八达通，属于 NFC 类终端，所有交易记账存在本地机器，不即时在支付后台记账，需要后期同步。好处是不需要网络支持，但缺点是完全封闭，只认机器。

5.1.2 解决思路

• 支付终端选型：尽量选择能够集成支付信息返回的终端，能够与系统在终端一级进行对接。
• 网络平台选型：可以考虑使用第三方平台，其效果如微信/支付宝，由第三方平台去解决与银行系统的认证和信息返回。

5.2 大型活动检票支持

5.2.1 存在问题

需要在网络挤占、短时段内快速检票和精准上车。涉及到几个问题：

• 网络拥堵问题：一个小区域范围内同时出现大量手机连接，基础设施（移动基站）会造成挤占，导致网络速度慢。实际乘客数量可能远低于该区域人群数量，但因为挤占原因，乘客难以通过联网获取电子车票。同样，检票也需要联网进行核票，同样会出现核票困难的问题（即时乘客使用纸质票）。
• 提前取票问题：较为便捷的方式是通过通知形式，让乘客提取对电子票进行截图，需要乘客配合（纸票除外）
• 班次标识问题： 车辆需要与班次有明确的标识和指引，不然会导致乘客检错票/上错车的情况，耽误散场时间。

解决思路：

• 推广App 购票，在购票成功时自动将车票二维码下载到本地 App，避免出行时才获取电子票
• 离线检票：检票端提前与服务器同步，在检票 App 中存该时段和地点的班次信息，有检票端 App 直接本地验票
• 信号增补：通过增补设备，将外部网路引入检票现场，服务出票和检票。