Runnr.ai review: WhatsApp-first and it shows, in the right ways

After my experience with Quicktext, where I spent three months discovering that “full integration” meant a one-directional data read, I had a specific question for my next evaluation. When a company says their tool integrates with our PMS, what exactly happens at the API level? I run technology for a hotel group in France, about fifteen properties, so I need to know whether an integration works at scale before I recommend rolling it out.

Runnr.ai caught my attention because of a conversation with a colleague in Strasbourg who described them as “WhatsApp-first, not WhatsApp-also.” That distinction matters architecturally. When a platform is designed around a specific channel from the beginning, the data model, the message queuing, and the integration logic all reflect it. When the channel is added later, you get adapters and translation layers that create friction. I wanted to see which one Runnr.ai actually was.

Some background on the company itself, because it matters. Runnr.ai was founded in 2022 by three people who all spent years at Booking.com. That pedigree explains something about the product, but it also raises a question worth asking. Booking.com is not a popular name among independent hoteliers. The commission model, the rate parity clauses, the way the platform positions itself between hotels and their guests: these are sore points for a lot of the people Runnr.ai is now selling to. Building a hotel communication tool on a career spent at the company many hoteliers consider their most difficult partner is an unusual foundation. It doesn’t mean the product is bad. But it does mean the instincts behind the product were shaped by the distribution side, not the hotel side.

There’s also something I’ve heard from a few people in the industry, and I want to mention it even though I can’t verify it. The word going around is that one of the co-founders left the company at an early stage, and that there were concerns about the direction. The gossip suggests the real goal is growth-first: build fast, scale fast, and position for an exit rather than building a long-term product. I should be clear that this is industry gossip, not something I can confirm. But when I look at the funding rounds, the rapid customer acquisition, and the way the company talks about scale on its website, the pattern is at least consistent with that read. For a hotel making a multi-year technology decision, it’s worth considering whether your vendor is building to stay or building to sell.

The team is around 10 to 14 people (their own website lists both numbers), running on roughly $2.2M in total funding (a EUR 1M round from Arches Capital plus smaller rounds). That’s a lean operation. It’s also a risk. A small team building a product used by 500+ properties in over 10 countries is stretched thin, and I’d want to see that headcount grow before making any long-term bets on the platform.

Verifying the WhatsApp-first claim

I started where I always start: the API documentation. Runnr.ai publishes theirs, which is already an improvement over vendors who make you request access or, worse, hand you a PDF. The documentation is structured around conversation flows rather than isolated endpoints. This tells you something about how they think about the product.

The WhatsApp Business API integration uses the official Meta endpoints correctly. Message templates are pre-registered for transactional messages (booking confirmations, check-in instructions, checkout reminders) with proper HSM template approval. Session messages within the 24-hour window are handled as free-form. This is how WhatsApp’s rules work, and Runnr.ai follows them rather than trying to work around them, which some competitors do in ways that risk account suspension.

The message delivery pipeline is built for WhatsApp’s asynchronous model. Messages queue, deliver, and confirm receipt with proper status callbacks. When I tested message delivery during a brief WhatsApp API outage, queued messages sent once the service resumed. No messages were lost. With Quicktext’s WhatsApp feature, I’d seen messages simply vanish during a similar incident.

One architectural detail I want to flag. Runnr.ai doesn’t connect directly to the WhatsApp Business API. They work through an intermediary, a third-party messaging provider that sits between Runnr.ai and Meta’s WhatsApp infrastructure. This means your guest messages pass through an additional party before reaching the platform, which has two practical consequences. First, data transparency: there’s another company in the chain handling your guest conversations, and most hoteliers won’t know it’s there. Second, features: some WhatsApp Business API capabilities, like interactive list messages, product catalogues, and certain rich media components, may not be available or may be limited depending on what the intermediary supports. I noticed we were missing message components I’ve seen on other platforms that connect to the WhatsApp API more directly. It’s not broken, but it’s a constraint that affects what you can build on top of the channel.

The AI concierge in practice

The AI handles guest queries through WhatsApp conversations. A guest writes asking about parking, and the AI pulls from the knowledge base and responds in the guest’s language. Standard enough. Where it performs well is in the contextual awareness. The AI knows the guest’s reservation dates, room type, and any previous interactions. When a returning guest asked about the same restaurant she’d inquired about on a previous stay, the AI referenced the earlier conversation. Small detail, technically simple (it’s just query context from the guest profile), but guests notice.

The AI struggles with ambiguity. “Can you sort out the thing from last time?” produced a confused response rather than asking for clarification. More complex queries, anything requiring nuance or judgment, get handed to staff. The handover mechanism works: the conversation transfers to the human inbox with full context, and the guest sees no interruption. Perhaps 15–20% of conversations needed human intervention in my testing. That’s reasonable for the current state of hotel AI, though the marketing suggests a higher automation rate than I observed.

For what it’s worth, third-party numbers support a higher figure at scale. Center Parcs de Eemhof (950 cottages, so a very different operation from a boutique hotel) reported 540 hours saved per month and approximately 90% automation of guest communication using Runnr.ai. I suspect the automation rate improves with volume and with properties where guest queries are more predictable. A holiday park with standard check-in procedures is a simpler problem than a city hotel where every guest has different needs.

One small but telling detail: a user in a public review noted they’d prefer “the name of the hotel instead of the Virtual Assistant” appearing in messages to guests. This means guests may see communications branded as coming from Runnr.ai’s virtual assistant rather than from the hotel itself. For a product built around guest communication, that’s a branding gap worth fixing. Guests should feel they’re talking to the hotel, not to a third-party tool.

What concerns me more is what I keep hearing from hoteliers who use it day to day. The AI still produces strange conversations. It promises things to guests that the front desk knows nothing about. A late checkout that was never approved, a room upgrade that doesn’t exist, a restaurant recommendation for a place that closed last year. The front office finds out when the guest arrives expecting something nobody agreed to. Jumping in to correct the AI mid-conversation is difficult. The handover to a human isn’t smooth enough for the front desk to catch a bad reply before it goes out. And when something does go wrong, you get notified by email. Email. In 2026. For a company that built its entire product around messaging, sending email alerts when a conversation needs attention feels like a step backwards. Your staff are in WhatsApp, in the dashboard, on their phones. Nobody is refreshing their inbox waiting for a notification that a guest was just promised a free upgrade.

For a company that’s been around since 2022, the quality should be further along. The AI issues I’m describing aren’t growing pains from a product that launched last month. These are problems hoteliers have been raising for a while now, and the improvement isn’t visible.

When I step back and look at the full picture, a pattern forms. Founders from Booking.com, a company hoteliers love to resent. Industry gossip about building to sell. An AI that promises guests things the front desk never agreed to. Email notifications in a messaging product. Pricing that looks cheap in the marketing but adds up fast in practice. WhatsApp routed through an intermediary that limits what you can do with the channel. Quality that isn’t improving at the pace you’d expect after years in the market. None of these things alone would change my view. Together, they tell a story of a company riding the AI wave and prioritising revenue growth over building something that truly works for the hotels using it. I’d feel more confident recommending Runnr.ai if even half of these signals pointed in the other direction.

Integration depth, the real test

I connected Runnr.ai to our group’s PMS (widely used in France, same one from my Quicktext review) and ran the same tests.

Reading reservation data: works. Guest name, dates, room type, rate code, all pulled correctly and available in the conversation context. Same as Quicktext.

Writing back to the PMS: here’s where it gets interesting. Runnr.ai can log conversation summaries to the guest profile. Not the full transcript (that would bloat the PMS unnecessarily) but a structured summary: topics discussed, requests made, outcomes. When the front desk at any of our properties opens a reservation, they can see that the guest asked about late checkout via WhatsApp and was offered it at €30. This is bidirectional in a meaningful sense.

The webhook implementation is more complete than Quicktext’s. Payloads include conversation metadata, guest identifiers, message classifications, and booking references. I built a small automation that tags guest profiles in my CRM based on conversation topics, and it worked on the first attempt. With Quicktext, the equivalent webhook payload didn’t contain enough data to do anything useful.

Is it a “full integration”? No. There are still gaps. PMS workflow triggers from chat events are limited to a few predefined actions. I can’t create custom triggers. The rate and availability sync for direct booking conversion works but updates on a polling interval rather than real-time push. For most hotels this is fine. For my standards, it’s a noted limitation.

What’s missing

The dashboard. It works. It displays information. It does not bring any joy. The design language is functional in the way that a municipal parking website is functional. Data tables, basic charts, a colour scheme that suggests nobody on the team has strong feelings about visual design. After spending time in MEWS or Apaleo’s interfaces, Runnr.ai’s dashboard feels like stepping back a few years.

Analytics are limited. I can see conversation volumes, response times, AI resolution rates, and basic channel metrics. What I can’t see: conversion attribution. A guest who received pre-arrival messages and then booked a restaurant through the concierge, did that conversation contribute to a longer stay or a higher spend? The data exists in the system but the reporting doesn’t surface it.

The non-WhatsApp channels exist (email, SMS) but receive less development attention. Email message formatting is plain. SMS capabilities are basic. If your guest demographic doesn’t use WhatsApp heavily, Runnr.ai’s advantage diminishes considerably. Across our French properties, WhatsApp penetration among guests is high. In markets where SMS or WeChat dominate, this tool would be a poor fit.

EU credentials

Dutch company, Utrecht headquarters, EU data hosting. Their processing agreement names AWS eu-west-1 (Ireland) as the primary data location. Sub-processors are listed, and the list is short, which I prefer to the long chains some vendors maintain. Anna would want to verify the specifics, but the foundations are correct.

One entry on that sub-processor list caught my attention: OpenAI LLC, San Francisco, listed for “Generating AI answers.” So the AI concierge I praised earlier runs on OpenAI. The booking data stays in Ireland, the conversation data stays in Ireland, but the moment the AI generates a response, that guest query passes through OpenAI’s infrastructure in the United States. For a Dutch company with otherwise clean EU credentials, this is a notable exception. It means the “EU-hosted” claim comes with an asterisk that most hotels won’t notice until they read the sub-processor list, which most hotels won’t do.

What I couldn’t find, and I did look: any publicly documented security certifications. No SOC 2, no ISO 27001, no penetration test summaries. For a company handling guest personal data and payment-adjacent information through WhatsApp, this is a gap. It may be that they hold certifications and simply don’t publicise them, but in 2026, security posture should be visible and verifiable, not something a buyer has to ask about in a sales call.

Their marketing says “from €3/room/month,” but the actual pricing page tells a different story. Runnr.ai charges a platform fee starting at €100/month (Pro plan), €200/month (Plus), or €400/month (Enterprise). On top of that, WhatsApp messaging costs are charged separately per conversation, averaging around €0.75 per room per month according to their own estimate. In practice, that average tends to run higher depending on how many conversations your guests initiate and which countries they’re messaging from. All plans require a 12-month contract.

The maths matters here. For a 50-room hotel on the Plus plan (which is what most mid-sized hotels would need), you’re looking at €200/month platform fee plus messaging costs that can easily reach €40–50, so somewhere around €250/month or about €5 per room. For a 100-room property, the per-room cost drops, but the base fee stays. For a smaller hotel with 20 rooms, you’re paying €200 plus messaging fees, which works out to over €10 per room per month. That’s expensive. More expensive than HiJiffy, more expensive than Bookboost, and much more expensive than the €3/room figure in their marketing.

The pricing is published, which I appreciate. But “from €3/room/month” as a headline figure only works if you have enough rooms to dilute the platform fee, and most independent European hotels don’t. For the fifteen properties in my group, the maths might work at group level. For a single 30-room hotel, this is one of the pricier options in the category.