80 lines
7.2 KiB
Markdown
80 lines
7.2 KiB
Markdown
|
---
|
|||
|
|
title: 运营调研 2026-03-04
|
|||
|
|
mdate: 2026-03-18 20:24:34
|
|||
|
|
mdevice: iPad
|
|||
|
|
doc_id: cb7639c436284d03aa5c1aeaadd0bb81
|
|||
|
|
date: 2026-03-18 20:23
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
# 运营调研
|
|||
|
|
|
|||
|
|
> 时间日期：2026年3月4日
|
|||
|
|
> 地点：福田区永东办公室
|
|||
|
|
> 调研人员：【空天】马卫东、李远祥、张钦贵、何高棋、冯汉栩
|
|||
|
|
> 甲方人员：【永东】Paul、票务部、销售部、客服部、电脑部相关人员
|
|||
|
|
> 调研方式：会议讨论+原系统演示方式
|
|||
|
|
|
|||
|
|
## 1. 调研内容
|
|||
|
|
业务范围：售票、排班（加班）、检票、客服（退票、停运）等方面
|
|||
|
|
> 本次调研尚未涉及财务、车务两个核心部门
|
|||
|
|
### 1.1 主要流程
|
|||
|
|
目前永东几个核心业务的流程
|
|||
|
|
#### 1.1.1 常规班车业务流程
|
|||
|
|
**基本业务流程：** 排班—> 售票—> 派车—>检票—>运输
|
|||
|
|
- 排班：提前一个月排班。班次会设定时间、线路、上下车站、可售票数和票价。
|
|||
|
|
- 售票：排班完成后即可售票（即乘客提前一个月可购买车票）。票种多样（如成人、老人、儿童、婴儿、行李票），对应不同的价格。可叠加优惠券（通过抖音获得）进行购买。售票方式多样，小程序、服务号、自助机、现场 TVM 机、PC 端等。
|
|||
|
|
- 派车：由车务部根据售票的情况进行派车。一般是发车前一天指定车辆和司机。（需要跟车务部确认）
|
|||
|
|
- 检票：由现场站务人员进行检票上车。跨境线路会有两段检票（在后端会记录检票的状态）
|
|||
|
|
- 运输：根据班次指定的线路进行，有固定的上下站点，上下站点有可能动态调整，例如施工封路、临时管制等。
|
|||
|
|
|
|||
|
|
#### 1.1.2 加班车流程
|
|||
|
|
加班名词解释：当某一个班次余票到达一个阈值，需要对该时段临时增开班次。加班需要站务、票务、车务同时配合。
|
|||
|
|
**基本业务流程**：余票监测—>站点票数统计—>发起加班—>增加班次—>启动售票—>调度车辆
|
|||
|
|
- 余票监测：一般由线路始发站的站务人员进行监测（不断刷新后台售票系统），余票低于10张，可触发加班机制。
|
|||
|
|
- 站点票数统计：始发站站务人员统计各站点的上车（购票）人数，来确定加班车从哪个站点首发（加班车不一定由原来的班次的始发站发出，由售票最多的站点开始发车）
|
|||
|
|
- 发起加班：站务人员根据监测和统计结果，向后台（没有明确哪个部门）请求加班。（目前是向电脑部文仔发起，因为需要即时排班，暂时没有了解到是否需要审批）
|
|||
|
|
- 增加班次：排班人员根据反馈情况进行加班，加班涉及到始发站点、可售票站点、上下站点的设置。加班号一般为同时段班次名称后加英文字符，例如班次号+b
|
|||
|
|
- 启动售票：车务部确认是否能派车后，发布班次，指定可售票数和票价（票价可能会作调整）
|
|||
|
|
|
|||
|
|
## 2. 存在的问题
|
|||
|
|
|
|||
|
|
### 2.1 线路设计问题
|
|||
|
|
- 原系统采用最早采用一段线路设计方式，即起【始点-->终点】进行设计，虽然实际运营过程中也涉及到下车过关的问题，但过关后仍然上同一辆车，造成浪费。（现在的运营模式是乘客在口岸过检后，乘坐到湾区其他城市，重新安排新的车辆）
|
|||
|
|
- 虽然后续加入了两段设计，但也是在原来的基础上分成两条线路，在检索上存在重复问题。
|
|||
|
|
- 跟线路相关的站点班次，需要实行各站点尤其是在口岸处的乘客统计，以作为调度的依据，决定加班和派车。
|
|||
|
|
|
|||
|
|
### 2.2 排班问题
|
|||
|
|
- 排班效率过于低下，操作比较复杂，缺乏高效率的工具辅助。
|
|||
|
|
- 一键排班功能不好用，树状目录的操作方式对信息过滤和多选并不友好
|
|||
|
|
- 加班的操作，需要重复一次排班的操作。
|
|||
|
|
- 加班监测需要由线路始发站站点人员进行手工统计（每个班次、每天均需要进行监测统计），并没有系统辅助或自动计算，统计数值需要从购票系统查询并从余票-->购票-->检票（上车）的转换
|
|||
|
|
|
|||
|
|
### 2.3 票务问题
|
|||
|
|
- 缺乏动态调价的操作，对票价进行修改需要针对每一班车进行调整，操作繁琐并重复
|
|||
|
|
- 站务人员使用 TVM 机进行补票（帮助乘客现场购票），需要同时配备几个机器（手机、TVM、八达通终端、Post 机终端），并指向【现金支付】，但埋数时站务需要重新整理各种支付方式对应的金额，工作繁琐。
|
|||
|
|
- 支付处理等待时间过程。尤其是通过银行系统支付，下订单后【等待支付】需要 15 分钟，车票被锁定，若不处理，锁定的票不能及时回仓（在香港，车辆大概 20 分钟一班，长时间锁票导致资源浪费），希望能缩短等待支付的时间。
|
|||
|
|
- 快捷购票问题。主要集中在购票界面，如小程序/自助机，操作步骤较多，希望能缩减一些操作，提升效率。
|
|||
|
|
> 突出表现为自助机，目前已经做一些改进，门店机器默认只能选择该门店对应的站点作为购票起点，减少了一些操作。
|
|||
|
|
- 放票设置。目前还没有能针对时段、代理商等进行放票比例或者数量的设置。
|
|||
|
|
|
|||
|
|
### 2.4 检票问题
|
|||
|
|
- 检错票。几种检错票的情况：提前检票，后续班次的票被本班次检票；回程票当做出发票提前被检，导致回程时票不能检；
|
|||
|
|
- 检票 App 容易选错班次，导致检票出错（检票 App 的设置流程不友好导致）
|
|||
|
|
- 无法检票。几种情况：口岸处信号不好，导致工作人员无法检票；大型活动如演唱会散场，基础带宽不够，导致乘客无法调出电子票或工作人员无法通过后台验票。
|
|||
|
|
- 不规范检票。人多时间紧张（大巴车有停靠时间要求），工作人员在明知检票异常情况不做处理，直接放行。
|
|||
|
|
- 无操作记录。没有记录检票门店（或检票员）信息，出现问题无法定位责任所在。其原因是检票员使用的是门店/站点的手机进行操作，所有检票员用的同一个站号，后台也没对门店进行区分，属于系统性问题。
|
|||
|
|
|
|||
|
|
### 2.5 退票问题
|
|||
|
|
- 责权声明不够明显。购票是没有明显突出退票的规则和责权，导致乘客并不知退票的代价
|
|||
|
|
- 来回票退票问题。购买了来回票，因行程、天气、管制等原因，不能取消回程的，仅退回程票（根据退票规则）
|
|||
|
|
- 没有改签的操作。
|
|||
|
|
|
|||
|
|
### 2.6 代理商问题
|
|||
|
|
- 代理商没有下级代理的概念，不能管理子代理。
|
|||
|
|
- 代理商没有报表功能，不能自行对账。
|
|||
|
|
- 架构不合理，网络代理商的接入挤占大量的系统资源，曾经导致系统崩溃。
|
|||
|
|
|
|||
|
|
### 2.6 系统问题
|
|||
|
|
- 系统没有角色、部门的概念。权限设置针对个人用户，不能有效约束用户行为，配置麻烦且。权责划分没有部门定位，尤其在多部门协作时容易出现无法追踪问题。例如，检票没有门店概念。
|
|||
|
|
- 缺少关键操作的后台记录。一些重大/危险/跨部门的操作，目前均由系统管理员（电脑部）进行操作，责任归属不明确；缺少日志跟踪对于追溯问题发生时段比较困难。
|
|||
|
|
- 缺乏内部的消息管理系统。信息流向基本上靠人工和传统通讯手段（电话、聊天软件、电子文档、纸质材料），即时性不强，数据难以回归系统进行协作和统计。
|