609 lines
38 KiB
Markdown
609 lines
38 KiB
Markdown
---
|
||
title: 第一阶段需求分析报告
|
||
mdate: 2026-03-26 16:47:54
|
||
mdevice: lazy的MacBook Air
|
||
doc_id: 47ee8ffd85b24aedb3269a8143104d1a
|
||
date: 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 直接本地验票
|
||
- **信号增补**：通过增补设备，将外部网路引入检票现场，服务出票和检票。
|
||
|
||
|
||
|
||
|