When AI knows your rates and business rules: what changes for an inbound agency

A travel proposal brings together many decisions. It has to answer the client's request, combine feasible services and apply the right commercial conditions. The opportunity to bring in artificial intelligence appears when the process can work with that agency-specific knowledge.

To evaluate that possibility, it helps to be precise about what it means for a solution to "know the business." It must be able to use valid information, apply verifiable rules and recognize when it is missing a piece of data to move forward.

A rate has context

An amount on its own is not enough to price a service. You need to know which dates it applies to, what currency it is in and what its pricing unit is. Occupancy, number of travelers, minimums and other supplier conditions may also come into play.

A transfer priced per vehicle requires knowing the capacity and how many vehicles are needed. Accommodation requires relating nights, rooms and occupancies. An excursion may change price depending on group size.

The information must preserve those differences. If every rate is reduced to a generic "price" field, part of the calculation will still depend on interpretation outside the system.

Business rules are part of the knowledge too

After cost come the conditions of sale: which markup applies, whether there is a specific agreement with the client, which currency is used and how included services are presented.

To automate that path, the team needs to make the rules explicit and resolve possible conflicts between them. For example, if a client has a special condition, it must be clear when it overrides the general condition and who can authorize an exception.

A practical way to start is to gather the questions the team usually asks its most experienced person. Each answer may reveal a condition that is not yet documented or that is applied differently depending on who is quoting.

Combining services requires reviewing the whole trip

The fact that a service has a price does not mean it fits into any itinerary. The combination also depends on schedules, duration, location and the requirements of the request.

Consider an afternoon arrival and an excursion that starts that same morning. Both services may have valid rates, but the combination does not fit the requested trip. The process needs to detect that incompatibility or flag what information the team must confirm.

Also, a rate available in the system is not the same as availability confirmed with the supplier. The proposal must reflect the actual status of each service and any pending conditions.

A concrete test: add a traveler

Take a request for four travelers, three nights of accommodation, a transfer and an excursion. Once it is priced, add a fifth traveler.

Check what happens with the vehicle, the room allocation and the excursion price. The total cost can change in different ways depending on each supplier's conditions; it is not safe to assume that multiplying the per-person price is enough.

Ask the solution to show what data it used and what rules it applied. If an occupancy or a rate for the new group size is missing, the result should identify that gap before treating the proposal as ready to send.

This example is an evaluation test, not a client case or a promise about any specific tool.

Evaluate what happens when the information falls short

A demo with complete data shows only part of the process. It is also worth testing an expired rate, two different versions of the same service or an undefined commercial condition.

For each situation, watch whether the tool explains what is missing, avoids presenting an estimate as a confirmed price and makes it easy for the person in charge to resolve the case. Once corrected, check how the proposal is updated and whether the change is logged.

The ability to leave a point pending is part of a reliable operation. It lets the team focus its review on the decisions that actually need it.

Prepare the knowledge before expanding automation

You can start with one family of services and a limited set of suppliers. For that test, identify the source of each rate, its validity and who maintains the information. Document the business rules that apply and pick requests whose correct result you already know.

Compare the results and record the differences. Some will reveal a data problem; others, an incomplete rule or an integration limitation. Resolving them explicitly lets you assess whether the process is ready to cover more cases.

The goal is for the team to understand why a proposal has a given price, what is confirmed and what is still to be reviewed. That clarity is what makes automation useful in day-to-day work.

In your next evaluation, bring a real request, change one condition and ask them to show you where each amount comes from. That is where you will see how much of your operation's knowledge goes into the result.