Single Source of Truth

Single source of truth is a data-management idea that arrives in restaurants through software rather than through the floor. It matters here because a mid-sized group runs six to twelve systems that all know something about the same guest: one or two reservation platforms, a point of sale per venue, an events system, a reviews inbox, an email tool, sometimes a hotel property management system. A restaurant CRM is the layer that claims to be the authoritative one, and understanding what that claim can and cannot mean is the difference between buying something useful and buying a seventh copy of the guest.

Does a single source of truth mean one system holds everything?

No, and this is where the phrase gets oversold. Every connected system will keep its own copy of guest data, because each one needs that data locally to work. Resy needs a name on tonight’s booking. The point of sale needs a payment record. Nothing about consolidation removes those copies, so a single source of truth is not a state where only one copy exists.

What it means in practice is that one system is authoritative per fact, and everything else defers to it. The book stays the authority on tonight’s table. The point of sale stays the authority on what the check was. The CRM becomes the authority on who the guest is: which records are the same person, what their history adds up to, what they prefer, and what they have consented to. Arguments about guest data inside a group are almost always arguments about which system owns a field, and settling that is most of the work.

Which system should own which guest field?

Ownership divides cleanly along the lines of what each system observes first-hand.

• Tonight’s reservation, party size, and table. Owned by the reservation platform. It is the system the floor works in and the only one with a live view of service.
• Check totals, items, and tenders. Owned by the point of sale. Financial records should never be restated somewhere else.
• Guest identity and contact detail. Owned by the CRM, because it is the only layer that sees every system’s version of a person and can decide which value is current.
• Preferences, tags, and notes. Owned by the CRM, then written back into the reservation platform so the host reads them where they are already looking.
• Consent and unsubscribes. Owned centrally and applied at send time. A guest who opts out at one venue has opted out of the group, and no individual campaign should be able to override that.
• Visit history across systems. Owned by the CRM by definition, since no single system can assemble it.

Why does a single source of truth fail in restaurants?

It fails in three specific ways, and none of them is a software outage.

The first is unresolved identity. If duplicates are not matched, the authoritative record is authoritative about a person who does not exist, and a four-visit regular reads as four first-timers. Nothing built on top of a guestbook survives that, which is why matching is the foundation rather than a feature.

The second is coverage. Every check that never joins a guest and every unidentified walk-in is a hole in the record, so a guestbook assembled from 60% of a restaurant’s volume is a truthful account of 60% of the business. The number nobody sees is the one describing the rest.

The third is delivery, and it is the failure operators notice last. A record can be complete, current, and correct, and still be somewhere the team does not look. A host works the reservation book during service, a server works the point of sale, and a cook works from a ticket. Truth that lives only in a marketing dashboard has no effect on a Friday night. This is why write-back into the reservation platform matters more than it sounds: it moves the authoritative record onto the screen already open in front of the person greeting the guest.

Can a reservation platform be the single source of truth?

For bookings, it already is, and no CRM should try to take that over. For the guest, it cannot be, because a reservation platform only sees what happens inside itself. It does not know what the table spent, what the guest wrote in a review, that the same person hosted a private dinner in the events system, or that they eat at a sister restaurant every other week under a different email address.

There is also a freshness caveat worth setting expectations on, because vendors are loose with it. Reservation changes usually arrive within moments, since booking platforms push events as they happen. Point-of-sale data more often arrives on a scheduled import, so spend from last night lands in a batch rather than the second the check closes. A cross-system guest record is therefore best described as continuously updated rather than real-time, and any platform that claims otherwise about every source is worth questioning on the detail.