POS Integration

A point-of-sale integration is the connection a guest data platform depends on most and can control least. Reservation data is comparatively uniform between platforms. Point-of-sale data is not, because the systems were built for accounting and inventory rather than for handing guest behaviour to something else. Two venues can run the same guest platform, connect the point of sale properly in both, and end up with different pictures of the same evening.

What does a POS integration actually send?

Three things, and the third is the one that varies most.

• The check. Total, time closed, table, server, and tender type. Every integration carries this much, and it is enough to reconcile against a reservation.
• The items. Line-level detail: dishes, categories, modifiers, and what was poured. Some systems pass this and some send only a total, which decides whether a restaurant can build anything around what guests actually order rather than only around what they spend.
• Guest identity, mostly on off-premise orders only. Toast and Square can attach guest contact detail to delivery, takeout, and online orders, where an account sits behind the order. Dine-in checks generally arrive with no identity regardless of product. Oracle Simphony, TouchBistro, Revel, and Silverware pass no guest detail at all, so every check there has to be matched to a reservation on table and time before it belongs to anybody.

That last point is invisible in a demo and worth asking about directly. A venue whose point of sale carries no guest identity depends entirely on the matching layer above it.

How does a check with no name on it reach a guest?

By reconciliation against the reservation book. The book says a party of four sat at table 12 at 8:00pm, the point of sale says a check closed on table 12 at 9:47pm, and a platform decides those are the same party. It works well and fails on ordinary things: floor plans that name the same table differently in each system, split checks, transferred bar tabs, and parties that arrive at a different size from the one booked.

The share of checks that find a guest is a restaurant’s match rate, and it is the number to ask about when comparing platforms, since an integration that ingests everything and matches poorly produces a guestbook full of spend attached to nobody.

How much check history can a POS integration bring with it?

Less than most operators assume, and it depends on the system rather than on the platform reading it. Some point-of-sale products expose years of closed checks and can be backfilled in one pass, so a new guestbook arrives with history on day one. Others retain only a short window, and there is no deep history to recover no matter how good the integration is.

The practical consequence is a timing decision. Where a point of sale holds only a short window, guest spend history starts accumulating from the day it is connected, so a quarter spent deciding is a quarter of visits that will never carry a check against them.