只凭手续费和行情「承载到现有站点」容易发生的问题
在公共部门的票务销售数字化中，早期阶段就因为「便宜 / 有实绩 / 其他公共机构在用」的理由，讨论能否承载到现有票务站点或销售平台的情况很多。
问题是承载平台类型与方案不符的情况。例如以下组合：
- 想用单次活动销售站点来运行振兴券·店铺支付方案
- 需要多票种·自定义结算，却只用全国型电子商品券服务一体运营
- 想在多个窗口和Web销售设施入场券，却勉强归入单活动销售页面
表面合同单价虽然降低，但现场窗口·事务局·参加商家的手工作业(重复录入、异常处理、结算转记)增加，数字化原本要减少的负担又回来了——这样的案例并不少见。本文采取在比较费用前，对齐谁·做什么·怎么结算，由此决定类型的顺序。
先写出来｜现场流程和4种方案模式
纸质预售券、窗口现金、振兴券发放——公共部门的票务周边，每个方案的「谁卖票(销售主体)」和「销售额给谁(结算对象)」都各不相同。
票务数字化的讨论开始启动的场景例如：
- 活动·物产展 — 限时付费入场、指定席·自由席销售
- 振兴券·商品券 — 高级商品券·地区货币型发放·店铺支付
- 博物馆·设施入场 — 常设展·特别展日期指定券、窗口与Web并用
- 周游·交通套餐 — 周游通票或交通+设施套餐(与交通运营商的联合方案)
针对每个方案，请将以下3点写在1页上(这是后续类型选择的基础)：
- 谁卖票(公共机构、旅游协会、设施、活动主办方等)
- 现场谁确认入场(窗口、闸机、店铺终端等)
- 销售额·补助金给谁、怎么给(商家是1家还是多家、分配规则)
这1页模糊不清就发出报价请求的话，返回的提案类型混杂，比较表的每一行前提都不同。
从需求选择承载平台类型｜4类别与服务示例
上述1页清晰后，选择承载平台的类型。承载平台是指委托票务销售·支付·入场确认的服务或公开站点的种类(交通单独·住宿OTA方案在本文范围外)。
表可横向滚动
| 类别 | 服务示例 | 适合案例(需求参考) | 类型不符容易发生的问题 |
|---|---|---|---|
| 电子商品券·振兴券平台 | PayPay 商品券、e街等 | 参加店铺支付为中心的商品券·振兴券(e街也支持旅游券·周游券) | 只用于指定席·闸机入场为主要目的的活动票。设施向全国销路也只用这一类型替代 |
| 旅游票务流通平台 | Goodfellows JTB(票务HUB / Webket / PaaSket)等 | 各设施入场·体验券连接到Web·旅行社·便利店等，入场确认和销售额按设施单位汇总(有多设施通票) | 店铺支付型振兴券为主要目的。公共机构·DMO前置的方案中，想将活动票Web销售·协办店·条件性发放与设施入场流通平台分开一体运营 |
| 票务销售系统(云型) | e+(Eplus)、TicketMe、teket等 | 1个活动·演出的票务销售(预售·当日·座位。合同多为主办方名义) | 想用同一合同一体运营振兴券店铺支付或活动以外的广域结算 |
| 方案专用站点 | SmartPlate Ticket等 | 多票种一体运营、自定义结算·获取条件、公开站点与票的统一展示一体设计 | 标准商品券·设施流通·单活动销售就足够的案例 |
服务示例是类型选择参考。功能和合同条件请在报价时向各公司确认。
PayPay商品券·e街 — 商品券与店铺支付
PayPay商品券是公共机构在PayPay上发放·销售的电子商品券，用户在参加店铺的PayPay支付中使用。官方资料列明娱乐票·在线订单·自动售货机等不能使用的类别，因此作为闸机入场或座位销售的主角不太合适。e街是商品券·振兴券之外，还整合了旅游券和周游电子票等的公共机构套餐。现场以店铺·设施支付终端和应用余额组合为中心，入场专用检票终端或与旅行社·OTA的批量对接不在设想范围内。高级商品券或参加店铺范围广的振兴方案用这一类型单独完成的情况较多，而在全国销路销售多设施入场·单活动座位管理最好在别的类别分开报价。
设施入场券 — Goodfellows JTB等
Goodfellows JTB的票务平台组合了票务HUB(销路对接·商品登录·结算)、设施Web销售Webket、入场确认应用PaaSket三个，是按设施的流通平台。美术馆或主题公园等各设施的入场券，通过旅游预约站·旅行社·便利店·设施Web等多个销路销售，现场用QR码入场确认和销售额汇总对齐。通票是将多设施入场整合到1个QR的设施联动商品(周游通票等)。公共机构·DMO前置，想将活动票Web销售·店铺券·条件性发放·商家结算与入场券流通平台分开一体化时，考虑别的类型。
单活动·演出销售 — e+·TicketMe等
e+(Eplus)、TicketMe、teket等是用云承接1个活动·演出票务销售的类型。Web·便利店打印·当日窗口等渠道因服务不同，但设计上容易限定在同一活动的销售·检票·销售额汇总。地区活动·物产展·会堂演出是典型案例，预售·当日都能处理的情况较多，与能在同一活动单位组合指定席·抽签的案例契合度高。合同多为文化振兴财团·旅游协会·执行委员会等主办方名义，与公共机构本体的广域结算或将多票种放入1个钱包的需求，合同主体·功能框架容易不符。
方案名称专用站点
SmartPlate Ticket等方案专用站点，以公共机构·DMO·执行委员会前置的方案名称公开URL为轴，将获取条件·多票种·各商家结算一体设计的类型。想让用户在同一品牌下看到方案站点和持有票的清单(钱包)时考虑。仅活动Web销售·仅1设施入场需求封闭的情况下，表中其他类型常常足够。预售·店铺券·条件性发放·交通套餐等规则不同的票用同一运营运转时，可能会并排出现这一类型的报价。
类型确定后｜报价请求用确认清单
4类别中哪个接近确定后，缩小到同类型的供应商请求报价。在此之前与相关方共享以下内容，容易防止合同后的运营不符：
- 销售主体·合同名义 — 公共机构名义还是旅游协会·设施运营者名义
- 方案标识 — 公开站点名称、标志、域名
- 销售期间·退款规则 — 中止·恶劣天气时的处理
- 结算对象 — 参加商家多家时的分配方式
- 票种增加频率 — 仅单次活动还是常设增加票种
- 与现有平台的关系 — 从合同中的振兴券·入场券平台迁移的可行性
- 个人信息·支付 — 公共机构直接处理还是第三方委托
- 结算数据·审计 — 补助事业报告·审计(适用时)
- 周游·交通套餐 — 运行日·线路单位限制(适用时)
将选定的类型和上述内容整理成1页后再进入RFP·报价请求，现场流程与合同内容的差距容易缩小。
功能与导入示例详见服务网站。
常见问题
公共部门票务销售数字化应该从哪里入手?
现场流程1页(谁卖 / 谁确认入场 / 谁结算) → 4类别中哪个接近 → 同类型服务报价的顺序推荐。
想用其他公共机构在用的同一服务承载的情况?
可以参考，但方案类型和结算未必相同。类型不符可能增加运营负担，请优先整理自家机构的1页流程。
想在同一手机画面处理振兴券和活动票的情况?
以店铺支付为中心的高级商品券的话，PayPay商品券或e街容易成为候选。e街也能处理周游·旅游票，请用需求1页确认类型。获取条件·票种·结算不同的多方案在1个公开站点一体运营时，进入方案专用站点的评估线。
总结
1. 一页写清现场与精算窗口。2. 选分类并记局限。3. 同型2–3家询价。4. 按主体·精算·券种对照报价。5. 留选型理由并排合同试运会议。
相关服务
SmartPlate Ticket｜方案专用票务平台
多票种统一展示·自定义结算·公开站点一体设计作为需求具体化后的选项。
在公共项目的票务数字化中，把「销售主体—入场核验—结算」写进同一张表，再按型别询价，能减少后期运营返工。
在公共项目的票务数字化中，把「销售主体—入场核验—结算」写进同一张表，再按型别询价，能减少后期运营返工。
上线前请把窗口、闸机与 Web 前售的负责人写在同一张公共票务迁移表上，并按型别向 2–3 家同型供应商询价，避免「系统已换、流程仍旧」。
若方案含多次乘车或设施联票，请在 RFP 中单列「是否同案」，再比较票务销售型别，避免报价范围漂移。