← Property management

Mews review: the privacy audit of Europe's biggest cloud PMS

anna

Rating

8/10

I don’t typically review PMS software. My previous reviews for Six Hoteliers have focused on guest communication tools, where the privacy stakes are high but the data footprint is relatively contained. A PMS is different. It sits at the centre of everything: guest profiles, passport scans, credit card tokens, rate agreements, housekeeping notes, invoicing histories. If you’re going to trust a single vendor with the most sensitive data your hotel produces, you’d better understand what they do with it.

Mews is the obvious place to start. It’s Europe’s largest cloud-native PMS by most measures: over 15,000 customers in 85+ countries, more than $200M in annual revenue, and a fresh €255M Series D raised in January 2026 that values the company at $2.5 billion. Elena already runs Mews at her 30-room resort in Greece, and when I told her I was reviewing it, she said something along the lines of “just tell me what’s in the fine print.” So that’s what I did. I read the fine print first, tested the product second, and formed an opinion third.

For context, this review is part of our property management category, where we’re testing eight PMS platforms across the team. My job is to look at Mews through the lens I always use: data processing, privacy architecture, GDPR compliance, and whether a vendor’s stated commitments survive contact with reality.

Starting where I always start: the DPA

Mews publishes a Data Processing Agreement on their website. You can read it without signing anything or contacting sales, which is the right starting point. I’ve audited enough DPAs to know that the ones you have to request by email tend to be the ones with the most creative interpretations of “necessity.”

The DPA is structured properly. Mews positions itself as data processor, your hotel as controller. Processing purposes are defined and scoped. There are provisions for data subject access requests, deletion, and portability. Standard contractual clauses are referenced for any transfers outside the EEA, though Mews states that primary data processing occurs within the EU. The legal basis for processing is articulated per category rather than lumped under one broad justification.

What I looked at closely: the data retention language. Mews specifies retention periods and ties them to the contractual relationship and legal obligations (tax records, for example, which in most EU jurisdictions require seven to ten years of retention). This is correct. What I would prefer is more granularity. Guest communication logs, for instance, don’t carry the same legal retention obligation as invoicing records. A DPA that distinguishes between these categories is stronger than one that applies the same retention logic to everything. Mews’s approach is adequate, not exceptional. It doesn’t trip my “blanket clause” alarm the way some competitors do, but it doesn’t set a new standard either.

The DPA was last updated in late 2025. I confirmed this directly. For a company processing data on behalf of 15,000 hotels, annual DPA reviews are the bare minimum, and they’re meeting it.

Sub-processors: the real question at $2.5B scale

This is where things get interesting. When a company raises $710M in total funding and processes over $10 billion in payments annually, the sub-processor list is no longer a formality. It’s a map of everywhere your guest data could end up.

Mews maintains a sub-processor list. Getting to it requires some navigation; it’s not as prominently published as Bookboost’s, which sits on a dedicated page and updates visibly. But it exists, it names the sub-processors, and it states their purposes and locations. I counted the entries. The list is longer than I’d like. That’s the inevitable consequence of a product that bundles PMS, payments, point of sale, and booking engine into one platform. Each functional area introduces its own dependencies.

The payment processing chain is particularly worth examining. Mews processes over $10 billion annually through its integrated payments product, Mews Payments. This runs through Adyen, which is Dutch and publicly listed on Euronext Amsterdam. From a jurisdictional standpoint, that’s as good as it gets for European payment processing. Guest card data is tokenised; Mews is PCI DSS compliant. I didn’t find issues here, but I did spend time looking, because this is where the volume of sensitive data is highest.

What concerns me is trajectory. A company at this growth stage acquires other companies (they bought Atomize, a Swedish revenue management tool, in 2023), adds product lines, and expands into new markets. Each of those moves tends to add sub-processors. I’d want to see a commitment to notifying hotels before adding new sub-processors, with a reasonable objection window. The DPA includes provisions for this, though the practical enforcement of that objection right is something I’d test if I were a larger customer with more negotiating power.

One more thing on sub-processors: the Atomize acquisition means Mews now processes revenue management data alongside PMS data. That’s a deeper data relationship than a simple integration. When your PMS vendor also controls your pricing intelligence, the data flows become more intertwined, and the privacy implications compound. I asked Mews about this during my evaluation and received a reasonable answer about data separation, but I’d want to see that formalised in the DPA itself.

Testing at our Stockholm property

I trialled Mews for six weeks at our design hotel. We run 42 rooms, mostly design-conscious leisure travellers and a steady stream of business guests from the Nordics. Our existing PMS is a legacy system I won’t name because it would be unkind.

Setting up Mews was not quick. The onboarding process took the better part of two weeks, including data migration, rate configuration, channel manager connections, and staff training. Mews assigns an onboarding specialist, and ours was competent and responsive, which made a real difference. But I’ve since spoken to colleagues who had a less polished experience. One hotelier at a 60-room property in Munich told me her onboarding felt rushed, as if the specialist was juggling too many properties at once. She described a gap between the structured, attentive process shown during the demo and the reality once the contract was signed. My own experience was good, but it’s worth knowing that onboarding quality seems to vary.

Rate plan configuration was more involved than I’d expected. We run a fairly standard setup for a Nordic design hotel: a handful of room categories, seasonal pricing, corporate rates, and package deals. Nothing exotic. But the way Mews structures rate plans, with products, rate groups, and restrictions layered on top of each other, took real time to map out. Hotels migrating from simpler systems will feel this. The flexibility is there, and I appreciate it once it’s configured correctly, but the initial complexity caught me off guard. I spent an entire afternoon on rate plans alone before they matched what we had in our old system.

Once running, the daily operation was faster than what we had before. The interface, which Mews calls the “commander,” is clean and modern. The dashboard shows arrivals, departures, in-house guests, and housekeeping status in a way that my front desk team understood within a day or two. That said, I want to be precise about the word “intuitive” because Mews uses it frequently in their marketing. The broad layout is intuitive. The logic of moving through common tasks is not always so. Some workflows require more clicks and tab switches than I’d expected. Modifying a reservation, applying a discount, and then adjusting the payment in a single transaction, for example, took my team through four or five screens. For a platform built around the idea of speed, a few of these daily tasks feel heavier than they should. This is not a dealbreaker, and experienced users will develop muscle memory. But it’s a gap between how the product is marketed (“frictionless” comes up a lot) and how certain workflows play out in practice.

Where Mews earns its reputation is the automation layer. The system is built around the idea that hotels should automate everything a computer can do and free staff for everything it can’t. Automated check-in, automated check-out, automated payment processing, automated housekeeping task generation. I’m sympathetic to this philosophy, though I think it suits some hotels more than others. Our design hotel in Stockholm trades on personal interaction. Guests expect a human at the desk who knows their name, not a kiosk. I turned off several of the automation defaults during setup, which Mews accommodates without difficulty. The product doesn’t force automation; it just defaults to it.

The booking engine is functional and integrates cleanly with the PMS. Direct bookings flow through without the data re-entry that plagues some competitors. Channel manager connections (we use a mix of Booking.com, Expedia, and a few niche Scandinavian channels) synced correctly during my trial. Rate parity held. Availability updates were prompt. No overbookings, which is the minimum standard but one that several PMS tools I’ve heard about still occasionally fail.

Integrated payments and what they mean for data

Mews Payments deserves its own section because it changes the data equation. Most PMS platforms connect to a third-party payment gateway. Mews has built payments into the core product, processing transactions through Adyen but managing the guest-facing experience, tokenisation, and reconciliation within the Mews platform itself.

From an operational standpoint, this works well. Payment reconciliation was automatic during my trial. Chargebacks are tracked within the PMS. Terminal management (we tested with two Adyen terminals at reception) was straightforward. Guest folios, deposits, and pre-authorisations all worked without the manual intervention our old system required. I should note, though, that Elena mentioned hearing from a colleague running a larger property that reconciliation delays can surface, particularly around month-end when transaction volumes spike. We didn’t experience this at our scale, but it’s something I’d watch for at properties processing higher volumes.

From a privacy standpoint, integrated payments mean Mews holds a deeper data relationship with your guests. They process not just who stayed and when, but how they paid, what they spent at the bar, and how often their card was declined. This is sensitive commercial data. The PCI DSS compliance is properly maintained, and tokenisation means Mews doesn’t store raw card numbers. But the breadth of financial data flowing through a single vendor is something every hotelier should consider. If you’re using Mews for PMS, payments, POS, and booking engine, you’ve centralised an enormous amount of data in one place. The convenience is real. The concentration risk is also real.

I asked Mews whether a hotel can use the PMS without Mews Payments. The answer is yes; you can connect external payment processors. But the product is clearly designed to encourage the integrated option, and the pricing reflects that. Hotels using Mews Payments get better rates on the software subscription. This isn’t unusual in the industry, but it’s a factor worth acknowledging: the financial incentive pushes toward deeper data centralisation.

I checked the Mews booking engine’s cookie implementation on our website. The disclosure is adequate. First-party cookies are used for session management; third-party cookies for analytics are disclosed and consent-managed. The consent banner uses a proper opt-in mechanism rather than the “continue browsing equals consent” nonsense that some vendors still deploy.

I also examined the Mews Marketplace, which is their integration hub. When you connect third-party tools through the marketplace, those tools introduce their own tracking and data processing. Mews’s privacy documentation covers this (third-party integrations are the hotel’s responsibility), which is legally correct but practically challenging. A hotel manager connecting a new upselling tool through the marketplace isn’t going to audit that tool’s cookie implementation. The marketplace makes it easy to extend functionality; it also makes it easy to inadvertently introduce privacy issues. This is a systemic problem across all marketplace-based platforms, not unique to Mews, but it’s worth flagging.

The marketplace and 600+ integrations

The Mews Marketplace lists over 600 integrations. That number is impressive and, I suspect, slightly inflated by counting minor variations separately. The practical reality is that most major hotel technology categories are well represented: revenue management, guest messaging, upselling, reputation management, door locks, energy management, accounting. If you need to connect something to your PMS, there’s a reasonable chance Mews has a pre-built connection for it.

The marketplace architecture matters for privacy because each integration creates a data flow. Mews uses an open API, which Thomas would appreciate from an engineering standpoint. But from a privacy standpoint, every API connection is a potential data egress point. Mews provides granular permission controls for marketplace connections (you can specify which data categories an integration can access), which is the right approach. I tested this by connecting and then disconnecting a trial integration, and confirmed that the permission revocation was immediate and complete.

Compared to a platform like Apaleo, which takes the API-first philosophy even further by making the PMS itself headless, Mews strikes a middle ground. You get a fully functional PMS with a built-in interface, plus the ability to extend it through integrations. For hotels that want a working product out of the box rather than a platform to build on, this is the more practical choice. The trade-off is that you’re more dependent on Mews’s own design decisions, whereas Apaleo gives you the freedom (and the burden) of choosing your own front-end.

Support, and what happens when a company scales this fast

This deserves attention. During my six-week trial, I contacted Mews support four times. Twice I received helpful, specific answers within a few hours. Once I waited over a day for a response that could have been more thorough. The fourth time, I was passed between two agents and had to re-explain the issue from scratch. That last interaction was minor (a question about tax configuration for Swedish VAT rules), but it left an impression.

Elena had a similar observation. She told me that support at Mews feels different now compared to two years ago when she first set it up. Back then, she spoke to the same person repeatedly and they knew her property. Now she rarely gets the same agent twice, and the responses are more templated. She doesn’t think it’s bad, exactly, just less personal. I’ve heard this from other hoteliers too, at a conference in Berlin last year. The pattern is familiar: a company grows from 5,000 customers to 15,000, support headcount doesn’t scale at the same rate, and the experience shifts. Mews is going through those growing pains now. It’s not a reason to avoid the product, but it’s something to be aware of, particularly if you’re the kind of property that relies on vendor support rather than having an in-house technical team.

Pricing and the contract question

Mews runs three tiers: Essentials, Advanced, and Enterprise. Starting price is around €300 per month, scaling with room count and feature set. This is mid-market pricing for a cloud PMS. Not cheap for a small independent, but not enterprise-only either. Elena pays on the lower end for her 30-room property and considers it reasonable value.

What I dislike is the contract structure. Mews typically requires a two-year commitment. For a PMS, I understand the logic: migration is expensive, onboarding takes time, and neither party benefits from a hotel switching systems every six months. But two years is a long time to commit to a vendor, particularly when you haven’t yet experienced how they handle a major issue, or how their support holds up once the onboarding team hands you off to the general support queue. I asked about shorter terms and was told they’re available on Essentials, but Advanced and Enterprise pricing assumes a two-year agreement.

This is a practical problem, not a principled one. Two-year contracts are common in PMS land. But in a market where cloud-native competitors are offering monthly billing (RoomRaccoon, for instance, doesn’t lock you in), the two-year default feels like a legacy practice grafted onto a modern product. If Mews is confident the product retains customers on merit, the contract shouldn’t need to do the retaining.

Pricing transparency is mixed. You can find the tier structure and starting prices on the website, which I appreciate. But the actual price for your specific property requires a sales conversation, because it depends on room count, payment processing volume, and which add-ons you need. Sophie would have more to say about this. I’ll just note that it’s neither the most opaque nor the most transparent pricing in this category.

What Mews gets right about being cloud-native

Mews was built in the cloud from day one, unlike several competitors that migrated legacy on-premise software to hosted environments and called it “cloud.” This distinction matters more than marketing suggests. True cloud-native architecture means continuous deployment (Mews pushes updates without downtime, without scheduling maintenance windows, without requiring your IT person to install anything). It means the product I tested this week is already slightly different from the product I started testing six weeks ago, because features and fixes ship continuously.

For privacy, cloud-native architecture also means that security patches are applied globally and immediately. When a vulnerability is discovered, every hotel on Mews gets the fix at the same time. With on-premise or hybrid systems, patches sit uninstalled for weeks or months because someone has to schedule the update. That’s a meaningful security advantage.

The system was stable throughout my trial. No downtime, no data inconsistencies, no sync errors with channel managers. Uptime was, as far as I could tell, perfect. I’ve heard reports of the system slowing down at properties with higher room counts during peak occupancy periods. That’s hard for me to verify at 42 rooms, but it’s something I’d ask about if I were evaluating Mews for a 200-room hotel. Six weeks at our scale isn’t long enough to make definitive reliability claims, but nothing I experienced gave me reason for concern.

What I’d tell a colleague

Mews is a good PMS. It’s not a perfect privacy story, but it’s a reasonable one for a company of this scale, and it’s better than many alternatives. The cloud-native architecture is a real advantage. The integrated payments are operationally solid, with the caveat that you’re centralising a lot of data in one place. The marketplace is extensive. The automation philosophy is sound, even if you choose to dial it back (as I did).

The commander interface is well-designed in broad strokes, though some daily workflows take more steps than you’d expect from a platform that markets itself on speed. Give your team a week or two, not a day, to feel comfortable with it. The learning curve is steeper than the marketing materials suggest, though it’s manageable.

Be realistic about onboarding. Mine went well, but the experience isn’t uniform. Ask to speak to your assigned onboarding specialist before signing, and set clear expectations about the timeline. Rate plan configuration, in particular, deserves more attention than the sales process implies.

Support is adequate but showing signs of strain. If you’re a small independent without internal IT, factor this in. Two years ago I might have called Mews support a strength. Today it’s a neutral point.

The DPA is adequate without being exemplary. The sub-processor list exists but could be more transparent. The two-year contract is an annoyance. And the broader question of data concentration, of putting your PMS, payments, POS, revenue management, and booking engine all with one vendor, is something every privacy-conscious hotelier should think about carefully.

For Elena’s Greek resort, Mews is probably the right choice. It’s modern, it works, and it doesn’t require a technical team to maintain. For my design hotel in Stockholm, I’d seriously consider it as a replacement for what we’re currently running. The privacy audit didn’t uncover anything alarming, which is the best compliment I can pay a vendor: I went looking for problems and found mostly reasonable decisions.

I’d rate it an 8. The architecture earns it. The privacy posture sustains it. The contract, support trajectory, and data concentration keep it from being higher.

Anna, for all six of us