Cost

What a restaurant ordering bot costs

An ordering bot is ten to sixteen delivery days, and the menu is the variable. A short fixed menu is quick; modifiers, combos, portion sizes and per-branch availability multiply the work. The decisive question is whether the kitchen will actually accept orders on a screen during service.

What a restaurant ordering bot costs: effort, cost and what moves it

Fixed price: $6,300 USD
Delivery: Awaiting sign-off

Effort: 15 delivery days
Biggest cost driver: Menu modelling and kitchen acceptance, not checkout
Commercial basis: Fixed price agreed before work starts; scope changes quoted separately
Year one, beyond the build: Support retainer, Managed hosting, plus payment processing fees, printer hardware, third-party delivery fleet

As of 2025-10-01, Telegram Bot API 13.4

Why this costs what it costs

Restaurants come to this with a clear and correct commercial motive: aggregator commissions in the UAE take a substantial share of every delivery order, and a direct channel keeps it. That arithmetic is genuinely compelling and it is why these projects get funded. It also produces a specific failure pattern, because the arithmetic assumes the orders arrive and get cooked, and the hard part of an ordering bot is not taking the order.

The hard part is the kitchen. During service, a printer that produces a ticket is used and a tablet that needs tapping is not. If the flow requires someone to acknowledge an order on a screen while three pans are going, orders will be missed, and each missed order is a customer who never orders directly again. Every ordering bot that works has an acceptance mechanism the kitchen genuinely uses — usually printing to the same printer the aggregator tickets come out of, or a single loud confirmation on a device that has one job. That decision is made with the kitchen, in the kitchen, and it shapes the build more than any menu detail does.

The menu itself is where the day count moves. A short menu of fixed items is a day of modelling. A menu with sizes, sauces, extras, exclusions, combos that change the price of components, per-branch availability and items that sell out at eight in the evening is a small product catalogue with rules, and it takes as long as it takes. Restaurants consistently underestimate this because the menu is obvious to them — everyone in the building knows that the large shawarma comes with a different sauce set, and none of it is written down anywhere a system could read.

The third thing worth pricing honestly is delivery. If you have your own drivers, the bot needs zones, fees, minimums and a dispatch view, which is a real slice of the work. If you use a third-party fleet, it needs their integration and their status callbacks. If you are pickup only, most of this disappears and the project is meaningfully cheaper. Deciding this at kickoff rather than in week two is worth more than any efficiency in the build.

The breakdown

Work	Days	Cost	What it covers
Menu modelling	3	$1,260	Categories, items, sizes, modifiers, exclusions, combos and per-branch availability. Priced against your real menu, which is almost always more complicated than the printed one.
Ordering flow	3	$1,260	Browse, customise, basket, quantity edits, and a review step that shows exactly what will arrive and what it costs before anything is charged.
Kitchen acceptance	2	$840	Getting the order in front of the kitchen in a form they will use during service — printer, dedicated device, or both — with an acknowledgement the customer can see.
Delivery zones and fees	2	$840	Zone boundaries, per-zone fees and minimums, address capture that works from a phone, and a clear refusal when an address is outside the area.
Payment	2	$840	Card checkout or cash on delivery, with the reconciliation and refund handling that either choice implies. Cash is not free — it has its own accounting path.
Order status and reorder	1	$420	Accepted, preparing, on the way, delivered, pushed into the same chat, plus one-tap reorder of a previous order, which is where repeat revenue actually comes from.
Manager surface	1	$420	Mark an item unavailable, pause ordering when the kitchen is overwhelmed, adjust an order, and see the day's totals. All from a phone.
Deployment and staff training	1	$420	Launch during a quiet service with someone present, plus a short session with the shift that will run it tomorrow morning.
Total	15	$6,300	Fixed on signature. Scope changes are quoted separately, never absorbed silently.

What moves the number

Modifier depth drives menu cost more than item count.

Forty items with no options is quicker than twelve with sizes, sauces and exclusions. Send the real menu with every variation before asking for an estimate, not the printed one.

A kitchen under load will not tap a tablet.

Acceptance must fit the way service actually runs, which almost always means printing. An ordering bot whose orders are missed at peak is worse than no bot, because it disappoints the customers who tried the direct channel.

Delivery zones need real boundaries and real fees.

Free-text addresses produce orders drivers cannot find. Zone modelling with an explicit out-of-area refusal is part of the build, and it is where own-fleet restaurants spend more than they expect.

Telegram allows twenty messages per minute into a single group.

A busy service pushing every status update into one staff group hits the limit and messages queue. Status routing has to be designed for peak volume rather than for a demonstration.

Items sell out mid-service and nobody updates a system.

A one-tap availability toggle on a manager's phone is the difference between an accurate menu and a refund. It is a small line here and the most-used feature in the finished product.

Multiple branches multiply menu, zone and routing logic together.

Two branches is not twice one branch — it is per-branch availability, per-branch zones and an order routing decision. Worth scoping from the start if a second location is likely within the year.

What year one actually costs

Running cost	Year one	Detail
Support retainer	$3,480/yr	Menus change constantly, and a restaurant bot receives more small change requests than any other category. The monthly allowance is the part clients actually use here.
Managed hosting	$660/yr	Runtime and order history, with backups. Order records matter for disputes and for understanding what actually sells through the direct channel.
Payment processing fees	billed by the provider	Per transaction on your own gateway contract, and the number to compare against aggregator commission rather than against zero.
Printer hardware	billed by the provider	A one-off purchase if the kitchen needs a dedicated printer, bought locally by you. Modest, and the highest-leverage hardware in the project.
Third-party delivery fleet	billed by the provider	Billed per delivery by the fleet operator where you use one. Still typically well below aggregator commission on the same order, which is the whole argument.

Buying the same thing elsewhere

Where you buy it	What the money buys	What you carry
Delivery aggregators only	Demand generation, a delivery fleet, customer service and payment handling with no technology to build. For a new restaurant with no audience, this is how you get started and there is no shame in it.	Commission on every order, no relationship with the customer, and no ability to bring them back directly. The economics get worse as you get busier, which is the opposite of what you want.
Your own website with online ordering	A direct channel you own, indexed by search engines, reachable by anyone with a browser and no app required.	Every order starts with someone choosing to visit a website, and repeat ordering depends on them remembering to. Conversion from a link in a chat is materially worse than ordering inside the chat.
A restaurant POS vendor's ordering module	Already connected to your menu, your stock and your reporting, with one supplier for everything and no reconciliation between systems.	Customer-facing interfaces in POS products are usually the weakest part, and the channel is a web page rather than a chat. Check the module actually gets used before assuming it removes the need.

Questions about the money

Does this actually beat the aggregators?

On unit economics, clearly — you keep the commission. On demand, no: aggregators bring customers you do not have. The pattern that works is using both, and pushing your existing customers to the direct channel with a reason to move, which the bot makes cheap to do.

How does the kitchen see orders?

Usually printed on the same printer that already produces aggregator tickets, because that is what a kitchen under load will actually use. A dedicated device works where the kitchen is calm enough for it. This is decided with your head chef, in your kitchen, before the build.

Can we take cash on delivery?

Yes, and in parts of this market it remains a meaningful share of orders. It is not free to support — driver reconciliation and end-of-shift cash-up have their own flow — but it is well inside the payment line rather than an extra.

What about our existing POS?

If it has a documented API, an integration is quoted separately after we read it. Many restaurant POS systems in this market do not, and the honest answer is often that the bot prints a ticket and the POS entry stays manual, exactly as it is for aggregator orders today.

How do customers find the bot?

A QR code on the table, on the packaging and on the receipt, plus the link in your social profiles. The packaging is the one that compounds — every delivery order you currently pay commission on is a chance to convert that customer to the direct channel.

Can it handle table reservations too?

Yes, though it is a different flow with a different failure mode and adds roughly two days. Restaurants that want both should scope them together, because a reservation bot and an ordering bot sharing one menu and one customer record is cheaper than two projects.

What happens when we are too busy to take more orders?

A pause switch on the manager's phone stops new orders with an honest message and a time to come back. Being unable to say no is how a direct channel produces a bad night and a set of refunds.