Singapore Airlines Replaces Its Scripted Chatbot with an LLM and Doubles CSAT

It is a familiar pain for anyone who has built customer support: the scripted chatbot. Every intent has to be described, every branch drawn in advance, and then a person writes something like "my flight was cancelled, and I have a transfer and a hotel, what do I do?" The bot answers with a menu of five options. Singapore Airlines went through this and rebuilt its Kris bot on an LLM. The company shares figures and architectural details from which there are a few takeaways.

What changed in Kris

In the old dialog-flow setup, topic coverage depended on how many dialogs had been described by hand. If the needed intent did not exist, the conversation most often went to a human agent, even though the question could have been resolved via self-service. Scaling such a system is hard: every new topic means a new branch.

After the move to the OpenAI API, the bot parses the customer's free-form intent on its own, answers based on a knowledge base, holds a conversation about several topics at once, and hands the chat to a human employee together with context. Kris now answers general questions, handles special requests, reports flight disruptions in real time, and performs some transactions. Planned next are booking changes, baggage operations, and more complex agentic scenarios.

The airline's reported result: CSAT rose 2x. Separately, agents were given a call summarization tool built on the same API so they spend less time on post-call wrap-up. Average case handling time fell by roughly 10%.

Flight Recommender: the model calls tools instead of inventing prices

The second product is Flight Recommender. Customers describe a trip in plain language instead of fiddling with date and destination filters over and over. Usage grew almost threefold over the year.

It is not built on the idea that "the model knows about flights itself." An orchestration layer sits between the model and the user, connected to fare and seat availability data. The model interprets the request, calls the necessary tools, and retells the result in human language. Prices and seat availability come from the airline's systems, not from the model's memory.

Protective mechanisms are built around this: input and output validation, handling of malicious and inappropriate requests, hallucination reduction, handling of personal data, and access only to the context needed for a specific request. The next step is to turn search into a dialog in which an idea can be refined without starting over.

AI across the whole development cycle, not just in code

The most practical part of the case for teams concerns development. Models are used at the stages of clarifying requirements, analyzing stakeholder meetings, writing specifications, finding edge cases, generating test cases, reviewing architecture, and slicing large tasks into verifiable chunks.

An example from the source: for one commercial feature, the team first asked the model to challenge assumptions and find ambiguous requirements. Only after that did the AI help build design options, implementation plans, tests, and code. On selected activities, productivity gains reached up to 20%. The role of people shifted from producing artifacts to framing tasks, reviewing, and validating.

Separately, there is an internal platform called Jarvis with access control. Employees use it to work with PDFs, Word, Excel, and presentations, and to build their own workflows and small knowledge bases. More than 60% of staff use it monthly.

What to keep in mind when reading

This is a case study from the OpenAI website, meaning commercially motivated material. The CSAT measurement methodology is not disclosed, and it is unclear what exactly was compared and over what period. The figures for handling time (about 10%) and development (up to 20%) are far more modest than the headline "2x." They are best treated as a realistic benchmark rather than a promise.

Practical takeaways for teams building support or search:

• Scripted bots hit the wall of manual topic coverage. An LLM with a knowledge base removes this limit, but requires a high-quality knowledge base and a careful handoff to the agent with context.
• Facts (prices, availability, flight statuses) should come from tools, while the model is left to understand the request and phrase the answer.
• Build in guardrails, personal data controls, and human review from the start, not after the first incident.
• Requirements checking and edge case generation are worth adopting earlier than automatic code generation: that is exactly where the Singapore Airlines team describes the most obvious benefit.