A cruise booking is not a hotel stay with a boat attached.
Ship, sail date, stateroom category, cabin number, deck, dining preference, port-by-port itinerary, final payment date. Every one of them is a field in Travel Agent Companion — not a sentence you typed into a notes box and hope to find again.
The fields a cruise actually needs
Most CRMs model a trip as a date range with a price. That is enough for a hotel and not enough for a sailing. These are the cruise-specific fields a reservation carries, each one stored as data you can filter, report on and sort by.
- Cruise line and ship
- Both are references, not free text — so a sailing can be reported on, filtered, and priced against the right vendor profile.
- Cabin number, type and deck
- Balcony, cabin 9214, deck 9. The three facts a client asks about first, and the three a notes field loses.
- Dining preference
- Early, late, or open seating. Cruise-only, and the kind of detail that decides whether a repeat client feels remembered.
- Sail date and itinerary
- Port-by-port, with sea days as sea days rather than gaps in a calendar.
- Final payment due date
- Cruise lines cancel for a missed final payment. It is a tracked date with its own received date, not a reminder you set yourself.
- Deposit and planning fee
- Deposit amount and the date it landed. Planning fees are tracked separately, because they are your revenue rather than the vendor’s.
- Confirmation number and supplier
- The number the client quotes back to you, against the supplier who issued it.
- Booking value and commission
- What the trip is worth and what you earn on it, expected and received tracked apart.
Built for independent cruise agents and agencies of two to five — not adapted from a hotel CRM.
Join the waitlistBookings become journeys
When a proposal is approved, the quote becomes a journey in draft. Take the deposit, confirm the reservations, and it moves to active — then completed once everyone is home. Draft, active, completed, cancelled; no invented statuses in between.
A journey holds every reservation for the trip, and a trip is rarely only the sailing. The same journey carries the flights, the pre-cruise hotel night, and the transfer to the terminal, because a reservation can be a cruise, a flight, a hotel, a car, a train, a bus or a ferry. One trip, one page, whatever it is made of.
Documents live on the journey — e-tickets, vouchers, itineraries — so the thing a client asks for is attached to the thing they are asking about.
Groups, with cabin blocks and their own deadlines
A group cruise is not fifteen separate bookings and it is not one big one. It is a block of cabins held against a sailing, with a payment schedule per traveller and deadlines that belong to the group rather than to any one person on it.
Travel Agent Companion models that directly: the cabin block, the travellers in it, who organises it, the payments each has made, the documents the group shares, and the group’s own deadline schedule. A generic CRM asks you to keep that in a spreadsheet, because it has no concept of a cabin block at all.
Overview: key dates, a financial summary with payment progress, cruise details including the cabin block, and four cabins with their occupants.
Supplier confirmations, parsed and then approved by you
Confirmations arrive as email. The platform reads them — attachments included — and proposes what it found: this looks like a reservation, on this sailing, for this contact, on this journey.
Then it stops and waits. Nothing is written to your records until you approve the match. Every parse is a candidatewith a decision attached, and the run history is kept, so a wrong guess is visible rather than silently merged into a client’s file. Re-keying confirmation numbers by hand is the tax; a machine guessing on your behalf without asking is the risk. This is the middle.
Contacts, travellers, and the person who pays
The person paying is often not the person sailing. A grandparent books the cabins; a corporate assistant arranges the trip; one member of a family holds the credit card for all six. So contacts and travellers are separate records that link, rather than one record pretending to be both.
Travellers attach to the reservations they are actually on. That is what lets a group’s payments, documents and deadlines resolve per person instead of per booking.
What the client sees
Travellers get their own portal view of the trip. You can preview exactly what a given client sees before you send it, from their contact page — so “what did they get?” is something you look at rather than something you reconstruct.
| A general-purpose CRM | Travel Agent Companion | |
|---|---|---|
| The sailing | A date range and a price, with the ship and itinerary typed into a notes field. | Cruise line, ship, sail date and port-by-port itinerary as references and dates you can filter and report on. |
| The cabin | No concept of one. Stateroom category becomes free text, if it is recorded at all. | Cabin number, cabin type, deck and dining preference as fields on the reservation. |
| A group | Fifteen separate deals, or one deal and a spreadsheet of who has paid. | A cabin block with its own deadline schedule, per-traveller payments, organisers and shared documents. |
| Supplier confirmations | Forwarded to yourself and re-keyed by hand. | Parsed from email, matched to a contact or journey as a candidate, and written only once you approve it. |
Why a general-purpose CRM can't do this
It is not a matter of effort or configuration. A CRM built for hotels and flights has no column for a stateroom category, no concept of a cabin block held against a sailing, and no notion that commission on this booking will arrive eleven months after you made it. You can add custom fields, and many agents do. What you cannot do is report on them, sort by them, or trigger anything from them — because to the system they are still just text.
The result is the arrangement most cruise agents already live with: the CRM holds the client, and a spreadsheet holds everything that makes the booking a cruise. Two records of the same trip, and the important one is the spreadsheet.
Keep reading
- Sales workflow
Inquiry to deposit, in five phases.
- Data ownership & migration
Your book of business stays yours.
See your bookings stored the way you actually sell them.
Travel Agent Companion is in early access. Join the waitlist and we’ll email you when it opens up.