Survey the operation first, not the software
Surveying the operation means writing down on one sheet what is sold, through which channels each sale comes in, who enters what and where it breaks today, before looking at a single screen of any system.
It sounds like paperwork and it is the opposite. A receptive agency in Bariloche with 12 products, 3 sales channels and 2 people in the office has, without knowing it, about 30 decisions already made: only one person touches the spreadsheet, both answer WhatsApp, the agencies that buy send an email and someone types it in, tomorrow's schedule gets put together at 22:00. Each of those decisions is a question for the demo.
What comes out of that sheet is a short list of what cannot fail. In most receptive agencies it has three or four lines: capacity must not be overwritten between channels, each agency's debt must be visible without rebuilding it, the traveller must be able to pay on their own, and the day sheet must come out without typing. A system that does not solve those lines does not get a demo, however nice the website looks.
The six pieces it has to cover, and the question that reveals each one
A system for a receptive agency has to cover six pieces, and for each one there is a single question that shows in two minutes whether the piece really exists or is a module bolted onto something else.
| Piece | The question that reveals it | Where it lives in Viajalo |
|---|---|---|
| Bookings and capacity | What happens if I sell the last seat over WhatsApp and on the website at the same time? | Bookings, capacity and the day sheet |
| WhatsApp assistant | Does it answer with the real capacity of that departure or with a canned text? | WhatsApp assistant |
| Quotes | When the client accepts, is the booking born on its own or does someone enter it? | The quote as a web page |
| B2B network | Does the agency buying from me book on its own at its own rate, without paying a licence? | B2B network with current accounts |
| Administration and margin | Is debt in pesos and in dollars shown separately or converted? | Administration and margin |
| Own website | Does the traveller pay in their language and in the product's currency, or "ask on WhatsApp"? | The agency's website |
If an answer starts with "we do that through an integration", write down the name of the integration and who maintains it. If it starts with "that can be developed", write down the price.
The demo runs on your catalogue or it is useless
A demo with the vendor's sample data shows that the system works with the vendor's data, which is the one thing you will never need.
What to bring to the demo fits in an email: 3 products with their prices (one in pesos and one in dollars, to see what happens with two currencies), one departure with small capacity (the 19-seat van, not the 120-seat catamaran), the name of an agency that buys from you regularly and the last 5 quotes you sent. With that, the demo stops being a presentation and becomes a test.
At Viajalo the demo is built on the agency's real catalogue, so that email is literally the material it is prepared with. Publishing the website afterwards depends on how many products there are: days, not months.
Seven tests to run in the demo
A demo of a system for receptive agencies is judged with seven concrete tests, each with what you need to see on the screen and the sign that something is held together with tape.
| Test | What you need to see | Warning sign |
|---|---|---|
| Sell the last seat through two channels at once | One confirms; the other sees the departure sold out immediately | "That hardly ever happens" |
| Move a booking from 9:30 to 14:00 | One seat is freed and another taken, without cancelling and recreating | You have to cancel and re-enter |
| Accept a quote from a phone | The booking is born with its seats drawn down and its payment link | Someone enters it by hand afterwards |
| Have a buying agency make a booking | It logs in at its net rate and the booking lands on its current account | They get a rate sheet and book by email |
| Charge a traveller in their currency | They pay in the product's currency; the balance is kept per currency | Everything converted at the day's rate |
| Ask for tomorrow's day sheet | It comes out with pickups by hotel, a list per supplier and payment status | It is built by exporting to a spreadsheet |
| Send something to the accountant | A CSV with entries, payments and split taxable bases | "The accountant gets that from the bank statement" |
If two of these fail, you already know the operation will stay in the spreadsheet, only now with a system sitting next to it.
The warning signs show up before you sign
The warning signs when choosing a system for receptive agencies almost always appear in the sales conversation, before touching the product, and it helps to have them written down so you recognise them when they sound reasonable.
A per-user price that penalises adding the person who enters bookings or the guide who scans vouchers. A months-long implementation for a 2-person agency. A "free" migration where nobody says who loads the data or when. A single language, when 30% of January's travellers speak Portuguese. And the most repeated phrase of all, "that can be developed", which without a price and a date means it does not exist.
None of them is disqualifying on its own. Two together are.
The switch costs days of loading, not months
The real cost of changing systems in a receptive agency is the time it takes to load the catalogue and the bookings already sold, and that time is measured in days if the catalogue has 12 products and in somewhat more if it has 60, never in months.
What is worth being clear about before starting is who does the loading. At Viajalo the catalogue is built together with the agency during the demo and over the following days: products with their currency and their public and net prices, departures with their capacity, buying agencies with their credit limit. Bookings already taken are loaded with their payment status so the day sheet is complete from the first day.
What is not worth waiting for is an importer that reads any spreadsheet and sets everything up on its own. Every agency keeps its spreadsheet differently, and an accompanied load of 12 products comes out better than an automatic import that then has to be corrected row by row.
For a DMC there are two more questions
A DMC, on top of all of the above, sells to several agencies at once and operates in more than one currency, so it adds two questions to the list: how each buying agency's debt is kept, and what happens to the balance in reais, pesos and dollars at the same time.
Both have their own article, with the table of what a Latin American DMC needs from its software: Software for DMCs in Latin America.