POS (Point of Sale)

The point of sale runs the transaction layer of a restaurant: menus, orders, checks, payments, and tips. It is also, without being designed for it, the richest behavioural dataset in the building. A reservation platform knows who booked. The point of sale knows what they ordered, what they skipped, what they drank, and what they spent.

What guest information does a POS actually hold?

Less than operators expect, and the answer differs by order type before it differs by product. A dine-in check is anonymous at source: nobody asks a walk-in for an email before ringing in a burger, so the check records what was sold and not who bought it. Off-premise orders are the exception, because delivery, takeout, and online orders have an account behind them. Toast and Square can pass guest contact detail on those. Lightspeed, SpotOn, Silverware, and Oracle Simphony pass no guest identity at all, so a check there has to be matched to a reservation before anyone knows whose it was.

Item detail differs too. Some systems expose every line on the check, which is what makes it possible to tell a wine drinker from a cocktail drinker. Others pass a total and a revenue centre, which supports spend analysis and nothing about preference. Before buying anything that promises guest intelligence from check data, ask which of these your point of sale sends.

Can a POS tell you who your regulars are?

At most venues, no, and the reason is what the system was built to do. A point of sale is designed to open a check, price it, take payment, and close it. Nothing in that sequence requires knowing the guest, so the guest is optional and usually absent.

Where a POS has a loyalty module, it can report on the guests who enrolled and remembered to identify themselves, which in a full-service restaurant is a minority of covers. The system also stops at its own boundary. It has no view of who booked, none of the sister restaurant across town, and none of the guest who dined twice without ever identifying themselves.

What does a restaurant CRM do with POS data?

It joins the check to a person and keeps the result. Reservations come in from Resy, OpenTable, SevenRooms, or Tock, checks come in from the point of sale, and the platform reconciles them on table, time, and party size, or directly on email where the POS supplies it. The share of checks that lands on a known guest is a restaurant’s match rate, and it is the number that governs how much of the following list is real.

Once matched, check data becomes guest data. Spend accumulates on the profile instead of on the night, item detail supports tags for what a guest actually orders, and average check can be read per guest over time rather than only as a nightly average. One expectation to set: reservation changes tend to arrive within moments, while point-of-sale data usually comes in on a scheduled import, so a guest profile is continuously updated rather than instant.