By Eduard Pàmpols, founder of RestoVector - 10.2.2026
A restaurant dashboard can look most convincing when it should be asking a question. A neat percentage, a green indicator and a tidy weekly comparison may suggest that the underlying records are complete. But what happens when one supplier price has not arrived, a waste entry is missing or nobody has finished the stock count?
For an independent operator, that is a useful question to bring to a software demonstration. Complete records show how a system works under ideal conditions. Incomplete records reveal what it tells the people who must make decisions before the paperwork catches up.
A small example is enough to run this check. Ask the software provider for a demonstration environment where records can be safely changed. Choose one dish, one ingredient and a short reporting period. Keep a separate calculation that can be verified independently, then remove one record at a time. The figures below are invented solely to illustrate these tests. They are not customer results or evidence of savings.
First, agree on what the number means
Before changing anything, ask the demonstrator to define the metric on screen. “Food cost” might mean the ingredient cost of a recipe, the value of stock consumed during a period or a percentage calculated against sales. Those measures answer different questions, and a missing purchase price affects them differently from a missing sale or an unfinished count.
Write down the reporting dates, units and records included. If the system shows a percentage, identify both the numerator and denominator. Check whether the figure is final, provisional or an estimate. This small step prevents a misleading test. A number can only be checked properly once its meaning is clear.
Test one: remove a supplier price
Create a simple recipe using 200 grams of an ingredient priced at $10 per kilogram. That ingredient contributes $2 to the recipe cost. Add other ingredients with a combined cost of $1, giving a total of $3. Now remove the $10 price, or use an ingredient for which no price has been entered. Ask the demonstrator to explain what the system does.
Does the recipe become incomplete? Does the system retain a previously recorded price? Does it substitute another value? An estimate may be useful, but its basis should be visible wherever someone relies on it. A $1 total presented as a complete recipe cost would deserve scrutiny because it could mean that the unpriced ingredient has effectively contributed zero. Equally, an unchanged $3 total needs an explanation. Perhaps a historical price is being used, or perhaps the view has not refreshed.
Ask where the price came from, when it applied and how an operator would notice that a current price was unavailable. Repeat the check in an export if spreadsheets form part of the normal review. The figure should remain understandable even when a supporting record is missing.
Test two: leave waste unrecorded
Next, use a simple stock reconciliation. Begin with 10 kilograms of an ingredient, receive another 5 kilograms and record a closing count of 6 kilograms. Assuming no other movements, the difference is 9 kilograms.
Suppose the demonstration records identify 7 kilograms of recipe use and 2 kilograms of waste. The quantities now reconcile. Remove the waste entry. The remaining records explain only 7 of the 9 kilograms. Ask where the unexplained 2 kilograms appears. That difference should remain available for investigation. Missing transfers, inaccurate counts, preparation yields and other recording differences could also explain it. The test is whether the system distinguishes recorded waste from an unexplained difference.
Also inspect any waste summary. “No waste recorded” and “no waste occurred” are different statements. If a report displays zero, ask whether the operator can distinguish a completed log with no waste from a log that was never completed. Finally, restore the entry. Check whether the reconciliation updates and whether the record retains enough context to explain the change.
Test three: stop a stock count halfway through
Set up two ingredients that both have positive opening stock. Complete a closing count for one, leaving the other uncounted. Use a separate copy of the example to enter a genuine zero for the second ingredient. Compare the outcomes. A blank count means that a quantity has not been established. A counted zero means that someone recorded none remaining. Treating those states identically can distort the interpretation of consumption.
Ask whether an unfinished count can be submitted, whether a manager can see its completeness and what happens to reports that depend on it. Provisional reporting can be useful, provided the unfinished count and its effect on the figures are clear. Then finish the count after viewing the report. Does the report change? Can the operator tell when the count was completed and which version informed an earlier decision?
People reviewing results at different times may see different figures. Both may be explainable, but the supporting records and the reason for the change need to remain accessible.
Turn the demonstration into a short acceptance check
Keep a record of each test, including the starting inputs, the missing record, the displayed result, any warning and the outcome after correction. Screenshots and a small worksheet are enough. Before proceeding, review the results against these questions. Ask the demonstrator to show where each answer can be found in the software.
- Can operators distinguish missing information from a recorded zero?
- Can they identify estimates and their source?
- Can they trace a summary back to the records supporting it?
- Can they see what remains incomplete?
- After a correction, can they explain why a result changed?
Run these checks with someone who will use the software during an ordinary shift. A warning that only the demonstrator knows how to find offers limited help to a busy manager. Restaurants often need to act while information is still arriving. A useful dashboard helps an operator understand both the available evidence and its limits. Testing a few missing records before adoption is a practical way to see whether the software will provide that guidance when service gets busy.
Eduard Pàmpols is the founder of RestoVector, web-based restaurant management and cost-control software for independent restaurants and restaurant groups. It connects service, kitchen, inventory, purchasing, recipe costing, waste and analytics so managers can trace results to the underlying records.
Are you an industry thought leader with a point of view on restaurant technology that you would like to share with our readers? If so, we invite you to review our editorial guidelines and submit your article for publishing consideration.
