Automate everything except the money

The pitch for automating travel operations is easy to make and mostly correct. Coordination work is repetitive, high-volume, low-judgment, and identical across thousands of agencies. Software is good at exactly that shape of problem.

So it’s worth being specific about the one place where the argument stops — and why stopping there is a feature rather than an unfinished roadmap item.

The asymmetry of reversibility

Almost every step in a trip’s lifecycle is recoverable. Send a slightly wrong draft itinerary and you send a corrected one. Request a quote from the wrong supplier and you’ve wasted an email. Chase a voucher that already arrived and you look mildly disorganised for ninety seconds.

Money is different in kind, not in degree. Marking a payment as received when it wasn’t sets off a chain of downstream actions — vouchers issued, suppliers paid, the trip moved to ready — that are individually hard to unwind and collectively very hard to unwind quietly. Sending funds to the wrong operator is not a support ticket. It’s a recovery process involving banks in two jurisdictions and a conversation nobody enjoys.

Automate the reversible. Keep hands on the irreversible. Almost everything else follows from that one line.

What automation should still do around payment

Keeping payment marking manual is not the same as leaving payment entirely alone. The work surrounding the money is exactly as repetitive as everything else, and it should be handled:

• Requests go out automatically. Generating and sending a payment request is reversible and tedious. Automate it.
• Reminders chase themselves. The deposit that’s four days overdue should not depend on someone remembering.
• Deadlines are tracked. Supplier payment terms, cancellation windows, balance-due dates — all of it monitored without human calendars.
• The state is visible. Anyone looking at the thread should see exactly what’s been requested, what’s outstanding, and what’s overdue.

What stays manual is narrow and specific: the act of asserting that money has actually moved. That assertion is a human looking at a bank record and taking responsibility for what they see.

The bank-feed objection

A reasonable person asks: why not read the bank feed and mark it automatically? The transaction is right there.

Sometimes that works. Often it doesn’t, for reasons that are mundane rather than technical. Clients pay in the wrong currency and the amount doesn’t match. They pay from a company account with a name that matches no one in your system. They pay two deposits in one transfer for two different trips. They pay a balance minus the bank charges they weren’t expecting. They reference the wrong booking.

Automated matching handles the clean cases and produces false confidence on the messy ones — and the messy ones are precisely where the money is at risk. A system that’s right ninety-five percent of the time about payments is not ninety-five percent good. It’s a system that has taught its users to stop checking, which makes the remaining five percent considerably more dangerous than it was before.

Manual is not the same as slow

The objection that lands hardest is the practical one: doesn’t this create a bottleneck? If one person has to mark every payment, does the whole pipeline wait for them?

Only if the manual step is poorly designed. The failure mode isn’t manual confirmation — it’s manual discovery. If someone has to hunt through a bank statement, cross-reference a spreadsheet, then find the right thread, the human step takes ten minutes and gets deferred.

Done properly, everything is pre-assembled: the thread, the expected amount, the deadline, the outstanding balance. The human contribution is a single deliberate action taken with full context. That takes seconds, and the seconds are the point — a decision that fast is still a decision, and it still has a name attached to it.

The trust argument

There’s a reason to keep this line that has nothing to do with error rates.

Agencies adopting automation are being asked to hand over the coordination of their client relationships to software. The reasonable fear underneath that is loss of control — that the system will do something on their behalf they wouldn’t have chosen, to a client they’ve spent years cultivating.

A clear, permanent, non-negotiable line at money is the most legible possible answer to that fear. Not “the system is very careful with payments.” Not “there are safeguards.” Just: it does not move money on its own, ever, and it can’t be configured to.

Every automated step should be pullable into manual control at any point, per account or per trip. But payment marking isn’t a default that can be flipped — it’s the fixed point the rest of the system is built around. A boundary that can be configured away isn’t a boundary. It’s a setting, and settings get changed at 11pm by someone in a hurry.