A small restaurant group had two branches, about thirty employees, and two partners. One managed the kitchens, while the other handled the finances. The business was established, but every management decision began with the same ritual: opening five files and systems and trying to understand what was really happening.
Starting point: the data existed, but the full picture did not
The data was spread across systems that each worked well on their own:
- Sales in the point-of-sale system, separately for each branch.
- Supplier orders and food costs in the kitchen management system.
- Shifts and working hours in the scheduling app.
- Accounting in iCount, managed by the accountant.
- And, of course, a central spreadsheet that one partner had built and updated manually every week.
Preparing the weekly report took the finance partner seven to nine hours, and it always described the previous week. Questions such as “How much does an hour of labor cost us relative to profit at each restaurant?” were answered by intuition because the calculation was too laborious to repeat every week.
What we built
We did not add a new operating system. We connected the existing ones to a single dashboard:
- Automatic data collection from the point-of-sale system, kitchen system, and shift app every night into a central database, using the systems’ own interfaces.
- A live dashboard available on both phone and computer: daily revenue compared with the same day the previous week, food cost as a percentage of revenue, labor cost relative to revenue for each branch, and the five best-selling and most eroded items.
- Exception alerts instead of reports. Rather than waiting until the end of the week, the partners receive a notification when something deviates: weekly food cost crosses a threshold, a branch’s revenue differs materially from the average, or a supplier raises the price of a key item.
- Metrics defined with them, not for them. Three working sessions focused only on what they actually needed to see. Many numbers from the old spreadsheet never entered the dashboard because no decision relied on them.
Results after two months
- Preparing the weekly report fell from an average of eight hours to less than half an hour spent reviewing a ready-made view.
- Within three weeks, the dashboard exposed a 4% food-cost variance at one branch. The investigation found a change involving a key supplier. Correcting it with the supplier brought the cost back to standard, a saving the partners estimate at thousands of shekels per month.
- The weekly management meeting was cut in half and, according to the partners, became a conversation about decisions rather than an argument about numbers.
What this story teaches
A good dashboard is not a collection of charts. It is a short list of decisions the business must make, alongside the data needed to make them. That is why defining the metrics is the most important part, and it must be done with the business owners, not for them.
Questions we are asked about this kind of process
Our systems are old and do not have an API. Can they still be connected? There is almost always a route: an official API, an automated export file, or reading an existing report. During discovery, we examine each system and explain in advance what is possible, what will be partial, and what is not worth the effort.
How long does it take to see value? Here, the initial dashboard went live within three weeks, and the insight that paid for the project arrived two weeks later. We prefer to launch a first version quickly and refine it using real data.
How is this different from the reports our systems already produce? Each system can see only its own data. The value lies in the connection: labor cost against profit, or food cost against the menu. No single system holds both sides of the equation.
The client’s identifying details were removed at their request. The data was measured with the client before and after the project.
