建議按以下順序梳理：
- 用 6 類 表定位 MaaS 觀光議題
- 判斷 二次交通、交通 套票 接近表中哪一行
- 確認 tripla 等 地域 OTA 與既有 MaaS 較易一體化的範圍
- 將拆分 預訂 與 使用 的 待評估 模式在報價表中與其他類型 並列 比較
- 用 判斷清單 收窄至 2～3 種型，再發起詢價
下文按此順序說明。
MaaS 與觀光票務｜6 類定位
設計 MaaS 觀光 票務 時，需先對齊訪客可見的「一段旅程」與背後的 銷售主體、驗票、精算。訪客向 MaaS 站點各地推進的同時，DMO 在詢價前仍需整理「在哪購買、由誰精算」。請先將本地需求對照下列 6 類 表。
表格可橫向捲動
| 類別 | 典型需求（MaaS×觀光） | 交通+設施+優惠券一體 | 購後列表展示 | 適用論點／邊界 |
|---|---|---|---|---|
| 1 電子商品券·振興券 | 門市支付型優惠券、溢價商品券 | 易與交通 MaaS 本體分層 | 應用餘額·門市終端 | 勿僅以閘機／乘務員驗票型 套票 為主角 |
| 2 觀光票務流通 | 設施入場券多渠道銷售·QR 核銷 | 以單設施、定型入場為主；周遊 通票另登記商品 | 各設施核銷應用 | 鐵路 MaaS 乘車券+廣域 精算 一體屬另案設計 |
| 3 活動票務銷售 | 單場活動·單設施預售與當日 | 以單場預售·核銷為主 | 按活動列表 | 廣域 MaaS 一體購買介面見第 4～6 行 |
| 4 交通·MaaS 乘車券 | 數位乘車券、自由通、二次交通 銜接 | 都市型 MaaS（Web 同時購交通+設施） | MaaS Web／應用已購介面 | 業者參與、路線登記、分成依賴協議會設計 |
| 5 地域 OTA·預訂基盤 | 住宿·體驗預訂 Web（tripla Book 等） | 住客限定優惠券、體驗同捆較合適；交通 全線一體易分議題 | 預訂管理介面與票務介面易分離 | 預訂結算在 OTA，周遊 通票另基盤——後述「待評估」 |
| 6 施策專用站點 | 多券種、領取條件、多社 精算 | 廣域 周遊（交通·巴士·設施同一 Web） | 施策 URL+已購列表 | 僅靠向既有 MaaS 增商品難以匹配券面規則的需求 |
表內特徵 並列 對照。交通·MaaS 乘車券、地域 OTA·預訂基盤、施策專用站點 三行中「購買介面」落點不同，二次交通、套票、設施優惠券的追加成本也會變化。
鐵路·DMO 公開的 MaaS 含 Web 同時購交通+設施的都市型、鐵路 QR 核心的企劃券型、縣·DMO 特設設施 周遊 型等，訪客 購買介面 位置與驗票方式因型而異。下文說明 購買介面位置 與 預訂與使用的拆分。
二次交通、套票與 MaaS 的銜接
二次交通 與交通+設施 套票 可落在 交通·MaaS 乘車券 行，也可落在 施策專用站點 行。差異在於訪客 在哪購買，以及各業者 精算報表 由誰定義。
表格可橫向捲動
| 論點 | 掛到既有 MaaS 購買路徑 | 施策名義 Web 一體銷售 |
|---|---|---|
| 購買入口 | 在訪客已用的 MaaS Web／應用上追加 巴士 一日券、周遊 商品 | 在 DMO·廣域協作名義 Web 上同捆交通+設施 |
| 二次交通 | 路線·運行日主資料在業者側；MaaS 作銷售與使用日誌窗口 | 銷售窗口在一體站點，巴士 業者按分成規則參與 |
| 套票 | 鐵路 QR 企劃券+巴士 同捆多需鐵路基盤+協調 | 在同一施策域名擴展領取條件、多語言、券種 |
單線 巴士 分 IC 聯動、QR 乘車券、向乘務員出示等，MaaS 對接前先統一路線側驗票方式可縮短討論。二次交通 載入 周遊 商品時，先寫明 GTFS、運行日主資料位置及與 巴士 業者的分成。交通+設施 套票 易分為在鐵路基盤同捆 巴士，或在施策 Web 同捆交通與設施。
tripla 等與既有 MaaS｜較易一體化範圍
以 tripla Book 為代表的 地域 OTA 正作為 DMO 區域的住宿·體驗預訂 Web 推進。觀光票務 中「與住宿同捆的體驗」「住客限定優惠券」多接近 地域 OTA·預訂基盤 行。
日本觀光廳觀光 DX 整理指出，註冊 DMO 應構建可完成 住宿·體驗預訂與結算的地域站點，並以 2027 年度末為目標的 KPI 亦見於觀光廳「觀光 DX 推進方向研討會」資料。預訂 側易先行；購後廣域 周遊 通票、交通 套票、按業者分成能否僅靠地域 OTA 標準功能擴展，取決於參與業者數與券種規則。
較易掛到 既有 MaaS 購買路徑的模式包括：
- 協議會·業者參與推進的觀光型 MaaS — Web 同時售交通+設施 票務；使用時螢幕出示、閘機 QR 等因路線·設施而異
- 廣域 MaaS 上的數位乘車券·企劃券 — 在訪客已用的 Web／應用追加 周遊 券種
- 縣·DMO 特設數位周遊券 — 無 MaaS 協議會的區域也可從施策 Web 後續同捆交通 套票
tripla 等 地域 OTA 的典型流是：住宿預訂完成後引導體驗·優惠券，現場以預訂確認介面或 QR 入場。鐵路閘機一體廣域自由通、多 巴士 業者分成、機場限定 周遊 通票能否用同一模板擴展，需在 詢價時對照功能清單。
在既有觀光應用內承載券面·核銷·退款的改造易超出認證·結算·門市聯動範圍，專用票務站點分離型也應在報價表中 並列。
待評估｜預訂基盤與使用基盤的拆分
存在將住宿·體驗 預訂（表 地域 OTA·預訂基盤 行）與購後 周遊 列表、多社 精算（接近 施策專用站點 行）分開設計的模式。若符合下列 2 項以上，拆分 預訂基盤 與 使用基盤 的構成也應在報價表中 並列。
- 結算仍用既有 OTA·住宿電商，僅購後按施策規則發放數位券
- 多券種一體展示（交通·設施·優惠券·發放券）希望與預訂介面分 URL 公開
- 按業者的精算報表、截止日、補貼日誌與 OTA 標準精算輸出不一致
- 領取條件（住客限定、訪客屬性、機場發放）在預訂流與票務流中不同
拆分 預訂 與 使用 的對照參考為紀伊半島廣域通票 KiiPass：從 Web 購買到交通·巴士·設施在 同一已購介面 使用，並一體設計多社 精算，與向既有 MaaS 增一行商品在銷售窗口、退款、券面擴展上不同。
在住宿 OTA 等完成結算後，於另一票務基盤承載權益發放·使用·精算 的構成，並非各地均有定型方案。方式含 PMS 聯動住客券、地域 OTA 預訂 ID 聯動、施策專用站點代碼發放等，因基盤而異。將預訂結算與購後券面·精算 拆分的型，應與地域 OTA 完結型在報價表中 並列。
判斷清單｜詢價前論點
MaaS 觀光 票務 詢價備忘建議先寫下列內容，再比較供應商，以減少表行混淆。
- 1. 訪客購買介面 — 以 MaaS Web、地域 OTA、施策專用 Web 何者為正（並用時的分工）
- 2. 商品內容 — 交通自由通、交通+設施 套票、僅設施 周遊、條件發放（都市型 MaaS、鐵路 QR 核心、縣特設、交通套票同捆等）
- 3. 二次交通 — 對象路線、運行日主資料位置、與 巴士 業者分成、GTFS 是否就緒
- 4. 驗票 — 閘機 QR、乘務員／工作人員螢幕、設施閘機（是否假定全業者終端統一）
- 5. 精算 — 按業者 精算報表、截止日、未使用·停航處理
- 6. 多語言與退款窗口 — 銷售·諮詢以誰名義公開
地域 OTA 與施策專用站點傾向混用時，請對照前文「較易一體化範圍」與「預訂與使用拆分」，收窄至 2～3 型再索取功能清單。
詢價文可附下列一句以便回覆格式一致：「訪客 購買介面 以 MaaS 乘車券／地域 OTA／施策專用 Web 何者為正；交通 套票、二次交通、設施優惠券是否同一已購介面；按業者 精算報表 的截止日與欄位定義由誰掌握。」若以單場活動銷售或僅多業者分成為主論點，請在詢價文中明示表 活動票務銷售 行與 精算 項。
總結
- 用 6 類 表固定購買介面所在行
- 確定 二次交通、套票 走 MaaS 路徑還是施策專用型，並寫明與 巴士、鐵路的銜接需求
- 並列 比較 tripla 等與既有 MaaS 較易一體化範圍，以及拆分 預訂 與 使用 的 待評估 模式
- 對照一體設計案例，以 判斷清單 進入詢價
功能與導入示例詳見服務網站。
常見問題
Q1. MaaS 觀光票務可以從既有地域 MaaS 起步嗎？
協議會與 Web 銷售基盤就緒的區域，追加交通+設施 票務 是有力選項。僅從設施 周遊 起步的縣特設型與鐵路 QR 核心企劃券型，驗票與退款窗口不同。請在 交通·MaaS 乘車券 與 施策專用站點 行 並列 對照購買介面與 精算 窗口。
Q2. tripla 能否一體做到交通自由通？
tripla Book 的優勢是作為住宿·體驗的 地域 OTA 預訂 Web。鐵路閘機一體、多 巴士 分成、機場限定 周遊 通票能否同一模板涵蓋，取決於券種與參與業者，需對照功能清單。交通重心放在 交通·MaaS 乘車券 行，廣域一體放在 施策專用站點 行 並列 比較。
Q3. 觀光型 MaaS 與廣域周遊施策 Web 有何不同？
前者在 MaaS 購買路徑上購買交通+設施；後者是 DMO·廣域協作施策 Web，一體設計已購列表與多社 精算。後者更接近拆分 預訂 與 使用 的 待評估 模式。廣域一體運營例 KiiPass（紀伊半島廣域通票）從 Web 購買到交通·巴士·設施共用同一已購介面。
Q4. 能否事後將二次交通掛到 MaaS？
可以，但先對齊路線·運行日主資料與券種正本再 周遊 商品化較安全。社區巴士 需先整理 GTFS 與運行單位。
Q5. 能否向 OTA 購宿客自動發放限定周遊通票？
方式多樣，並非各地均有相同模板。代表例含 PMS 聯動住客券、地域 OTA 預訂 ID 聯動、施策專用站點代碼發放等，購後聯動可否取決於所選基盤。不支援時可從施策專用側設計起步，將拆分預訂結算與購後券面·精算 的型在報價表中 並列。
相關服務
SmartPlate Ticket
對於拆分 預訂 與 使用 的 待評估 模式，或落在 施策專用站點 行的 MaaS 觀光 票務，若希望從 Web 購買到施策專用票務站點一體營運，SmartPlate Ticket 是可選方案之一。購後列表、領取條件、多社 精算 概覽見 SmartPlate Ticket 服務站點與服務資料（免費）。住宿 OTA 購後權益發放聯動為 視需求與聯動方式可商談，不可斷定為全地域標準功能。與既有 地域 OTA、MaaS 的分工，寫在詢價文中作為拆分預訂結算與購後券面·精算 的 待評估 模式較易整理。
