Recommended order:
- Fix secondary transport scope, target routes, and sales entity
- Compare purchase-surface types (transit/MaaS ticket platform vs program-dedicated site) on one table
- For community buses, align operations, GTFS, and ticket validation
- Map links to tourism passes and MaaS (Mobility as a Service — search-to-ride design), then write quote and pilot scope per model
Sections below follow this order.
Secondary transport defined | Digitalization scope
Secondary transport is local movement after the main line—community buses, sightseeing loop buses, demand-responsive service, and connecting route buses. From here on, quotes assume you will put visitor sales channels, products, usage logs, and operator settlement into a digitalization table.
Table scrolls horizontally
| Segment | Typical case | Decide first for digitalization |
|---|---|---|
| Station connector bus | Resort station to hot-spring town or lakeside | Valid routes on a day pass and rail combo products |
| Community bus | Municipal or contracted local loops | Operating-day/trip master data and GTFS ownership |
| Wide-area tourism legs | Multi-operator buses plus venues | One tourism pass product vs per-operator settlement |
Digitalization is not only a ticket app—it can include open data in route search, ride logs, and settlement report formats. MLIT regional transit DX (MaaS 2.0) also points to integrated MaaS apps, dispatch, digital ticketing, and data use (press release).
Transit/MaaS ticket platform | Two sales models
When quoting secondary transport digitalization, line up these two models. One loads products on purchase flows visitors already use (transfer/regional MaaS apps); the other sells on a regional program web and shows the purchased screen—the difference is where visitors buy.
Table scrolls horizontally
| Model | Purchase surface | When this model fits | If products & settlement grow |
|---|---|---|---|
| Transit/MaaS ticket platform | Register local products on transfer/regional MaaS apps and existing purchase flows | You want bus day passes on an app flow visitors already use | Confirm platform registration, allocation, and change scope in requirements |
| Program-dedicated site | Web sales on a regional program URL; purchased tickets on the same screen | DMO or wide-area body holds sales desk, refunds, and guidance; bus + venues in one tourism pass | Split roles with existing MaaS purchase flows and sales desks |
Transit/MaaS ticket platforms include multi-operator route registration with digital bus tickets in one app (e.g. RYDE PASS) or operator-packaged route, fare, and settlement report clouds (e.g. Locobus Ticket). Wide tourism pass purchases on one MaaS (e.g. Tabi-Shinshu) also use this purchase path. Visitors buy from transfer/regional apps; crew check or device read follows per route.
Program-dedicated sites fit when you want to sell secondary transport on a regional web sales screen, not mixed with other regions’ products in a national app. Non-operator sellers can hold sales desk, refunds, and settlement report formats, but onboard device changes need bus operator agreement. After picking a model, fix crew check, device read, or show-screen per route and operating unit.
| Label | Reference (model image) |
|---|---|
| Tabi-Shinshu type | Nagano wide-area MaaS (Tabi-CONNECT)—transit, tourism, and store coupons in one purchase; public tourism pass including secondary transport |
| Community bus ops kit type | MLIT COMmmmONS pilot—operations planning, logs, GTFS output (Kariya, Hirado) (tech report) |
Community bus requirements | Operations, GTFS, tickets
Community buses often have few routes and operating days, with staff juggling timetables and ridership counts—typical secondary transport. Before “building an app,” decide who owns the operating day, trip, and stop master for digitalization.
Table scrolls horizontally
| Topic | Confirm | If misaligned |
|---|---|---|
| Service planning | Seasonal timetables, non-operating days, extra trips | Digital tickets sold outside valid periods |
| GTFS / route search | Who updates data shown in Google Maps etc. | Visitors ask why routes do not appear in apps |
| Tickets | Flat day pass vs distance-based routes | Mixed IC, QR, and show-screen loads crew unevenly |
| Operator settlement | One code per route vs joint-service split | Allocation rules when bundled in a tourism pass |
The community bus operations support kit (COMmmmONS) helps plan service, logs, forms, and GTFS on the web; pilots report shorter irregular work. Running ticket digitalization alongside operations data makes valid-route lists easier to sync with timetable changes. Small operators may first aim for numeric operations logs before app builds.
On flat-fare sightseeing loop buses, many teams start with show-screen tickets, then add QR readers for crowds or log needs. For community buses, note peak crew checks and grant/pilot ridership logs in quote memos to shorten method debates.
MaaS links | Tourism passes, search, data
MaaS covers search, booking/purchase, ride/admission validation, and settlement reports. Secondary transport digitalization connects through cashless transit and open operations data.
- Purchase entry — transfer app regional mode, municipal transit MaaS, or tourism program web for bus sales (prior table)
- Product bundling — rail combo + secondary transport + venues in one product, or transit-only digitalization first
- Data — whether ride logs support operator settlement and tourism pass audits
Wide examples such as Tabi-Shinshu—transit, tourism, and coupons on one MaaS with separate ride vs venue presentation—help when bundling secondary transport in tourism passes. Splitting lodging/activity booking (regional OTA) from post-purchase ride/tourism pass bases is a boundary between “booking complete in tripla-like tools” vs self-designed transit+venue allocation.
Summary
Before quotes, work through:
- Route list and sales entity (operator, DMO, etc.) on one memo
- Two-model table: purchase surface, sales desk, devices, allocation
- For community buses, agree operating days, GTFS owner, and ticket method (IC / QR / show-screen)
- Add tourism pass / MaaS links (entry, bundling, settlement reports) and quote/pilot plans for the next meeting
See features and rollout examples on the service site.
FAQ
Q1. Is secondary transport the same as a sightseeing loop bus?
Not always. Secondary transport is all post-station local movement; tourism loop buses are often sightseeing circuits. For digitalization quotes, fix the route list and sales entity (operator vs DMO) first.
Q2. Can we digitize community buses first?
Yes. Include service planning, GTFS, and day-pass sales channel (MaaS platform vs program-dedicated site) in the same quote comparison to extend to tourism passes later.
Q3. RYDE PASS vs our own site?
RYDE PASS-style sells bus and tourism pass products inside apps visitors already use. A program-dedicated site sells on a regional URL with the program holding purchased lists. Write sales desk and device split on the comparison table.
Q4. Which national or municipal pilots should we cite?
Use names only as model labels—e.g. wide MaaS + tourism pass (Tabi-Shinshu) or the community bus operations kit pilot—to check local route counts and operator structure.
Related service
SmartPlate Ticket
When you want purchase on a regional program web, one wallet for secondary transport in a tourism pass (bus + venues/coupons), and operator settlement, you may include SmartPlate Ticket as one program-dedicated site option in quotes. After splitting roles with transit/MaaS ticket platforms on the comparison table, see the SmartPlate Ticket service site and service materials (free).
