Opening a site and acquiring one are different projects that fail in the same order. In both cases the guest data problem arrives about three weeks after everybody stopped thinking about guest data, which is roughly when the kitchen stops being the emergency.
A new build starts with nothing and slowly drifts away from how the rest of the group works. An acquisition starts with somebody else's database, somebody else's consent record, and a reservation platform none of your GMs have used.
Here is what breaks, in the order it usually breaks, and what each one costs to fix at the point you notice it.
Week one: identity breaks first
The moment the new site takes its first booking, you have guests existing in two places that cannot see each other. Your group's best customer walks into the new room as a stranger, and everyone finds this charming until the third time it happens.
You cannot fix this in week one and should not try. What you can do in week one is keep it fixable: insist the new site captures the same identifier as everywhere else — phone, email, ideally both — from the very first cover.
A site that runs six months without capturing phone numbers has produced six months of covers you can count and guests you can never recognise. No later cleverness recovers that, by anybody, at any price.
Weeks two to four: the definitions drift
Your group has a definition of a regular. The new site is three weeks old and has nobody who meets it, so its GM invents a local one, and now you have two definitions and a reporting line that quietly means different things at each end.
The same happens with VIP flags, note style, what counts as a no-show, and whether a walk-in gets recorded as a booking. Every one of these gets invented locally in the absence of an answer, and unpicking it later is harder than it sounds, because by then people are attached to their version and can explain why it is better.
Send the definitions before they are needed. One page, before opening. It is the cheapest item on this list and the most commonly skipped.
The acquired-site problem: the list you inherited
An acquired restaurant comes with a mailing list, and the mailing list is the most dangerous asset in the deal precisely because it looks like the safest one.
Those guests agreed to hear from a restaurant with a different name, a different chef, and possibly a different menu. Whether that permission carries across is a genuine legal question that depends on where you operate, and it is worth asking properly rather than assuming either answer.
The reputational version is simpler and does not require a lawyer: the first thing those guests hear from you should not be a group newsletter. If you send one, the unsubscribe numbers will teach you what you should have asked first.
- Do not merge the inherited list into your main list until somebody has answered the consent question in writing.
- Do not rename the restaurant in their inbox before you have renamed it on the door.
- If you can contact them at all, make the first message from the new owner about what is changing and what is not — not a campaign.
- Keep inherited records separately identified for at least a year, so you can always tell an inherited guest from one of yours.
Month two: the history arrives, badly
At some point somebody exports the acquired site's guest history and hands you a spreadsheet. It will have fewer columns than promised, a shorter date range than promised, and a name field containing entries like "Smith - do NOT seat 12".
Do not load it anywhere yet. Run the same audit you would run on your own systems: date range, identifier available, fill rate, duplicate rate. Fifteen minutes of counting tells you whether you have been handed a guest database or a list of names, and those are very different gifts.
And do not auto-merge it with your existing guests. An inherited file is exactly the situation where name-only matching does damage: two databases, two spelling conventions, and at least one John Smith on each side.
Month three: the floor notices before the report does
The signal that onboarding has worked is not a dashboard. It is a host at the new site saying "she has been to the wine bar nine times" and behaving accordingly, without anyone having asked them to.
The signal it has failed is a guest saying "I have been coming to your other place for years" at the podium, to a host with no way to know that and no graceful reply available.
Give the new team the sentence for that moment before it happens. Something like: "Then let me get this right — what do you usually drink." Honest recovery beats improvised familiarity every time, and guests can tell the difference immediately.
A checklist for the first ninety days
None of this is difficult. All of it is easy to postpone, and the cost of each item roughly triples every month you leave it.
- Before opening — agree the guest identifier and make the field required.
- Before opening — send the group definitions on one page: regular, VIP, no-show, note style.
- Week one — confirm you can export guest data from the new site yourself, without ringing anybody's support line.
- Week two — name one person at the site who owns guest data. A person, not a department.
- Month one — audit any inherited file before it touches anything else you own.
- Month one — answer the consent question in writing, with proper advice if the answer is not obvious.
- Month three — compare the new site's fill rate against your other sites. A gap here is a training problem and it is still cheap.
- Month three — ask a host at the new site to describe a regular. If they describe a person rather than a rule, you are in good shape.