Sales to operations handover: what ops needs when a trip is won

A good sales-to-operations handover gives operations everything it needs to book and run the trip without asking sales again: what the client accepted, each service with its supplier and its status, every traveller as named in their passport, the flights, the client's special requests, and the money due both ways. It also names one operations owner and a date to start.

What operations needs from sales when a deal is won

Sales asks "did they say yes?"; operations asks "what exactly did we promise, to whom, from which supplier, and who pays whom by when?" Every item below should be on the deal before anybody says "it's yours".

Name the operations owner before the deal is won

A deal in the iTravel travel CRM carries two people: the seller who wins it and the operations owner who will run it. Name the second before the deal is won, so the person who will answer the duty phone has read the file before the client pays a deposit.

Make it a rule rather than a habit. A stage gate says what must be filled in before a deal may enter a stage you choose: for example, no "Confirmed" without travel dates, the travellers and the operations owner. Nothing is required until you set it, and something that simply happened, such as a client accepting on the quotation's link, is never refused by a gate. How to lay the stages out is in travel sales pipeline stages.

Travellers and flights: collect them once, from the people who have them

Retyping names from a photo of a passport is where spelling errors are born. Collect the details from the travellers, once.

• Named travellers and a rooming list sit on the deal, and the rooming list also works as a spreadsheet for a group.
• A details link lets the traveller, or the lead for the whole party, fill in the details you choose to ask for: names as in the passport, date of birth, passport number and expiry, nationality, diet, access needs and medical notes, and an emergency contact at home. Health details are kept only with consent. The link expires after the number of days you set, can be revoked, and never clears an answer already given.
• A partner agency's traveller is reached only through the agency. The link goes to the agency, in the agency's brand, never to their client.
• Flights come from the booking itself. Paste the reservation text from a GDS or an airline e-ticket and each segment comes back for review: flight, date, airports and times as printed, in local time. The status code decides whether a seat is held: HK, KK, TK, RR and HS are; HL, UC and the rest are not, and the handover should say so.

Suppliers: who, what you asked, and what they promised

Every line of the quotation should name who supplies it. A supplier is one record across your account, holding its reservations inbox, office phone and the duty phone someone answers at night, its payment terms in days before the service, the currency it invoices in and the language you write to it in. If you price from your own rate cards, each card names its supplier as well (DMC rate sheets covers keeping them).

For a service you do not contract, ask before you promise. An availability request asks "can you do it, at what price, and will you hold it until…?" The supplier answers on a page with no login, the answer lands on the quotation line, and the deal's owner is told. The question carries the service, its days and the party, never the client's name, email or phone, and never your price.

The handover must keep three states apart: confirmed, held until a date, and only priced. A hold has a deadline, and a deadline belongs on somebody's task list.

Money due both ways

From the client. The deal's payment schedule holds each instalment with its due date and amount, and what came in. Every unpaid instalment is one task due on its date, judged in your agency's own timezone, so "balance due" turns up in the morning list rather than in somebody's memory. You can send a link to pay the next instalment online, and switch on reminders that go before, on and after each due date, on the days you choose.

To each supplier. The supplier's terms say how many days before the service it is paid. Put those dates on the handover even when finance pays: operations is the first to hear that a supplier has not been paid.

Which comes first is your policy. Some businesses pay a supplier only once the client's deposit has cleared; others pay on the supplier's terms whatever the client does. Write yours down once, so operations does not decide it file by file. If the client is slow to accept in the first place, travel quotation follow-up is the step before this one.

What goes on the documents, and what stays inside

• The client's copy carries what they accepted, at the price they accepted. Your cost and margin are not hidden by a template: they are never written into the client's paper at all.
• An availability request shows the supplier the service, its dates, the party and your note, never your client's contact details or your price.
• If you also run Vouchers, each service has a guest note that prints and an internal note that never leaves the workspace, so "late check-out requested" reaches the hotel and "client complained about the last trip" stays inside. What the paper itself must say is in what a hotel voucher must show.

The handover itself

In the CRM alone, the deal is the file: operations works from the same deal, with its quotation, travellers, suppliers and schedule. Turn the handover into a step with a checklist template: items such as "traveller details complete, 21 days before departure" or "reconfirm hotels, 3 days before departure", each assigned to the operations owner. An automation rule you write applies it when a deal enters your won stage. If the client moves the trip, the open checklist tasks move with it, except any a person has already re-dated by hand.

If you also run Vouchers, the won deal goes to operations in one press, as a trip.

• It carries the file reference, the named travellers and the rooms, so nobody retypes forty names, and it goes to the operations owner.
• The lines of the accepted option, with the lines common to every option, become the trip's services at the client's price, each keeping its supplier. An optional extra goes only if it was taken. A line with no date is named back to be added by hand, never given an invented date.
• The client's brief goes onto the trip as its note.
• The handover creates one task for the operations owner, naming the file and the dates, due tomorrow, or today when the trip starts within a week.
• Pressing twice still opens one trip. If the deal changes hands later, the trip follows the new owner, unless operations has given it to someone on purpose.

If you also run the booking portal, a won deal can be booked there on its own file, and its first booking marks it as with operations and creates the same single task.

A worked example: a family of four, won 24 days before travel

Say two adults and two children, aged 9 and 5, accept option B of a five-night quotation 24 days before they travel: two hotels, arrival and departure transfers, one guided tour, and the optional dinner cruise ticked. This is the handover as operations should receive it.

In the CRM alone, the won stage applies your checklist, and "traveller details complete, 21 days before departure" lands three days from now. With Vouchers, the handover also makes one task for the operations owner, due tomorrow, as the trip starts more than a week out. Either way, the hold on Hotel 2 and the waitlisted return flight can change the trip, so they go first.

Handover checklist

1. The operations owner is named, and your stage gate requires it before the stage you call confirmed.
2. The accepted version, option and extras are clear on the deal, and nothing quoted but not accepted is on the handover.
3. Every line names its supplier, and each service says whether it is confirmed, held until a date, or only priced.
4. Every traveller is named as in their passport, with ages, rooms, and passport expiry checked against the travel dates.
5. Flights are pasted from the booking, and any segment that is not held is flagged.
6. Special requests are in the client's own words; health details are kept only with consent.
7. Every client instalment has a due date, and every supplier's pay-by date is written down.
8. Nothing internal is on a paper the client or a supplier will read.
9. Operations has one task, one owner and one date to start.