Which Hospitality Software Survives Cheap AI?

Key Takeaways: AI is collapsing the cost of building small software, which means single-purpose tools are becoming commodities. The hospitality tools most exposed are the ones doing one job on borrowed data: standalone survey senders, review blasters, bulk SMS with no guest history behind it. The tool that gets more valuable is the hub, the system holding the guest record that everything else reads from. This piece is about how to tell which of your vendors is which, and why the hospitality hub cannot simply be Salesforce.

---

The Argument Worth Paying Attention To

Jason Lemkin of SaaStr made an observation recently that is worth sitting with if you buy hospitality software. His version: “A lot of software will become cheap and free,” particularly single-user point solutions. His evidence was concrete. He replaced a $4,000-a-year email marketing tool with something he built himself in under an hour, because the tool he was paying for had gone stale, with no AI and no integrations.

But the second half of his point is the one most people skip. Complex software did not become less important in his stack. It became more important. His CRM became the hub his AI agents run on, and he described more than twenty agents operating on top of it.

Both halves are true at once, and the distinction between them is the most useful procurement question in hospitality right now.

Two Kinds of Vendor in Your Stack

Look at your current subscriptions and sort them into two piles.

The first pile is tools that do one job using data they got from somewhere else. A survey tool that emails guests after checkout. A review-request sender. A bulk SMS tool you paste a list into. A separate app for digital guidebooks. Each one solves something real. But none of them own anything you could not get elsewhere, each one adds a login, and each one needs its list refreshed from a system that actually knows who your guests are.

The second pile is systems of record. Your PMS, which owns inventory and the reservation. Your CRM, if it genuinely owns the guest relationship rather than renting a copy of it.

The first pile is what gets cheap. Not because those vendors are bad, but because their moat was the effort of building the thing, and that effort is collapsing. When an operations manager can describe a post-stay survey flow to an assistant and get a working version the same afternoon, a $500-a-month survey subscription becomes a hard sell.

The second pile does the opposite. It gets more valuable as more automation runs against it, because everything downstream depends on reading the guest record correctly.

Why The Cheap Tool Was Replaceable

It is worth being precise about why that email tool lost. It was not price. It was that the tool was stale and disconnected. No AI, no integrations.

That is the tell. A tool with no integrations is a tool holding a stale copy of someone else’s data. It was always the weakest thing in the stack; AI just made the alternative obvious.

Run the test on your own vendors. For each one, ask: if this disappeared on Monday, what would I actually lose? For a point solution the honest answer is usually “a workflow I would have to rebuild, and a list I would have to re-export.” For a system of record the answer is “the history of every guest relationship we have, and the connection to the system that books them.” Those are not the same kind of loss.

The Hospitality Hub Cannot Be Salesforce

Here is where hospitality diverges from the general business case.

In most industries the hub Lemkin describes is a general CRM. That works because the central object of a general CRM matches the central object of the business: a deal, moving through a pipeline, owned by a rep, with a close date and an amount.

Hospitality does not have deals. It has reservations. A reservation has an arrival date and a departure date, a property or unit, a rate, a folio, a party size, and a guest who may come back every summer for a decade. It generates events that nothing in a pipeline model has an equivalent for: a cart abandoned at checkout, a stay completed, a gap night that opened on Tuesday, a folio that closed higher than it opened.

You can model all of that in a generic CRM. Operators do. It requires custom objects, a consultant, and someone to maintain the mapping every time either system changes. We wrote about that trade in more detail in our comparison with Salesforce.

So hospitality needs the same architecture with a different centre. Not a pipeline CRM with reservations bolted on, but a platform whose native object is already the reservation, and whose native identity is the guest across every stay they have ever had with you.

What Makes Something A Hub

Four things, and they are worth checking against any vendor claiming the role.

It assembles the record rather than storing a copy. Guest profiles should be built from your PMS in real time, not uploaded. If the answer to “how does data get in” involves a CSV, it is not a hub.

Every channel writes back to it. Email, SMS, WhatsApp, web chat, OTA messages and voice should thread into one guest record, so the conversation is a property of the guest rather than a property of whichever tool happened to carry it. That is the whole point of a unified inbox.

It carries the things you cannot rebuild. Consent, per channel, per guest. Stay history. Lifetime value. Attribution back to the campaign that produced the booking. An audit trail. These are the assets that make a system expensive to leave, and they are exactly what a point solution does not have.

Agents can reach it. This is the new requirement, and it is the one most hospitality vendors have not answered. If your AI assistant cannot query the guest record directly, the record is not part of your AI stack. SendSquared exposes it through an MCP server and a command line tool, so an assistant works from the same live record your team does, under the same permissions.

The Part That Has Not Happened Yet

Lemkin’s forward-looking claim is that agents will soon build small software on their own, invisibly, and simply hand you the result. You would not necessarily know an app had been built for you.

Take that seriously for a moment, because it changes what you should be buying today. If an agent can spin up whatever small tool a situation needs, then the scarce thing is not tools. The scarce thing is a trustworthy record for those tools to read from and write to. An agent that builds you a perfect owner-reporting view on top of a stale export has built you a perfect way to be confidently wrong.

Which turns the procurement question inside out. The right thing to consolidate on is not the vendor with the longest feature list, because features are the part getting cheap. It is the vendor that owns your guest data correctly, integrates with the system that books them, and lets your agents in.

That is what we mean by the AI context layer, and it is the reason we built the integrations before we built the automation on top of them. The integration is the hard part. It always was. AI just made everything around it look easy by comparison.

What To Do This Quarter

Nothing about this requires a big migration. Three concrete steps:

1. Sort your stack into the two piles. Anything in the point-solution pile that is up for renewal deserves the “what would I actually lose” question before you sign again.
2. Find out where your guest record actually lives. If the honest answer is “spread across six tools and a spreadsheet,” that is the thing to fix first, ahead of any AI project.
3. Ask every vendor how an agent reaches their data. Not whether they have AI features. Whether your AI can read your data out of their system. The answers will sort your vendors faster than any feature comparison.

If you want to see what the hub looks like against a real PMS, book a demo and we will walk your own guest data rather than a sandbox.