I do not write much about the Individual Restaurants years. They were eighteen of them, and they shaped almost everything I think about hospitality technology, so it is probably time I did.
When I joined, the group had six sites. When I left as CTO, it had forty-five: Piccolino, the Gino D’Acampo restaurants, Bar & Grill, and others. I started in operations and moved into IT because somebody had to, and because I found I liked the problem of making a restaurant run better more than I liked the problem of running one. This is a reflection on what that growth taught me, from the systems side.
Six sites to forty-five
At six sites, technology is a convenience. You can know every manager by name, walk every floor in a week, and fix most things with a phone call. The POS is whatever the first restaurant chose. The reporting is a spreadsheet someone updates on Monday morning.
Somewhere between fifteen and twenty sites, that stops working. Not dramatically. Quietly. The spreadsheet is a day late, then two. A menu change takes a week to reach every till. A supplier price rise lands in the kitchens before it lands in head office. Nobody is doing anything wrong. The business has simply outgrown the point where it can be run on memory and goodwill.
That is the moment the role of technology changes from convenience to infrastructure. The systems have to become the way the business knows itself.
What a head office needs
A restaurant group’s head office needs to see the whole estate in one place, on the same day, in numbers it trusts. Sales by site, by daypart, by category. Labour against forecast. Food cost against theoretical. Bookings against covers. It sounds obvious. Getting there means every site on the same POS configuration, the same menu structure, the same definitions of what counts as a cover, and a data layer that joins it all without a human in the loop.
The food company, which supplied the kitchens, needed something different again: purchasing, stock, pricing, and a feed to and from the restaurants that let a chef order what the menu required and let finance see what had been bought. The kitchens needed it to be fast and forgiving, because a head chef at six in the evening does not have patience for a system that asks twice.
Three audiences, three sets of needs, one set of data. Most of the work of those years was getting them to agree on what the data meant.
The back bedroom
Club Individual started in my back bedroom. There was no budget for it initially and no certainty that guests would want it. The hypothesis was simple: if we could recognise a guest across all of the group’s restaurants, reward them for coming back, and talk to them in a way that reflected what they actually ordered, they would come back more.
It was one of the first app-led loyalty programmes in UK restaurants. Over a decade it grew to nearly two million members. What I remember is not the number. It is the first time I stood in a Piccolino and watched a server recognise a member from the system before the guest had said a word, and the guest’s face when they realised they were known. That was the whole idea, working.
What I took from it
- Standardise before you scale. Every site that joins with its own configuration is a debt you repay later with interest.
- Reporting is only useful if the operations team believes it. Spend as much time on definitions as on dashboards.
- Build for the floor first. If the server and the chef hate it, it does not matter what head office thinks.
- Loyalty is a data strategy wearing a guest-facing coat. Treat it that way from day one.
Everything TLC does today comes from those years. The clients we work with are at various points along the same road, from six sites to forty-five and beyond, and the problems are remarkably consistent. That is reassuring, in a way. It means they can be solved.
If any of this is relevant to your estate, get in touch. There is more writing here, and the studio behind the work is TheLoyaltyCo.