KoratMost shops in Thailand are running three systems that do not speak: a point-of-sale for the till, a delivery app's tablet for orders, and a group chat for the roster. The customer is a stranger in all three. Korat exists because those are not three problems — they are one order, seen from different chairs.
Opening a shop takes about a minute
Create a business, give it a name, an address and a phone number, and pick its type. The type decides which modules load. There is no setup wizard to sit through and nothing to configure before you can take a first order, because the settings that matter — opening hours, delivery, PromptPay, categories — are a tab you can come back to.
Deleting a business takes two confirmations on purpose. Editing the name, address, phone or description is a single sheet, and the changes show on your public page immediately.
Restaurants: the QR is the whole security model
A member of staff opens the table. That mints a token that belongs to that sitting only, and the QR carries it. A customer scans, joins the session, and orders. When the table closes, the token dies with it — which is what makes a photographed QR, or one forwarded to a friend down the road, useless.
Orders do not go straight to the kitchen. They land in a waiting-for-confirmation queue on the kitchen display, and a person confirms or rejects each one. That single step is the difference between a QR menu and a system you can leave running on a busy Friday. Opening hours have a last-order buffer, so the app warns the table that the kitchen is closing and then stops accepting orders entirely.
The rest of the restaurant module is the ordinary work: a menu with photos, categories, availability, stock, option groups with price deltas, combos, buffet packages with a countdown and leftover charging, an alcohol gate with staff age verification, table reservations, delivery with a fee and a scheduled pickup time, and a checkout with a labelled discount, tendered-and-change, and a PromptPay QR for the exact amount.
Retail, stays and clinics get the same treatment
- Retail
- A till for the counter, an online-orders console with the five-step pending → confirmed → packing → shipped → delivered flow, tracking numbers, rejection with a reason, products with attributes and variants, and stock with low-stock warnings.
- Stays
- Rooms you check in and out on a grid, room types with photos and nightly rates, seasonal and promotional pricing rules by date range, a bookings inbox, room-service requests, and monthly tenancies with deposits, water and electricity meter readings and generated bills.
- Services and clinics
- Services with a duration and a price, appointments with staff assignment, and courses or memberships that customers buy and redeem session by session. A clinic relabels the interface to appointments, patients and treatment courses.
Reports, customers and loyalty come with every type
Revenue, order count and average ticket for today, the last seven days, the last thirty or all time; the split between cash, PromptPay and other; the top five sellers; and a seven-day revenue bar chart. Any receipt can be reprinted or shared as text, and all of it sits in the same business console. A tax invoice cannot be issued: under Thailand's Revenue Code s.86/13 only a VAT registrant may issue one, and nothing in this system records any shop's registration yet — so every document is a plain receipt with no VAT line. The payments guide walks through exactly how money moves — cash, PromptPay, and what Korat never touches.
The customer list builds itself out of the sales ledger — you do not type customers in. Each one carries their purchase history, your notes and your tags, loyalty points earned at a rate you set in your own currency, a minimum sale and reward you configure, and a redeem button. That is the part a delivery platform structurally cannot give you: it owns the customer, and you get an order.
Staff: GPS clock-in, overtime, and who is allowed to see what
Every business type gets the same HR module. Staff clock in and out with GPS and an optional note. Leave requests are approved or rejected in the console. Shifts turn into worked minutes and overtime past eight hours in a day, against an hourly or a monthly wage, and payroll is computed per member. An ordinary member of staff sees only their own pay; the owner and managers see everyone.
Permissions are a matrix, not a switch. There are thirteen core capabilities plus whatever the installed modules add, with presets for owner, manager, waiter, kitchen and general staff, and per-person overrides on top. A tile a member cannot use is not greyed out — it is not there. A member with nothing yet sees a plain “you have no permissions yet” screen instead of an empty console that looks broken.
Be clear about where this is enforced. In the app, the capability check that hides a tile runs on the device. The same permission matrix also exists in the database as has_capability(business_id, capability), and the row-level-security policies use it — so the role presets expand on the server and the database never trusts the app's idea of who is a manager. Full server-side enforcement of every console screen is still being rolled out. The security page says exactly how far it has got.
Your public page is part of the product
Every business has a page: cover, logo, gallery, opening hours with an open-or-closed state right now, address, phone, directions, a follow button, a chat-to-the-shop button, and a call to action that changes with the type — order, browse products, book a room, book an appointment. You can post to the feed as the business, and those posts are always public.
Reviews on that page can only be written by someone the database can prove was a customer: ate in, ordered delivery, stayed, used a service, or bought a package. Everyone else sees a lock card explaining why there is no write button. The star rating is recomputed by a database trigger from the review rows and cannot be typed in by anybody, including us. You can reply to any review.