Pre-Shift

Pre-shift is the short meeting a restaurant holds before service begins. The team covers menu changes, eighty-sixed items, specials, and the night's reservations, including which guests are regulars, which are VIPs, and which tables are celebrating something. It is where guest data reaches the floor.

Pre-shift is the last point at which anything a restaurant knows about tonight’s guests can still change how they are treated. Everything a CRM does upstream, matching checks to reservations, resolving duplicate profiles, tagging preferences, exists to make five minutes before doors worth attending.

What guest information belongs in a pre-shift?

Facts a server can act on in the next four hours. In practice that means the guest’s name and where they are sitting, the occasion if there is one, one or two things they reliably order, a seating or table preference, an allergy or dietary restriction, and when they were last in.

What does not belong is everything else. A briefing that reads out lifetime value, visit counts, and campaign history for fourteen tables is a briefing the team stops listening to. Two or three specifics per notable table is the working limit, and the discipline is choosing them. “Table 6 at 7:30, second anniversary, they had the tasting menu last year, she does not drink” is usable. A dossier is not.

Where does a pre-shift report come from?

Every reservation platform prints tonight’s book, and Resy, OpenTable, SevenRooms, and Tock all carry guest notes on it, so a venue running one platform well already has the beginnings of a briefing. The limits show up in what the book does not contain: what the table spent last time, whether the guest is a regular at the group’s other restaurant, tags that came from point-of-sale detail rather than from something a host typed.

Loyalist generates pre-shift reports that pull the night’s bookings together with the tags and notes held on each guest profile, so the briefing arrives assembled rather than compiled by a manager reading bookings one at a time. It is a scheduled report rather than a live alert, which suits the moment it is built for: it lands before service, gets read out, and gets printed for the pass.

Why do pre-shift briefings get ignored?

Because of what happens the first time one is wrong. A server greets a table as returning guests who have never been in, or welcomes back a couple whose last visit ended in a complaint nobody flagged, and the whole report loses authority with the room. Teams are quick to discount a source that has embarrassed them once.

Almost always the cause sits in the data rather than in the briefing. Duplicate profiles split a real regular into three first-timers, so the person who should have been recognised is not on the list. Unmatched checks leave visits missing, so a guest’s history looks thinner than it is. Notes typed into forty different phrasings cannot be pulled into a report at all. A briefing is a reading of the guestbook, and it inherits every problem the guestbook has.

Last updated