SaaS Isn't Dead. For a Travel Agency, the Second S Is the Whole Point

SaaS is not dead, and travel agencies should be glad about it. Code has become cheap, so the value of software has moved to the second S: service. Service means the software knows your rates, your people and your approvals, and someone keeps it running as travel changes around it.

I have spent 31 years in travel, from my first agency job in the 1990s to one of India's largest online travel companies, and now building NAMA. A post by James O'Brien, co-founder and COO of Lyco, put words to something I have watched for years. He was responding to an interview with SAP's CTO, Dr. Philipp Herzig, in The Rundown, where Herzig pushed back on the weekly "SaaS is dead" posts. His two points: building software is far easier than running it, and deciding what to build takes a deep read of the business, its people, its processes and its data.

O'Brien's conclusion: when AI can produce a working app in an afternoon, writing code stops being the scarce part. The scarcity moves to service. Apply that to an Indian travel agency and it explains most of what goes right and wrong with agency software.

Is SaaS dead now that AI can write code?

No. What is dying is the old software deal: one product, built once, sold to thousands of companies that bent their processes to fit it. That deal made sense when writing code was the expensive part. A travel agency knows this deal well. It is the CRM where "booking" means something different from your booking, the accounts package that has never heard of a service charge on a tour, the itinerary tool that cannot read a hotel contract in a PDF.

Code being cheap does not remove the work. It removes the excuse for making the customer do the adapting.

What does service mean for a travel agency?

Service is the unglamorous part. Sitting with the people who do the work. Understanding the data their day depends on. Knowing whose judgment the team already trusts. Running the thing as the business changes underneath it.

In an agency, the data is scattered: rate sheets in Excel, contracts in PDFs, supplier confirmations on WhatsApp, margins in the owner's head. These silos are not a technical problem. They are the reason a quote takes hours.

At NAMA this is the work we do with every agency before anything is switched on: load the agency's own rates, connect its own email and WhatsApp, write its follow-up rules in plain language. The software part is quick. The service is where the time goes.

Why do rates decide whether travel software works?

In travel, the data under the software decides whether it helps or harms. At one of India's largest online travel companies, I saw API inventory carry no market-specific rates, so a Japanese client working in Gurgaon was booked at Indian-market rates. Convincing the hotelier to honour the right rate took enormous time and effort. And Singapore hoteliers reprice several times a day, with heavy blackout dates around the large conferences that run all year.

A rate you remember is not a rate you can quote. Software that guesses rates is worse than no software, because it sends the wrong number at the speed of light. This is why NAMA builds every quote from the agency's own rates, suppliers and markups, with the source of each number visible.

Whose judgment does the software trust?

Herzig's sharpest point, quoted in O'Brien's post: the companies moving fastest gave access to people whose judgment the organization already trusted.

In an owner-led agency, that person is the owner. Every agent in the office knows the rule: the owner approves the quote, the owner decides the exception. That is how our agent, EKLA, works. It acknowledges the enquiry from your own number, prepares the quote, and sends the proposal to your phone. You reply approve or reject. Nothing reaches a client until a person the business trusts says yes. The chasing goes to the agent. The judgment stays with you.

What happens when the business changes under the software?

Travel changes daily. Rates move, blackouts appear, a supplier changes terms, a client wants the airport transfer removed. If every change needs a developer ticket, the software sits frozen while the business moves.

Service means the change is part of the deal. A follow-up rule you state in a sentence, "follow up every quote after 2 days on WhatsApp", becomes a bounded workflow that runs the same way every time. A new rate sheet gets loaded, not coded for. The software keeps fitting because someone is running it, not because it was perfect on the day it shipped.

What should an agency ask before buying software now?

Five questions worth asking any vendor, including us:

• Does it build quotes from my own rates and contracts, or from generic data?
• Can I see where every number in a quote came from?
• Does anything reach a client without my approval?
• Do enquiry replies go from my own email and WhatsApp number?
• When my rates or rules change, who updates the system, and how long does it take?

Software as a Service, taken literally, is more true now than it has ever been. Code is cheap. Knowing an agency's rates, people and judgment, and keeping the whole thing running, is the valuable part, and it always was. That is what we build at NAMA: software that runs a travel company end to end, from enquiry to invoice, so a quote that took hours goes out in 15 minutes and no enquiry waits for the owner to be free.

Source and credit: this post responds to James O'Brien's LinkedIn post on the second S of SaaS (O'Brien is co-founder and COO of Lyco), which quotes SAP CTO Dr. Philipp Herzig's interview in The Rundown.