在活動票務銷售系統比較中, 先明確比較什麼, 然後審查同類型候選·營運差異·票務銷售系統(雲型)的設計限制. 在縮小供應商範圍前, 記錄僅預售是否足夠或同時需要多次乘車券等類似方案; 這能保持RFP範圍穩定. 完整通路整理見公共部門票務銷售數位化; 手續費深入見票務銷售平台手續費比較(即將推出).
建議順序：1. 比較前三確認 → 2. 活動SaaS對照 → 3. 手續費與合約 → 4. 維運與SaaS邊界 → 5. 導入流詢價。下文依此順序。
比較前的3項確認
搜尋活動票務銷售系統會看到供應商LP和熱門N項清單文章. 清單中大多數名稱是活動·場館雲預售(票務銷售系統) — 為單場演出預售和入場確認建構的服務. 地區券·多次乘車券·交通費·住宿OTA是不同設計; 混入活動預售矩陣會比較錯誤類別.
兩種模型｜票務銷售系統(雲型) vs 方案專用站點
比較表通常排列相同模型的服務. 通路整理見公共部門票務銷售數位化; 專用站點見選擇方案專用票務系統(即將推出).
| 比較類型 | 票務銷售系統(雲型) | 方案專用站點 |
|---|---|---|
| 設計中心 | 單場演出預售和入場確認; 支付給單一主辦方; 供應商託管銷售頁面 | 多票種·分發規則·結算一起; 專用網域和錢包 |
| 比較方法 | e+·TicketMe等 — 向此模型2~3家供應商詢問相同清單 | 將單獨備註拆分為僅預售報價vs集成營運(上述指南) |
| 下方3項確認 | 如#1為中心且#2~3不適用 → 票務銷售系統比較 | 如#2或#3適用 → 先明確範圍 |
在排列產品名稱前, 記錄以下3項.
- 單活動(或單賽季)的付費票務銷售·入場確認 — 這樣就夠了嗎?
- 從第一天起同一時間表是否需要地區券·多次乘車券·交通套餐·OTA連結?
- 是否需要單螢幕多票種·條件性分發·多營運商結算?
如僅第一項為中心且無#2~3, 可進入票務銷售系統比較.
如#2或#3適用, 僅票務銷售系統矩陣很少提供足夠訊號. 分別請求僅預售報價和集成營運討論, 或使用上述連結重構整個方案.
持續場館營運(租賃·售票處·會員管理)與單次預售票務銷售系統在不同層次. 文化設施·博物館票務數位化(即將推出)參見設施票務與活動票務銷售系統的差異.
主要服務｜活動票務銷售系統(雲型)
當3項確認指向活動票務銷售系統時, 團隊通常從公開規模和必需功能(指定席·抽籤·串流·LINE等)縮小到2~3家供應商. 價格和功能透過供應商報價確認.
主要活動票務銷售系統選項
| 優先級 | 服務 | 選擇理由(公開資訊) | 典型適配 |
|---|---|---|---|
| 1 | e+ (WOS) | 簽約組織15,000+, 累計活動350,000+, 會員26M+ (官方2024年12月) | 指定席·抽籤·市場覆蓋·中大規模 |
| 2 | TicketMe | 公共部門指南和案例多; 零前期·使用量計費提案(需報價) | 小中規模·年幾次預售週期 |
| 3 | teket | 座位·抽籤·串流在一個活動中; 公共案例(需報價) | 串流與預售一起進行時 |
手續費範圍在下方手續費與合約及票務銷售平台手續費比較(即將推出)中. 下面對齊功能·營運·推廣.
主要比較軸(e+與TicketMe)
對於公共預售, 許多團隊首先排列公佈市場規模的e+ (Eplus)和公共指南·案例多的TicketMe在同一清單上.
| 軸 | e+ WOS | TicketMe |
|---|---|---|
| 定位 | e+上銷售·行動票·市場會員基礎 | 雲銷售; 主辦方品牌站點中心(官方提案) |
| 規模適配 | 中大規模; 指定席·抽籤; 重複活動 | 小中規模; 年幾次 |
| 銷售功能 | 指定席·抽籤·行動票·便利商店·現場列印銷售 | QR數位·便利商店·海外銷售(官方提案) |
| 推廣 | 覆蓋約26M會員(有條件) | 主辦方驅動觀眾 |
供應商清單｜營運·功能(e+ / TicketMe / teket)
將下表原樣傳送給e+·TicketMe·teket並在手續費建模前比較供應商確認儲存格中的答案.
| 確認事項 | e+ WOS | TicketMe | teket |
|---|---|---|---|
| 當日入場確認 | 行動票(離線使用提案·官方) | QR數位(官方) | 供應商確認 |
| 數位存取差距 | 便利商店取件·現場列印(官方) | 便利商店(官方) | 供應商確認 |
| 指定席·抽籤 | 標準計畫(官方) | 抽籤(LP提案) | 座位·抽籤(提案) |
| 串流捆綁預售 | 供應商確認 | 供應商確認 | 同一活動中串流(提案) |
| 退款·取消 | 計畫和營運依賴 | 退款支援(LP提案) | 供應商確認 |
teket是當所需功能偏離e+·TicketMe(如捆綁串流)時的附加候選. 統一錢包·訂製結算·條件性分發通常在票務銷售系統產品邊界之外 — 簽約前詢問供應商選項是否足夠或需要不同建構, 特別是希望在同一螢幕上顯示多次乘車產品時.
從紙質遷移見公共部門活動票導入｜從紙質的遷移步驟.
簽約前確認的營運事項
按候選填寫清單表並比較. 即使沒有掃描器, 在簡報材料中記錄入場流程·連接性有助於當日協調. 如從一開始就需要統一錢包, 在進入票務銷售系統比較前重新執行開頭的3項確認.
需要專用品牌時｜票務銷售系統設計限制
活動·場館票務銷售系統(雲型)通常適合單活動(或賽季), 購買或抽籤完成且支付給單一主辦方. 痛苦常出現在目標偏離產品假設時, 而非簡單缺失功能.
票務銷售系統假設單產品·單活動·單收款方
| 主題 | 典型活動票務銷售系統 | 不一致時 |
|---|---|---|
| 票種 | 按活動註冊產品 | 想要預售+多次乘車+券在一個錢包 — 感覺拼湊在一起且UX破裂 |
| 獲取 | 購買·抽籤 | 條件性免費分發(僅訪客等) — 標準流程外 |
| 結算 | 轉帳給主辦方 | 跨營運商拆分·訂製CSV·稽核 — 財務重新設計 |
| 通路 | 在供應商平台上結束 | OTA或住宿結帳後的權利 — 不同通道 |
| 品牌 | 供應商頁面+主辦方名稱 | 方案網域和多語言站點 — 模板外 |
稍後在同一螢幕上出現一件事時
在票務銷售系統上啟動預售後, 同一UI上的多次乘車·追溯券·僅訪客分發請求常導致雙重營運或重新報價. 這不是新增功能而是改變建構模型 — 早期拆分預售報價和集成營運討論, 或與利益相關者確定單活動範圍.
何時考慮專用站點
如以下2項或更多適用, 也見選擇方案專用票務系統(即將推出). 交通+設施套餐有時在現有多次乘車基礎設施上執行(多次乘車券數位化, 即將推出). 並非每項都需要專用站點.
- 多票種統一錢包
- 條件性分發和訂製獲取規則
- 跨多營運商訂製結算
- 方案品牌多語言站點打包
手續費·合約｜進入建模(詳情在手續費文章)
活動票銷售成本混合使用費·註冊·便利商店·列印. 供應商在註冊+使用與僅使用上不同, 因此比較每活動總額. 手續費重要, 但退款·便利商店·當日支援·後續功能新增也影響總成本和風險. 簽約前預測總營運成本並明確各供應商的支援範圍很重要, 特別是在需要訂製功能或特殊要求的情況下.
公開範圍(計畫和日期變化 — 供應商確認):
| 服務 | 公開範圍 | 備註 |
|---|---|---|
| e+ WOS Light | 演出註冊¥5,000(稅前) + 銷售費8% | 一般入場等(官方2024年12月) |
| e+ WOS Standard | 註冊¥10,000(稅前) + 預售8% / 一般10% | 指定席·抽籤(官方2024年12月) |
| TicketMe | 零前期·約5%使用 | Ticket Lab指南·供應商確認 |
| teket | 約8%一般 / 10%指定 | 比較媒體·供應商確認 |
範例(說明): ¥3,000 × 500張票 = ¥1.5M收入僅8%使用 ≈ ¥120k銷售費 + 演出註冊(便利商店·列印·退款額外). 損益平衡和年度總計在票務銷售平台手續費比較(即將推出)中. 手續費前涵蓋3項確認·清單表·設計限制可減少簽約後返工.
推出流程｜從範圍到RFP
- 3項確認 — 明確比較什麼; 票務銷售系統矩陣vs拆分諮詢
- 拆分請求 — 單活動預售·入場確認vs統一錢包·結算·分發規則; 如後者適用則保持單獨備註
- 僅預售 — 以e+·TicketMe為錨, 功能匹配則加teket; RFP向2~3家供應商用相同清單
- 手續費建模·合約 — 在手續費文章中比較每活動總額(不僅手續費); 確認票種·條款·退款後簽約
案例｜和歌山 KiiPass（與活動 SaaS 對比）
和歌山 KiiPass 在施策專用站點（SmartPlate Ticket）上一體營運廣域周遊通票與同一錢包，與活動預售 SaaS 型不同。詳見KiiPass 案例。
SmartPlate Ticket · 案例廣域周遊通票｜和歌山 KiiPass交通·設施·特典同一錢包，多方精算於施策專用站點一體營運。
功能與導入示例詳見服務網站。
常見問題
Q1. 比較文章中列出的服務應如何排序?
許多團隊透過公開規模 → 公共部門案例 → 必需功能縮小到2~3家供應商後比較清單答案 — 通常從e+·TicketMe開始, 為捆綁串流新增teket.
Q2. 供應商站點顯示設施案例 — 這意味著涵蓋一切嗎?
大多數活動票務銷售系統以單活動銷售為中心. 場館租賃·會員·售票處·多票集成營運在另一層. 票務銷售系統範圍限於預售·入場確認; 營運更廣時拆分設施·專用站點審查.
Q3. 選擇最低手續費推出會成功嗎?
手續費模型有幫助, 但後續新增票務銷售系統外需求(統一錢包·條件性分發·多營運商結算)常強制雙重營運. 先確認3項確認和是否拆分預售報價vs集成討論.
比較活動類票的銷售系統時，建議把「僅單場預售」與「多券種一體營運」寫在同一張需求備忘錄裡，再對照上文的系統類型、手續費與營運清單，避免把振興券或周遊產品與活動預售混在同一比較表。若只需單活動付費票的銷售與入場確認，可優先在票務銷售系統（雲型）候選中比較；若從第一天起就需要統一錢包或訂製結算，應另行列出專用站點需求，而不是強行塞進同一張比價表。
總結
1. 三確認備忘。2. 填2–3社表。3. 單活動總額與合約漏項。4. 一體維運需求與SaaS限界。5. 發詢價並指定試購負責人。
相關服務
SmartPlate Ticket — 用於多票種·資格規則·訂製結算
不適合票務銷售系統產品盒的建構 — 統一錢包·條件性分發·多營運商結算 — SmartPlate Ticket. 對於在活動票務銷售系統中難以設計的集成營運(如 KiiPass), 見SmartPlate Ticket服務站點.
比較活動票銷售系統時，在招標文件中寫明座位、退款與結算匯出欄位，供應商回答會更可對照。並單獨記錄「僅預售」與「含多次乘車券」是否同案，避免 RFP 範圍漂移。