A CRM for food delivery: orders, menu and couriers

What does a CRM for food delivery do?

A CRM for food delivery is the owner’s side of the business: the screen where every order lands, moves through the kitchen’s statuses and ends as delivered, or with a reason why it wasn’t. The menu and the list of clients sit next to it. Some people call it restaurant delivery software. The name matters less than whether it follows your day.

We built one for Lunchbox Batumi, a kitchen that delivers set lunches six days a week. Its owner has to know how many sets to cook for each day, where each one goes and who ordered what. Before, all of that sat in chat messages that someone had to retype.

Clients now order in a Telegram bot: a few taps for the day, the number of sets, cutlery and an address. This article is about the other side, the web dashboard where the owner runs the kitchen, and what to ask for if you are choosing one.

How should an order move from new to delivered?

Through a fixed set of statuses that match the kitchen, with rules about which move comes next. In Lunchbox the board has five columns: new, contacted, confirmed, packed and delivered. An order from the bot appears in the first column already filled in, and from there it moves only to the statuses its rules allow next.

Not every order ends well, and the board treats that as part of the job. Rejecting an order, cancelling it or marking a failed delivery asks for a reason. A week later, “not delivered” on its own tells you nothing. With a reason written down, you can tell a wrong address from a kitchen that ran late.

Above the columns sit two short lists: the last four orders that were not delivered and the last four that were completed, with the full lists one click away. A delivered order is completed at once, so the columns hold the work that is still open.

The overview page opens with four of today’s numbers, and the latest orders with their statuses sit below them.

How do you plan the menu a month ahead?

On a calendar, where moving a day is a drag rather than a rewrite. Lunchbox keeps the menu in a monthly calendar with three dishes a day: soup, a main and a salad. The kitchen’s menu runs in a cycle of 24 days, four weeks of six.

When plans change, the owner drags a day to another date. If that date already has a menu, the two swap places, photos included. Orders that clients have already placed keep their date, their dishes and their price, so moving the menu never changes what someone ordered.

Ordering for each date stops the day before, at a time the owner picks (23:59 unless changed), so by the morning the kitchen knows how many sets to cook.

What should the CRM remember about each client?

Every request they have made, where it went, and anything the team should know. A Lunchbox client card lists the client’s requests with the date, the address, the number of sets and the dishes, and keeps a note for the team. A regular’s habits sit on one page instead of in someone’s memory.

Weekly orders showed why the rules have to be yours. Clients can order a whole week at once, and after the first real weekly order came in, the rule changed: accepting one day of it accepts the whole week, and the client gets a single confirmation. In a stock CRM, a rule like that is a workaround someone has to build. In a CRM made for the kitchen, it is one rule changed to fit how orders really arrive.

Can the CRM send the menu to clients by itself?

Yes. Each day at noon Batumi time, the menu for the day after tomorrow goes out in Telegram, and only to clients who got a delivery in the past seven days. Nobody has to remember to post it, and clients who stopped ordering a while ago don’t get it.

For everything else there are broadcasts. The owner writes a message, confirms it, and it goes to the bot’s clients.

Statistics sit on a page of their own and cover the last two weeks.

How do the kitchen team and couriers use it?

In the same Telegram bot the clients use, with a role of their own. In Lunchbox the owner’s role in the bot sees every request, and the staff role sees today’s orders to pack and deliver. Nobody installs a courier app or opens the dashboard to find the next address.

Couriers have two buttons that talk to the client: one says the lunch is on the way, the other that the courier has arrived. The client learns both in the same chat where they ordered.

The busiest day so far brought 15 orders through the bot. The client says deliveries are more accurate now and the kitchen saves a lot of time, though nobody has measured it in hours, so we give no figure.

A kitchen CRM, a generic CRM or a spreadsheet?

Most food businesses still work without a CRM. In 2025, 19.7% of companies in accommodation and food service in the EU used CRM software, against 28.5% across all the sectors the survey covers, according to Eurostat. Those figures count only companies with 10 or more people. A kitchen with a smaller team is not in them at all.

For a kitchen that is outgrowing chat, the choice usually comes down to three options:

A spreadsheet is enough while orders are few and one person keeps the whole day in their head. A ready CRM fits when your process matches its stock stages and the team opens it every day; we go through the signs in our article on building or buying a CRM. A CRM built around the kitchen pays off when the menu, the cutoff, weekly orders and couriers are the work itself, not extras bolted onto a sales pipeline.

How much does a CRM for food delivery cost?

A CRM built with us costs from $500 and takes from 2 weeks. What moves the price above that:

• roles: the owner, the kitchen, couriers, and what each of them sees;
• statuses and the rules between them, including which moves need a reason;
• where orders come from: a Telegram bot (from $100 on its own), a site form or both;
• moving your clients over from a spreadsheet;
• mailings, reports and statistics.

The first call and the written scope are free. The price is fixed in that scope before work starts and changes only if the scope does. You click through a working prototype before the bulk of the work, and the person who scopes the project builds it. We work remotely from Batumi, Georgia, in English or Russian.

To see how the Lunchbox system came together, from the bot to the board and then weekly orders, read the story of the build. The dashboard also runs as a live demo on fictional orders, where you can drag cards across the board and days across the calendar.

Questions

Sources

1. Eurostat: Integration of internal processes by NACE Rev. 2 activity (isoc_eb_iipn2), enterprises using CRM software, 2025

Alexander ZabrodinCEO · Founder

ZabSoft is a software company in Batumi. The person who scopes your project is the person who builds it.