Why Are Travel Operations Still Manual?

How travel companies accidentally turned their people into the integration layer between systems and what closing the seams actually looks like.

There is a question that sits unasked in most travel business reviews.

The headcount report shows the operations team grew 30 percent in four years. The technology investment line shows the same period saw the largest wave of software adoption in the company's history. The CFO asks whether the headcount is justified. The COO explains that volumes are up, complexity is up, client expectations are up.

Nobody asks the question underneath all of that: if we invested this heavily in technology, why did we need more people to run the operation?

The honest answer is not comfortable. Almost nobody in this industry says it out loud.

The technology did not reduce the work. In most cases it increased it. Not because the tools were bad purchases. Because nobody accounted for what happens in the space between them.

That space between the GDS and the mid-office, between the booking system and the hotel portal, between the flight tracker and the driver dispatch is where the manual work lives. Not in the systems. In the gaps.

Why do travel companies use so many disconnected systems?

Every travel business built the same staircase. Not deliberately. Step by step, over years, one rational decision at a time.

It starts with the GDS. Amadeus, Sabre and Travelport the backbone of every booking operation. Mandatory. Non-negotiable. The core system around which everything else is built.

Then comes the communication layer. Outlook, Gmail, Microsoft Teams. Traveller requests arrive by email. Supplier confirmations come back by email. Amendments happen by email. The GDS does not read email. Someone has to.

Then the NDC / LCC aggregator. AirGateway, TravelFusion, Duffel because the airlines started distributing their best fares and ancillary content outside the GDS. Any TMC or OTA that wanted access needed a separate connection. Another system. Another login. Another data model that does not naturally speak to the one before it.

Then the hotel portal. Booking.com Extranet for some bookings. Hotelbeds for others. The chain's own corporate portal for negotiated rates. Each with its own availability feed, its own confirmation format, its own amendment process.

Then the policy engine. For most TMCs this is not a system at all it is a PDF, a spreadsheet, a knowledge-base inside some helpdesk and the accumulated tribal knowledge of the agents who have been there long enough to know what the client actually wants rather than what the policy document says.

Then the mid-office. A separate system, a separate login, where PNRs are supposed to be tracked through their lifecycle, except the data has to be manually transferred from the GDS because the two systems were not built to share it automatically.

Then the expense tool. Concur, Zoho, Expensify because finance needs to reconcile travel spend against cost centres, and that data lives in the booking system in a format the expense tool cannot read without an export, a reformat, and a reimport.

Then the reporting layer. Because the client wants a monthly spend analysis, and producing it requires pulling data from the GDS, the mid-office, the expense tool, and the hotel portal, assembling it in a spreadsheet, and formatting it to match the template the client approved in 2019.

Seven systems, Sometimes eight systems. Zero native integration. At every point where data needs to move from one to the next, the same solution has been deployed not by design, but by default.

A person.

When the systems do not connect, the only available bridge is a human being. That is not a failure of people. It is a failure of integration architecture.

Why does corporate travel booking still take so long? The 172-click answer.

A corporate travel request arrives in an agent's inbox at 9.14am. The traveller needs flights from London to New York, a hotel in Midtown, and a car from JFK.

Here is what actually happens next.

The agent opens Outlook to read the request. Opens Amadeus to search flights, firing GDS commands to shop, price, and check availability across multiple fare types and booking classes. Cross-references the client's policy document to check whether the preferred carrier, the class of service, and the advance booking window all comply. Opens the hotel portal to check Midtown availability against negotiated rates. Switches to the car supplier extranet. Assembles the options in an email template. Sends the quote.

That sequence before the client has even responded took 15 to 20 minutes and involved 172 individual clicks and system switches. Not an estimate. Measured, in a live TMC operation.

The client approves the first option. The agent returns to the GDS, builds the PNR, applies the negotiated fare, adds OSI and SSR remarks for seat preference and meal, places the booking on hold. Checks the PNR against the policy engine for compliance. Routes for manager approval which means an email, a wait, a follow-up if the approver does not respond before the time limit expires.

On approval: issue the ticket, confirm the e-ticket attached, book the hotel in the portal, confirm the car, create a mid-office record, generate the itinerary, email the traveller, email the PA.

That is one booking. A mid-sized TMC processes hundreds of these per day. The agent is already working through seven others simultaneously, each at a different stage, each in a different system.

How many steps required human judgment? Three. Reading the traveller's preferences. Handling a policy exception. Writing the covering email.

Everything else was data transfer between systems that were never designed to share it.

This is the core problem that travel operations integration solves not by replacing the GDS or the mid-office, but by connecting them so the agent does not have to.

How can DMCs automate airport transfer operations?

A destination management company's ground operations team starts the morning with 60 airport transfers scheduled across the day. Each has a passenger, a flight, a driver, a vehicle, and a time.

The flight data lives in a flight tracker app, open in a browser tab. Driver assignments live in a WhatsApp group. Vehicle allocations live in a spreadsheet. Passenger details live in a booking system. Hotel confirmations live in an email thread.

At 8.43am, one of the inbound flights is delayed by 90 minutes. The ops coordinator finds out when a supervisor manually checks the flight tracker. He updates the spreadsheet. He messages the driver on WhatsApp with the revised pickup time, to the wrong group. He emails the hotel. He calls the passenger.

By 11am: three transfers completed. Two flawless. One had a driver at the wrong terminal. The passenger waited 25 minutes. She called the emergency line. The coordinator handled the call while managing a coach departure running late because the hotel gave incorrect bay information.

No technology failed. The flight tracker tracked. The spreadsheet stored. WhatsApp delivered the message to the wrong group.

The failure was in the architecture. Five systems, zero integration, one coordinator responsible for being the connective tissue between all of them.

Automating airport transfer operations for a DMC does not require replacing these tools. It requires connecting them, flight status data feeding automatically into dispatch, driver assignment triggered without coordinator input, guest notification sent from a single source of truth. That is what a properly engineered integration layer for ground operations looks like.

Why do tour operators still rely on spreadsheets for hotel allotments and rooming lists?

A tour operator running Mediterranean summer departures has 180 active departure dates. Each has a hotel allotment, an air series block, a ground transfer contract, and between 40 and 120 passengers.

The allotment sell-back deadlines, the dates by which unsold rooms must be released or paid for regardless live in a spreadsheet. Release date tracking is someone's responsibility. It is not automated. It is not systemised. It is a column someone checks when they remember to.

In the last quarter, three deadlines were missed. The operator paid for 34 rooms across three properties that were never sold. Not because of low demand. Because the deadline passed without anyone noticing.

The rooming lists passenger names, room types, dietary requirements, special requests are assembled from the booking system, formatted into each hotel's preferred template (because none accept the same format), and submitted by the contractual deadline. Each amendment requires the coordinator to reopen the file, update it, and resubmit it.

Across 180 departures with an average of 12 amendments each: 2,160 manual updates in a single season. The coordinator did not choose to spend her career updating spreadsheets. She is spending it that way because the booking system, the hotel's preferred format, and the communication channel between them were never integrated.

The answer to why tour operators still rely on spreadsheets is not a lack of willingness to change. It is that no one has engineered a connected layer between their reservation system and their supplier communication channel. Until that seam is closed, the spreadsheet remains the only available solution.

How can OTAs manage flight cancellations and schedule changes faster?

An online travel agency wakes to find that weather at a major hub has caused 340 cancellations overnight. Affected booking count: 42,000 passengers across 18,000 bookings.

Under normal conditions, the post-booking operations team handles schedule changes through a queue. An agent reviews each record, classifies it as minor or major, and actions accordingly. Normal volume: 400 changes per day. The team is sized for that.

On this Monday morning the queue contains 18,000 records. The team has not grown overnight. The same agents who processed 400 cases yesterday are looking at a queue 45 times larger.

The response is the same every time: all hands to the queue. Customer service call volumes spike. Average handling time increases. The queue does not clear by end of business. By Tuesday morning, thousands of customers whose flights were cancelled 36 hours ago have still not received a communication with their options.

Not because the agents were slow. Because the volume exceeded what a manually operated process, sized for normal operations, can handle. And because the automation that could have handled the 14,000 clear-cut cases unambiguous cancellations where the rebooking rule is deterministic was not in place. Those cases sat in the same queue as the 4,000 that genuinely required judgment.

The cost is not only the overtime. It is the customer who booked elsewhere. The chargeback from the customer who received no communication. The TrustPilot review that ranks first in search results for the next three months.

Managing flight cancellations faster does not require a larger operations team. It requires an integration layer that classifies, routes, and automates the deterministic cases so agents handle only the ones that need them.

Why do guest requests get missed in hotel operations?

A guest booked a four-night resort stay and noted, in the booking form, that she and her husband were celebrating their 20th anniversary and would love a private dinner setup on the last evening.

The note was received. The reservations agent read it. It was typed into the PMS comment field. And there it stayed attached to a booking processed by a different team, assigned to a room by a third team, serviced by housekeeping that never opened the PMS notes, and checked in by a front desk agent with 12 arrivals that morning who reviewed the booking but did not open the extended notes field.

The anniversary dinner was never organised.

The guest raised it on her fourth day. By then, what would have been straightforward four days earlier required emergency coordination across four departments. It happened. It was imperfect. The couple appreciated the effort. They did not return.

The note was not lost. The intention was not absent. The failure was structural a comment field is not a workflow. Information entered into one system, never seen by the system responsible for acting on it, might as well not have been entered at all.

Connecting hotel PMS to operational workflows so that a guest request creates an assigned task with a deadline, an owner, and a completion requirement is an integration problem, not a hospitality problem.

What is the hidden cost of disconnected travel systems?

Most travel businesses do not have a line on their P&L labelled integration overhead. But if they did, it would contain items currently scattered across different cost buckets.

Agency Debit Memos. ADMs raised by airlines for ticketing errors, fare miscalculations, and waiver violations arrive months after the original transaction. The agent who made the error has moved on. The root cause is not investigated. The ADM is paid, absorbed as an ops cost, and the pattern continues. ADMs are the delayed tax on integration gaps in the ticketing workflow.

Unused ticket credits. Voided or partially used tickets carry residual value applicable to future bookings but only if tracked, monitored before expiry, and applied proactively. In most TMCs, unused credit tracking is a monthly finance exercise. Credits expire. The airline keeps the value. The cost never appears as integration failure.

Missed sell-back deadlines. The 34 rooms paid for because a spreadsheet column went unchecked. Not demand failure. Architecture failure. A properly integrated allotment management layer would have fired a notification 30 days, 14 days, and 7 days before the deadline. Nobody would have needed to remember.

Rate leakage. The hotel absorbed a rate parity violation because the OTA's mobile rate undercut direct booking for three weeks before anyone checked. The cost appears as yield variance, not integration gap.

Waiting time charges. The DMC absorbed driver waiting costs because the flight delay did not propagate to dispatch until after the driver had already been sent. The cost appears as operational loss, not integration failure.

SLA breaches and churn. The corporate client escalated because the TMC's duty of care response took 90 minutes when the contract said 30. The client stayed. The trust did not fully recover. The cost appears as churn risk, not architecture debt.

Individually these look like operational noise. Together they are a structural tax on every booking processed paid not because the work is hard, but because the systems that should be sharing information are not.

How can travel companies reduce manual work by integrating booking, supplier, finance, and customer systems?

The answer is not another tool.

Every system in the staircase is doing what it was designed to do. The GDS books. The hotel portal confirms. The mid-office tracks. The expense tool reconciles. The reporting layer reports. None of them failed.

The gap is between them. And closing gaps is an engineering discipline, not a product purchase.

Infarsight's integration practice connects travel technology stacks at full transactional depth, GDS to mid-office, booking system to hotel portal, flight data to driver dispatch, PMS to operational workflow, schedule change queue to rebooking automation. The integration layer is built to be observable, maintained post-deployment, and designed to evolve as supplier systems change and API versions update.

The specific integrations that close the seams described in this post:

For TMCs: Amadeus, Sabre, and Travelport GDS integration at full PNR lifecycle depth. NDC aggregator connectivity AirGateway, Duffel, TravelFusion. Mid-office and CRM integration. Policy engine automation. Expense tool reconciliation feeds.

For DMCs: Flight status API integration feeding directly into dispatch workflows. Driver assignment automation. Guest notification pipelines connected to live flight data.

For tour operators: Booking system to hotel portal integration with automated rooming list generation. Sell-back deadline tracking and alert automation. Schedule change cascade management across multi-supplier programmes.

For OTAs: GDS schedule change queue automation with classification and deterministic case processing. Disruption management workflows that separate cases requiring judgment from cases requiring execution.

For hotels: PMS to operational workflow integration guest requests converted to assigned tasks with owners, deadlines, and completion requirements. Channel manager and rate parity monitoring feeds.

Where no API exists legacy suppliers, older PMS versions, email-only systems Infarsight deploys non-API integration patterns: RPA-driven browser automation, structured email parsing, SFTP batch exchange, and flat file processing. The same observability standards apply regardless of the connectivity method.

What does automated travel operations look like?

The best-run travel operations share one characteristic that has nothing to do with size, technology budget, or leadership seniority.

They have fewer gaps between their systems.

Not fewer systems. Fewer points at which a human being is required to move data from one to the next.

The booking request arrives and the GDS query fires automatically. The policy check runs against the live engine, not a PDF. The PNR time limit is tracked by the system with a visible countdown. The hotel rooming list generates in the correct format automatically the coordinator reviews it, not builds it. The flight delay propagates to the driver dispatch system before the coordinator's phone rings. The schedule change classifies itself clear-cut cases actioned automatically, judgment calls escalated with full context already assembled.

The operations team is not smaller. They are focused differently.

On the rebooking that requires commercial judgment. On the group departure that needs a human present. On the client relationship that requires trust, not data re-entry. On the exception that genuinely cannot be resolved without experience and discretion.

They are not bridges between systems. They are travel professionals.

Your people did not become the integration layer because they were not good enough. They became the integration layer because nobody engineered the alternative.

Closing that gap is Infarsight's work.

How can Infarsight help travel and hospitality companies reduce manual handoffs between systems?

Infarsight's enterprise integration services are purpose-built for the operational complexity of travel, hospitality, and mobility the only domain where a single booking touches a GDS, an NDC aggregator, a hotel CRS, an expense platform, a finance system, and a reporting layer, all before the traveller checks in.

The engagement starts with an integration assessment: mapping your current systems, protocols, and connectivity gaps. The output is a prioritised view of which seams are costing the most in agent time, in error rate, in revenue leakage and an engineering approach to closing them.

This is not a platform purchase. It is an engineering engagement. The integration layer Infarsight builds is observable, maintained, and designed to evolve as your technology stack changes.

If this post described your operation, an integration assessment is the right first conversation.

Frequently asked questions about travel operations automation

Why are travel operations still manual despite automation technology being available?

Because automation requires integration, and most travel technology stacks were not designed to be integrated. Each system was purchased to solve a specific problem. Nobody engineered the connections between them. The result is a stack of capable tools with no shared data layer and people filling the gaps between them manually.

How can TMCs reduce the time it takes to respond to a corporate travel booking request?

The 15 to 20 minutes a TMC agent spends on a single quote contains approximately three steps requiring human judgment and approximately 15 steps requiring data transfer between systems. Reducing response time means automating the data transfer steps GDS query on request receipt, policy check against live engine, hotel and car availability pulled automatically so the agent focuses on the three steps that actually need them.

How can travel agencies integrate GDS, CRM, email, and finance systems?

Through an integration layer that connects each system at its native protocol level GDS via SOAP or REST API, CRM via standard API, email via parsing and structured extraction, finance via batch export or direct feed. Infarsight integrates at full transactional depth with Amadeus, Sabre, and Travelport, as well as NDC aggregators, hotel portals, and mid-office platforms.

How can DMCs automate airport transfer driver assignment?

By connecting flight status data directly to the dispatch system so a delay notification from the flight API updates the driver's pickup window automatically, without a coordinator manually checking a tracker, updating a spreadsheet, and sending a WhatsApp message. The coordinator reviews exceptions. The system handles the routine.

Why do tour operators still use spreadsheets for allotments and rooming lists?

Because the booking system and the hotel portal were never connected. The rooming list lives in the booking system. The hotel expects it in a specific format. With no integration between the two, the coordinator becomes the transfer mechanism exporting, formatting, and resubmitting manually. An integration that generates the rooming list in the hotel's required format and submits it automatically removes the coordinator from the data transfer and leaves them available for the judgment work.

How can OTAs handle flight cancellation queues faster during disruption events?

By separating deterministic cases from judgment cases at intake. Fourteen thousand of the eighteen thousand disruption records described in this post required no judgment same rule, same outcome, same communication. An automated classification and processing layer handles those without agent involvement. The agent queue contains only the four thousand that genuinely need human decision-making. Average handling time drops. Queue clears faster. Customer communication goes out within minutes of the disruption, not 36 hours later.

How can hotels stop missing guest requests that are noted at booking?

By converting PMS comment fields into operational tasks. A note in a comment field is information stored. A task with an owner, a deadline, and a completion requirement is information actioned. The integration between the reservation record and the operational workflow connecting PMS to the task management system used by housekeeping, F&B, and the front desk is what turns a note into a delivered request.

What is the real cost of disconnected systems in travel operations?

It is not primarily the labour cost of manual steps. It is the structural leakage ADMs, unused ticket credits, missed sell-back deadlines, rate parity violations, SLA breaches, and churn that occurs when information that should flow automatically between systems instead requires a human intermediary who may be busy, on leave, or simply not aware that the deadline passed. This leakage does not appear as "integration cost" on any P&L. It appears as a collection of operational noise items that, in aggregate, represent a significant tax on every booking the business processes.

Related: Enterprise Integration Services · Travel COE · Intelligent Automation · Data Engineering