A scheduled departure is sold one booking at a time and operated as one group. This guide explains the difference between a trip and a departure, how capacity and room inventory work, what it takes to operate the group as a unit, and how Tourcube's departure record handles it.
Group tour operator software manages scheduled departures: fixed-date trips sold seat by seat, and usually room by room, up to a maximum group size, then operated as one group with shared guides, suppliers, rooming, and documents. The trip is the product, the departure is the operated instance of it, and each booking joins a departure.
It is the operations-heavy half of tour operator software. Selling a scheduled departure is fast because the product is already priced; the work is in knowing what can still be sold, and then running the date well once it is full. That is why the departure record, rather than the booking, is the center of this kind of operation.
Most confusion in this area comes from mixing the two up. A trip is defined once with everything attached to it. A departure is created for each date the trip runs, inherits the trip's setup, and then accumulates its own bookings, guides, vendor services, and money.
| Lives on the trip | Lives on the departure |
|---|---|
| Trip code, name, duration, rating, brand, accounting group | Departure date, departure ID, status (planned, active, waitlist) |
| Inventory model: persons, rooms, room types, cabins, composite; options and choice groups | Allotments per room type, rooms and persons sold and available, waitlist entries |
| Seasons, price codes, seasonal pricing; payment and cancellation terms | Departure pricing and group allocations of rooms and services |
| Itinerary content, seasonal content, documents and forms, task schedule | Bookings and passengers, guides assigned, tasks generated from the schedule |
| Distribution settings and publish-to-web state | Budget and operations, vendor payments, booking receipts, profitability |
| Change history on the trip | Vendor and passenger communications, reports, portal documents, air |
When a trip's terms or content change, every future departure picks the change up. When a departure's guide or hotel changes, only that date is affected. Software that does not separate the two either makes every departure a copy that drifts, or makes every change a global one.
SUMMIT TRAILSCtrl K?✨Support RequestLog Out| Departs | DepartureID | Nights | Status |
|---|---|---|---|
| 08/14/2026 | FJE081426 | 10 | Active |
| 09/04/2026 | FJE090426 | 10 | Active |
| 09/18/2026 | FJE091826 | 10 | Waitlist |
| 06/19/2027 | FJE061927 | 10 | Planned |
| Room Type | Rms Alot | Rms Sold | Rms Avail | Psn Avail |
|---|---|---|---|---|
| Double | 6 | 5.00 | 1 | 2 |
| Single | 2 | 1.00 | 1 | 1 |
| Totals | 6.00 | 2 | 3 |
A trip's departure dates in Tourcube, each with its own status, and the room-type inventory for one selected date: rooms allotted, sold, and available, and persons available.
The trip record lists its departures with their status. Selecting one shows that date's inventory: how many rooms of each type are allotted, sold, and still open, and how many people can still be booked. Adding a date is a matter of creating a departure from the trip, not copying a spreadsheet tab.
Day-tour software counts seats. A multi-day group departure counts rooms and people at once, because a double room can hold one traveler or two, a single supplement changes the room mix, and guides occupy rooms without being sold. The software has to answer two questions for every date: how many more travelers can we take, and in what room configuration?
Each trip declares how it is sold: whether it has scheduled departures, which inventory types apply, whether it has options or choice groups, whether a private version is available. Every departure and every booking on the trip then follows those rules, and the booking screen only asks for what the trip needs.
SUMMIT TRAILSCtrl K?✨Support RequestLog OutThe Trip Rules on a Tourcube trip record. This trip sells scheduled departures with rooms, persons, and room-type inventory, and has options but no choice groups or tiered pricing.
Once a departure has bookings, almost everything that happens next happens to the whole date rather than to one traveler. This is where scheduled-departure operators spend most of their time, and where a departure record earns its place.
Rooms and services for the whole date are confirmed with hotels, transport, and guides once, as allocations, rather than booking by booking. Deposits and balances to those vendors are requested from the departure. Vendor payables, explained →
Guides and trip leaders are assigned to the departure, counted in the room and person totals, and given a portal with the guest list and every document for that date.
Invoices, pre-trip reminders, and final documents are generated for every passenger on the departure in one pass, from a named staff member, with per-booking status showing who has received what. Guest communications and portals →
Health, waiver, and preference forms are chased and captured into the bookings. What travelers enter, such as dietary needs or a medical note, flows into the manifests without retyping.
Arrival and departure flights are tracked per booking and summarized per departure, so transfers and pre-trip nights can be planned from an air manifest rather than a mailbox.
The trip's task schedule generates the departure's to-dos automatically. Budget and operations track the departure's costs against its receipts as the date approaches.
| Doubles | ||
| Room #1 | Carter, Douglas | |
| Carter, Elaine | Anniversary trip | |
| Room #2 | Dixon, Linda | Gluten-free |
| Dixon, Robert | ||
| Room #3 | Ellis, Barry | |
| Ellis, Joan | Ground floor preferred | |
| Singles | ||
| Room #6 | Bennett, Susan | Vegetarian |
| Room #7 | Holloway, Karen | |
| Name | City and State | Gender | DOB | Age | Previous Trips | Occupation |
|---|---|---|---|---|---|---|
| Carter, Douglas | Ashland, OR | M | 04/12/1961 | 65 | 3 | Retired |
| Name | City and State | Gender | DOB | Age | Previous Trips | Occupation |
|---|---|---|---|---|---|---|
| Bennett, Susan | Santa Fe, NM | F | 09/02/1968 | 57 | 1 | Architect |
| Name | City and State | Gender | DOB | Age | Previous Trips | Occupation |
|---|---|---|---|---|---|---|
| Dixon, Linda | Boise, ID | F | 06/23/1970 | 56 | 5 | Teacher |
A rooming list and a departure manifest, both generated from the same departure's bookings. Dietary needs, special occasions, and emergency contacts come from the forms travelers completed.
The rooming list a hotel receives and the manifest a guide carries are only trustworthy if they are produced from the live bookings on the departure. When they are, a late cancellation or a room change is one edit on the booking, and every document reflects it the next time it is produced.
Setup once on the trip, dates created from it, each date with its own bookings, guides, vendors, and money.
Allotments per room type, sold and available computed live, guides accounted for, and inventory models that match how the product is sold.
Held against the departure and turned into bookings when space opens, without re-entering the party.
Group allocations, vendor communications, and vendor payments requested and tracked per date.
Rooming lists, manifests, and air lists generated on demand, with the guide portal as the way they reach the field.
Invoices, reminders, and final documents built for every passenger on the departure in one pass, with per-booking status.
Staff can filter dates by brand, destination, activity, and availability and create a booking in seconds. The booking record →
Receipts and vendor costs on the same date, so each departure's result is visible without a spreadsheet.
The departure screen is the deepest in Tourcube: seventeen working panels covering bookings and passengers, budget and operations, accounting split into vendor payments and booking receipts, pricing, inventory and waitlist, reports, portal documents, itinerary, air, vendor communications, passenger communications, tasks, comments, group allocations, forms and pre-trip questionnaires, custom fields, and setup. Availability is computed live from allotments, and persons account for guides automatically.
Trips are defined once with departure dates, seasons and seasonal pricing, seasonal content, task schedules that generate departure to-dos, distribution settings, and one-click publishing to the website. Trip Shopper lets staff filter departures by date, brand, destination, rating, activity, or theme and create bookings for scheduled trips quickly, and the home page splits each user's departures by development and operations role.
A trip is the product: the code, the itinerary, the duration, the inventory model, the seasons and prices, and the content. A departure is one operated instance of that trip on a specific date, with its own capacity, bookings, guides, vendor services, and budget. Bookings join a departure, not a trip.
By room type and by person at the same time. Each departure holds an allotment of rooms per type (double, single, guide room) and a person capacity. Rooms available equal the allotment minus rooms sold; person availability accounts for guides automatically. A trip's inventory model can be standard, room type, cabin, or composite depending on how it is sold.
The departure moves to a waitlist status and new requests are held against it. When a cancellation frees space, availability updates immediately from the allotments and a waitlisted party can be converted to a booking.
Yes. A departure can be flagged private or custom for a group that takes the whole date, while still using the trip's itinerary, pricing, task schedule, and documents.
From the departure's live bookings. Rooming lists, manifests, air manifests, hotel lists, guide contact lists, passport manifests, and dining manifests are generated as PDFs from the departure record, with Flex reports adding grid tools and Excel export. They are never maintained as separate documents.
Yes. Guides and trip leaders have a mobile-friendly portal for the departures they are assigned to, with guest lists and guest details, every departure document and report, and uploads for required forms and expense reports.
Yes. Tourcube's departure record is the deepest screen in the platform, with seventeen panels covering bookings and passengers, budget and operations, accounting, pricing, inventory and waitlist, reports, portal documents, itinerary, air, vendor and passenger communications, tasks, comments, group allocations, forms and pre-trip questionnaires, custom fields, and setup.
These guides explain how multi-day tour operations work and what software should do about it. Start with the overview, or go straight to the part of the business you are thinking about.
We will set it up in the actual product, from inventory to rooming list, and give you an honest read on fit.
Book a demo