Restaurant Management System: What It Covers and How to Write Your Requirements

If you're about to choose a restaurant management system, or build one, start by deciding which of your records it has to hold. Vendors use the name loosely. For one it means everything from the dining room to payroll, for another it's a single module. Broadly, it's software that keeps a restaurant's working records in one place: the menu, orders, tables, bookings and guests, and in fuller suites stock, staff hours and costs. Any record it doesn't hold still needs a home, and it's better to settle where that is before you sign than after the first month closes.

Front of house, back of house and the office

The usual split has three parts. Front of house is everything the guest touches: the menu, ordering and payment, tables and reservations, guest records. Back of house is the kitchen and the stockroom, which means kitchen display, stock counts, purchasing and recipe costing. The office has staff schedules, payroll and the accounts.

Vendors name these pieces differently. One says order management, another says sales screen, and both are talking about an order. That's why requirements hold up better when they're written as records and rules rather than as a list of module names. The record stays the same whichever screen it ends up on.

One price change shows where your menu is kept

If changing one price means editing the POS, then the QR menu, then the delivery listing, your menu has three owners. Copies kept by hand drift apart the first time someone forgets one of them. Bookings in a notebook and guest numbers in a manager's phone drift the same way.

So use a price change as the test. Enter the new price once. If it shows up on the guest menu, on the delivery listing and in next week's sales report, the system really holds the menu item. If someone has to type it into three screens, the menu still lives in three places.

The 30/30/30/10 rule as a scope check

The 30/30/30/10 rule is a rule of thumb for splitting revenue. Roughly 30% goes to food and drink, 30% to labor, 30% to everything else it takes to keep the doors open (rent, utilities, marketing, repairs), and about 10% is left as profit. Use it as a starting budget, not a target. A coffee bar and a steakhouse don't buy or staff the same way, and a real split can land well away from it.

Where the rule really helps is in choosing software, because each of its four numbers comes from a different record. Revenue comes from orders. Food cost needs what you bought, what you counted and a recipe for every dish, so a menu item with a price and no recipe can't tell you what the plate costs. Labor needs clocked hours and pay rates. Operating costs come from the invoices in your accounts.

A system that only holds front-of-house records can report revenue and none of the three cost lines. That can work, as long as you know it before you sign and you've decided which other system supplies food, labor and overheads. The stock counts behind food cost also give you the inventory turnover ratio, so keep both numbers in mind when you pick the system that holds them.

What a typical restaurant's software actually looks like

Ask what software a restaurant runs and the answer is often a stack, not one system. There's a POS at the counter. Delivery orders come in on the platforms' own tablets, bookings sit in a separate tool or a paper book, and the accountant works in another package. Somewhere in the middle there's a spreadsheet with recipe costs or the staff rota. We don't know of a public, dated count of which software most restaurants use, so we won't quote a market share here.

A stack isn't a problem in itself. The cost is at the joins, wherever someone reads a number off one screen and types it into another. Write down each join in your own setup and who re-keys the number there. That list is the start of your requirements.

Pricing a POS by the month, not by the sticker

The cheapest POS on a comparison page is the one with the lowest subscription line, and that line isn't the whole bill. Before you compare, add up what each system would charge you in a normal month:

• The subscription, for the number of locations and terminals you actually run.
• Payment processing, charged per transaction, so it grows with sales. A low subscription tied to one processor can end up costing more than a higher one that lets you choose.
• Hardware: terminals, card readers, kitchen printers, tablets. Some vendors sell it, some lease it, some let you bring your own.
• Integration fees for delivery, booking, accounting or a digital menu. Some are free, some are a monthly charge per connector.
• Add-ons such as extra users, extra locations or higher order limits, which are often sold separately.

Run that sum for every vendor on your shortlist, using one of your real months and your real order count. If you take payment at the table, read how QR payment works before deciding whether the POS or another tool handles it, because that decision changes the processing line.

Guest records: what a restaurant CRM needs to hold

A CRM can only work with the guest records that reach it, and plenty of guests leave none. A walk-in who pays cash leaves no name. So before comparing CRM tools, list the places where a guest's details can come in at all: an online order, a reservation, a feedback form, a loyalty sign-up, a promo code.

The record itself is short. Name and contact details, with consent to be contacted. Visits or order history. Booking notes like allergies, a preferred table or a birthday. Any feedback or reviews the guest left.

For a given restaurant, the right CRM is the one that sits where those details already come in. If you already send feedback forms, they're a cheap source of guest records, and which survey questions you send affects whether guests finish them.

The menu item needs the fullest definition

Of all the records, the menu item needs the fullest definition. A requirement that only says name and price gets you a system that can't tell a guest whether a dish contains nuts, can't take breakfast off at eleven and can't show which portion size sells. A complete item has a description and a photo, a price for each portion, modifiers like an extra shot or no onion, allergen and nutrition data, and the days and hours it can be ordered.

The menu item is also where front and back of house meet. The price sits in the menu or the POS. The recipe that sets its food cost tends to sit in a back-office system. If the two don't share the same item, matching what sold against what it cost turns into a weekly spreadsheet job for somebody. Ask the vendor about that link before you spend time on their menu screen.

Rules your staff already follow

A record is something that exists: an item, a table, a booking. A rule is what the system does when something happens. Your restaurant already runs on rules, and probably few of them are written down. They get explained to each new hire and remembered mid-service. Write each one on a single line: what happens, what the system does, who can override it.

Breakfast items can't be ordered after eleven, and the set lunch only shows at lunchtime. A delivery order under the minimum basket is refused, and the delivery time you promise is prep time plus travel time. Alcohol needs an age check. A promo code works for delivery but not dine-in, or only above a certain spend.

Then come the questions about who. Does the guest send the order from their phone, the waiter from a tablet, or both? Who can cancel it, and how far into the kitchen can it get before it can't be cancelled? Money has rules of its own: portion prices, cover and service charges, suggested tips, how a bill gets split. So do the awkward moments, like an item running out mid-service or a table that has paid and is still sitting there.

Some of these rules won't fit any software you look at. Keep them on a separate list. They stay with your staff, and they're the ones a new hire is most likely to get wrong.

Writing requirements from one real service

You don't need a template. Take a notebook through a full service, ideally one busy and one quiet, and note every time the same information is entered twice. An order read off a ticket and keyed into the till. A phone booking copied into the book. A price changed on the board but not in the app. Each one is a requirement you can defend, because you watched it happen.

Then follow a single order from the moment it's taken until it reaches the accounts, and count the places it passes through. If it's more than two or three, integration belongs near the top of your list.

Two things won't show up in the notebook. A digital ordering channel shortens the wait to place an order, but it doesn't make the kitchen cook any faster. If the kitchen can't keep up, the delay just moves from the table to the pass. And not every table wants to order from a phone. Large groups and some occasions still expect a waiter. Plan online ordering for your restaurant as a channel that runs alongside table service, not instead of it.

Shortlisting vendors

We make one of these systems, so we won't rank the others. Sort vendors by what they're built around instead. Back-office suites tend to start from inventory, purchasing and accounting. POS-centered systems start from the order and the payment. Guest-facing platforms start from the menu, the ordering channels, the website and reservations. Your notebook tells you which of the three your gaps fall into.

Take the three double-entry problems that came up most often and ask each vendor on the shortlist to solve them in a demo, on their screen, with your menu loaded. If the answer is a feature name, ask to see the screen.

Setting up in the right order

Setup has a fixed order, because each step reads from the one before it. The menu comes first, item by item with portions, modifiers, allergens and availability, and it tends to take longest. Then tables and areas, then channels and which menu shows on each, then the notebook rules moved into settings, then the connections to your POS, payment provider and printer. After the first full day of service, ask the system for that day's sales by item. If you have to export them and rebuild the day in a spreadsheet, the reporting requirement isn't met.

Generated content goes last, because it copies whatever is already in the system. In July 2026 we generated a test website for a bakery in the FineDine panel. Its Popular Items section showed a T-Bone Steak and a Filet Mignon from the sample menu, and because the venue details were empty, the location came out as a placeholder. Whatever our description said, those parts were taken from the menu and venue records.

FineDine covers front of house and revenue, not food, labor or overheads

FineDine covers the front-of-house rows and reporting. In Menu Manager, a menu item holds its description and photo, a price for each portion, modifiers, nutrition and allergen data, and the days and hours it's available, all in one record. The guest's QR menu and AI Website Builder both read from that record. If your menu already exists as a photo, PDF, Excel or CSV file, Menu Manager can build a menu from the upload, so the longest setup step becomes mostly checking and correcting what came through.

Tables sit in areas on a floor plan, each with its own QR code or one shared code. Tablets can run in a waiter's hand, fixed to the table or as a self-service kiosk. Several of the notebook rules have a setting of their own: minimum order, delivery time as prep plus travel, age verification for alcohol, tips, cover and service charges, and promo codes limited to one channel. Guest records, feedback forms and item reviews sit under Guests & Engagement.

Reporting comes in two layers. The standard reports cover summary, item, business and reservation figures. AI Reports (FineDine IQ) updates hourly, compares revenue, orders and average ticket with an earlier period, flags anomalies and suggests actions, for example items that are missing photos. Together they cover the revenue line of the 30/30/30/10 rule. POS, payment and printer connections are listed in the Marketplace, some free and some with a monthly fee, so check whether yours is there before you start.

FineDine has no inventory, purchasing, recipe costing, staff scheduling, payroll or accounting module. Staff accounts have roles that control who can do what, but hours aren't recorded. Food cost, labor and operating costs have to come from another system. The line to add to your requirements is how that system gets sales by item, whether from FineDine or from the POS you connect.