Covers

Covers are the oldest volume metric in hospitality, and every point-of-sale and reservation system reports them. The harder question, and the one a restaurant CRM exists to answer, is which person each cover belonged to.

What is the difference between covers, checks, and tables?

Covers, checks, and tables are three different counts of the same night, and mixing them up is the most common reporting error in a restaurant. A four-top paying on a single check is four covers, one check, one table. Reservations are a fourth count and the least reliable of the set, because a party booked for six that arrives as four is still a six in the book.

The difference matters most when money enters. Average check divides sales by checks, while per-person average divides sales by covers. Restaurant software blogs routinely use those terms interchangeably, and a group that conflates them overstates spend per guest by roughly its average party size.

Why doesn’t a cover count tell you who was there?

A cover count is volume, not identity. Two hundred covers where a team can name forty guests is a different asset from two hundred covers where it can name none, and standard nightly reporting cannot distinguish those two nights.

Each system holds half the answer. A reservation platform like Resy or OpenTable knows who booked and how many were coming. A point-of-sale system like Toast or Square knows what the table spent and what it ordered. Neither knows both, so a cover that is never connected to a check stays anonymous: real volume, no relationship.

How does a restaurant CRM match a cover to a check?

A restaurant CRM matches covers to checks by reconciling reservation records against point-of-sale checks, and the work is harder than a lookup. The book says four covers on table 12 at 8:00pm; the POS says a $340 check closed on table 12 at 9:47pm. Deciding those are the same party is an assignment problem, and four things routinely break it:

• Table names disagree. The book says 12, the POS says T12, 012, or Patio 2. Every venue names its floor differently, so the join needs normalizing first.
• Times drift. A party booked for 8:00 sits at 8:12 and closes out at 9:47, because a check timestamp marks the end of a meal, not the start.
• Party sizes change. Booked for four, arrived as three, added a fifth for dessert.
• Checks split and move. One table can produce three checks, one check can span two tables, and bar tabs transfer to the dining room mid-meal.

The share of covers successfully connected is a restaurant’s match rate, and it is the number worth watching, because every guest metric downstream inherits it.

What changes once covers are matched to guests?

Once a cover is joined to a check and a guest, volume becomes history. A venue can see that one guest accounted for twelve covers across six visits this quarter, or that a lapsed regular’s final visit was a $600 anniversary dinner rather than a $40 lunch. Neither fact is visible in a cover count, and both change how that guest should be treated the next time they book.

This is the work a guest data platform does and a reporting tool does not. A restaurant CRM matches checks to reservations and resolves both to a single guest profile, so a night’s volume becomes a record of who was actually in the room.