AI automation for travel agencies, DMCs and cargo agents in the UAE
The close stops waiting on the settlement, and every difference is named before anyone goes looking for it.
The BSP settlement, the supplier statements and your own booking records are read as they arrive and matched against what was actually sold, ticketed and refunded. What agrees closes without anyone touching it, and what does not stops at a person with the line, the booking and the reason attached.
Four jobs a travel business repeats.
The settlement
Matched as it lands, not at the end of the month.
The BSP file, the airline and hotel statements and your own booking records rarely tell the same story, and the difference gets found by someone holding the systems open side by side. Every line is matched as it arrives, and only the ones that disagree, the ADM among them, reach a person.
The commission and the refund
Tracked to the booking that created them.
Commission arrives late, in pieces and on somebody else’s terms, and a refund can sit in a supplier queue long after the customer stopped waiting for it. Each one is held against its own booking, so an override that was never paid or a refund that never landed is raised while it can still be recovered.
The itinerary costing
Costed on this season’s numbers, not last season’s.
A group or a series means net rates from suppliers who each answer differently, allocation that moved since the last cycle, and margin one person carries in their head. The gathering and the assembly run on their own, and the margin call stays with whoever owns it.
The booking file
Complete before anyone needs it to be.
One booking scatters across the reservation system, the supplier confirmation, the visa or insurance document and the invoice, and it only gets assembled when something has already gone wrong. The file is built as the booking moves, so the whole story of a passenger, a series or a group sits in one place.
Travel software ends at the login.
It holds the booking, and the matching still happens in someone’s head. Runbook arrives knowing your business, because writing down how you actually settle a month is where we start.
You own it. No seat bill.
It runs in your cloud account. If you stop paying us, it keeps running. What stops is us watching it, fixing it and extending it.
How the work runs.
The audit
We sit with the people who make the calls and read everything they read, including the exceptions that are not written down anywhere. You get the work mapped, the jobs ranked worth programming and not, and the value case in your own numbers.
The build
The data layer first, then the agents on top of it. It ends in production, inside the systems your team already opens, not in a pilot.
The run
We watch it and extend it as the work changes. Failures reach us before they reach you.
You leave the first meeting with a one-page sketch of the job you brought.
Questions travel and DMC teams ask.
Our reservation system already produces a reconciliation report. Why is this different?
A report tells you the two records disagree. The work is deciding which one is right, and that decision comes from the fare rules, the supplier agreement and what your team knows about this account. Runbook encodes that decision, matches everything that can be matched, and puts only the genuine exceptions in front of a person.
Our finance team already handles the settlement. Where does this fit?
Runbook sits underneath your finance team. The matching, the chase for a statement that has not arrived and the assembly of the exception list stop being that team’s week. The judgment on a disputed line, a write-off or an ADM stays with the finance team, and the close stops being the reason the month runs long.
Every itinerary is different.
What differs between two itineraries is the combination, not the work behind it. On every programme the same suppliers are approached for net rates, the allocation is confirmed against what has actually moved, the blackout dates are checked and the replies are chased until they arrive. Runbook runs that, so nothing is quoted against a rate nobody confirmed.
Our data sits in the reservation system, a supplier portal and a spreadsheet only one person understands. Is that a problem?
That is the normal starting condition, and it is why the data layer gets built before anything else. A PDF statement, a portal with no export, a rate sheet with the tiers in merged cells and a system nobody has the password to are all inputs we have worked with. The condition of the data changes the sequence of the build, not whether it can be done.
How long does it take?
The scope, the fee and the finish date are agreed with you in writing before anything starts. We do not publish a length, because it follows the size of the operation, how many systems the work touches and what condition the data is in.
Who owns it when you leave?
You do. The code, the credentials and the documentation sit in your accounts and under your name from the day we start. It runs in your cloud account, and if you stop paying us it keeps running.
What does the first meeting cost?
Nothing. It is forty five minutes, and you leave with a one-page sketch of the job you brought: the steps as they run today, where the line would sit, and what we would measure.
We are a cargo agency, not a tour operator. Does this still apply?
The nouns change and the shape does not. A CASS settlement, a carrier statement and your own job file disagree the same way a BSP settlement and a booking file do. The work is the same: match what agrees, name what does not, and put the decision in front of the person who owns it.