Restaurant management software for Malaysian outlets

A usable system has four records that must agree. The menu says what can be sold today, including items that are finished. The order says what a table or a delivery source asked for, with modifiers on the line. The ticket says what the kitchen still owes. The close says what was sold, voided, comped, and taken as cash, card, or a recorded delivery payout. Staff meals and wastage sit beside those totals so they do not hide inside sales.

The first release we recommend is narrow: one outlet, one menu, dine-in orders, a way to record a delivery order, kitchen tickets, voids and comps with a reason, and a close. Recipe deduction for a short list of expensive ingredients can be in or just after that release, depending on whether the chef will maintain the recipes. A second outlet, a full purchasing module, and a customer-facing QR menu are later. Outlets that demand the catalogue on day one usually stall in training.

Hardware stays practical. A ticket can print or show on a screen the kitchen already has. We do not design a new printer brand, and we do not require a kitchen display if paper tickets are what the pass will actually read. The software should match the physical pass, not the other way around, in the first month.

Every dish the kitchen cooks should be a line on one queue, whether it started at a table, at the counter, or on a delivery tablet. The line carries the modifier, the time, and the source. The pass marks it done. The floor sees that status without shouting. Double entry is the defect we are removing: the same nasi lemak existing as a tablet notification and a handwritten chit.

Modifiers are where packages feel foreign. “Less spicy”, “no onion”, and a named allergy need to be structured enough that the ticket is readable, and free enough that the floor is not blocked by a perfect taxonomy. A short modifier list per item, plus a note for the rare case, is the shape that survives a rush. A note with no item is how orders get lost.

Set meals and courses need a rule you can say in one sentence. If a set is three choices from a list, the order should not allow a fourth without a role that can override and record why. If the kitchen fires starters and mains separately, the ticket should show the fire, not rely on the waiter walking in. If you cannot say the rule, we should not build a guess.

A table has a status: empty, seated, ordered, served, paying. The floor uses that list during service. Reservations, if you take them, are a name and a time that become a table. A walk-in is the same object with no prior booking. Large bookings can hold a section so the floor does not sell those seats twice. This is operational, not a guest-marketing suite.

Takeaway is an order with no table and a collection time. Delivery-platform orders are the same shape plus a source and an external reference. Staff key them when the tablet rings, or a later phase imports a file the outlet already downloads. The kitchen queue does not care which tablet rang. Availability on the platform is still the platform’s job. We will not claim to be a channel manager for every delivery app in Malaysia.

If your current point of sale already pulls delivery orders cleanly and the kitchen lives in it, keep that connection. Custom software is the right conversation when the terminal is fine for payment and everything about the pass is still paper. Replacing a working card flow just to own the software is a poor trade.

A void removes a line before it should count as a sale. A comp is a sale you chose not to charge. They are different, and both need a user, a time, and a reason. Outlets lose margin when either can be done with a shared cashier login and no trail. The close should list them. A manager should be able to see who comped the most this week without accusing the room from memory.

The close itself is the day’s pack: sales by item or category, sales by tender, open orders, voids, comps, and the difference against cash counted. It moves the business date forward only when exceptions are cleared. A system that lets anyone edit yesterday without a trace will not survive the owner’s Monday questions. Late adjustments are visible as adjustments.

Tenders include cash, card, e-wallet, and a recorded delivery settlement. The card line is an amount, not a card number. The delivery line is what you expect the platform to pay, which may differ from the menu total after their commission. That difference should be visible. Hiding it inside “sales” is how owners argue with a true number.

Recipe deduction is optional and should stay short. Pick the ingredients whose variance hurts: a protein, a dairy, a packaged drink, a dry store that is easy to walk out. Each recipe line is a quantity the chef agrees. A completed sale deducts it. A waste entry deducts it with a reason. A delivery from the supplier adds it. A count replaces the theoretical quantity with what is on the shelf.

Between outlets, a transfer is a stock movement with a sender and a receiver. The central kitchen produces. The cafe receives. Both should confirm, otherwise the producing kitchen will show stock it no longer has and the cafe will show a magical appearance. This is the same idea as a warehouse transfer, kept small enough for a cook to tap after prep.

If the ingredient list grows into a full warehouse with bins and barcodes, use the inventory system pages on this site rather than stretching a restaurant screen into a store. The restaurant record should remain the sale and the ticket. The store record can be the carton. Connecting them is a phase after both are trusted.

Packaged tills are the default for a single cafe whose menu, modifiers, and drawer match the product. You pay a subscription, you get receipt hardware paths that already exist, and you accept the buttons. Sorable is not a reseller of those products and not a cheaper clone of their payment stack.

Custom restaurant management software fits when the exception is daily. A central kitchen, a catering book beside the dining room, a staff-meal rule, or a course fire the buttons cannot show. If the dinner shift keeps a second list to finish service, the template has already lost, whatever the monthly fee is.

The honest test is one Friday. Watch a dine-in order, a modifier, a void, a delivery order, and the close. If the package finishes that night, buy the package. If the side list is where the truth lives, a scoped build is the conversation. The workflow audit is where we say which of those two you are.

We do not store card data, and we do not replace your bank’s terminal. We do not operate GrabFood, Foodpanda, or ShopeeFood. We do not issue halal certificates, council licences, or hygiene grades. We do not file SST. The close can store tax amounts your accountant has defined and can export them.

We do not build a consumer super-app, a loyalty science product, or a reservation marketplace. A simple reservation list for your own dining room is in scope when you need it. A public directory of restaurants is not. Guest phone numbers, if you keep them for a booking, are personal data and should be limited to the roles that seat people.

We also do not run the outlet. Training the Saturday crew is the manager’s job. The system should be small enough that a new cashier can learn the order and the close. If a feature needs a manual the length of a menu, it waits.

We start from the service you would trust on a Friday at 8pm. Menu size, how orders reach the pass, what a void looks like, and where the closing number is written. That is the workflow audit. It can end with “keep your till.”

The quote then names one outlet and a price. Orders, tickets, modifiers, and a close often fall between RM12,000 and RM40,000 setup, plus a monthly care plan. A second outlet, recipe deduction across a long ingredient list, and an accounting export are additional. Build time for the first release is often 6–12 weeks after scope approval, including a parallel run over real services.

Read the restaurants page if you are still deciding whether custom is the category. ERP and inventory pages apply when the pain is the back store or the ledger rather than the pass. Sequence them. The kitchen cannot wait for a perfect finance integration before it has one ticket queue.