How DMCs Can Streamline Multi-Supplier Itineraries

A seven-day itinerary with nine components is not nine bookings sitting side by side. The transfers depend on which hotel you chose. The guide's meeting point depends on the transfer. The restaurant was picked because it was walkable from somewhere.

It is a dependency graph, and that is why multi-supplier work is disproportionately hard relative to the number of lines involved. Everything below follows from taking that seriously.

Build from components, not blank pages

The single largest time saving available to most agencies, and the one most often skipped because building the library feels like overhead when there is a quote due on Friday.

You do not use a different hotel every time. You use the same forty or so suppliers, arranged differently. So the work is assembly, not research — and treating it as assembly means each supplier gets described and costed once rather than retyped into every proposal.

A component worth reusing carries: the supplier and what exactly is included, your cost and in which currency, the standard duration or timing, the description you send clients, and the cancellation terms.

Whole itineraries are worth templating too. Agencies run the same nine-day circuit repeatedly with variations — rebuilding it each time is the clearest avoidable work in the business.

The change cascade

Here is the thing that makes multi-supplier work fail, and it is rarely the change itself.

The hotel for nights three and four releases your rooms. You find an alternative twenty minutes away and consider the problem solved. It is not. That single substitution has moved:

• The transfer arriving on day three — different destination, different duration, different price
• The transfer departing on day five — different origin
• The guide's meeting point on day four, and possibly their start time
• The restaurant booked because it was walkable from the original hotel
• The client document, which now describes a hotel they are not staying in

One change, five things to touch. Handle it by memory at four in the afternoon with two other trips live and you will miss one — usually the guide, who then arrives at a hotel with nobody in it.

The discipline that prevents it: when any component changes, deliberately check the item before it, the item after it, and anything chosen for its proximity to the original. Three questions, thirty seconds, and they catch nearly all of it. Whether that lives in software or on a checklist matters less than that somebody does it every time.

Confirmation is not binary

A client asks whether their trip is confirmed. Seven components are, one is provisional, one has not been requested yet. The honest answer is complicated, and agencies frequently give a simpler one than the facts support.

Status belongs against each component rather than against the trip, and the states worth distinguishing are: requested, provisionally held, confirmed with a reference, and paid. Those are four different commercial positions and collapsing them loses information you need.

• Record the supplier's own reference against each confirmed line. Chasing a booking without it is a conversation nobody enjoys.
• Track who requested it and when, so an unanswered request surfaces rather than being assumed confirmed.
• Review the outstanding lines as a list, weekly, across all live trips. The two unconfirmed components on a trip three months out are exactly what gets forgotten.

The failure this prevents is specific and expensive: a trip everybody believed was confirmed, with one component that was only ever requested, discovered a week before arrival when the supplier has no availability left.

The release calendar

Every held component has a date after which it stops being an option and starts being a commitment. Those dates differ by supplier, by season and sometimes by room type, and they are usually recorded in whatever email the supplier sent.

Missing one does not produce an error message. It produces a cost you agreed to without deciding to — rooms you now owe for on a trip the client never confirmed.

Two habits handle most of it:

• Capture the deadline at the moment you hold the component, in the same place as the component itself rather than in an inbox.
• Look at the next fortnight's deadlines once a week, as one list across every live trip. That single review is what turns a scattered risk into a routine decision.

The same logic applies on the client side. Your deadline for a client decision should sit comfortably before your earliest supplier release date, not after it — an obvious point that is violated constantly because the two dates are tracked in different places.

Net rates, markup and separation

Every component has two numbers — what you pay and what you charge — and the operational requirement is that the first never reaches the client while the second is the only one they see.

That sounds trivial and is the source of the most embarrassing errors in this business, because the two numbers live in the same working document. A costing spreadsheet sent instead of the proposal, or a client document assembled by deleting the cost column, is how a net rate reaches an agent who then knows exactly what your margin is.

• Generate the client document rather than editing your costing into one. Deletion is a process that eventually fails; generation cannot leak a field it was never given.
• Decide markup per component, not per trip. Transfers, guides and accommodation frequently carry different margins, and a single blanket percentage hides which parts of the trip actually earn.
• Hold cost in the currency you will pay it in, since converting at quote time and forgetting is how currency movement quietly removes margin.

Where you sell both to agents at net and directly at retail, the same separation applies twice — and an agent seeing your retail price, or a traveller seeing your net, is a worse problem than either audience seeing nothing.

The client document

For most DMCs the itinerary document is the product the client actually experiences before travelling, and it does two jobs — selling the trip, then guiding it.

What belongs in it: day-by-day timings, supplier names and addresses, what is included and explicitly what is not, contact numbers that work locally, and the practical things a traveller needs at each point. What does not: your costs, supplier references, internal notes, or anything about margin.

Two problems worth solving deliberately:

• Versions. A quote revised four times produces four documents, and the client will act on whichever they opened last. Version the file visibly and make clear which one is current, or you will be arguing about a hotel nobody agreed to.
• The final version. The document that sold the trip and the document a traveller carries are not the same thing — the second needs confirmed times, addresses and contacts, issued once everything is confirmed rather than reused from the proposal stage.

If you sell through overseas agents, they also need something forwardable to their own client, which is a third audience with different requirements again — worth deciding once rather than reformatting each time.

Margin, per component

Trip-level margin is the number agencies watch and the one that reveals least. A package showing a comfortable overall margin routinely contains one component sold at a loss and another carrying the trip — and until you can see which, you cannot renegotiate the right contract or reprice the right element.

Three views worth building once:

• Margin by component type — accommodation, transport, guiding, entrances. Tells you where your business actually earns.
• Margin by supplier, which is what you take into a rate negotiation.
• Margin by client or agent, which frequently shows that your busiest partner is not your most profitable one.

None of that is possible unless cost is recorded against each component at the moment it is added. Reconstructing it afterwards from invoices is a job nobody completes, which is why so many agencies run on trip-level margin and instinct.

How Travelity helps

The trip proposal builder exists for the assembly problem — building a proposal from components and producing a client-facing document from it rather than editing a costing sheet into one. Confirmed trips carry through into bookings without retyping, and client records persist across trips.

To be clear about scope, as in the DMC software guide: we are not a full back-office system. Supplier contracting at scale, rate loading and automated supplier payment scheduling are a different category of product, and an agency whose complexity sits there should buy one.

Frequently asked questions

How can DMCs build itineraries faster?

Build a library of reusable components with costs attached rather than starting each proposal from a blank page. Most agencies use the same hotels, guides and transfers repeatedly, so the work is assembling known pieces rather than researching new ones — and a component library also means a supplier price rise gets corrected once instead of in every future quote.

What happens when one supplier in an itinerary cancels?

Rarely just one change. A different hotel usually means different transfer times at both ends, possibly a different meeting point for the guide, and any restaurant or activity booked around the old location. Treat one supplier change as touching four or five components and check the connected items deliberately rather than trusting memory.

How should DMCs track confirmation status across suppliers?

Per component rather than per trip, because an itinerary with seven of nine items confirmed is neither confirmed nor unconfirmed. Recording status against each line is what lets you answer a client honestly and what stops the two outstanding items being forgotten until a week before travel.

What should go in a client itinerary document?

Everything the traveller needs and nothing about your costs. Day by day timings, supplier names and addresses, what is included, what is not, and emergency contacts. Net rates, markups and supplier reference numbers belong in your own records, and a document assembled by copying from an internal file is how they leak.

How do DMCs avoid missing supplier cancellation deadlines?

Record each supplier release deadline against the component when you book it, and review those dates as a list rather than as scattered notes. Deadlines differ by supplier and by season, and missing one converts an option you were holding into a cost you have committed to without deciding to.

Bottom line

Treat the itinerary as a dependency graph rather than a list. When one component changes, check the item before it, the item after it, and anything chosen for its proximity — three questions that catch nearly every cascade failure.

Then build from reusable costed components so a price rise is corrected once, keep confirmation status per line rather than per trip, review supplier release deadlines weekly as a single list, and generate client documents rather than editing your costing sheet into one.

Related guides

• Booking software for DMCs and travel agencies
• Managing group bookings and private tours
• Multi-currency pricing for tour businesses
• How to take deposits for multi-day tours
• Tour booking software for small operators: a complete guide