Choosing software as a DMC, not as an agency

Most travel software is built for the company that owns the client. A DMC does not own the client — it owns the ground — and almost every assumption in a normal travel CRM is wrong for that shape of business. The demo still looks fine, because a demo is one quotation to one buyer.

Your buyer is an agency, and they resell your number

An agency quoting a traveller can round, pad and present. You are quoting somebody who will add their own margin and send it on, which changes what the document has to be.

• Your net has to be unambiguous. A single blended figure forces your buyer to guess what they can mark up. Per-person by occupancy, per-vehicle, per-extra — priced as lines they can rebuild.
• Your document will be re-branded. Assume it. If your quotation cannot be produced without your letterhead, your buyer will retype it into theirs, and every retyping is a chance for your number to arrive at the traveller wrong.
• Your terms travel with it. The release period and the cancellation ladder are the parts an agency most often drops when they rebuild the document, and they are the parts that cost you money when a group falls away.

White-label quotations covers the other side of the same arrangement.

One trip, several prices, all correct at once

The hardest requirement, and the one that is usually absent. The same Kathmandu-Pokhara-Chitwan week is not one price. It is a different price for a European agency on contracted rates, a domestic agency on your standard net, and a long-standing partner on a negotiated one — and it has to be possible to change one of those without touching the others.

Software that stores a package with a price attached cannot do this. Software that stores a package as a shape and prices it against whichever rate set applies can. Ask the demo to produce the same itinerary at two different net levels and watch how much of the work is repeated.

The rate card is the product

For an agency, the rate card is a cost input. For a DMC it is the thing you sell, and the operational question is who keeps it current. Four hundred hotel rows across a season, plus vehicles, guides, permits and monument fees, changing at least twice a year.

The useful test is not whether the software has a rate table. It is whether somebody who is not you can maintain it — a hotel updating its own rows, a colleague loading a season — and what stops them from seeing anybody else's. See hotel contracting before you sign.

Currency, because you have three of them

A DMC's cost lines arrive in the currency each supplier contracted in and go out in the currency the buying agency works in. The failure is not exotic: a platform that converts everything to one base at a rate typed in months ago, and a total that silently adds two currencies together because no line carries its own.

The safe design keeps the supplier's currency on the supplier's line and states it. See quoting in the supplier's currency.

What happens after the quotation is accepted

An agency's work mostly ends at the booking. Yours starts there — rooming lists, hotel confirmations, vehicle allocation, guide rosters, arrival transfers against flight times. A platform that is excellent at quoting and has nothing after it means the operations half of your business stays in WhatsApp and a spreadsheet, which is where it already is.

This is worth being honest about when you evaluate. A quotation tool is not an operations tool, and a vendor who says it is both usually means it has a booking status field.

The questions to ask, in order

• Can the same itinerary carry two different net rates without being rebuilt?
• Can a document go out on my buyer's branding, with their terms, and no trace of the platform?
• Can a supplier maintain their own rates without seeing anybody else's?
• Does every cost line keep its own currency?
• What exists after "accepted", and is it a status or a workflow?

None of these come up in a first demo, and all five decide whether the thing survives a season.