Because projects ran in parallel and back to back, AI Travel Solutions used a standing team of seven business analysts instead of hiring for each project.

1 person

Lead business analyst

Focus

AI Travel Solutions' point of contact; maintaining the repeatable method and its templates; allocation and quality review

2 people

Booking and supplier business analysts

Focus

Booking flows, inventory, supplier connections and payments

2 people

Operations and support business analysts

Focus

Changes, cancellations, refunds, support desks and out-of-hours processes

1 person

Finance and ERP business analyst

Focus

Back-office processes, posting rules, supplier settlement and ERP requirements

1 person

AI and data business analyst

Focus

AI use cases, data readiness, approval points and escalation rules

• Analysts usually moved between projects at stage gates, so no project lost its analyst midway through a stage.
• The lead BA kept the method's templates current and added lessons from each project to them.
• A second analyst reviewed every baseline before it went to AI Travel Solutions.
• The lead BA and AI Travel Solutions' delivery lead agreed assignments each week, working from a shared view of upcoming projects.

On almost every project we traced four flows. The systems, rules and failure points were different each time, so the table shows the typical patterns rather than any single client.

Flow

Systems it usually touched

Typical failure point

What the requirements fixed

An enquiry

Website forms, email, phone, CRM

Enquiries sat in personal inboxes, and quotes were rebuilt from scratch when a consultant was away

Shared enquiry queues, quote records linked to the customer, and follow-up rules

A booking

Booking engine, inventory, supplier connections, payments

Bookings were re-keyed between systems, and supplier confirmations were checked by hand

Clear booking states, automatic supplier confirmation checks and exception queues

A change

Booking engine, supplier systems, payments, customer communication

Price differences, supplier fees and updated documents were worked out manually for each change

Change rules, repricing steps, document reissue and an approval point for fees and refunds

A support case

Helpdesk, booking records, phone, out-of-hours lines

Agents searched several systems to understand a booking before they could help

Support cases linked to the full booking, with priority rules for travellers already in destination

Preparation defined what the software had to do before any screen was drawn. Some projects were a new booking flow, and others were a change to an existing desk. Each one had a separate baseline, built from these components.

User roles

Multi-brand operator

• Group head office with reporting across brands
• Brand managers controlling content, pricing rules and terms for their brand
• Product and contracting teams managing inventory and supplier agreements
• Reservations and customer service agents, scoped to their brands
• Finance teams handling payments, refunds and supplier settlement
• In-destination and out-of-hours support teams

Single agency

• Agency manager
• Travel consultants handling enquiries, bookings and changes
• Administrator covering payments, documents and supplier queries

Journeys

Traveller

Search or enquire, receive a quote, book, pay a deposit and balance, receive documents, request a change, get help during travel, and raise a complaint afterwards

Staff

Take an enquiry, build a quote, confirm a booking with suppliers, process a change, handle a supplier schedule change, issue a refund or credit, and manage a support case

Corporate traveller

On travel management projects: book within policy, get approval where policy requires it, and change a trip

Data to collect, and data to keep out

Needed

• Lead traveller contact details and booking preferences
• Names exactly as they appear on travel documents, at the point of booking
• Booking, payment and supplier references
• Assistance requests, such as wheelchair support, recorded in structured fields
• Marketing consent, recorded separately from booking consent

Not collected, or collected only when required

• Passport details at the enquiry stage. These are collected only when a flight booking requires them, and kept no longer than needed
• Card security codes, or card data outside the payment provider's systems
• Health information beyond specific assistance needs the traveller chooses to share for their trip
• Sensitive details in free-text notes, which agents were guided not to use for this purpose
• Children's details beyond what the booking and supplier require

Integrations

• Booking and reservation systems, with an agreed system of record for each booking element
• Inventory and contracting systems for hotels, transfers and excursions
• Supplier connections such as airline content, bed banks and ground handlers
• Payment providers, including deposits, balance due dates, refunds and multiple currencies
• Helpdesk and customer communication tools
• Accounting and supplier settlement

Non-functional requirements

Access

Role-based access by brand and desk, with support access to booking data limited to the cases an agent is working on

Payments

Card data handled only by the payment provider, with strong customer authentication for online payments

Privacy

UK GDPR requirements for consent, retention and traveller rights, with assistance needs treated as sensitive data

Availability

Support tools available outside office hours, since travellers need help in every time zone

Scoped backlog

Epics and user stories with acceptance criteria, prioritized and split into releases the development team could estimate

Every booking creates financial events: deposits, balances, supplier costs, commissions, refunds and currency differences. On projects that touched finance, we prepared the back-office and ERP work inside the same baseline, so booking and finance systems agreed on every booking.

Booking to cash

Deposits, balance payments, refunds and credit notes, and the financial posting each booking event creates

Supplier settlement

Supplier costs, due dates, payment runs and reconciliation against supplier statements

Revenue and cost timing

When revenue and costs are recognized, such as at booking or at departure, as agreed with the client's finance team

Multi-currency

Selling and buying currencies, exchange rates, and how currency gains and losses are recorded

VAT and regulatory data

Where the Tour Operators' Margin Scheme or ATOL reporting applied, the booking data needed for margin calculations and returns, confirmed with the client's tax advisers

Brand and entity structure

How brands and legal entities map to companies, cost centres and the chart of accounts

Commission and agent accounting

Commission rates, commission payable and receivable, and net or gross billing for agents

Corporate invoicing

For travel management projects, consolidated invoices by corporate client, cost centre and traveller, with card payment reconciliation

Data migration readiness

Open bookings, supplier balances, customer accounts and history, with quality checks before migration

Selection support

A requirements catalogue, demo scripts built on real booking and change scenarios, and a scoring model for comparing ERP and travel back-office options

Independent agencies rarely needed a full ERP. For them, we specified how the booking tool should feed an accounting package, including supplier payments and commission tracking.

Travel has rules that generic requirements templates miss. Where they applied to a project, they were written into the baseline as business rules and confirmed by the client's compliance lead.

Package travel

On flight-inclusive package projects, requirements reflected the UK Package Travel Regulations and ATOL protection, including the information travellers must receive, how significant changes are handled, and refund timelines when the organiser cancels.

Supplier schedule changes

Airline and supplier changes outside the traveller's control were modelled separately from changes the traveller requested, because the fees, options and communication are different.

Deposits and balances

Payment schedules, reminders and what happens when a balance is missed were defined as rules by brand and product.

Corporate travel policy

On travel management projects, policy checks, approval workflows and out-of-policy reasons were captured as configurable rules for each corporate client.

Duty of care

Support requirements treated travellers already in destination as the highest priority, with clear routes to out-of-hours teams.

Acceptance criteria described what the operation needed to achieve, so the application was judged against the desk, not a feature list.

Supplier schedule change

• Given an airline changes a flight time on a confirmed package booking
• When the change is received from the supplier connection
• Then the booking is flagged for review with the old and new times shown
• And the agent can see whether the change counts as significant under the brand's rules
• And the traveller is not contacted until an agent has approved the message

Organiser cancellation refund

• Given the operator cancels a package booking
• When the cancellation is confirmed
• Then a refund task is created with the due date set by the applicable rules
• And the task is escalated to finance if it is not completed before that date

Support case priority

• Given a traveller contacts support while they are in destination
• When the case is created
• Then it is marked as in-destination and placed at the top of the queue
• And it is routed to the out-of-hours team if the office is closed

AI sat inside each project's baseline, and the use case was never the same twice. Across the projects we defined four main use cases, each with different data, approval points and limits. On every project the requirement was a controlled aid for the team. Nothing was released as an ungoverned chatbot.

Answering routine traveller questions

Typical project

An online travel agency or tour operator with high volumes of repeat questions

What the AI could see

The traveller's booking details after secure sign-in, and approved content on baggage, transfers, documents and brand terms

Approval point

Content leads approve the knowledge base for each brand before launch and on a regular review cycle

Limits

No visa, passport or health entry advice beyond linking to official government travel advice, and no changes to bookings

Drafting a first response

Typical project

An independent agency or a customer service desk handling enquiries and complaints

What the AI could see

The incoming message, the linked booking and approved templates

Approval point

An agent edits and sends every response, and nothing goes out automatically

Limits

No offers of compensation, refunds or goodwill without agent approval

Routing an enquiry

Typical project

A multi-brand operator with separate desks for sales, changes, groups and support

What the AI could see

Message content, brand, booking status and travel dates

Approval point

Agents can reassign any case, and routing rules are reviewed against misrouted cases

Limits

Messages from travellers in destination, safety concerns and complaints mentioning legal action always go to a person immediately

Summarizing a booking change

Typical project

A desk processing a high volume of amendments and supplier changes

What the AI could see

The booking before and after the change, supplier messages and the price difference

Approval point

The agent reviews the internal summary and the traveller-facing summary before either is saved or sent

Limits

No final price or fee stated unless it matches the booking system

Before any assistant or agent was put in front of staff or customers, each project documented data readiness, covering booking data quality, consistent supplier content and up-to-date brand terms. It also documented what the model could see, the decision boundaries and the escalation rules. Travellers were told when they were dealing with an AI assistant, and each use case was tested with realistic questions, including ones it had to decline or hand over.

Software development followed the requirements on the projects that went to build.

Traceability

Each requirement was linked to user stories, test cases and releases, so the client could confirm every agreed outcome was delivered.

Testing with real scenarios

Acceptance testing used realistic bookings, changes and support cases, including supplier failures and out-of-hours contacts.

Implementation support

We supported data migration, cutover planning around peak booking periods, and short role-based training for agents.

Change control

When scope moved, each change was assessed against that project's baseline and decided by the client through AI Travel Solutions.

Projects that did not go to build

For these, the baseline and backlog were handed over so the client could take them forward later or use them to choose a supplier.

Larger operators needed a shared model with local and brand variation. Independent agencies needed a smaller scope that fit how their desk worked. Both came up often, and each was specified separately. An independent agency never received a trimmed-down copy of an operator's design.

Area

Multi-brand operator

Independent agency

Brands

Shared booking model, with brand content, terms, pricing rules and templates held as configuration

One brand, with the agency's terms and tone

Desks

Separate sales, changes, groups and support desks with routing between them

Consultants handling the whole trip for their customers

Rules

Brand and product-level rules for deposits, changes and cancellations

A small set of rules the agency can maintain

Integrations

Booking engine, inventory, multiple supplier connections, helpdesk and finance systems

Booking tool, payment provider and email

Reporting

Comparable measures across brands and desks

A short view of enquiries, bookings and open changes

ERP and back office

An ERP with brand and entity structure, supplier settlement and multi-currency

A booking tool feeding an accounting package, with simple supplier payment and commission tracking

AI scope

Routing and change summaries at volume, with governance across brands

First-response drafting and routine questions