How to write a trip handover brief that doesn’t suck (a template for tour operators and DMCs)

A trip handover brief is the document that gets a trip from the designer’s head into the hands of whoever is going to operate it — an ops manager, a guide, a partner DMC, a relief team member who picked up the phone at 3pm on a Friday.

Most handover briefs fail in the same predictable ways: too long, written like a sales pitch, missing the things a guide actually needs at the airport, and assembled at 11pm the night before departure. This article is the template we’d hand to any operator who asked.

What a handover brief is actually for

The brief has three jobs:

• Give the operator enough context to make sensible judgement calls on the day, without phoning the designer
• Surface the things that aren’t in the system — quirks, agent context, things the client said but never put in writing
• Be readable in 90 seconds by someone who has never seen this trip before

That third one is the bit most briefs fail at.

The 90-second rule

Imagine a guide is standing at the arrivals exit, phone in one hand, name board in the other, with 90 seconds before the clients walk through. They need to glance at the brief and have the answers to:

• Who am I meeting?
• How many of them are there?
• What’s their first move from the airport?
• Is there anything weird about them I need to know before saying hello?
• Who do I phone if something goes sideways?

Everything in the brief should serve those questions. If a section doesn’t, it’s either in the wrong place or it shouldn’t be there at all.

The template

Here’s the structure that survives operator-to-operator handovers, designer-to-ops handovers and ops-to-guide handovers. Six sections, in this order.

1. Trip snapshot

Top of the page. Big enough to read on a phone at arm’s length. This is what the 90-second reader looks at first.

• Trip name (Whitfield · Rwanda + Kenya)
• Dates (15 — 26 May 2026)
• Pax (2 adults)
• Agent and market (Origin Travel · London)
• Trip designer and ops owner (with phone numbers, not just names)
• One-line summary (“12-night gorilla + Mara honeymoon, all internal flights confirmed”)

2. Guest context

What the operator needs to know about the people before they meet them.

• Names and how they pronounce them
• Reason for travel (honeymoon, anniversary, family reunion, first safari)
• Dietary, mobility, health-relevant context
• What they’re excited about
• What they’re anxious about (this one matters)
• Things they asked you to keep in mind

This is where “the agent told you something quietly six weeks ago” goes. If you don’t put it here, it dies with whoever heard it.

3. Itinerary at-a-glance

Not the full proposal. Not every transfer time and meal plan. A day-by-day strip:

• Date · property/location · key activity · who’s with them

Two lines per day, max. The detail lives in the system; the brief is the index.

4. Commercial status (internal only)

Visible to ops but never to the client or agent. Just three lines:

• Quote status (sent / approved / locked)
• Payment status (deposit received / balance due)
• Anything outstanding the agent owes us (signed form, passport scan, dietary form)

5. Operational readiness

The checklist. Each item is binary: done or not.

• Flights confirmed and matched to transfers
• Supplier confirmations received from every property
• Welcome letter and final documents sent
• Guide briefed (where applicable)
• Vehicle assigned (where applicable)
• Emergency contact card prepared

If anything is missing, name it explicitly with the owner and the deadline. Vague items (“finalising flights”) are the things that bite at 11pm on the eve of arrival.

6. Next actions

Ordered. Owned. Dated. Three to five lines at the bottom of the brief.

Example:

• Mon 19 May — Confirm Singita activity preferences with agent (Owner: Lara)
• Tue 20 May — Send final docs pack (Owner: Lara)
• Wed 21 May — Guide briefing call with Joseph (Owner: Ops)

What to leave out

• Marketing prose. The brief is not a proposal. No “immerse yourself” sentences.
• Full supplier rate cards. The brief links to the supplier record; it doesn’t copy it.
• Everything the agent said in three months of emails. The brief captures what matters at handover, not the full email chain. Keep the chain in the system, in case it’s needed later.
• Stuff that contradicts the proposal. If the brief and the proposal disagree, the trip is in a bad place. Reconcile before sending the brief.

How long should it be?

Two pages on a desktop. One page if you can. If your brief is five pages, you’re using it as a backup for the system, which means the system is failing somewhere else.

When to write it

Not the night before. The brief should be updated as the trip moves through its lifecycle — by the designer when they confirm flights, by ops when they confirm suppliers, by finance when they confirm payment. The “handover” isn’t a one-time write; it’s a state the trip is in by the time it’s ready to operate.

Generating it from the system

If your operating system holds the structured data — guests, dates, properties, flights, transfers, agent context, payments, tasks — then the brief shouldn’t need to be typed out from scratch. It should be generated, then edited.

That’s exactly what FieldDesk’s operations brief does: generates a handover brief from the trip’s structured data, then waits for you to edit it inline before you share. It’s one of the four AI features live in FieldDesk today. Like all of them, it lands as a draft for review — never auto-sent, never auto-shared.

One-page summary

• The brief has three jobs: context, surface the unwritten, be readable in 90 seconds
• Six sections: snapshot · guests · itinerary · commercial · ops readiness · next actions
• Two pages max
• Update it as the trip moves through its lifecycle, not the night before
• Generate it from structured data if you can; edit it before you share

If you want to see what a structured handover brief looks like generated from a real trip, book a demo and we’ll show you live.