RobosizeME’s Sean Anderson: why not all hotel automation should be AI

We sat down with Sean Anderson three days into his role as Chief Revenue Officer of RobosizeME, and he came at it from a useful angle, because he's done this before. At Book4Time, the spa and wellness software company, he consulted with founder and CEO Roger Sholanki for a year before joining as VP of Sales and eventually CRO. He’s followed a similar pattern at RobosizeME: he invested in the last funding round in February, consulted with RSM's founder and CEO Stephen for a month or two, and has now joined full-time as CRO to run sales, marketing, and partnerships.

When we asked him to explain RobosizeME in plain terms, he reached for a framing built for a CIO. In hospitality, even in 2026, there's a pile of manual, repetitive, tedious work that has to get done every single day across reservations, finance, distribution, and revenue management. RobosizeME's job is to be the glue between the systems that handle it. The term he used to describe this best was agentic middleware, though as the conversation went on he was careful that "agentic" is only part of what they actually do.

The work that eats two hours a day

Sean's clearest example came from a corporate director of revenue management he'd spoken to the week before, who runs a team of 66 people. The chain offers its franchisees a corporate revenue-management service, and when the corporate team is involved rather than the franchisee going it alone, they see a real RevPAR uplift from the expertise. But every day, new rate recommendations come in, and the corporate revenue managers spend two to three hours playing email ping-pong to get approvals, because they need an audit trail on every sign-off from the franchisee. It's low-value work, and it caps how far the program can scale, because there are only so many hours in the day. RobosizeME automates that approval loop so the team can cover more properties and focus on higher-value work. The franchisee gets higher RevPAR, corporate benefits, and there are fewer mistakes because the manual step is gone.

The other examples are the same shape. OTA and virtual-card reconciliation, where someone has to take a virtual card from one payment window and move it to another by hand, then assign what's covered on the OTA's card versus the card collected on property. At a busy front desk the on-property card sometimes overrides the OTA card, and then you've got a tangle of issues to fix manually through the OTA portal. Reservation quality checks are another. The thread through all of it is manual work still being done, in 2026, across reservations, finance, and distribution.

The part that isn't AI, on purpose

Here's the part that sets RobosizeME apart from the AI-for-everything pitch. When there's a defined, standardised process to run, they use RPA, robotic process automation, rather than AI. The preferred way in is an API, but APIs aren't always available, or aren't as open as vendors claim, even now. That isn't a blocker, because RobosizeME can log into systems and do the work anyway, the equivalent of a digital worker doing it by hand, standing in for a person and carrying out the task on the hotel's behalf. That part, Sean agreed, is not AI. They use AI when it's the right approach, and don't when it isn't.

His reason is cost and reliability. There's real promise in tools like Claude and Gemini, but token efficiency isn't there for every task, and AI isn't the right tool across the board. He pointed to one organisation that burned through its entire annual token budget in Q1 and had to pull back. The forward-thinking chains are pushing these initiatives down to the property level and experimenting, which he reads as a healthy sign even when it gets bumpy, but if all you have is one tool, and that tool is an LLM, it's probably the wrong approach for producing a business outcome at a cost that works.

What "production ready" really means

Sean mentioned more than once a distinction that matters more than the hype. It's easy now to build something that looks amazing. He's done it himself with these tools, stood up a whole application from the ground up, and then watched it hit production and fall over. That gap, between a demo that works and something a vendor can actually run and support, is the hard part. The concern with letting customers build their own automations is exactly that: they might build it, but is it production-ready, and can it be supported?

The same caution runs through how he talks about risk. When people freestyle with these tools and wire them into core systems, you have to be certain about data sovereignty, data privacy, PCI compliance. He'd caught a presentation in the exhibit hall about the trade-off between quality, speed, and scale on one side and compliance on the other, the idea that you can have two of the three at once. On core systems, he said, the privacy and sovereignty pieces simply have to be in place, and you can't take risks there.

A library, not a one-off

RobosizeME has been around for about two years and has built up a sizable library: Sean put it at 56 automations, split into three suites: finance, reservations, and distribution/revenue management, each with a recommended four or five to start with. The work is increasingly customisation and configuration rather than building from scratch, because no two chains or management companies operate exactly the same way, even when they run the same underlying systems. For now RobosizeME does the building rather than the customer, partly out of the same production-ready caution.

The proof point he offered was a boutique upper-upscale lifestyle chain, not a big group, that started a finance-centralisation project aiming to save 600 hours a month. They've passed that and are now at 3,300 hours a month, with new automations added each quarter, starting with the simpler high-impact ones and moving gradually into more complex work.