15 years of an in-house system: how to prepare your inbound agency to integrate AI

Building an in-house system over the years means turning an agency's know-how into processes, data and rules. That is where decisions about suppliers, bookings, clients and ways of working end up, decisions the team built through experience.

The arrival of artificial intelligence raises a concrete question: what does that system need in order to take part in a more automated operation? The answer depends on how it stores information, how it shares it and which tasks it lets you run.

Start with the work that is still done by hand

A process can be well organized and still require many manual steps. The team finds a rate in the system, copies it into a spreadsheet, calculates the price and then moves the result into a proposal. Each step works, but someone has to connect the whole path.

Pick a recent quote and reconstruct how it reached the client. Note where information was looked up, which calculations were done outside the system and which decisions required checking with someone else. Also note the corrections: a date change, an extra traveler or a hotel upgrade.

That path helps you identify a first task to automate and measure it before making changes. It could be retrieving valid rates, drafting a proposal or recalculating a service under defined rules.

Check what information an integration can use

The fact that a piece of data shows up on a screen does not guarantee that another tool can interpret it correctly. To work with a rate you need its amount and the conditions that give it meaning: currency, validity, pricing unit, occupancy, number of travelers and applicable restrictions.

It is worth reviewing a sample of the most common services and of the hardest ones. If an important condition only appears in a free-text note, you will need to define how to interpret and validate it before using it to calculate.

You also need to agree on which source is the valid one. If the system has one rate and a shared spreadsheet has another, an integration needs a clear rule to resolve that difference. Otherwise, the uncertainty carries over into the new process.

Define how the system connects

The technical team can assess whether there are integration interfaces, exports or exchange mechanisms suited to the chosen process. The decision should consider what information is queried, how often it is updated and what happens if a connection fails.

Reading data and changing a booking require different controls. A first test can be limited to preparing a draft for review. If creating or editing records is enabled later, it is worth defining permissions, validations and a log of the actions taken.

For example, a proposal generated from a rate should make it possible to identify the version used. If the supplier updates the price, the team needs to know whether to recalculate and under what conditions. A useful integration preserves that trail.

Separate what gets calculated from what gets interpreted

Interpreting a client's request, proposing a combination of services and writing an itinerary are different tasks from calculating amounts under business rules.

The process design has to state where each rule is applied and how the result is verified. If the rate for a date is missing, the system should leave that point pending. If a combination depends on availability, it should distinguish a proposal from a confirmation.

Human review also needs a precise scope: what the person must check and what information they will have to do it. An "approve" button adds little if it forces someone to rebuild the entire quote from scratch.

Test a full path before expanding

For a first test, choose a frequent type of request, with known suppliers and available conditions. Agree on the expected result and compare it with the current process.

The evaluation can include:

• Time to prepare and review the proposal.
• Amount of data that gets copied again.
• Differences between the expected and the actual calculation.
• Cases left pending due to missing information.
• Corrections needed when the request changes.

Then introduce variations: another date, an extra traveler, an expired rate or a service with no price loaded. These tests show what is solved and where the process still needs intervention.

Decide what to keep based on that test

The in-house system can keep working as the management and data backbone. Some parts may need adjustments to integrate; others may keep doing their job well. There may also be components that are more expensive to update than to replace.

That decision deserves a comparison of the adaptation effort, future maintenance and operational continuity. The years invested explain the value of what was built; the concrete test helps decide the next step.

Before evaluating an integration, bring a real quote and the full path your team follows to resolve it to the conversation. It is a far more useful starting point than a feature list.