A till on its own is a competent, blind thing. It records what was sold with perfect accuracy and has no idea who sold it to whom. For decades that was simply how it was, and you did the joining-up in your head or not at all. It does not have to be that way any more, and once you have run a service where the till and the booking system share one record, the old way feels like working with the lights half off.
This is about that specific connection and why it matters more than any single till feature. For choosing a till in general, the EPOS guide is the place to start.
The blind till
Here is the standalone till's version of an evening. A booking comes in, you know who is on table twelve from the diary at the host stand. They sit, they order, they pay, they leave. The till records eighty-four pounds at table twelve and a list of items. The booking system records that a name turned up. Neither tells the other anything. At the end of the night you have an anonymous total and a used-up reservation, and the connection between them, the fact that this spend belongs to this guest, exists only if someone bothers to make it by hand, which they almost never do.
Multiply that across every table, every night, for a year, and you have thrown away the single most useful thing your business touches: a record of what each guest is actually worth to you. Not because anyone decided to, but because the two systems never spoke.
The connected till, through one night
Now the same evening with the till and bookings sharing one record. The differences are individually small. Together they change the night.
The team knows who is at each table, because the booking carried the guest through to the floor. The regular on table twelve is greeted by name without anyone checking a screen, and their corner-booth preference and the fact that one of the party cannot eat shellfish are already there, not relayed by memory. If they pre-ordered, it is ready to fire the moment they sit. When they pay, the spend lands on their record automatically, so the next time they book you know not just that they came but what they are worth.
None of those is dramatic on its own. A name remembered, an allergy flagged, a preference honoured, a spend recorded. But that is what good service is: a hundred small things going right, quietly. A connected till makes those small things happen by default rather than depending on whoever is on and how good their memory is that night.
The data dividend
There is a longer-term payoff beyond the smoothness of a single service. When every bill lands on a guest record, you build, over months, a true picture of who your guests are by value. You can see your real regulars rather than your loudest ones, spot the valuable guest who has quietly stopped coming, and aim your marketing at the people most likely to come back. None of that is possible if the till and the bookings live apart, because the raw material, who spent what, never gets assembled.
This is why I would weigh this connection above almost any individual till feature. A faster till that knows nothing about your guests is still leaving your most valuable asset on the floor at the end of every night. A slightly less flashy till that feeds one guest record is building something.
Integration versus one system
You can sometimes achieve a version of this by integrating a separate till and a separate booking system. It can work. It also tends to be the fragile part of a setup, the bit that breaks when one side updates, that syncs partially, that needs babysitting. Two products stitched together after the fact are doing something neither was designed for.
A single platform where the till and the bookings share one record by design does not have a seam to break, because there is no seam. The guest, the booking, the order and the payment are the same data seen from different angles, not separate data forced to agree.
Where Grace fits
In Grace there is no integration to maintain between the till and bookings, because they are one platform around one guest record. The booking carries the guest to the floor, the till knows who is where, preferences and allergies are already in front of the team, and every payment flows back onto the guest's history automatically. You can see how reservations feed this on the Reservations page, and how to think about the till itself in the EPOS guide.
It is built this way because I spent years running a till that knew nothing about the people it served, and the waste of that was the thing I most wanted to fix.
FAQ
What does it mean for a till to connect to a booking system?
It means the table the guest booked and the bill they run up are linked to the same guest record, automatically. The till knows who is sitting at table twelve because the booking system told it, and the spend flows back onto that guest's history without anyone typing it in. - q: "Why does that connection matter during service?" a: >- It removes small frictions all night: the team knows who is at each table, preferences and allergies are already there, pre-orders can be ready to fire, and the end-of-night spend lands on the right guest. Individually minor, together they change how a service runs. - q: "Can I get this with separate till and booking systems?" a: >- Sometimes, through integrations, but bolted-together systems tend to be fragile and partial. A single platform where the till and bookings share one record by design is more reliable than two products stitched together after the fact.