The Problem Starts with Comparison, Not the Kitchen
A network of two or three locations rarely fails due to a bad kitchen. It fails because each floor manager keeps their own notebook or spreadsheet, following their own rules. One counts a reservation from the phone call, another only from a confirmed table. The head chef at the third location doesn't record reservations at all because foot traffic dominates there. The owner receives three different numbers and doesn't know which one to compare.
- Each manager has own calculation rules
- One counts from phone, the other from confirmed table
- Third point doesn't save reservation at all
- Owner gets three numbers without common definition
- Event logged the same way at each point
- Reservation definition set by owner, not shift manager
- Each point has its own label in the same database
- Panel shows three points in same columns
The scale of this is visible even at the single restaurant level before it becomes a network. Among 245 restaurants and catering companies in Warsaw, whose websites opened and were automatically analyzed, 112 have neither an inquiry form nor a sign-up form. That's 45.7% of this group. A guest's inquiry is then never recorded anywhere, so there's nothing to compare between locations.
How Numbers from a Location Reach the Owner's Screen
- 01guest
- →02reservation/order
- →03shared CRM
- →04admin panel
- →05report
- →06owner's decision
An inquiry from a phone, from a Google listing, from Messenger or WhatsApp goes to one place, not to one manager's notebook. Each location logs events the same way, so the manager no longer decides on their own what counts as a reservation. The admin panel shows all three locations side by side, on one screen, with the same columns. The entire mechanism relies on a shared CRM system for all locations - without it, each location returns to its own format.
Your system substitutes values. Report layout shown only.
This standardization is based on our practice in implementations, not on restaurant industry research. If after a month managers still send numbers in old formats, standardization didn't work and you need to return to event definitions, not add another report. The indicator to watch is the number of inquiries that didn't reach the shared CRM, but stayed in the manager's phone or Messenger.
Who Runs This Daily: Roles, Tools, and Responsibility for Numbers
The network needs a clear division of who is responsible for what. Otherwise, the screen with numbers won't help anyone. The floor manager at each location is responsible for ensuring that the event recording process works identically everywhere. The head chef submits orders to the supplier through the same CRM, so supplies for all three locations are visible side by side, not in three separate messages. The accountant settles the daily revenue based on the same reports, not on what the manager emails them. The owner looks at the panel once a day and makes decisions based on facts, not one manager's memory.
- Google Business Card
- Messenger
- Venue phone
- Shared network CRM
- SMSAPI — confirmation for guest
- Google Calendar — banquet halls
- Owner panel
In practice, these flows are connected by automation. n8n or Make receives inquiries from Google Business Profile, from Messenger or WhatsApp, and enters them into the CRM with a location label. SMSAPI sends the guest a reservation confirmation, and Google Calendar holds banquet hall dates so two locations don't book the same hall for a wedding on the same day. You can find more about this mechanism in one location in a separate text about reservations, suppliers, and reviews in one restaurant. Integrations that connect the cash register, calendar, and messengers are responsible for tying these sources together.
Integration sometimes breaks, most often after a password change or after a platform API update. Inquiries then don't disappear; they just go back to the old mode and sit in the manager's inbox until someone notices. The panel administrator receives an error notification, and it is they, not the floor manager, who fix the connection.
The same problem is visible before the network even starts expanding. Among 359 restaurants and catering companies in Warsaw, whose websites we analyzed automatically, 66 are visible exclusively on third-party platforms. That's 18.4% of this group. Such a platform is a directory, a reservation portal, or a social media profile. Such a location has no place of its own where a guest can leave an inquiry, so there's nothing to enter into the network's shared CRM.
How Much the Shared Screen for Multiple Locations Costs: What the Cost Depends On
The cost depends first of all on how many locations and how many data sources are involved, because every source has to be opened and checked on its own. The admin panel where all locations are visible side by side gathers the data in one place. The dashboard with numbers for the owner shows the state right now. AI reports that translate numbers into decision language say what is happening to that state and why. The scope is settled after a conversation about how many locations and what data are involved.
Email integration opens the first channel, Telegram or WhatsApp integration the second — every channel hands over its data differently, so every one is a different piece of work. CRM automation joins those sources into one flow, and only then does the panel show the whole network instead of a slice of it. The scope is settled after a conversation about what your network uses today.
We don't promise a specific number of inquiries or a specific occupancy increase. No one can honestly guarantee that. The return depends on how many inquiries the network is losing today, and that becomes visible only after connecting the shared CRM.
When the Shared Screen for Multiple Locations Is a Bad Idea
The shared screen makes no sense for a single location that the owner sees daily with their own eyes. There the comparison problem simply doesn't exist because there's nothing to compare with. It's also not worth implementing in a network that is only testing a second location and may close it in six months. The maintenance cost of the integration will then exceed the benefit from one report. Sometimes locations have completely different menus, different guests, and different business models - one is an employee buffet, the other is an à la carte restaurant. Then the shared numbers still won't make sense without a separate analysis for each location.
We also don't promise that the screen itself will improve relations between locations. That still depends on whether managers want to use one source of truth, not on the tool itself. AI reports help read numbers, but the owner still makes the decision.
Frequently Asked Questions
Does Each Location Need a Separate CRM, or Is One Shared Enough?
One CRM for the entire network works better because it allows you to compare locations using the same columns. Each point logs its events in it under its own label, and the owner filters the view by location or looks at them all at once. Separate systems for each point take you back to square one: three different formats that must be compiled manually.
What if Locations Have Different Owners, for Example in a Franchise Model?
Then the panel shows only the data the franchisee agreed to, and the rest is visible only to the brand owner. Permissions are set at the account level, so one point's manager doesn't see the other's revenue. This resolves the access dispute, but doesn't remove each location's obligation to enter data on time.
How Long Does Implementing the Shared Panel for Two or Three Locations Take?
The time depends on how many systems need to be connected - cash register, reservations, Google listing. That's too individual to give one number of weeks without knowing the network. Instead of a deadline, we give the order of work: first the source integration, then the panel, and the first reports last - in that order, because a report only counts what the earlier links managed to record. A realistic schedule is established only after reviewing what each location uses today.
Do You Need to Replace the POS System at Each Location for This to Work?
No, the integration usually connects to what's already on the cash register rather than replacing it. The exception is a cash register that has no API, from which nothing can physically be extracted. Then you need to separately assess whether replacement is worthwhile. We don't promise every cash register can be connected without changes. That depends on the specific manufacturer.
Let's talk about one screen for your restaurant network in Warsaw.