Pan Enterprise Solutions, the software arm of Pan Innovation House · based in Gaziantep, Türkiye, with a London office
We do not replace the POS system at your till. We bring recipe costing, central kitchen dispatch, wastage and profitability per branch, the consolidation of online ordering channels and franchise tracking together in a management layer that runs on top of the till. Not an off-the-shelf package, but built for your business. The source code we write is handed over to you as defined in the contract.
Asking about price? We listen to the scope in a short call and share the budget frame and timeline in writing. The first 30-minute call is free; the scope of an on-site discovery, and its fee if any, is agreed in writing during that call.
We work on site for plants in and around Gaziantep; elsewhere in Türkiye and abroad, discovery starts by video call and a visit is planned if needed. Our London office is at Unit 6 Cranford Way, Hornsey, London N8 9DG.
Food service businesses almost always have a POS system, and it records sales properly. The problem is not recording the sale; it is not knowing what the product sold actually costs and where the difference disappears.
Point-of-sale software is widespread and mature in this sector. The gap sits on the cost and chain-management side behind the sale; it appears especially as branch numbers grow and a central kitchen comes into play.
| Layer | Software in use today | The gap it leaves |
|---|---|---|
| Point of sale (POS) and ordering | Simpra, Adisyo, SambaPOS and similar POS systems | They are mature, widespread solutions for order taking, billing, till operations and basic reporting; in most businesses they should stay in place and there is no reason to replace them. The gap is not in recording the sale but behind it: recipe costing, the central kitchen flow and comparing branches by the same measure. In most set-ups this management layer either does not exist at all or remains superficial. |
| Online ordering channels | Yemeksepeti, Getir Yemek, Trendyol Yemek and the brand's own ordering channel | Each channel provides its own panel and its own report; within a channel the figures are consistent. The problem arises in cross-channel comparison: commission rates, campaign contribution shares and cancellation handling differ from channel to channel. Normalising these differences by hand takes time and invites error; in the end channels are compared on turnover, when what should be compared is net contribution. |
| Accounting and bookkeeping | Logo, Mikro, Netsis, DIA and similar systems | They are necessary on the financial side and stay in place. But they do not carry kitchen concepts such as recipes, portions and wastage; here cost appears by account, not by product. When someone asks what a dish costs today, accounting records cannot answer, because that is not accounting's question. |
| Stock and stocktaking | Stock modules inside the POS, Excel count sheets | Basic stock tracking is possible and often sufficient in single-branch businesses. What is missing is the comparison between recipe-based theoretical consumption and the physical count. When that comparison is not made, the variance appears at month end as a lump sum whose cause cannot be investigated; waste, portion deviation and loss all blur into the same number. |
| Staff and shifts | Excel rotas, messaging groups, time-and-attendance (PDKS) devices | Shift planning and attendance tracking sit outside any system in most businesses. As a result, one of the sector's most decisive indicators is never calculated: labour cost as a ratio of turnover and of hours. When that ratio is unknown, the rota is built on habit rather than on demand. |
| Franchise and multi-branch management | Excel templates sent from head office, periodic reports | Branch data reaches head office late and in varying formats; consolidation is done by hand at the centre. Whether the brand standard is being applied cannot be measured, and problems are usually spotted during an audit visit. As the chain grows this method stops holding up; head-office workload grows linearly with every added branch. |
Product names are compiled from vendors' public pages (September 2026); PAN is not affiliated with them. The "gap" column summarises situations we commonly meet in discovery and is not a statement about any specific product.
Our solution is not a rival to your till. Your POS system stays in place; we build the layer that links sales data to recipes, recipes to stock and stock to profitability.
Every product's recipe goes into the system with its portion weights; cost is calculated from current purchase prices. When a recipe changes, the previous version is preserved. The standard moves out of the chef's memory and stays with the company.
Theoretical consumption is calculated from products sold and compared with the count. The variance is visible by product and within the period; it stops being an unexplained lump sum at month end.
Sales from dine-in, takeaway and online channels are gathered into a single report; commissions and campaign contributions are deducted so that channels' net contribution can be compared.
The cost of products made in the central kitchen and their dispatch to branches are tracked. Dispatched quantities are compared with quantities used at the branch; where in the chain the loss occurs becomes visible.
Wastage, spoilage, staff meals and complimentary items are recorded quickly on the floor. Recording happens to the extent that it is easy; that is why the interface is designed for the pace of the kitchen.
Profitability is reported, not turnover: a view net of wastage, labour, channel commission and fixed costs. Branches are compared by the same measure.
Not every business needs all of them. In a single branch, recipe and wastage tracking may be enough, while in a chain the central kitchen and branch dashboard come to the fore.
Product recipes, portion weights, costing from current purchase prices and menu margin analysis. Recipe versions are preserved.
See the module → WMSWarehouse and branch stock, the counting flow, comparison of theoretical and actual consumption, wastage and spoilage records.
See the module → MESBatches and costs of products made in the central kitchen and their dispatch to branches; monitoring the variance between dispatch and usage.
See the module → APIPulling sales data from the POS system and consolidating online ordering channels; separating out commissions and cancellations.
See the module → BISales and profitability reports by branch, channel, product and hour; branches compared by the same measure.
See the module → ERPShift planning, attendance tracking and labour cost as a ratio of turnover and hours; planning support based on peak hours.
See the module → QRA regular flow of franchise branches' sales and stock data to head office, audit checklists and finding follow-up.
See the module → QMSTemperature monitoring, digitised cleaning and control forms, records stored with date and responsible person.
See the module →Your POS system and your accounting software stay in place. The layer we build takes the sales data, links it to the cost and stock side, and produces the view management needs.
Our integration approach →We discuss your business structure, your branch count, your current till and accounting systems and the point that hurts most. We clarify expectations and scope and draw a realistic frame; at this stage understanding, not selling, comes first. The call carries no obligation. The first 30-minute call is free; the scope of an on-site discovery, and its fee if any, is agreed in writing during that call.
We walk the kitchen, the store and the central kitchen if there is one. We see how recipes are applied, how counting is done and how wastage is recorded. No interface that fails to match the kitchen's pace gets used; the design takes shape from this observation.
We usually start with recipes, stock and wastage in a single branch. Scope, timeline and deliverables are put in writing; for chain businesses, the rollout plan is also drawn at this stage.
The system is developed and run in parallel with the existing routine in one branch. The variance between theoretical consumption and the count is examined; gaps in the recipes surface at this stage and are corrected.
Other branches and modules are added in turn and channel integrations are switched on. Users are trained, and the documentation and source code are handed over as defined in the contract. Maintenance and support run under a separate agreement.
If your POS system works, it stays in place. Our job is the management layer above it; we will not try to talk you into replacing your till.
Nobody fills in long forms during service. We design the wastage and counting screens for the kitchen's real tempo; a screen nobody uses solves nothing.
The source code we write and your data are handed over to you as defined in the contract; third-party and open-source components remain subject to their own licences. We leave behind no structure built to keep you dependent on a monthly usage fee.
A structure built for one branch collapses at the fifth. We build the system for multi-branch operation and launch it with a single branch.
We do not change everything at once. We start with recipes and wastage and expand as the gains show; progressing without disrupting service is essential.
Documentation and a handover package are part of the job. If another team takes over tomorrow, we deliver in a state they can take over.
POS stock modules do basic tracking and are often sufficient in single-branch businesses. The gap usually opens in three places: comparing recipe-based theoretical consumption with the count, the central kitchen flow, and comparing branches by the same measure. If your current system covers these, we will not propose building anything new, and we will say so openly.
This is the most common situation, and it is precisely the first stage of the work. Recipes are drawn up together with the kitchen, portion weights included. This exercise is valuable on its own; in most businesses, this is where it is first seen that the same product is made at different weights across branches. We run the process, but your head chef decides the content.
It depends on the interfaces the channels offer and their partnership terms; we examine which data can be obtained from which channel at the start of the project and say so openly. Where a direct connection is not possible, a meaningful comparison can still be built by importing the periodic reports taken from the channel's panel into the system.
That is a commercial matter and belongs to your franchise agreement; on the software side, the scope of sharing can be controlled. A set-up is possible where only standard indicators flow to head office while each branch's detailed data stays with the branch. You define the boundary; we implement it.
Scope is built to scale. In a single branch, recipe costing and wastage tracking alone usually make the biggest difference; the central kitchen and branch dashboard are not needed. We do not recommend building a full-scope system from day one.
That is the most important design constraint, and we work to it. The screens used on the floor are kept simple enough to learn in a few minutes; complex operations are left to the management side. In a business with high turnover, a system that needs long training becomes unusable within a few months.
The timeline depends on scope and is given in writing after discovery. Our approach is to get a working system live in a single branch quickly and grow it from there. That way feedback arrives early and the return on the investment shows early.
A working system, plus the source code we wrote, the database and handover documentation as defined in the contract (third-party and open-source components remain under their own licences). User training and initial support are part of the scope. Maintenance and development then run under a separate agreement; you are not obliged to sign one, and you can maintain the system with your own team.
The number of branches, whether there is a central kitchen, how far recipes are written down, the access your POS and online ordering channels offer, and the franchise structure. We discuss a budget range in the first call; the exact scope, timeline and price are put in writing after discovery.
One person each from the kitchen and management, your head chef's time to write recipes down with their weights, report access from your POS and channel panels, and purchase price lists.
During discovery we choose the measures that suit you, such as the gap between theoretical consumption and the stock count, how consistently waste is recorded, or the point at which branch profitability becomes visible. We do not set targets before measuring the starting point; we agree them with you, based on your current data, before work begins, and results are not guaranteed.
Food cost is the ratio of the cost of the ingredients in a menu item's recipe to that item's selling price, usually expressed as a percentage. The ratio only means something when the recipe weights and current purchase prices are right. In the layer we build, each item's recipe is entered with its weights, the cost is calculated from current purchase prices, and theoretical consumption is compared with the stock count.
We would like to see your business on site, from the store to the kitchen and from the till to the online channels, and work out with you where profit is leaking and where to start.
