503 lines
40 KiB
Markdown
503 lines
40 KiB
Markdown
---
|
||
title: 第一阶段需求细化及建议
|
||
mdate: 2026-03-26 16:29:59
|
||
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）、信用卡、微信及支付宝（中银香港）
|
||
- 人民币支持：微信及支付宝
|
||
- 八达通和信用卡有专门终端进行收款，自助机也集成八达通支付功能。
|
||
|
||
**需求**：新系统需要对接之前已有的支付方式
|
||
|
||
**建议**：独立模块进行支付对接。
|
||
- 客户端的支付可直接调用接口，如微信、支付宝、银行卡
|
||
- 硬件端现场支付，如八达通、pos 机之类，尽可能找第三方平台进行集成，并提供相应 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 制作，并打印分发至各站点（包含总表和站点分表）。
|
||
- 站点协同。车辆发出后会将发车时间和站点上车人数统计数据，通过群信息方式流转至下一站点；车辆缺乏跟踪，站务人员不清楚车辆到达什么地点，部分站点有进站的时间要求（如葵芳），需要提前做安排。
|
||
- 排班协同。每一个站点都必须手工统计数据（如上车人数、剩余座位数等），并纸质记录。需要通过系统的售票页面，不断刷新班次可售票数信息。
|
||
- 财务协同。对 TVM 机以【现金支付】方式，每天均需要将售票订单与支付流水号进行关联记录。目前只能通过人工处理。
|
||
- 末班车。需要统计最后还剩多少乘客，是否已经全部完成检票（有的乘客因为通关被拦截，有的可能通关时间太晚，需要暂时等待）。末班车需要利用数据做好兜底工作。
|
||
|
||
> 备注：现有系统和工具的一些改进
|
||
> - 现有的站务 App 在检票时已经做了一些实时的统计，可以方便读出对应的实检/应检人数统计、座位剩余数等信息，但这些信息依然无法自动转发，最后还是通过人工记录并转发至工作群。
|
||
> - 为了方便查询，检票 App 加入了班次查询和司机查询，但没有对站点和班次进行强绑定，属于全查询工具，即查询所有班次和所有司机。
|
||
|
||
|
||
**需求**：站务工作繁琐，同时对接乘客和多个部门，需要高效的信息协同工具。
|
||
- 解决站务与车务的信息对接问题。包括【站点班次】与司机、车辆的对接信息，提升信息的流转效率，减少纸质传递。
|
||
- 解决与调度相关的统计问题。需要避免大量的人工抄数、统计等问题。
|
||
- 解决站点【现金】购票每天对账的问题。需要将 TVM 购票的单号与支付流水号进行关联的人工操作问题。
|
||
- 解决多个站点联动的问题。需要将站点统计信息进行关联站点的实时同步，避免人工抄数后转群发的问题。
|
||
|
||
**建议**：改进现有的大量人工、易出错的协同模式，用信息化工具将站务、车务、票务、财务多项业务进行串联。
|
||
- 对现有的检票 App 进行升级改造，在检票的每个环节中进行信息协同，即【检票 App】改造为【协同 App】，【协同 App】包含【购票】、【站点班次】、【检票】、【班次跟踪】、【司机任务】等模块，对应现场售票员、站长、检票员、调度人员、司机等多个使用角色。
|
||
- 接入车务信息，将每天的 Order 纸的信息与当天的【站点班次】进行关联，在新系统处实现信息自动分发，与站点关联班次的司机、车辆能够直接在的列表信息中获得，避免全量查询班次和司机。
|
||
- 班次自动跟踪。建立系统级别的消息通讯系统，贯通【后台系统】和【协同 App】，通过各站点的检票动作进行触发，对班次信息进行统计，并将统计信息和车辆进出站信息自动同步至该线路的下游站点。
|
||
- 加入购票功能，以取代原有的 TVM 机，减少现场工作人员设备的数量，实现【车票订单】的分类，减少人工对账的工作量。
|
||
|
||
### 4.2 乘车检票需求
|
||
**现状**：检票的问题主要出现在提前检票、检票错票、二段检票、站务选错班次、员工坐车检票等情况。
|
||
- 提前检票：由于乘客早到，希望能够早点出发，在站务确定还有剩余座位时给与提前检票。一般发生在直接到口岸的乘客。
|
||
- 检错票：乘客在出发时先检了回程票，导致回程时无法检票。
|
||
- 二段检票：乘客购买的跨境票，在二段检票时没有在对应的班次上检票（出行目的地时是一致的）。
|
||
> 以上这几种情况均为在检票上没有对票进行严格限制，或者基于现场需要快速检票快速疏导乘客给与的酌情权。在检票不通过的情况下也允许乘客上车，这是系统出现大量【扫票异常】的主因。
|
||
- 站务选错检票班次，目前的检票 App 没有对【站点班次】做强关联，检票的班次都是先通过查询后选择确认的，这个操作容易出错。一般会发生在前几名乘客检票之后才会发现纠正，导致之前几名乘客出现检票异常。
|
||
- 员工乘车检票：内部员工均有【员工乘车码】，每天有四次免费乘车福利，在座位富余的情况下可以扫码乘车。
|
||
|
||
**需求**：解决大量检票异常的情况，适配员工乘车以及优化站务检票工具。
|
||
|
||
**建议**：员工乘车码可以根据规则进行适配，站务检票工具可以通过站点位置、时间等方式匹配当前检票班次，扫码异常情况则需求在工作规范中体现，是否给与【异常上车】的酌情权限。
|
||
- 员工乘车检票，独立与乘客检票，后台有专门的员工乘车码模块，对应检票端的【员工乘车】，并进行【班次】联动和后台自动扣减。
|
||
- 站务检票优化，检票前自动进行信息过滤，检票端对【站点】和【班次】进行强关联，通过站点位置、当前时间，自动过滤和校正【待检班次】，减少检票员操作步骤，准确跳转至当前应检的班次。
|
||
- 车票验证和异常提醒，在扫票时获取票的班次信息并与当前站点、时间进行强校验，检验通过才允许上车；若不匹配，本地记录扫票异常信息，并提供异常列表，待其他乘客上车后再做处理；每个检票端均绑定门店或站点信息，如需要酌情权，可以通过后台系统进行配置；如要处理【异常】事件，则在【异常列表】中操作，并选择【酌情原因】，所有的酌情操作在提交时均有系统进行记录，明确责任。
|
||
|
||
### 4.3 检票记录需求
|
||
**现状**：检票过程中没有记录【门店】或【站点】信息，导致无法进行责任定位。这个问题主要出现在系统中没有门店概念。
|
||
- 现行系统的权限是针对【个人】进行设定，没有【角色】和【部门】的概念，而【门店】或【站点】是有固定的手机（绑定账号）进行操作，而这个用户没有与实际检票员进行绑定。
|
||
- 人员调动导致责任难以界定。由于客流的原因，会出现 B 站点需要从 A 站点抽调工作人员到 B 站点进行检票，这种情况虽然捆绑了检票员的账号，但操作的由于没有【门店】或【站点】，在出问题的时候不能确定具体是哪个【门店】或【站点】出错，责任也无法定位。
|
||
|
||
**需求**：需要对检票的操作关联至【门店】或【站点】，有效定位操作责任。
|
||
|
||
**建议**：在系统级别对内部用户进行【角色】或【部门】的分级授权，并对检票行为进行有效记录；加入【扫票异常】的处理，明确异常处理的流程，并记录异常处理的操作责任人和部门。
|
||
- 建立系统角色权限的分级体系。从原来的针对用户授权，改为根据【角色】授权，并在针对每个内部员工加入【部门】或【岗位】的绑定，用以规范内部员工的权限。
|
||
- 细化检票记录信息。在检票的信息中加入检票员和检票门店/站点，用以门店/站点检票的记录和统计，定位权责。
|
||
- 增加扫票异常处理操作。规范扫票异常处理的范围和处理流畅，提供允许异常处理的权限和行使的选项。
|
||
- 规范人员调度流程。在人员调度前需要在系统上进行临时更改，以确保调用人员与实际工作的门店/站点的对应关系。
|
||
|
||
### 4.4 大量检票需求
|
||
**现状**：重大事件或大型活动（如演唱会）散场时，由于信号问题、撤离时间限制等原因，导致无法有效检票。导致问题的愿意主要有以下情况：
|
||
- 网络挤占严重。活动地点大量聚集人员（相对绝对数量，只有一小部分是永东乘客），导致当地基站过载，真正乘客无法通过移动基站访问系统后台获取电子车票；检票人员出现同样问题，无法连接到系统后台进行有效的验票；
|
||
- 移动信号不佳。停车点在地下停车场，移动信号覆盖弱。
|
||
- 撤场时间限制。停车点有时间要求，需要在短时间内撤离大量乘客，检票压力大，且容易出现大量异常情况。
|
||
- 乘客上错车。由于现场人多，车辆标识不够完善，会导致乘客上错车的情况。
|
||
> 目前的做法是通过购票时留的联系方式或现场提醒乘客及时截取车票图片；由于无法进行有效检票，也存在某些“非乘客”采用 PS 方式去造假票。
|
||
|
||
**需求**：需要寻求一种高效方式来解决大量检票的问题，提高乘客验票和上车的效率。
|
||
|
||
**建议**：项目后期针对大量检票的需求，引入新设备和新模式解决此类问题，大概思路如下：
|
||
- 离线验票方式：检票端事先下载对应的班次购票信息，通过本地调用来验票。主要针对纸质票、旅游App购票的乘客（旅游 App 在购票成功时自动生成二维码在本地，无需联网获取车票）、提前截图的乘客。
|
||
- 设备增补方式：通过在检票地点增加信号热点或局域网方式进行有效验票。
|
||
- 在车辆或车票上做好对应的标识，降低乘客上错车的概率。
|
||
|
||
### 4.5 加班车检票
|
||
**现状**：加班车在售票时的班次不明显，尤其是在自助机上，如果有加班的存在，会出现两个相同班次，乘客无法区别哪个是加班车；同理，在检票时，检票员也无法确认乘客买的是否加班车。
|
||
> - 目前后台系统已经在对加班车的情况进行了改进，在排班时增加了加班的标识，但没有自助机没有与之对应。
|
||
> - 口岸站点（大站点）可能会同时有两辆及以上是加班车，乘客和检票员均无法对应哪辆是加班车，因此只能直接上车。口岸返回香港的不会因为此存在大问题，但往湾区城市的车辆，是有选座的设置，可能会存在上错车而占用别人位置的情况。
|
||
|
||
**需求**：增强加班车的标识，能够在售票和检票过程中都有明确的标识。
|
||
|
||
**建议**：从系统和车辆标识上做合理的配置。
|
||
- 后台排班与前端购票、检票的程序需要信息一致，同步更新，确保乘客和检票员能够在系统各应用上保持一致性。
|
||
- 在车辆上做明确的标识，能够在外观上识别车辆是否加班，例如增加电子显示牌或某些颜色的标志牌。
|
||
- 在车票上注明加班车信息。（目前票面上已经增加了加班的班次号）
|
||
|
||
## 5. 客服需求
|
||
### 5.1 退票需求
|
||
**现状**：乘客在购票的时候大多不太清楚退票的条款，当临时需要退票时，才从客服得知退票的代价，从而引发投诉。
|
||
- 退票的条款不够明显，属于隐藏式收起，没有点开【退改说明】用户是不了解具体的退改规则的。
|
||
- 在用户订单处也没有【退改】的相应说明。
|
||
|
||
**需求**：对前端购票程序加入明显的【退改说明】，能够在购票时证明乘客已经阅读并或系统以尽到告知义务。
|
||
|
||
**建议**：可以在以下环节补充【退改说明】的显示操作。
|
||
- 在购票前弹出【购票注意事项】，其中醒目标识【退改说明】的条款，5 秒后方可手动关闭（自助机可以不加入这个功能）
|
||
- 如果有短信息或电子邮件通知购票成功，可在短信息或邮件处附录【退改说明】的链接地址。
|
||
- 在用户订单处，查看订单时，可补充退改的一些基础内容。
|
||
|
||
### 5.2 来回票不能退回程票
|
||
**现状**：购票了来回票的乘客，因特殊原因不能及时返程，需要退返程票。目前系统上没有针对回程退回程票，要么在还未出发前全程退票，如果已经出发了，不予退返程票。
|
||
> 备注：来回票是有一定的折扣优惠，如果能够退回程票，则需要按照规则进行退款，不能简单地退一半价钱。
|
||
|
||
**需求**：需要对双程票的回程部分合理退票。
|
||
|
||
**建议**：通过系统改造，明确对回程票退票的规则，并予以退回程票。
|
||
- 需要有明确的回程票退票规则约束，明确其参与退票部分的基数，例如，退票基数=双程票价-单程票正价，再用基础参与退票规则的计算。
|
||
- 系统增加增加回程退票的功能的功能，在退票前先显示规则和计算处退票的款项，乘客确定退票时才进行退票操作。
|
||
|
||
## 6. 新业务需求
|
||
### 6.1 对接自我游系统
|
||
**现状**：目前正在开着的一些旅游产品，通过【自我游】平台（Saas 平台）进行销售和订单管理
|
||
**需求**：需要与旅游 App 进行对接。
|
||
**建议**：【自我游】平台已经有较为成熟的【微商】体系，项目前期可以直接进行对接，利用其后台功能发布和推广新的旅游产品，并且对接到旅游 App 中，可在旅游 App 连接其商品信息，并实现 App 内支付和管理。
|
||
> 长期做法可以通过引流转化，逐渐将【自我游】的用户导向永动的旅游 App
|
||
|
||
### 6.2 组合产品订单需求
|
||
**现状**：旅游产品的组合订单的兑现，需要在不同的系统和界面上进行操作。例如【迪斯尼+车票】组合，需要分别兑换迪斯尼门票和永东车票，在两套不同的系统中进行。
|
||
|
||
**需求**：需要在一个界面上操作，或者在用户订单中直接选择生成，让用户能够在一个界面上清晰操作。
|
||
|
||
**建议**：在对接【自我游】系统后，用户统一在【旅游App】上操作，【旅游 App】能够与永东订单挂接，并生成车票。
|
||
|
||
### 6.3 新业务整合
|
||
**现状**：现有的一些新业务，如旅游产品、包车业务、演唱会生态等，各自分散在不同的 Saas、系统、社交工具中进行，相对比较分散。
|
||
- 以上几个业务相对割裂，业务较为专注，但没有对重叠用户进行有效转化，提供系列服务
|
||
- 业务数据上没能实现统一，没法提供统一的用户体验
|
||
|
||
**需求**：需要整合现有的多项业务，为某些【高端用户】提供一条龙服务。
|
||
|
||
**建议**：为直巴、包车、旅游产品、演唱会等业务提供统一的入口，用户在同一个入口订购永东的多项业务。建议在【旅游 App】上实现整合。
|
||
|
||
|
||
### 6.4 其他需求
|
||
新业务的其他细致需求，将在新一轮的调研中进行汇总和整理。
|
||
|
||
## 7. 服务优化需求
|
||
### 7.1 乘车提醒
|
||
**现状**：对用户的乘车提醒目前大多采用【短信息】和【邮件】方式进行提醒，均采用购票乘客预留的联系方式。乘客基于个人隐私问题，不一定留真实的个人信息。
|
||
- 没有实名制购票。尤其在香港，购票没有实名制的操作，也没有电话验证，导致难以向乘客推送乘车信息。
|
||
- 在末班车的情况下，对未检票的乘客，目前通过【站务-客服】的方式进行通知。
|
||
- 没有针对乘客的行程（如乘车时间、地点、车辆到站情况）进行提前通知。
|
||
- 大型活动下情况下，没办法提前通知乘客尽快进行车票截图，以免信号拥堵。
|
||
|
||
**需求**：需要解决乘客乘车通知问题，降低短信息资费和减少人工客服通知的操作。
|
||
|
||
**建议**：在系统中建立相关的工具和手段进行优化。
|
||
- 新系统构建【信息服务】，通过平台消息服务，默认向【订单乘客】推送订单班车信息，并减少使用短信息的频次。
|
||
- 向用户推广【旅游 App】，【旅游 App】向后台系统进行订阅行程信息，实现推送。
|
||
- 乘车指引或者活动指引可以通过【旅游 App】提供更好的体验。
|
||
|
||
### 7.2 服务评分
|
||
**现状**：目前系统中缺少与乘客互动部分，例如基础的服务评分。
|
||
**需求**：乘客结束行程，可对本次服务进行评分，帮助改进服务。
|
||
**建议**：服务评分应该以订单为准，并以完成订单（即行程结束后）才能提供。
|
||
- 在乘客端的 App 中集成评分操作。
|
||
- 配合订单、下车时间和地理围栏进行判断能否评分。
|
||
- 需要加入常见的评分选项，以减少乘客输入的操作。
|
||
|
||
## 8. 代理商管理需求
|
||
### 8.1 代理商分级管理
|
||
**现状**：某些代理商会发展自己的子代理，目前系统没有子代理的选项。
|
||
**需求**：分主代理及子代理商，能够独立设定佣金率
|
||
**建议**：新系统中优化代理商的操作
|
||
- 主代理商账号由永东进行创建，并赋予主代理商权限。
|
||
- 主代理商自行创建子代理商，并由系统默认赋子代理权限。
|
||
|
||
## 8.2 网络代理商对接需求
|
||
**现状**：网络代理商如携程、同程之类，对接永东系统之后，每次用户查询都会给系统带来巨大的压力，甚至导致系统奔溃。
|
||
> 网络代理商的体量比较大，用户的每一次查询都会在永东服务器上查询一次（不管用户是否选择永东的班次），造成服务压力大。曾经出现过因为网络代理商查票大量查票，导致服务器崩溃。 虽然后期对架构进行了调整，将对接的 API 单独出来部署在微服务上，并将微服务的带宽将至 2M，实际上是限制了网络代理商的查票，并非真实解决问题。
|
||
|
||
**需求**：对接网络代理商的同时，需要考虑并发的问题，不能影响后台系统的正常运行。
|
||
**建议**：在系统部署架构上做优化。
|
||
- 使用 Go 语言进行 API 的重构，以适应更大的并发量。
|
||
- 通过微服务和分布式部署，将并发压力分散。
|
||
- 使用同步推送+缓存方式，降低对后台服务器、后台数据库的直接影响。
|
||
- 优化查询能力，从站点、线路、班次、计价等多个方面优化查询，降低压力。
|
||
|
||
### 8.3 其他需求
|
||
代理商的其他需求，将在【财务调研】的过程中进行细致讨论。
|
||
|
||
## 9. 信息系统需求
|
||
### 9.1 系统权限设置
|
||
**现状**：目前系统的权限只能针对【用户】级别，即每个用户需要单独设置权限，没有采用【角色】、【部门】等方式进行统一管理。对用户操作权限均到【模块】级别（目前加入了【子模块】来控制），权限难以控制，并且容易出错，后期维护也相对困难。
|
||
> 目前在权限的设定方面，只能通过修改系统的模块，将原有【模块】加入【子模块】来区分。
|
||
|
||
**需求**：以下是隐式需求，
|
||
- 系统通过用户角色的方式来指定用户的权限，能够规范人群的使用权限和简化配置。
|
||
- 从【后台系统】到【前端应用】，均通过能进行权限控制。
|
||
- 从系统管理员角度，只需要管理【用户】和【角色】这重关系。
|
||
|
||
**建议**：从根本上改变系统权限的逻辑，从【模块】级别变为【接口】级别。
|
||
- 权限的细致粒度到 API 级，每个 API 均在系统后台进行登记和命名。
|
||
- API 定义为【功能】，多个【功能】构成【功能包】，一个【角色】可以同时赋予多个【功能包】，一个【用户】可以具有多个【角色】身份。
|
||
- 从系统管理员角度，只需要管理【用户】和【角色】这重关系。
|
||
- 从业务角度看，只需要关注【业务】和【角色】这重关系。
|
||
|
||
### 9.2 消息推送服务
|
||
**现状**：面向乘客服务，主要使用运营商的短信息进行通知推送；内部协同方面，主要使用社交软件和邮件进行协作。短信息服务比较耗费用，邮件推送实时率不高，社交软件不适合信息流转。
|
||
|
||
**需求**：降低信息资费消耗，提高信息实时效率。
|
||
|
||
**建议**：能够建立永东的消息服务系统，减少对运营商短信息和社交软件的依赖，实现高效规范管理。
|
||
- 消息服务系统会在项目中进行搭建，部署在后台服务器，走互联网流量，使用 MQTT 协议。
|
||
- 配合系统业务和对外服务，建立统一的【消息订阅】机制，来辅助信息流转和推送。前面内容【4.1 站务协同】和【7.1 乘车提醒】提及到。
|
||
- 需要用户端软件支持，内部信息流转使用【协同 App】进行，对外服务使用【旅游 App】进行。
|
||
> 消息推送服务的难点在于需要对【应用端】软件支持。
|
||
|
||
### 9.3 查询和统计需求
|
||
**现状**：现有系统查询和统计性能偏低，主要表现在以下几方面：
|
||
- 站务需要刷新【站点班次】信息，页面刷新较慢。
|
||
- 客服对用户订单进行查询，整体速度较慢。
|
||
- 运营报表统计，需要非常长的时间，并容易导致系统崩溃。
|
||
|
||
**需求**：需要提升查询和统计的效率
|
||
|
||
**建议**：新系统将在数据表设计、前端页面、后台工具等方面进行优化。
|
||
- 数据库设计优化。合理分表和建立数据索引，减少跨表查询和提升检索效率。
|
||
- 建立归档制度。如订单、检票记录等只保留最近3个月数据，定期迁移到备份数据库。能有效提升查询和检索效率。
|
||
- 自动统计归口。针对常用的统计方式，定期如天/周/月/季/年等，进行统计，保留统计记录，下次统计只做统计结果的合并。
|
||
|
||
### 9.4 后台用户操作记录需求
|
||
**现状**：主要表现在后台权限和操作记录缺失等问题：
|
||
- 责权不清晰。现有系统大量的后台操作均没有审批功能，直接由负责该项业务的人员直接操作，或由系统管理员进行直接操作。
|
||
- 责任跟踪困难。系统且缺乏关键操作的日志，出现问题后难以追溯根源。
|
||
|
||
**需求**：隐式需求：
|
||
- 由【业务】决定【权限】，由用户的【角色】决定功能操作。
|
||
- 系统重要的操作可追溯。
|
||
|
||
**建议**：加入审批和关键操作日志
|
||
- 审批功能。按照实际的业务流程进行提交和审批（可能会导致运营效率降低，但相对可靠，需根据实际运营进行考虑）
|
||
- 关键日志记录。例如修改权限、修改线路、班次、加班、票价等这些关键操作，记录操作用户、时间、IP 等关键日志信息，用于追溯。
|
||
- 明确权限。需要明确每一个用户的【角色】权限，在源头解决问题。
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|