A restaurant chain I worked with in 2023 already held every number it needed to grow. What it did not have was anyone asking those numbers a useful question.
Most conversations about restaurant data start in the wrong place. The first thing an owner is usually sold is a monthly summary: this item sold the most in March, so buy 30 percent more of it for April. Reasonable. It is also something the cashier at the till could tell you for free.
That is a report. It says what happened. Analysis asks why it happened, to whom, and what to do next — and those are different questions with far more money attached to them.
Key takeaways
- The gap was interpretation, not collection. The ERP already tracked billing and inventory. Nobody was connecting the two into a decision.
- The first real step was not analysis at all. It was naming things correctly. “Cold drink” was hiding an entire audience dataset.
- A branch is an audience, not an address. At some branches, close to 60 percent of orders landed at lunch — and that pattern pointed to a specific, monetisable group of people.
- The best-selling dish is not always the most valuable dish. Linking recipes to ingredients let sales volume be read against margin.
- Good data draws the line between an optimisation problem and a structural one — and knowing which is which saves a business from spending on a fix that cannot work.
What is the difference between a report and analysis?
The chain ran a customised ERP — billing synced to inventory, stock moving in and out against orders, an alert when an item dropped below a set threshold. On paper, sophisticated. The vendor was charging a premium for “data analysis” on top of it, and the analysis was the March-to-April line above.
So I asked the owner a longer set of questions. Why did that item sell more? At which branch, at what time, to which kind of customer? Was it bought alone or inside a bigger basket? Was it profitable, or only popular? What did those customers order alongside it, and did the branch ever run short during the rush?
None of that required new data. It required connecting the data the business already had. That is the whole difference between a dashboard that looks impressive and one that changes a decision.
If you own or run anything with a till and a stockroom — a restaurant, a clinic, a pharmacy chain, a retailer — you are almost certainly sitting on the same unused signal.
The first step wasn’t analysis. It was naming things.
Before a single pattern could surface, three quiet fixes had to go in.
First, the drinks. The system logged fizzy drinks as “Cold Drink”, sorted only by quantity. I asked for every bottle to be entered by name — Pepsi, Coke, Sprite, 7UP, Dew, Mirinda, Fanta — with sugar and zero-sugar variants marked separately. A dull inventory line became a purchasing-preference dataset that could be read by branch, by daypart and by basket. A Karachi branch does not have to drink like an Islamabad one. A weekday office order does not have to look like a family dinner.
Second, the recipes. I sat with the head chef, who already had the portion breakdown for every dish written down, and handed it over on the spot. I asked the vendor to build a method that deducted exact raw quantities — rice, chicken, beef, mutton, chilli, ginger and the rest — from inventory each time a plate was billed. Bill a chicken karahi, and the system now subtracted that dish’s true ingredient cost, not a guess.
Third, the missing count. There was no headcount in the billing, so I proposed a standard per-head charge on naan, or a small bottled water offered to every dine-in guest by their number, and separate flags for takeaway and delivery. Now the data knew how many people sat down, and through which channel each order came.
There is a human step people skip when they read this. The vendor who built the ERP was the owner’s oldest, most trusted supplier, and he took the changes as an accusation that his work had been wrong. That idea, once it settles, makes a person very hard to work with. So I spent real time showing him that this was the most valuable thing the system had ever done, and that the credit for it was his. The technical change was easy. The trust was the actual job.
Then I let the system run for a little under three months, and read what it said.
What did the data say once it could speak?
The first pattern was the daypart. At some branches, close to 60 percent of orders came at lunch. That reads like a simple “lunch is busy” — until you talk to the branch managers and look at what surrounds the building. The lunch rush was employees from the offices next door. That branch was not busy at lunch by luck; it owned a captive weekday office catchment.
So the recommendation was not “cook more at noon.” It was to treat that branch almost as a hospitality venue for those offices: stronger office-lunch and group deals, corporate meal offers, and after-hours party packages to pull the same people back in the evening. I also proposed two well-lit photo booths, group and selfie framing, so a team lunch turned into something people shared. The insight was never “lunch sells.” It was “the people buying lunch are a known audience who can be sold to at other hours.”
The recipe link opened a second question the business had never been able to ask: which dish is actually worth promoting? A best seller by volume is not always the best contributor to margin, and a quieter dish can carry a healthier one. Read the trade and this has a name — menu engineering — but the principle is plain: once you can see volume against ingredient cost, you stop pushing what is merely popular and start pushing what pays.
The basket said more than any single dish. A karahi order tended to bring naan, raita, a salad and drinks with it; a barbecue order built a different basket entirely. That let the chain design bundles around how customers already bought, instead of inventing combinations nobody wanted. The unit of analysis stopped being the item and became the order — and the goal stopped being more transactions and became more valuable ones.
Two more patterns followed the same logic. Branches in office districts, residential areas and commercial strips were plainly different audiences under one brand, so the promotions, thresholds and even staffing could go local while the brand stayed national. And dine-in, takeaway and delivery were three different businesses wearing one name: the customer had not changed brand, the customer had changed context, and packaging, bundles and offers needed to follow.
Where the alerts were quietly lying
The generic low-stock alert sounded useful until you asked: low compared with what? One branch cleared a product in a morning; another barely moved it in a week. A single threshold across all of them either ran the busy branch dry or left the quiet one overstocked. Calibrating the warning to each branch, product and daypart changed the question from “is stock low?” to “is stock low against the demand we are about to face?”
The recipe deductions exposed something else. Once the system knew what should have been consumed for the dishes sold, any gap between that and the actual inventory movement became a signal worth chasing: portion drift, wastage, mis-entered stock, unrecorded staff meals. Variance stopped being an accounting nuisance and became an operations diagnostic — a way to see which branches ran a tight kitchen and which did not.
And a monthly best-seller report, however tidy, moves at the speed of the reporting cycle. A dish can look ordinary across a whole month and sell out every weekend between seven and ten in the evening. Watching velocity, not just monthly totals, is what let stock and promotion decisions keep pace with the counter.
The one problem the data could explain but not solve
Here is the limit, said out loud, because leaving it out would be dishonest.
One branch stayed weak no matter what the numbers suggested — thin evenings, low weekend traffic, poor conversion even on promotions. The temptation in marketing is to assume every problem yields to a better campaign. The data refused to agree. Read closely, the weakness was structural: location, accessibility, parking, the mix of land use around it, the way traffic moved past it. A campaign builds awareness. A discount builds an incentive. A bundle improves the offer. None of them moves a building.
That was one of the most valuable conclusions of the whole exercise. Good data does not solve everything; it tells you which problems are optimisation problems and which are structural — and which ones no amount of spend will fix.
One more limit, on my side. Several of these recommendations were acted on; I did not run a measured before-and-after on revenue, so I will not put a number on the lift. A figure I did not measure is a figure I will not publish. What I can stand behind is the shift in how the business made decisions, which is the point.
Frequently asked questions
What is data analysis, as opposed to a data report?
A report tells you what happened — which item sold most last month. Analysis asks why it sold, at which branch, to which customers, inside which basket, at what margin, and what the business should do next. The same raw numbers answer both; only the second one changes a decision.
What data does a restaurant already have that it is not using?
Usually far more than it thinks. Billing data, inventory movement, the kitchen’s own recipe portions, the time and channel of each order, and the branch’s physical location are all being recorded. The value sits in connecting them, not in buying more software.
Do you need an expensive tool or a data team to start?
No. The chain in this case used its existing ERP. The first improvements cost nothing but clearer thinking: naming products properly, linking recipes to ingredients, and capturing headcount and channel. Spend follows evidence, not habit — and the evidence is often already on your servers.
Can better data fix a branch that is struggling?
Sometimes, and sometimes not, and the data will tell you which. If the weakness is a menu, a daypart or an offer, that is an optimisation problem you can work on. If it is the location itself, no campaign will move it — and knowing that early saves the money you would have burned trying.
The takeaway
The restaurant did not have a data problem. Its billing system, its inventory, its kitchen and its branches were each generating a signal. The missing layer was the join between them — orders to products to recipes to ingredients to inventory to branches to dayparts to channels to customer behaviour — and, underneath that, someone willing to ask a better question than “what sold?”
The most useful thing I found in that business was not how much data it had. It was how much business intelligence was sitting inside ordinary transactions, waiting for someone to interrogate it. The tools were never the point. The question was.
Free tool: The Newsroom Master Prompts and the fortnightly note Interrogate the Machine — the same discipline, applied to AI output instead of order baskets — are on hissangul.com. Read, and join the list.
Detailed audience-and-data work for a specific organisation runs quietly under The Smart Spend, by enquiry.
About the author
Hissan Gul trains journalists, newsrooms and social-science students in Pakistan to work with AI and open-source research without giving up verification. He was previously Head of Digital at Independent Urdu, where he coordinated 80+ journalists across 10+ countries, and has 15+ years across newsrooms, the development sector and paid media. He is a Fellow of the International Center for Journalists and completed Google’s Train the Trainer programme under Digital Sahafat.
