This article lines up decision points to align before quotes: which sales and delivery model sells transit plus venues, how far each operator’s core systems must change, where sales and settlement sit, and where visitors see ticket faces and lists (wallet). It then walks through the four product categories, four delivery models, multi-operator settlement, published tourism-pass examples, conditions that fit existing MaaS or dedicated tourism sites, and when to include a program-dedicated site in bid comparison (validation and settlement contracts are separate in every model). Single-route bus ticket models are covered in Bus digital ticket introduction guide | Methods comparison and operations; general municipal voucher portal theory is in Municipal ticket sales digitalization | Platform vs dedicated site.
Recommended order: 1. Fix tourism-pass product category → 2. Compare four delivery models → 3. Fix wallet / activation → 4. Lock multi-operator settlement columns → 5. Match public examples and narrow to 2–3 models for quotes. Sections below follow this order.
Tourism pass types | Free pass, bundles, and packaged tickets
A tourism pass may look like one ticket to visitors, but transit, venues, and coupons are usually separate products bundled behind the scenes. Before quoting, fix which of these four categories (product content) you are closest to—then sales channels and wallet design drift less. The four categories and the later four delivery models use separate table rows and headings: categories describe product content; delivery models describe channel and platform.
Table scrolls horizontally
| Category | Content | Published examples |
|---|---|---|
| Transit free pass | Unlimited or fixed-ride rail, bus, ferry, etc. | Minami-yo Digital Free Pass, Yaeyama Free Pass |
| Transit + venue bundle | Ride tickets bundled with venue admission or experiences | Sendai MaaS transit + admission, Tabi-Shinshu |
| Venue and area pass (transit-light) | Multiple venues on one QR or pick-your-own set | Okayama Haretabi, Odaiba area pass |
| Conditional distribution | Airport-only, visitor-only, or other eligibility rules | Inbound coupons, pilot distribution programs |
Digitalization differs by category in who sells, what to show on site (gates, crew, venues), and settlement report granularity. In wide areas, whether you must replace every participant’s fareboxes, IC, and onboard devices at once also drives coordination cost in model selection.
Digitalization models | Four delivery types for tourism passes
In tourism-pass digitalization quotes, published tourism and sightseeing MaaS cases usually map to these four delivery models. Single-event presale SaaS or store-payment-only voucher programs sit outside the main comparison axis for integrated tourism design (Event ticket sales system comparison · Municipal ticket sales digitalization).
Table scrolls horizontally
| Model | Published examples | Tourism requirements it fits | Operator fare and gate systems | Roles and boundaries |
|---|---|---|---|---|
| Sightseeing MaaS (web / app) | Sendai MaaS, Tabi-Shinshu, Ehime Minami-yo, Kurukuru Naruto | Buy transit + venues/shops in one flow; council and operator participation | Show-screen-first can defer gate upgrades. Device reads and location-based fares need deeper integration | MaaS council as sales desk; per-route and per-venue contracts |
| Prefecture / DMO dedicated digital pass | Ise Marugoto ticket, Okayama Haretabi Passport | Program brand and dedicated URL. Venue loops, taxi + coupons, etc. | Often program site + app / QR display, not integrated rail gates | Adding transit later adds product design and validation |
| Rail-issued digital packages and QR tourism | Kintetsu digital passes, JR West WEST QR, etc. | Visitor-focused rail-centric tourism. Bus and venues bundled as set products | Sits on rail gate and QR base. Wide-area bus often separate contracts | Sales and refunds on operator side; not the same layer as DMO-front unified wallet |
| Region-wide unified tourism ticket site | Kagawa / Takamatsu airport style, Wakayama KiiPass, etc. (integrated design reference) | Multi-product wallet, conditional distribution, multi-party settlement, multilingual as one premise | Program holds sales desk; hard to assume every operator upgrades core systems | When conditional distribution and custom settlement are core, split requirements from other models. Single product or rail-web-only: compare design cost on equal footing with the three models above |
The table compares traits on equal footing—not “one winner.” Note sales desk, wallet, settlement, and which operator systems change how much, then narrow to two or three models and line up feature lists—typical flow.
- Sales entity — Sales, refunds, inquiries (city, DMO, MaaS council, rail web)
- Validation — Gate QR, screen to crew/staff, venue gates, NFC tap
- Connection to existing systems — Start only after unified fare collection, or begin with show-screen / separate QR layer
Nationwide distribution for venue admission alone is a separate layer from the pass itself. Lodging and experience booking vs post-purchase tourism wallet are often split; MaaS and tourism ticket design | Booking vs usage platform (coming soon) covers that.
Ticket wallet | Ticket face, activation, and list view
For tourism-pass digitalization, where visitors see “my tickets” drives inquiry volume and day-of operations.
Table scrolls horizontally
| Topic | Decide | If misaligned |
|---|---|---|
| Source of ticket face | Child ticket count and display names per product | Split guidance on “which screen to show” on site |
| Activation | Immediate use vs date pick vs start button | Weak copy when rail QR and venue QR mix |
| Offline | Display and paper exchange when offline | Issues on remote routes and islands |
| Multilingual | Languages on ticket face, FAQ, guidance | Inquiry spikes on inbound tourism passes |
Sendai MaaS buys and lists on the web; validation is mostly screen display. Ise Marugoto ticket uses a dedicated site plus app purchase and taxi tap, with different checks per mode. Okayama Haretabi is closer to a venue-loop wallet: one email QR for multiple venues.
Multi-operator settlement | Cutoffs, reports, and audit
Rules to split one tourism-pass sale across rail, bus, ferry, and venues are easier to lock in contracts before digitalization than to fix later.
| Topic | Confirm |
|---|---|
| Settlement granularity | Per operator, route, and cutoff; report formats vary by project |
| Unused and canceled service | Weather cancellations, substitutions, refunds |
| Fee burden | Who pays payment fees and MaaS usage fees |
| Grants and pilot reporting | Log fields (use datetime, operator codes, etc.) |
On wide tourism passes, fix allocation from ride and entry logs together with operator agreement. Settlement rules are a separate track from unifying every fare system. Public materials mention approaches such as Yaeyama tourism MaaS linking mobile tickets and payment-terminal data for allocation accuracy. Details: Multi-operator ticket settlement design | Reports and cutoffs (coming soon).
Implementation examples | Published tourism models
Categories and model tables alone are hard to picture—below are short public examples by model (figures follow each official source; here we focus on design type).
Sendai MaaS (Miyagi Prefecture / Sendai City) — City-led sightseeing MaaS. Visitors buy digital tickets for transit (bus, subway, taxi, etc.) and venues, dining, baths, etc. on the web; screen display at gates, drivers, and staff is central. No app download required per official guidance. Reference for urban tourism transit + venue bundles.
Tabi-Shinshu (Nagano Prefecture) — Transit, tourism, and shop coupons on one MaaS (Tabi-CONNECT). Venues: show prepaid tickets; transit: show ride tickets. Digital rural development public case for wide-area tourism including secondary transit.
Tabi-Shinshu | Digital rural menu book
Ise Marugoto ticket (Mie Prefecture) — Dedicated site for digital passes; Horai app purchase; unlimited taxi + coupons, etc. Example of prefecture / DMO-front dedicated tourism. Differs from Kintetsu web bundle sets in sales entity and validation.
Ise Marugoto ticket dedicated site
Okayama Haretabi Passport (Okayama Prefecture) — Pick five venues from the list; one QR for the loop. Digital tourism pass without transit—a venue-loop example. Useful reference if you later add a bus bundle to wallet design.
Okayama Haretabi Passport [official]
Reference | Wide-area integrated operations
Separate from market examples, published cases that integrated multi-product wallet, conditional distribution, and multi-party settlement include the Kii Peninsula wide pass and Takamatsu airport distribution coupons. Use for requirements cross-check in quotes (local recognition varies by project).
KiiPass wide-area tourism pass case study
SmartPlate Ticket · Case studiesWide-area tourism pass case study | Wakayama KiiPassWeb purchase to one wallet for transit, venues, and perks. Tourism-pass model with centralized wide-area settlement.
When existing MaaS or dedicated tourism sites fit
Tourism-pass digitalization is easier without a new region-wide site when: sightseeing MaaS already runs, the prefecture operates a dedicated digital pass site, or rail digital packages can bundle bus and venues—product count, validation, and settlement stay close to the existing service design.
Regional and urban MaaS — Sendai MaaS, Tabi-Shinshu, KANSAI MaaS, Kobe Kobe Tourism MaaS Council digital packages: visitors buy digital ride and tourism tickets on web/app. Where operator signup and route/venue registration progressed, adding transit-centric day passes and free passes is easier. If “defer every operator’s fare-collection upgrade” is strong, device reads and location fares may clash—compare on equal footing with dedicated pass sites and unified regional sites.
Prefecture / DMO dedicated sites — Ise Marugoto, Okayama Haretabi: program name and URL as one digital pass. Also fits venue-only loops that later add bus bundles. Shizuoka Shizutetsu trip ticket sells in-prefecture transit sets as ticket portal products—a same-model reference (general voucher portal comparison: Municipal ticket sales digitalization).
Rail web and QR packages — Where Kintetsu, JR West, etc. publish visitor digital passes, transit core sits on rail sales and gates. Differs from DMO-front wide passes in desk, refunds, and settlement—keep as model 3 in the table.
Single-route ride tickets only or one-off event presales: compare Bus digital ticket introduction guide or Event ticket sales system comparison first.
When to include a dedicated tourism site in bid comparison
If two or more of the following apply, put a program-dedicated tourism ticket site on equal footing in the bid comparison table. Sendai MaaS and prefecture dedicated sites show this is not “dedicated site required for every case.”
- Unified wallet for multiple products (transit, venues, coupons, distribution tickets)
- Eligibility and custom rules (airport-only, visitor attributes, stamp distribution, etc.)
- Custom multi-operator settlement (per-operator reports, cutoffs, audit logs)
- Multilingual on the program domain with unified ticket faces
- Wide area where one fare/gate base cannot cover all operators (program holds sales desk)
Starting with screen display and adding onboard devices later connects to show-screen and phased rollout in the Bus digital ticket introduction guide. The Reference operations above read as requirement examples that often match this bar.
Introduction steps | Selection checklist
Tourism-pass digitalization in five steps helps align stakeholders on sales desk, validation, and settlement.
- 1. Fix category and sales entity — Free pass vs venue loop; where sales desk sits
- 2. Map to four delivery models — Sendai-style, Ise-style, rail QR, etc.; narrow to two or three and compare features
- 3. Wallet and validation design — Gate QR, screen display, venue gates (assume fleet-wide devices or not)
- 4. Agree settlement rules — Report fields (sales, usage counts), cutoffs, unused tickets
- 5. Pilot and parallel end conditions — Paper/counter parallel period; single inquiry channel
Rail package web sales and multilingual: Packaged ride ticket web sales | Rail tourism requirements (coming soon).
See features and rollout examples on the service site.
FAQ
Q1. Can we start tourism-pass digitalization from MaaS?
Where a council and product base already exist, as with Sendai MaaS, adding transit + venues is a strong option. Some municipalities start venue-only like Okayama Haretabi. When eligibility, multi-party settlement, or a dedicated domain grow, re-run the model table and include a unified regional site on equal footing in bids.
Q2. How do Ise Marugoto and Sendai MaaS differ?
Ise Marugoto is prefecture/DMO dedicated digital pass (app purchase, dedicated URL). Sendai MaaS is urban sightseeing MaaS with transit + venue lists on the web. Transit weight and validation (screen vs taxi tap, etc.) differ.
Q3. Are rail digital passes (Kintetsu, JR West QR) the same design as municipal wide passes?
No. Rail QR puts gates and start of use on rail infrastructure with strong visitor SEO. DMO-led wide passes use models 1, 2, and 4 in the table—decide desk, settlement, and wallet first.
Q4. If we digitize bus routes first, can we add a tourism pass later?
Yes, but safer after route, operating-day masters, and product source of truth align. Align single-route bus models in the Bus digital ticket introduction guide first to shorten integration talks.
Q5. Can we launch a tourism pass without changing fareboxes or gates?
Without replacing every operator’s fare collection at once, show-screen MaaS, venue QR passes, or unified sales desk on one site can be easier starts. Validation and settlement/allocation contracts still apply. Rail gate-first and device-read MaaS differ in coordination depth.
Summary
1. Write local pass category and seller on one sheet. 2. Fill the four-model table (purchase surface, sales desk, system change). 3. Fix visitor wallet, activation, languages. 4. Agree settlement cutoffs and report columns. 5. Filter models by selection criteria and send quote requests to the next DMO meeting.
Related reading
- Municipal ticket sales digitalization | Platform vs dedicated site — Four program categories overall
- Transit + venue bundle digitalization | Integrated delivery models (coming soon) — Bundle types
- Packaged ride ticket web sales | Rail tourism requirements (coming soon) — Rail packages and multilingual
- MaaS and tourism ticket design | Booking vs usage platform (coming soon) — Booking vs usage split
- Event ticket sales system comparison | Municipal and cultural venues — Boundary with single-event sales
- Multi-operator ticket settlement design | Reports and cutoffs (coming soon) — Multi-operator settlement
- SmartPlate Ticket service site — Tourism and integrated operations overview
- SmartPlate Ticket service materials (free) — For requirements workshops
Related service
SmartPlate Ticket
When several items in the dedicated tourism site bid bar apply, one option for tourism passes you want to run end-to-end from web purchase on a program-dedicated ticket site is SmartPlate Ticket. Overview aligned with the Reference cases above is on the SmartPlate Ticket service site and service materials (free).
