The first customer set the scope: build the booking core for the office first. The first pass is these 8 office screens. Everything else is the expansion, sequenced inside-out on top of a working booking core.
Why they switch (it is not a nicer spreadsheet)
The first pass does not yet remove the office's data entry. It removes the fragility. It wins on three things Excel cannot give them: it gets the operation out of a few heads and makes the day one-person-runnable by any office staffer, it looks professional to the operators Kalitravel depends on, and it is the foundation every offload channel later writes into. Sell it on resilience and professionalism, not on less work.
Only the bus company's office logs in. Two roles: Manager (ops manager or owner) and Staff (office assistant). Both see the whole company's bookings and the daily board, and both can create, edit, move, and cancel bookings. The Manager additionally manages the catalog, schedule, users, and settings. Tour operators are reference data, not users.
Daily Operations Board
Manager + StaffThe spreadsheet replacement. The make-or-break screen. Shared across the whole office.
Bookings
Manager + StaffCreate, edit, move, and cancel bookings; filter across dates. The whole company sees every booking.
Tour List
ManagerThe catalog of bookable tours.
Create / Edit Tour
ManagerThin: the catalog can be seeded, a minimal form is enough.
Schedule
ManagerDefine which tours run on which days, producing tour instances.
Tour Planning grid (NEW)
Manager + StaffForward occupancy: tours as rows, days ahead as columns, booked/seats per cell. From the 2026-06-19 field video.
Board sticky double-header (NEW)
Manager + StaffScroll demo: the date and the current tour stay pinned. From the 2026-06-19 field video.
Office Login
Manager + StaffManager and staff authenticate here, with role-based redirect.
Office Dashboard
Manager + StaffToday and this month at a glance, across the whole office's bookings.
Booking Entry
Manager + StaffThe office enters a booking that arrived from an operator or referral agent, with all 14 manifest fields.
The order is deliberate, from the inside out, because the inside is the lowest-friction adoption path. No external party has to change anything first. The wireframes below are the expansion, not the first pass.
A direct booking widget on Kalitravel's own site. Fully in our control, it offloads entry for direct bookings and opens the commission revenue. This is the easiest offload and comes first. Prices belong here, not in the office core.
The big operators (TUI, Alpitour) will never log into Kalitravel's tool, so their bookings are imported from their feeds, not typed and not self-served. Harder than the widget because every feed differs. Invoicing, commissions, and reconciliation land here too.
Drivers, language matching, and assignment, then the north star: a two-sided operator portal where operators have their own logins and users and self-serve bookings. A future direction, not a near-term build.
Full implementation plan
The technical architecture, data model, screen specs, build plan, deployment, and security review live in ideaplaces-docs under Tour Platform / Implementation Plan.