What the word actually means
"POS" originally meant point of sale — the till. A terminal at the counter where somebody rings up what was ordered and takes payment.
Today almost every vendor uses POS to mean the entire restaurant system. The word has stretched to the point of being useless as a label.
So when a quote says "restaurant POS", it may mean any of:
- a billing terminal and nothing else
- billing plus kitchen tickets
- the full stack: ordering, kitchen, tables, billing, reports, inventory
- any of the above, with hardware bundled or not
Never evaluate on the label. Ask for the module list, and ask which modules are included at the quoted price rather than available as add-ons. The broader category and how the modules fit together is covered in restaurant management software, explained properly.
What a small restaurant genuinely needs
Four things. Everything else is a later problem.
1. Order capture. Getting what the guest wants into the system once, accurately, from wherever the order is taken — a captain's device, a counter, or the guest's own phone.
2. Kitchen communication. The order reaching the line, in the right sequence, without being shouted or retyped.
3. GST billing. An itemised bill with CGST and SGST shown separately, correct serial numbering, and the payment method recorded. The requirements are in restaurant billing and GST in India.
4. Basic sales reporting. Revenue, average order value, top sellers, busiest hours. Four numbers, not forty.
If a quote covers those four reliably, it is a working system. If it covers those four badly but adds loyalty, inventory, CRM and a marketing module, it is a worse system with a longer feature list.
What to be sceptical about
Inventory. The most-bought and least-used module in restaurant software. It only produces value if somebody counts stock accurately every week, indefinitely. Most restaurants do it for a month. Be honest about which kind you are before it goes on the quote — and note that you can get most of the benefit from a monthly manual count and the method in food cost percentage.
Loyalty programmes. Worth having eventually; almost never worth paying for in year one, when you do not yet have the repeat base to run one on.
CRM and marketing modules. Usually a mailing list with a markup.
Aggregator integration. Genuinely valuable if delivery is a real part of your business. If it is 4% of revenue, it is not worth choosing a system around.
Multi-outlet consolidation. For the outlet you have not opened yet. Buy it when you open it.
The hardware question
This is where the money actually goes, and where the least scrutiny is applied.
| Item | Typical cost | Genuinely required? |
|---|---|---|
| POS terminal | ₹25,000 – ₹80,000 | Only if the software demands a fixed till |
| KOT printer | ₹8,000 – ₹15,000 | Not if the kitchen uses a screen |
| Cash drawer | ₹3,000 – ₹6,000 | If you take meaningful cash |
| Kitchen display device | ₹10,000 – ₹20,000, or ₹0 | Often a tablet you already own |
| Card machine | From your bank or PSP | A separate decision from software |
A worked comparison for a 24-table casual dining restaurant:
Traditional bundle: terminal ₹45,000 + KOT printer ₹12,000 + cash drawer ₹4,000 + installation and training ₹8,000 = ₹69,000 up front, plus software at ₹1,500/month = ₹18,000 a year. Year one: ₹87,000.
Phone-based: hardware ₹0 (staff devices), QR sheet printing under ₹200, software ₹1,500/month. Year one: ₹18,200.
The functional gap between the two is usually much smaller than the ₹69,000 gap in the bill. That does not make terminals wrong — a busy QSR counter genuinely wants one — but it should be a deliberate choice, not the default the vendor quotes.
The design question that matters more than features
Ask this: when a guest orders, how many times does that order get typed?
In many restaurants — including ones with software — the answer is three or four. Written on a pad. Entered at a terminal. Printed as a KOT. Re-keyed at the till when the guest asks for the bill.
Every re-entry is a fresh copy, and every copy can disagree with the others. That is where mismatched totals, missed second rounds and the counter queue at closing time come from. It is a design property, not a staff problem, and no amount of extra people at the counter removes it.
A well-built system creates the order once and has every other stage read and update that same record. Fewer modules with one record beats more modules with four copies.
Three questions to ask before you sign
"Can I export my data, and in what format?" Menu, orders, sales history. A vague answer here is the answer.
"If I change a price today, does last month's revenue change?" It should not. Each order line should store the item's name and price as they were when it was ordered. Systems that store only a reference to the menu item quietly rewrite history every time you reprice, which makes every trend line you will ever look at fiction.
"What does this cost at eight staff accounts, after the trial, including annual maintenance?" Per-user pricing looks cheap at a demo. Get the real number at your real headcount, in writing.
Two more worth adding: what happens to an order placed while the internet is down — queued, lost, or half-recorded? And what is the notice period and the exit process?
Common mistakes
Buying on the demo. Every system looks capable at 11am in a quiet room. The question is how many taps it takes at 8:40 with three tables waiting. Ask to trial it during your own service.
Choosing on module count. A system covering 80% that your team uses beats one covering 100% that they work around.
Bundling hardware without asking. Covered above; it is the single largest avoidable line.
Rolling out to the whole floor at once. Put it on two tables for a service or two alongside your existing process. You are testing the workflow under pressure, not the brochure.
Skipping training because "it's simple". A captain who has worked on paper for nine years will revert to paper the first time the app confuses them — and then you are running two systems. One hour, real devices, real menu, before a live service.
What to do before you buy
- Write your three actual problems in your own words. If a system does not fix those three, its feature list is irrelevant.
- Get the module list in writing, marking what is included versus an add-on.
- Price the quote at your real headcount, after any trial period, with maintenance included.
- Separate the hardware line and challenge every item on it.
- Ask the three contract questions. Export, price snapshotting, real cost.
- Trial on two tables during a genuine rush before committing.
The short version
- "POS" now means anything from a till to a full system. Judge the module list, never the label.
- A small restaurant needs order capture, kitchen communication, GST billing and four sales numbers. The rest can wait.
- Hardware is where ₹40,000–₹1,50,000 quietly appears, and it is frequently optional.
- Inventory only pays back if someone counts stock weekly forever. Be honest about that first.
- Ask how many times an order gets typed. One record beats four copies and more modules.
- Get export, price snapshotting and real per-user cost answered in writing before you sign.
