What a DMC is and why its software is different
A DMC (Destination Management Company) is the receptive agency that builds and operates services at the destination, and sells them both to travellers who arrive on their own and to the outbound agencies that send them from another city or another country.
That double sale changes everything. An outbound agency quotes other people's products and its problem is getting paid. A DMC has seats: the boat to Isla Victoria carries 120 people, the van to Tronador carries 19, the canopy guide takes 8 per slot. Each of those seats can be sold from the website, over WhatsApp, at the counter, or by an agency in São Paulo that holds it on a current account. If the four channels do not draw down the same number, one Saturday in January you sell 21 seats in a 19-seat van.
Software for a DMC, then, is not an invoicing system with a bookings module bolted on. It is a capacity system with everything else built around it.
Eight things it does every day, and what holds them up
The eight things a Latin American DMC does every day, and how each tool holds up: the spreadsheet plus WhatsApp most agencies use, and a system built for receptive work.
| Need | With a spreadsheet and WhatsApp | What the software has to do |
|---|---|---|
| Capacity per departure | Someone checks the sheet before confirming, and sometimes does not | Stop the sale in every channel at once when it sells out |
| Selling to other agencies | Rate sheet by email, booking by WhatsApp, debt in another tab | The agency logs in with its net rate and books on its own |
| Each agency's debt | Rebuilt at month end | Current account with debit, credit, balance and a credit limit |
| More than one currency | One column in pesos, another in dollars, converted by hand | Each product in its currency; the balance, per currency |
| The traveller's language | The PDF gets translated when needed | Website and voucher in the buyer's language |
| The day's operation | Put together at night, by hand | Day sheet, supplier lists and pickups come out on their own |
| Invoices and tax | The accountant asks the passenger's nationality booking by booking | Taxable base split by rate and by nationality |
| Cost and margin | Worked out once a year, if at all | Supplier cost per product; margin per period, without retyping |
None of these rows is exotic. They are the same eight things in Bariloche, Cusco, Cartagena and Foz do Iguaçu.
Capacity is the heart of it
The capacity of a departure is the number of seats left to sell on a specific date and time, and it is the one piece of data that has to live in a single place so no channel overwrites another.
It sounds obvious and almost nobody has it. The spreadsheet holds the capacity, but the booking is entered by whoever answered the WhatsApp, and between answering and entering, two hours and another sale went by. The system has to work the other way round: the booking draws down capacity the moment it is confirmed, wherever it came from, and when the departure sells out it disappears from sale at the same time on the website, in the assistant and in the catalogue the agencies see.
There is a second part people overlook: moving a booking to another time without losing the seat. A traveller asks to switch from the 9:30 catamaran to the 14:00 one. In the spreadsheet that is two cells and a phone call. In the system it has to be a change of departure that frees one seat and takes another.
Each agency's debt keeps itself or does not get kept
A current account between agencies is the record of what each buying agency owes the DMC for the services it booked and has not paid for yet, and it is the part of the business that survives worst in a spreadsheet, because the booking is entered by the other side.
In practice it runs on three pieces. A net rate per agency, different from the public price. A credit limit that stops new bookings when the debt reaches it, instead of letting it grow until someone notices. And a periodic settlement against an invoice, a transfer or an offset.
What a DMC needs from the software here is for the buying agency to come in through a link, see the catalogue at its own price, book on its own and have the booking land on its account at that moment. No rate sheet by email, no confirmation WhatsApp, no parallel debt spreadsheet. If a booking changes buying agency (it happens more than you would think), the account is reassigned without cancelling and recreating.
One detail that separates a system designed for receptive work from one adapted to it: the account with suppliers. The DMC does not only collect; it also owes the boat, the van and the guide. Both accounts have to be visible in the same place.
Currencies, languages and invoices: what the region adds
Operating in Latin America adds three layers that software built for Europe or the United States does not ship with: more than one currency inside the same agency, travellers who buy in their own language, and invoices with tax rules that change depending on who is buying.
For currency the rule is a single one: each product has its own and nothing gets converted on its own. An excursion sells in pesos, a private transfer in dollars, and the Brazilian agency owes reais. Adding it all up at the day's exchange rate produces a number that belongs to nobody. The balance is kept per currency and settled per currency.
For language, the traveller has to be able to choose, pay and receive the voucher without anyone translating by hand. A website in more than 15 languages handles the Brazilian who arrives in Bariloche in July and the French visitor who arrives in January with the same effort.
And for invoices, the taxable base has to come out split by each product's rate and by the passenger's nationality, because the accountant will ask booking by booking if the system does not have it ready.
Six questions that separate a receptive system from a bolted-on module
The questions that separate a system that understands receptive work from one that bolted a bookings module onto something else, and the answer worth hearing in each case.
| Question | Why it matters | The answer you want to hear |
|---|---|---|
| What happens if I sell the last seat over WhatsApp and on the website at the same time? | This is the case that breaks the spreadsheet | Whoever confirms first wins; the other sees the departure sold out |
| Does the agency buying from me have to pay a licence? | If it pays, it will not come in | It logs in through a link with its own user, without signing up for anything |
| How is debt kept in two currencies? | Converting invents an exchange rate | Balance per currency, settled separately |
| How long does loading 12 products and 40 departures take? | Months of implementation kill a small DMC | Days for the catalogue, not months; the demo is built with your products |
| Does the voucher carry the buying agency's brand? | The outbound agency does not want its traveller seeing another brand | Yes, with its brand and its cancellation policy |
| What do I send the accountant at month end? | If it has to be rebuilt, it is useless | A CSV export with entries, payments and split taxable bases |
If any answer starts with "that can be developed", write down the price of that development before going any further.
Who it is for, and who it is not for
Viajalo is built for small and mid-sized receptive agencies and DMCs that sell departures with limited capacity: regular excursions, shared transfers, boat trips, adventure activities and ski resorts, in Argentina and across the region.
It is not an airline GDS or an ERP for an operator with hundreds of employees and dozens of branches. If the core business is issuing tickets or packaging third-party flights, there are better tools for that. If the business is operating seats at a destination and selling them through several channels at once, this is exactly what it was built for.