Pacing

Pacing is set inside the reservation platform. Resy, OpenTable, SevenRooms, and Tock all cap covers or parties per interval, and that cap is the single setting standing between a full book and a night that arrives at once. Everything downstream inherits it: kitchen load, quote times, how long a table waits for its first course, and how much attention any one party gets on arrival.

How do I set pacing for my dining room?

Work from throughput, not from seat count. The kitchen can send a certain number of covers per fifteen minutes before tickets start stacking, and that figure is the real ceiling. Find it by watching ticket times against seatings on a few busy services rather than by dividing capacity by turn length.

Then check the interval against real dwell time. A thirty-minute grid in a room where parties sit for eighty minutes strands capacity in the middle of service, because the book cannot express a seating that lands at 7:50. Then hold back the share of covers walk-ins historically take, which at a bar-forward room is most of them.

The common error is one pacing rule for the whole week. Tuesday lunch, Friday at 6pm, and Saturday at 8pm are different rooms with different party-size mixes, and each deserves its own cap.

Why is my book full but the dining room half empty?

Pacing is the first place to look, and there are four usual causes. The cap is set below what the line can actually handle, which is common after a bad night led someone to tighten it. The interval is too coarse, so demand between slots has nowhere to land. Table holds or blocks were set for an event and never released. Or the party-size mix does not fit the inventory, since a cap consumed by four-tops leaves two-tops unsellable.

No-shows and party-size shrinkage widen the same gap from the other end. A book that reads full at noon is a forecast, and the room being half empty at 8pm usually means the forecast was capped too early rather than that demand disappeared.

Does pacing change what a restaurant knows about its guests?

More than operators expect, in both directions. Recognition happens in the twenty seconds around arrival, so ten parties landing at 7:00 means the host is greeting bodies rather than people. Preferences go unread, VIP flags go unused, and nothing new gets written down, because there is no moment in which to do it. Pacing that spreads arrivals is what makes pre-shift information usable at all.

The data side is less obvious. Parties seated in a wave produce overlapping checks on adjacent tables at nearly identical times, which weakens the table-and-time key that check-to-reservation matching depends on. Smooth pacing produces cleaner attribution as a side effect of producing a calmer service.