只憑手續費和行情「承載到現有站點」容易發生的問題
在公共部門的票務銷售數位化中，早期階段就因為「便宜 / 有實績 / 其他公共機構在用」的理由，討論能否承載到現有票務站點或銷售平台的情況很多。
問題是承載平台類型與方案不符的情況。例如以下組合：
- 想用單次活動銷售站點來運行振興券·店鋪支付方案
- 需要多票種·自訂結算，卻只用全國型電子商品券服務一體營運
- 想在多個窗口和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 中單列「是否同案」，再比較票務銷售型別，避免報價範圍漂移。