Support deservesmore thought.

There is a tempting way to make support look efficient: ask the passenger to do more. Find the booking again. Explain the problem again. Read a policy, interpret the exceptions, then contact another department. The support interaction gets shorter. The passenger’s job gets longer.

We believe the work belongs with the service that is best equipped to do it. If information is already available and we are authorized to use it, asking for it again needs a reason. If a request needs several internal steps, the passenger should not have to become the project manager who coordinates them.

This does not mean guessing at someone’s preferences or hiding meaningful decisions. A traveler should choose between alternatives that affect their trip, and approve actions that need their consent. Our job is to make those choices understandable, with the relevant consequences already worked out.

Perfecting that experience takes longer than adding another form or fallback message. It means investigating where people get stuck, testing different approaches and doing the integration work behind a simple exchange. We think that effort is ours to make. An interaction is not efficient just because the remaining work has disappeared from our dashboard.

Passengers trust support with sensitive information and consequential changes. That trust deserves real protection. It also deserves an honest explanation of why a particular check is needed. A familiar-looking hurdle is not, by itself, evidence that the passenger or their booking is safer.

Our starting point is the risk of the specific request: what information would be exposed, what could be changed, and how do we establish that this person has the authority to ask? Reading general baggage guidance and redirecting a refund are different situations. The controls should reflect that difference.

We challenge checks that add effort without establishing anything useful. Repeating information already supplied through the same untrusted channel, for example, should not be mistaken for independent proof of identity. Equally, a smoother experience is no excuse to bypass necessary verification or broaden access.

The hard work is designing protection and experience together: appropriate permissions, reliable verification, clear explanations and a workable recovery path when a legitimate traveler cannot complete a check. Where an airline requires a control, we need to respect it and improve the surrounding experience. Where a control is ineffective, we should be willing to question it rather than celebrate the box it ticks.

A capable human agent can be thoughtful, reassuring and resourceful. Those qualities matter. But copying the visible conversation is too small an ambition for AI. Machines and connected systems offer a different set of possibilities: checking alternatives in parallel, carrying context across steps and applying relevant knowledge without asking the passenger to wait while someone searches for it.

That creates the possibility of support that is faster, more thorough and more useful than a person working alone. It does not make the result automatic. A fluent model attached to an incomplete workflow can simply deliver an inadequate answer with greater confidence.

Human+ is our name for the higher standard we want to pursue. It requires research into real requests, careful integration with operating systems, testing of difficult cases and a clear understanding of where judgment or approval is needed. When an AI cannot act safely or reliably, recognizing that limit and making a good handoff is part of its capability.

We should compare the finished experience with what a skilled specialist could have achieved, then ask what technology makes possible beyond that. Did we find a better option? Explain a consequence earlier? Remove a wait? Better-than-human support is a demanding design goal, not a property we acquire by choosing a model.

Air travel support cannot be designed around a quiet Tuesday. Disruption can bring many passengers into the queue at once, each with an urgent and slightly different problem. Trips cross time zones. Travelers speak different languages. A connection missed overnight still needs an answer before the next departure.

For a human team, those demands create difficult trade-offs between staffing, availability, language coverage and the depth of help each person receives. We believe they make air travel an especially compelling setting for AI support: simultaneous requests need not compete for a person’s attention in the same way, and assistance need not depend on a particular shift being staffed.

But a model’s availability is not the same as operational readiness. Airline systems can slow down. Inventory changes. Tools fail. A language model can misunderstand an important distinction. Useful capacity means handling those conditions with appropriate limits, fresh information and a path to experienced people when needed.

That is why we care about performance during the difficult periods, not just a polished demonstration. The purpose of automation should be to preserve useful, considerate support as demand rises. If it only works for easy requests in calm conditions, it has avoided much of the problem that makes this industry worth serving.

Horizontal AI platforms have a legitimate ambition: give many kinds of businesses a way to automate support. Our concern is with an implementation pattern that can follow from that breadth. A generalist engineer is asked to automate an unfamiliar airline operation, with a short deployment window and a handful of example conversations.

Technical ability matters enormously. It does not remove the need for aviation knowledge. A request to change a flight may involve several passengers, connected segments, ticket conditions or a booking issued through another party. The same everyday phrase can describe very different work. An API connection does not tell an engineer which distinctions matter or whether the resulting trip still makes sense.

When those details are missed, a deployment can appear successful while leaving whole categories of requests unresolved. Difficult cases go to people; narrow successes dominate the demonstration. That is a failure mode to investigate, not a claim that every generalist platform or every deployment behaves the same way.

We believe the people designing automation should understand the operation deeply enough to challenge the workflow, recognize exceptions and evaluate the outcome. Engineers and travel specialists need to work together. Coverage should be judged against the actual mix of requests, including the cases the system declines, with customer experience examined alongside completion.

People often call because the alternative has failed them. The chat cannot complete the request, loses the context or sends them through a sequence of answers that never quite address the problem. In that situation, calling is a rational attempt to reach someone who can actually help.

A phone conversation asks both parties to be present at the same time. It can mean waiting on hold, repeating details after a transfer and staying on the line while work happens elsewhere. Text can let a passenger provide the request, continue with their day and return when there is something useful to review. It can also make it easier for a support operation to handle work concurrently.

That advantage only matters if chat can do the job. It needs to retain context, ask focused questions, complete the underlying work and make the outcome clear. It should not require the passenger to keep typing to prove they are still there while the system is busy. Nor should it close a difficult conversation and count the silence as success.

We want chat that people choose because it is the most effective route to a resolution. Voice still matters for accessibility, personal preference and situations where talking is genuinely easier. The goal is not to hide the phone number or punish someone for calling. It is to remove the reasons people feel they must.

NPS and CSAT can tell us something valuable about how an experience felt. We should listen to that feedback. But asking someone to grade support is not the same as establishing whether we delivered the best achievable outcome. A passenger may be relieved simply to receive a coherent answer after disappointing experiences elsewhere.

A traveler should not need specialist knowledge of fares, systems or airline processes to judge whether we explored a better solution. That expertise is our responsibility. If a more suitable option existed and we never looked for it, a positive survey response does not erase the missed opportunity.

We believe quality needs several forms of evidence: what the passenger says, whether the request was actually resolved, whether the action was correct and authorized, how much effort the passenger spent, and whether the problem returned. Specialist review should also ask which feasible alternatives were missed. Speed and completion alone are not enough if the resolution is wrong.

Honest measurement also means showing the boundaries. Define which requests are included in a coverage figure. Keep handoffs and repeat contacts visible. Examine failures and difficult cases, rather than letting easy successes set the story. Comparisons need to account for differences in the work being handled.

The benchmark should keep moving as we learn what is possible. We want satisfied passengers, but we also want the intellectual honesty to ask whether they had to settle for less than we could have delivered. A better experience than yesterday’s chatbot is progress. It is not the end of the work.