A restaurant is already two full-time jobs: the food, and the service. The mistake most operators make with online ordering is treating it as a third — a website project, an app relationship, a tablet on the counter that chirps at the worst possible moment. Done properly, the online side is not another job. It is the part of the business best suited to running itself.

What "online restaurant" actually means in practice is narrower than the phrase suggests: a menu people can read on a phone, modifiers that capture how people really order, a checkout that works, order tracking that answers the where-is-it question before it is asked, and something that responds when a customer wants to change, add, or complain. Every one of those is a solved problem. None of them needs to be solved by you.

Put the whole menu online — but not on day one

Kitchens and websites fail the same way: too many items, each done slightly worse. Launch with the dishes that travel well and photograph honestly, and let the dine-in menu keep the rest. A short online menu also keeps your modifier logic sane — and modifiers are where online ordering is won or lost, because they are the difference between "no onions, extra sauce" arriving correctly and a refund conversation.

• Start with the ten to fifteen items you would defend in a review, not the full carte.
• Model modifiers properly from the start — sizes, sides, spice levels, removals. Free-text instruction boxes are where mistakes and disputes breed.
• Photograph the food you actually serve, in the containers it actually arrives in.
• Decide your delivery radius and your quiet hours before launch, and let the ordering page enforce them so you never have to.

The apps are a channel, not a home

Marketplace apps bring you customers and charge you for the privilege — a commission on every order, and more importantly, ownership of the relationship. The customer who orders through an app is the app's customer; you cannot reach them, thank them, or bring them back. That is a fine trade for discovery. It is a terrible trade for regulars.

The phone is the hidden workload

Ask any operator where the evening actually goes and it is not the pass — it is the phone. Where is my order. Are you open Sunday. Can you do it without nuts. Can I move my booking to eight. Each call is a minute of a person you are paying to be somewhere else, taken during the exact hours you are busiest.

This is the workload a Phoxta restaurant absorbs outright. The agent answers on the channel the customer used — web chat, SMS, WhatsApp or the phone itself — with the real order status, the real menu, and the real table availability behind it. Allergen questions get consistent answers. Booking changes write straight to the diary. The tablet in the corner stops being a job title.

What to watch in the first month

• Direct-to-marketplace order mix — the share of orders arriving through your own storefront should climb every week, because those are the orders with full margin.
• Repeat rate at thirty days — a takeaway that people order twice is a business; one they order once was a promotion.
• Time-to-acknowledge — how long an order sits before the customer knows the kitchen has it. Silence here generates the calls.
• Refund rate by dish — one item usually accounts for most of the trouble. Fix it or drop it.

The kitchen closes at ten. The questions do not. The difference between those two clocks is either your evening or your software's.

None of this requires hiring a developer or gluing six subscriptions together. A Phoxta restaurant starts as a running business — storefront, menu and modifiers, checkout, order tracking, reservations and the agent that answers — and the pricing page shows what running it costs. Your attention belongs on the food; the rest is the machine's job.