Going from a handful of restaurants to more than thirty venues and about ten hotels is not only a matter of real estate or hiring. To support the growth of a restaurant group, the digital side has to keep up: tools, customer database, websites, booking and measurement must hold at every new opening, without the team starting from scratch each time.
That is the ground on which māhie has supported Monterock for more than six years. This article sets out what the case allows us to say publicly, then draws a method from it that you can apply to your own group, whether you run three venues or thirty.
Supporting the growth of a restaurant group: the Monterock case
Monterock is a Paris restaurant and hotel group whose growth māhie has supported for more than six years. Over that period the group went from 10 to more than 30 restaurants, and it now has 10 hotels. That is what the public case page on mahie.io states, quoting Alexandre Pasdelou:
"He has been a key player in our growth, taking us from 10 to more than 30 restaurants and 10 hotels. […] A valuable and committed partner." >Alexandre Pasdelou · Monterock
What this article does not cover. The Monterock case is published as a growth partnership, with no detailed figures and no list of tools. We therefore describe neither the group's internal setup, nor results per venue, nor budgets. What follows is a general method drawn from what we see with groups that are growing. It is not an account of what was done at Monterock.
What the case does show is duration: more than six years of collaboration during which the group more than tripled its number of restaurants. A group growing at that pace does not choose its tools once and for all. It evolves them at each stage.
Why growth breaks the tools of a single restaurant
An independent restaurant gets by with a website, a booking system, a newsletter and a spreadsheet. With one venue, everyone knows where the information lives. By the second or third venue, three problems appear.
- Tools multiply without links between them. Each opening adds its own website, mailbox, social accounts and sometimes its own booking tool. Nobody has the full picture.
- Customers are scattered. A guest who dines at two of your restaurants exists twice, with two records, two histories and possibly two different consents.
- Numbers cannot be compared. Each general manager tracks what they find useful, with their own definitions. Management can neither compare venues nor decide where to invest.
The usual reflex is to standardise everything at once. That is rarely the right approach. It is better to decide what must be common to the group, what can stay specific to each venue, and to move in stages.
Structuring shared tools without making every venue identical
A group does not need its restaurants to look alike. It needs them to share a foundation. To define it, ask three questions about each tool.
- Does anyone need to see the data of all venues together? If so, the tool (or its data) should be shared. This is typically the case for the customer database and reporting.
- Does the venue's identity depend on it? If so, leave room for freedom. Tone, photos, menu and atmosphere belong to each venue.
- What happens if the person who manages it leaves? A tool whose settings only one person knows is a risk. Document it.
In practice, a shared foundation usually includes:
- a booking tool configured on the same principles from one venue to the next (service names, payment rules, tags);
- a shared customer database;
- an email tool and message templates that each venue can adapt;
- a simple naming convention for campaigns, booking sources and venues;
- a shared dashboard, with the same definitions for everyone.
Write these choices down in a short document of a page or two. It is used at every opening: the new manager and the provider launching the website find the group's rules there.
One customer database from the second venue
The customer database is the first project to tackle, because it gets more expensive to repair with each venue added. A group that waits until it has twenty restaurants to merge its files discovers thousands of duplicates, fields filled in different ways and consents that cannot be traced.
The basic rules to set early:
- One record per guest, whatever venue they book, with their visit history across the group.
- Fields defined once and for all: what you record (allergies, occasions, preferences), how you record it and who can edit it.
- Consent attached to the record, with its date and source (website form, booking, newsletter). This is what lets you send an email legitimately and honour an unsubscribe across the whole group. Our guide on email marketing and GDPR covers this point.
- Shared segmentation: first visit, regulars, corporate clients, VIPs. The same segments across all venues let you run a group campaign as easily as a local one. See also SevenRooms Auto-tags if you use that tool.
Data arrives through several doors: the booking system, website forms, the newsletter, sometimes a dedicated CRM. The key point is that they sync automatically rather than by hand. We explain this logic in the article on syncing forms and newsletters with your CRM.
Websites and booking: an architecture that supports the next opening
Each new venue needs a website, or at least a page, a booking module and local search presence. If every opening starts from a blank page, cost and lead time grow with the size of the group. To avoid that:
- Start from templates. A common page structure (home, menu, booking, private events, contact) adapted with each venue's photos and copy.
- Choose an explicit architecture. One site per venue, a group site with one page per venue, or a mix of both: there is no universal answer, but the choice should be deliberate, because it affects search visibility and maintenance.
- Connect booking to the site the same way everywhere. The module should appear in the same place, with the same tracking parameters, so that numbers remain comparable.
- Plan for maintenance. A site forgotten for two years (outdated menu, wrong opening hours) costs bookings. Decide who updates what, and how often.
If you build with a tool such as Webflow, templates and structured content help keep this consistency. It is not essential, but the discipline it imposes is.
Measuring at group level
Measurement is often the last topic addressed, yet it is what makes decisions possible. A growing group must be able to answer simple questions quickly: which venue fills its quiet services, where bookings come from, which channel brings guests who return.
Three principles are enough to start.
- Same definitions everywhere. A "cover", an "online booking" and a "no-show" must mean the same thing in all your venues. Write the definitions down.
- Few indicators, tracked regularly. Our article on weekly KPI tracking for a restaurant offers a simple framework.
- A regular review with management. A fixed meeting with the numbers in front of everyone beats a dashboard nobody opens.
Do not wait for the perfect tool before starting. A shared spreadsheet fed reliably is better than a sophisticated platform nobody maintains.
Checklist before each new opening
This list is a starting point to adapt. It does not reflect the internal method of any particular group.
- The venue is created in the booking tool with the group's rules (services, payment, tags).
- The venue's site or page is live, built from the shared template, with the booking module connected.
- Forms and the newsletter feed the single customer database, with consent and source recorded.
- The group's customer segments apply to the new venue.
- The venue's Google listing is complete and consistent with the site. See our Google Business Profile guide.
- Booking-source tracking is active from day one.
- The venue appears in the group dashboard, with the same definitions.
- One person is named for each tool, with access documented.
- Floor teams are trained on the booking tool before opening.
Restaurant group growth: frequently asked questions
At how many venues should you structure your tools?
From the second venue. At that stage, choices are still easy to change and there is little data. The longer you wait, the longer and costlier it becomes to merge customer files and harmonise settings.
Should a group have one website or one per restaurant?
There is no single answer. A site per venue better serves each venue's identity, while a group site simplifies maintenance. Many groups combine both. What matters is to choose deliberately, taking local search and the team's capacity to maintain content into account.
How do you keep a customer database clean when several teams edit it?
Define fields and entry rules once for the whole group, limit who can edit records, and automate syncing from forms and bookings. Also plan regular duplicate clean-ups.
Does the Monterock case give figures?
The public case page states the growth from 10 to more than 30 restaurants and 10 hotels, over more than six years of partnership. It publishes no results per venue, no financials and no technical detail. This article does not invent any.
Need support with your group's growth?
Whether you are preparing your third opening or already run dozens of venues, the question stays the same: which tools should be shared, and how do you evolve them without blocking your teams? māhie supports restaurant and hotel groups day to day, sometimes for more than six years. In practice, we can:
- define a growth strategy with you: goals, channels, priorities, roadmap and budget, with a regular review with management;
- coordinate your providers (agencies, photographers, freelancers) so that everything stays aligned;
- unify your customer database: data clean-up, duplicates, consents, shared segmentation;
- build and connect your websites to your booking tool and your other tools;
- set up clear reporting to follow the same indicators across all venues.
Discover our Growth & outsourced CMO support and our CRM services, then Contact māhie to discuss.
