Microsoft 365 for Multi-Site Hospitality: The Setup We Recommend

Almost every multi-site hospitality group we take on has the same Microsoft 365 story. Someone set up a tenant for the first site, probably on Business Standard, probably with the founder’s email as the global admin. A second venue opened and inherited a couple of mailboxes. By the fifth site, there were shared logins floating around, a SharePoint site called “Documents” with everything in it, and a OneDrive belonging to a general manager who left eighteen months ago that still held the only copy of the supplier contracts. The tenant was right for one site. It was never properly redesigned as the group grew.

This post is for ops directors and IT leads of hospitality groups who are either standing up a fresh Microsoft 365 tenant or - more often - looking at what they already have and wondering where to start. It is architectural rather than step-by-step. The goal is to give you the six design decisions that actually matter at multi-site scale, the mistakes we see most often, and a view on what good looks like when the estate is run properly.

The six decisions that matter at multi-site scale

Most M365 problems in hospitality are not really M365 problems. They are decisions that were never made explicitly and then calcified into the way things work. These are the six we force a conversation on with every group.

1. Licensing by role, not by default

The instinct is to put everyone on the same SKU because it is simpler to buy. That is almost always wrong at scale. A head chef, a reservations manager and an operations director do not use the same tools and should not cost the same.

Our default recommendation for a multi-site group is a mix:

• Business Basic for front-of-house roles that only need webmail, Teams chat and occasional SharePoint access from a shared device. Hosts, floor managers, duty managers working from iPads.
• Business Standard for back-of-house and support office staff who need the desktop apps - finance, marketing, HR, procurement.
• Business Premium for anyone with a company laptop, any manager or director, and anyone with elevated access. This is where Intune, Defender for Business and conditional access live, and it is what unlocks the security posture we talk about later.
• Enterprise E3 or E5 only once you cross the 300-seat cap on Business SKUs, or earlier if you need specific compliance capabilities - retention at scale, eDiscovery, Purview DLP across SharePoint and endpoints.

Mixing SKUs is more work to procure but it saves meaningful money and, more importantly, it gets Business Premium in the hands of the people who actually need managed devices.

2. One tenant, properly structured identity

Single tenant. Always, unless there is a genuinely separate legal entity with no shared staff. We routinely see groups that have ended up with a tenant per brand or even a tenant per site, and the operational cost is brutal - licensing is duplicated, admins are fragmented, Teams federation is clumsy, and you cannot enforce policy consistently.

Inside that single tenant, Entra ID (formerly Azure AD) is the spine of everything else. The structure we recommend is:

• Security groups by site - site-soho, site-shoreditch, site-kings-cross - dynamic where possible, driven by a department or office attribute set at onboarding.
• Security groups by function - function-reservations, function-kitchen, function-finance, function-gm.
• Microsoft 365 groups for collaboration - these sit over the top and drive Teams and SharePoint membership.
• Role-assignable groups for anything admin-adjacent, protected by privileged access.

The point is not the naming. The point is that every access decision downstream - what mailbox you can see, what SharePoint site you land on, what device policy applies - is driven by group membership, not by clicking people in individually. That is what makes the estate maintainable.

3. Device management: Intune where it matters, kiosk where it does not

Intune is one of the strongest arguments for Business Premium, but it is not the answer for every device in the business. Our split:

• Office and management devices - laptops issued to GMs, head office, operations. Fully Intune-managed, Autopilot-enrolled, compliance policies enforced, BitLocker, Defender, the lot.
• Site-level shared devices - front-of-house iPads, reservations terminals, back-office PCs - handled as shared or kiosk devices. These usually do not need full MDM. They need strong local controls, a locked-down profile and an identity model where staff do not sign in with personal credentials.
• Personal devices - app protection policies rather than full enrolment, managed through mobile device management. Containerise the M365 apps so corporate data can be wiped without touching the device.

The mistake we see is either extreme - trying to Intune-enrol every till in the estate (expensive, pointless) or leaving every managers’ laptop unmanaged (dangerous, and a Cyber Essentials fail).

4. Mail flow and shared mailboxes that reflect how the business actually works

In hospitality, mail is rarely personal. Reservations come in to reservations@, events to events@, supplier invoices to accounts@, press to press@. Replicating that per site - reservations.soho@, reservations.shoreditch@ - while keeping group-wide addresses routed intelligently is one of the most underrated pieces of setup.

Our baseline:

• Shared mailboxes for every site-level function, owned by a security group not an individual.
• Distribution or dynamic groups for group-wide functions that need to fan out to every site.
• A clear convention on which addresses are public (on menus, on the website) and which are internal only.
• Mailbox delegation via group membership, so a new reservations host joining a site automatically inherits access on day one without a ticket.

Done properly this also stops the classic hospitality failure mode - the GM who leaves and takes eight months of booking history with them because everything was in their personal inbox.

5. SharePoint information architecture: hub and spoke, not one big drive

The single biggest SharePoint mistake in hospitality is treating it like a shared network drive. One site, called “Company”, with folders called “HR”, “Operations”, “Finance”, and flat permissions. It scales for about a year and then collapses.

What works at multi-site scale is a hub-and-spoke model:

• A single hub site for the group - brand, news, policies, the handbook, the things every employee needs.
• Function sites associated to the hub - Operations, People, Finance, Marketing, IT - owned by the relevant team, with their own permissions.
• Site-per-venue sites, also associated to the hub, for anything that is genuinely local - rotas, local suppliers, the maintenance log, the site-specific risk assessments.
• Navigation driven from the hub, so a new starter lands in one place and finds everything from there.

Permissions flow from the group structure in Entra ID. Nobody is added to a SharePoint site directly. If someone needs access to the Shoreditch site, they join site-shoreditch, and everything - mailbox, SharePoint, Teams - follows.

6. Teams structure and channel hygiene

Teams is where channel hygiene goes to die. Our rule of thumb is that a group of twenty sites needs roughly:

• One group-wide team for everyone, with a small number of announcement channels - strictly moderated.
• One team per function - Operations, Finance, Marketing, People - for cross-site collaboration inside that discipline.
• One team per site for the actual running of that venue - rotas, handovers, maintenance, daily ops.
• Private channels inside those teams for anything sensitive - manager-only conversations, disciplinary matters, commercial data.

What does not work is one team per project per site per topic, which is what you get if you let Teams grow organically.

The mistakes we see most often

Before we get to the security and identity overlay, the five recurring mistakes worth naming explicitly:

• Tenant sprawl - a tenant per brand or per site. Consolidate, even if it is painful.
• Shared admin accounts - admin@ logged into by three people with MFA set to the finance manager’s phone. Every admin needs a named account and, ideally, a second one for privileged actions.
• OneDrives holding corporate data - the reservations spreadsheet, the supplier list, the rota template, all in someone’s personal OneDrive. OneDrive is for personal work in progress. Everything else belongs in SharePoint.
• Flat SharePoint permissions - everyone is a member of everything, or nobody knows who owns what. Permissions should be inherited from site-level Entra groups and reviewed.
• No leavers process - accounts stay active for months after someone leaves, often still receiving reservations or approving invoices.

The security overlay

None of the above is worth much without a consistent security posture on top. For hospitality groups on Business Premium, the non-negotiables are:

• MFA enforced for everyone, with number matching and a sensible registration policy. No exceptions for “the chef who does not like apps”.
• Conditional access policies that block legacy authentication, require compliant devices for admin roles, and gate access from risky locations.
• DLP policies covering card data, supplier bank details and employee information across Exchange, SharePoint and endpoints. This is the M365 side of the PCI story we covered in our post on securing card payments across multi-site restaurant groups.
• Defender for Office on every mailbox - Safe Links, Safe Attachments, anti-phishing - because phishing is still the single most common entry point in hospitality breaches.
• Defender for Business on every managed endpoint, with alerts going somewhere that is actually monitored.

Why joiner/mover/leaver automation matters in hospitality

Hospitality has the highest churn of any sector we support. A group of twenty sites might onboard and offboard a hundred or more people a month across FoH, kitchen and support roles. Manual account creation and offboarding at that pace is not just expensive - it is dangerous. Accounts linger. Access accumulates. Former staff retain mailbox delegation nobody remembers granting.

The answer is automating joiner/mover/leaver off a single source of truth, usually the HR or rota system. When a starter is entered with a role and a site, the pipeline creates the account, licenses it appropriately, drops it into the right Entra groups and provisions everything downstream. When they leave, the reverse. This is the single highest-value piece of automation we build for hospitality groups, and it pays for itself inside the first quarter in most estates.

The CloudMatters view

As a Microsoft Solutions Partner working almost exclusively with hospitality, we see the same patterns across dozens of estates. The groups that run Microsoft 365 well are not the ones with the most expensive licensing - they are the ones that made the six decisions above deliberately, wrote them down, and left someone accountable for keeping the structure clean as the business changed.

If any of this reads like your tenant - and for most groups, at least some of it will - we would rather you fix it before it becomes a security incident than after. We help hospitality groups redesign and run Microsoft 365 as part of our managed cloud service, alongside the broader IT support we provide across the sector. If you are not sure whether your current setup is scaling with you, we are happy to take a look.