280 lines
19 KiB
Markdown
280 lines
19 KiB
Markdown
---
|
||
title: 需求整理（持续更新）
|
||
mdate: 2026-03-20 14:23:51
|
||
mdevice: lazy的MacBook Air
|
||
doc_id: 204168cc4c3244b992d2f7e45ca44e15
|
||
date: 2026-03-18 20:27
|
||
---
|
||
|
||
# 需求汇总
|
||
|
||
## 1. 线路与排班需求
|
||
|
||
### 1.1 线路结构优化
|
||
|
||
**现状**：原系统运营线路是单段设计，即【起点-口岸-终点】当做一条线路，没有考虑分段。跨境运营政策放宽后，售票和车辆调度不够灵活和高效
|
||
> 备注: 线路设计的合理性和存在的问题
|
||
> - 跨境运营政策放宽，可以允许两地使用不同的车辆和司机进行运营
|
||
> - 单段设计，对口岸乘客统计上效率低下，实际统计数据时效性不强
|
||
> - 多条线路的站点参与查票检索，检索速度慢，尤其是开发网上代理商接入，导致系统崩溃。目前通过限流方式初步解决。
|
||
|
||
**需求**：通过线路结构优化，提升运营效率和线路检索效率，有效接入互联网代理商，保证系统稳定性。
|
||
- 在口岸出实现有效的客流统计，便于排班调度
|
||
- 实现更灵活的线路制定，适应香港和内地两端的班次调配。
|
||
- 优化线路、班次检索，有效对接第三方售票平台，而不是限流保持稳定
|
||
|
||
**建议**：对线路进行结构性改进，强化**口岸**属性**，**以口岸作为中间平台，以优化查询统计效率，提升调度能力
|
||
- 无论班次线路一段或二段，必须具有口岸站点，不允许不经口岸的跨境站点。
|
||
- 以口岸作为平台，实行到达口岸的乘客统计，计算口岸通往各地的乘客数量。
|
||
- 二段检票需在口岸进行，否则不能进行二段检票。
|
||
- 口岸人数统计必须保留日报表，作为排班调度的依据（可持续优化）。
|
||
|
||
### 1.2 线路查询优化
|
||
|
||
**现状**：线路查询目前采用【城市—>站点】的选择模式，但由于内地城市区划变更以及港人的认知习惯，导致在城市设定时加入旧有的城市名称。显著突出在自助机操作上，多一步操作或返回操作，都容易导致现场购票排队加长的情况。
|
||
> 备注：两地认知惯性和检索效率（用户体验）
|
||
> - 城市规模大，区级行政单位多，导致站点过多，查询不利于乘客检索。例如广州作为城市，操作上应该列出广州所有的站点。
|
||
> - 港人对内地传统城区/郊区/县的使用习惯。例如番禺、顺德这些热门目的点，分别作为广州和佛山的区级单位，但港人的习惯是将其作为传统城市对待，以【市—>区/县—>站】这种多级检索方式可能导致查站困难。
|
||
|
||
**需求**：解决购票环节中两地用户的使用习惯和操作便捷性问题
|
||
- 符合港人对湾区城市和地区的传统认知
|
||
- 提供更加高效快捷的检索方式和手段
|
||
|
||
**建议**：兼顾正规的行政区域和传统地区对站点进行设置，以便进行检索。
|
||
- 站点多种绑定方式。分别绑定城市区号，例如参考国内的区号设定，并同时支持自定义地区绑定，如广州城区（越秀、荔湾、天河、黄埔、白玉区部分）
|
||
- 加入热门线路，方便在操作界面上直接点选。后期考虑通过注册用户的购票记录进行推荐。
|
||
- 加入口岸检索，方便港人直接到口岸换乘。
|
||
|
||
### 1.3 排班优化
|
||
|
||
**现状**：排班工作量大，大量的操作重复，容易出错，并且操作不友好。
|
||
> 备注：排班的常规操作
|
||
> - 单线单日排班：单个班次需要设定的内容过多，对于同一条线路的不同班次需要重新设置，重复量大。
|
||
> - 单线多日排班：一般比较固定地重复该线路的某一天的排班，除非特殊情况取消某些班次。
|
||
> 固定班次排班需要提前一个月完成，对应售票是预售一个月后的车票。
|
||
|
||
**需求**：降低排班的复杂程度，提升排班效率和准确度。
|
||
- 减少排班过程的重复操作，提升排班效率
|
||
- 规范化排班流程，减少误操作
|
||
- 对排班工具进行改进
|
||
|
||
**建议**：采用排班模板的方式，对线路进行映射，并制作排班规则进行批量排班。
|
||
- 单班模板。针对线路设定模板，例如上下车站点、票数、票价策略等，通过模板进行线路的多班次创建。
|
||
- 单日模板。设置或者选择排的单日所有班次作为单日模板，生成该线路的全天排班。可以制作工作日、休息日、节假日的模板。
|
||
- 排班规则。使用排班规则进行批量排班，例如从某日开始，连续 N 日重复应用某个单日模板。
|
||
- 票价策略。班次中包含票价策略的设定，例如节假日上浮的幅度、特殊时段的票价变动等。
|
||
- 单班修改。批量排班后可以针对单班进行修改，并有明确的指引提醒该班具有单独调整的操作。
|
||
|
||
### 1.4 一键排班改进
|
||
|
||
**现状**：原系统一键排班采用比较传统的节点树和多选框方式进行操作，使用上并不友好，容易错选。
|
||
> 备注：现有系统一键排班的操作方式
|
||
> - 节点树选需要层层展开，子节点过多时不好选择，多选（非全选）操作效率低下。
|
||
> - 缺乏检索和过滤功能，需要从 N 条线路或班次中人工选中并应用。
|
||
|
||
**需求**：提供切实好用的一键排班工具，降低重复操作的工作量。
|
||
- 改进一键排班不友好的操作，如目录树操作
|
||
- 提升一键排班的有效性和效率
|
||
|
||
**建议**：对操作进行改良，使用列表+过滤的方式进行准确操作。
|
||
- 参考上述【排班优化】，通过模板+策略的方式减少操作。
|
||
- 加入检索功能，对线路、模板、策略过多时进行检索过滤。
|
||
- 在提交前进行排班信息确认，如使用了什么模板、设置了什么策略、应用在那条线路、受影响有哪些班次，避免误操作后重排。
|
||
|
||
### 1.5 班次站点统计
|
||
|
||
**现状**：目前没有针对班次站点的统计。
|
||
> 备注：
|
||
> - 该需求是从加班和调度中引出，初步定位为服务于站务人员。
|
||
> - 用于加速[加班发起—>排班—>派车的流程]
|
||
> 班次站点统计有利于对班线的长期跟踪
|
||
|
||
**需求**：加班和运营工作的依据和辅助。
|
||
- 需要对班次站点的余票和购票情况进行统计，用作加班的依据。
|
||
- 为日常班车运营优化提供数据支持。
|
||
|
||
**建议**：将以后台自动统计的形式存在，定时对班次进行自动统计。参考下文【加班监测】内容。
|
||
- 后台服务对班次进行定时监测和统计
|
||
- 对服务加班条件的班次进行消息推送
|
||
|
||
## 2. 加班和调度需求
|
||
|
||
### 2.1 加班监测
|
||
|
||
**现状**：目前班次加开使用人工监测和调度的方式进行。由站点始发站门店人员进行整体监测（不断刷新后台票务系统），当班次余票低于一定数值如10张（各班次不一样，根据实际运营经验所得），即由始发站人员向排班人员【调配大巴部】发起申请，排班人员向调车人员【车务部】咨询是否有车，再决定是否加开。若决定加开，则需要在系统设置加开班次信息。
|
||
> 备注：目前加班的业务操作流程
|
||
> - 手动刷新查看余票，需要人工不断监测。原系统在高峰期刷新售票页面缓慢，等待时间过长。
|
||
> - 加班需要统计每个站点的售票情况，需要人工将余票转为售出票数
|
||
> - 加班车的始发站会根据本班（非加班）售票最多的站点，作为加班车的发车站点，不一定是本班的始发站发车
|
||
> - 触发加班的余票阈值不是固定的，需要根据实际经验进行调整，不是每个班次都一样。
|
||
> 目前加班的操作都是采用人工联系方式进行
|
||
|
||
**需求**：提升系统刷新余票性能，能够实现余票与售票的统计。
|
||
- 提升查票效率，减少等待时间
|
||
- 实现余票统计和售票统计的切换
|
||
> 备注：该需求属于外在需求，并不是需要沿着原系统改进，而是通过改进模式，用更好的方式替代。
|
||
|
||
**建议**：将人工监测和统计，改为【后台】按照规则自动统计并触发消息推送
|
||
- 在班次设置增加余票触发设置 N 张
|
||
- 建立后台算法，自动统计本班余票和各站点售票情况
|
||
- 通过消息机制，向负责排班的人员发起通知
|
||
- 完善车务系统，快速查询可用的司机和车辆
|
||
- 优化，去掉站务监测统计环节，缩减【调度-车务】环节所需时间。
|
||
|
||
### 2.2 口岸乘客统计
|
||
**现状**：跨境线路分为两段，乘客需在口岸下车，通关后再重新上车（不一定是原来的那一辆车）。实际调度时需要根据两地在口岸的乘客数量来匹配和调度车辆。因此需要加入口岸乘客的统计，用于通过实际数据来合理调度车辆。
|
||
> 备注：可能出现的几种情况：
|
||
> - 到从口岸下车乘客不定乘坐整条跨境线路，有可能到了口岸过关后选择其他交通工具，这部分可以剔除
|
||
> - 在口岸下车的乘客有可能再次选择在口岸站点买票乘坐永东的车前往内地城市（在香港就近没买到直通票，到口岸曲线操作）
|
||
> - 单边有多条线路多个班次指向同一口岸，但去往不同的内地城市，需要根据到达口岸的时间进行分类统计，优化调度。
|
||
> - 单向不断加班，导致另一侧同样需要增加运力。
|
||
|
||
**需求**：针对两地乘客数量匹配的问题，需要精准计算和匹配，合理调配车辆。
|
||
- 两地乘客在口岸进行换乘，多路汇入和多路输出需要在一个时间点内进行匹配
|
||
- 根据统计数据进行车型和班次的调整
|
||
- 加班存在的时候，乘客数据属于动态变更，需考虑变更后的跟踪和调整
|
||
- 会存在因交通原因晚到的情况
|
||
|
||
**建议**：后台程序加入实时统计，分时间和目的地进行报表和结果输出，并提醒是否增减运力和匹配车型。类似【加班监测】的模式。
|
||
- 通过口岸 ID 和到达口岸的时间进行匹配和统计
|
||
- 按照目的地城市和终点进行分类输出。
|
||
- 建立适当的规则进行消息提醒，避免人工监测数据。
|
||
- 可在司机端 App 加入动态跟踪，预计车辆到达口岸的时间
|
||
|
||
### 2.3 快捷加班
|
||
**现状**：加班需要重新创建班次并填写相关的参数，操作繁琐。
|
||
> 备注：加班班次规则和操作：
|
||
> - 现时的加班操作相关与新建一个班次，并将班次号与原班次进行递增，如原班次+b。
|
||
> - 工作量与重新创建一个班次无异，操作步骤过多。
|
||
|
||
**需求**：减少在系统设置加班的所需的操作，符合加班的班次命名
|
||
- 优化加班的系统操作
|
||
- 建立加班班次的命名规则
|
||
|
||
**建议**：加入【一键加班】功能
|
||
- 原班次的基础上增加快捷键，实现一键加班，复制需要加班的班次，并设置班次名称、首发站（可根据统计数据自动指定）、票数等参数。
|
||
- 在操作界面上加入加班提醒，并在可原班次信息上加入【可加班】的标识。
|
||
- 参考原系统的人工命名规则，在开通加班班次时自动应用规则。
|
||
|
||
## 3. 票务需求
|
||
### 3.1 动态票价
|
||
**现状**：实际运营是有实施动态票价，但系统中没有能设置动态票价的策略。
|
||
> - 调价需要在系统中单独选择某些班次进行调整，并在排班的时候完成
|
||
> - 调价也有一些快捷操作，例如从某天开始连续多少天进行整体调价
|
||
> - 调整期结束后，需要重新设置为原来的价格，会切换比较复杂
|
||
> - 没有灵活的调价方式，例如针对高峰期、大型节假日自动调价
|
||
|
||
**需求**：需要灵活的动态票价方式
|
||
- 常态调整，工作日和休息日的价格调整
|
||
- 高峰期价格调整，针对当前的高峰时段进行价格调整
|
||
- 针对性调整，针对大型节假日、大型活动进行调整
|
||
- 调价结束后自动恢复原价
|
||
|
||
**建议**：建议采用增加票价策略功能，在排班时应用具体调价策略来实现
|
||
- 基础线路具备【基础价】属性，并分段式计价，作为所有该线路所有班次的计价标准。
|
||
- 票价策略。使用票价策略的在【基础价】的基础上进行叠加计算。
|
||
- 班次可以同时叠加多个票价策略，来实现灵活的调价。
|
||
|
||
### 3.2 支付需求
|
||
**现状**：目前主要的支付方式
|
||
- 港币支持：八达通（mPay）、信用卡、微信及支付宝（中银香港）
|
||
- 人民币支持：微信及支付宝
|
||
- 八达通和信用卡有专门终端进行收款，自助机也集成八达通支付功能。
|
||
|
||
**需求**：新系统需要对接之前已有的支付方式
|
||
|
||
**建议**：独立模块进行支付对接。
|
||
- 客户端的支付可直接调用接口，如微信、支付宝、银行卡
|
||
- 硬件端现场支付，如八达通、post 机之类，尽可能找第三方平台进行集成，并提供相应 API，不建议采用硬件协议进行对接。
|
||
> 更改终端设备均需要重新开发，并且需要设备服务上开放授权，一般来说金融机构会有自己的闭环，不会开放终端接口。
|
||
> 需要永东信息化部门尽快选型
|
||
|
||
### 3.3 支付等待处理
|
||
**现状**：银行等待支付时间为15分钟，等待时间过长，导致票被锁定。
|
||
> 备注：等待支付的情况
|
||
> - 购票用户在使用银行支付时，中途离开，导致长时间内没支付
|
||
> - 竞争对手或用户恶意 Hold 票行为
|
||
> 根据调研情况，香港班次大概 20 分钟一班，15 分钟的 Hold 票行为导致资源浪费
|
||
|
||
**需求**：缩减等待支付这个时间，及时释放车票
|
||
|
||
**建议**：可以通过以下手段进行缓解
|
||
- 与银行联系，是否可以提供接口进行修改这个等待的时间。
|
||
- 后台对订单进行时间控制，超出指定时间（如 5 分钟）不支付，强行取消订单并释放车票
|
||
- 尽量减少一张订单购买多张票的行为（或者设定一个订单最多只能购买 5 张票），以降低锁定的票数
|
||
|
||
### 3.4 TVM 替代方案
|
||
**现状**：TVM 机目前主要用于门店站点为乘客购票并打印纸质票。TVM 目前存在以下的一些问题：
|
||
- 只能买票和打票，基本上不提供完整的支付功能，如支持微信和支付宝，不支持八达通和银行卡，需要配合其他支付终端使用。
|
||
- 站务人员需求携带多个设备在现场售票。突出表现在口岸（无电接入，不能部署自助机，只能靠 TVM）、葵芳站这类门店与上车点分开，难以现场购票。
|
||
- 不对外开放接口，应用不再更新，后续支持比较困难。
|
||
- TVM 没能区分乘客的支付方式，所有的支付全部按照现金【代号】进行记账，站务在埋数时需要对当天的 TVM 支付情况进行分类整理。
|
||
|
||
**需求**：系统和站务需求比较突出
|
||
- TVM 的购票 App 需要支持新系统，App 需要重新开发
|
||
- 需要减少站务人员所需携带的设备数量
|
||
- 能够区分支付方式
|
||
|
||
**建议**：需要对 TVM 设备重新选型
|
||
- 能够同时支持八达通、银行支付以及无线打印功能的终端
|
||
- 购票可以通过站务手机 App 进行购票和选址支付方式，在终端机进行支付，实现支付方式分类。
|
||
- 需要电脑部配合选型新的设备
|
||
|
||
### 3.5 快捷购票需求
|
||
**现状**：主要针对现场买票的高频操作几种情况：
|
||
- 自助机快捷购票。自助售票机目前仅在香港门店部署，机器集购票、支付、打印于一身，其使用频率较高。目前港区有大量乘客目的地是到口岸，在口岸处再选择其他出行工具。而自助机上的购票程序比较传统，没有【口岸】的快捷属性，导致乘客在购票过程中还需要从站点中选择线路班次。如【油麻地】站，本身有直接到【深圳湾】的班次，但在操作上需要选择 【终点】然后查询班次，没有明显的【深圳湾】按钮让乘客直达购票。
|
||
>自动售票机现在已经能实现绑定站点购票，即乘客在自动售卖机上不需要选择起始站点，自助机上不能购买该站点以外的车票。
|
||
- 站点（口岸）扫码购票。站点粘贴的乘车二维码为永东小程序，扫码后直接到小程序原生界面。对于在站点或口岸的乘客来说，最急切的需求是购买从扫码的这个站点购票出发。尤其在口岸站点处，人多和没有售卖机的情况，乘客用自己的手机进行购票才是最优选择。
|
||
|
||
**需求**：在站点处能够实现快速购票，减少操作步骤，明确操作指引。
|
||
|
||
**建议**：乘客在站点购票的过程中，具有明确的实体和时间，即隐藏着【该乘客希望在短时间内能从这个地点乘车至目的地】，建议从站点和乘客的购票时间上做优化处理。
|
||
- 优化门店自助机程序。门店自助机绑定站点，自助机购票只能购买该站点的线路班次，且出发点为该站点，不允许选择其他站点作为出发点；增加【口岸】快捷选择，该站点线路经过的口岸在自助机上明确列出，乘客点击口岸即可进入购票流程。
|
||
- 站点二维码优化。每个站点应该有自己的专属二维码，在【后台系统】的站点管理中增设【站点二维码】功能，扫该二维码直接跳转小程序的购票流程，默认起始站点为扫码的站点，其他操作与自助机购票对齐。
|
||
|
||
### 3.6 放票设定
|
||
**现状**：目前线路班次为统一放票，即排班确定后即进入统一售票。
|
||
> 备注：售票可能存在的问题：
|
||
> - 可能存在热门班次在一个时间段内全部被抢光
|
||
> - 可能存在线上全卖光，线下无票可卖
|
||
> - 可能存在被某些平台商全部卖光，自营门店或代理商无票可卖
|
||
> - 可能在某个站点（如始发站）被抢光，其他站点无票可卖
|
||
|
||
**需求**：灵活的放票方式，如分时段放票、分站点放票、按比例放票等方式
|
||
|
||
**建议**：建立班次放票策略
|
||
- 分时段放票
|
||
- 线上线下按照比例放票
|
||
- 可先使用试点线路班次再作推广
|
||
|
||
## 4. 站务需求
|
||
### 4.1 站务协同
|
||
**现状**： 站务的工作内容较为复杂，包含如咨询、购票、支付、检票、统计、加班、埋数等流程，与之对接的是票务、排班、车务、财务以及客服的部分工作。目前站务在除使用 【检票App】外，与多部门协同仅限于使用电话、聊天软件、纸质记录等方式进行，缺乏高效率的信息流转和协同的信息化手段。与其他业务和协同如下：
|
||
- 车务协同。车务的 Order 表使用 Excel 并采用聊天软件进行分发。
|
||
- 站点统计。车辆发出后会将发车时间和站点上车人数统计数据，通过群信息方式流转至下一站点
|
||
- 站点协同。车辆缺乏跟踪，站务人员不清楚车辆到达什么地点，部分站点有进站的时间要求（如葵芳），需要提前做安排
|
||
- 排班协同。每一个站点都必须手工统计数据，并才纸质记录。需要同时刷新班次乘车信息和记录站点上车人数
|
||
- 末班车。需要统计最后还剩多少乘客，是否已经全部完成检票（有的乘客因为通关被拦截，有的可能通关时间太晚，需要暂时等待）。末班车需要利用数据做好兜底工作。
|
||
>
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|