Skip to content
Sunbeam
Open menu

Technology for Restaurants and cafes

A guest should be able to see today's menu and send an order without the counter typing it again.

Direct answer

QR ordering is worth having when the table menu is a PDF, a third-party page the cafe cannot change, or a printed card that is wrong by Thursday. Sunbeam builds a menu the team can update, a QR code that opens it, and a ticket the kitchen or counter can work from. If a POS already does this well, the right work is the public menu and the gap around it.

Where the work breaks

The problems we expect to hear.

The menu the guest sees is not the menu the kitchen has

A PDF on the website, a different PDF behind the table QR, and a handwritten note for the dish that ran out. Guests order something the cafe cannot serve, and the counter spends the rush apologising for a file nobody updated.

Orders are written down and typed again

A guest tells the server, the server tells the pass, and someone keys it into the till. Each step is a chance to lose a modifier. A small cafe feels this most on the days it is too busy to fix mistakes politely.

Table booking and dine-in are separate chores

Reservations arrive by phone during service, which is the worst moment to take them. Aggregator orders, dine-in and takeaway then get reconciled at the end of the night from three different lists.

The website is a brochure that cannot answer a hungry person

Hours, location, the current menu and whether a table can be requested are the whole job of the site. A gallery with last year's menu sends people to a map app and a phone call.

What we would build

A first system sized to the actual work.

  1. 01

    A menu the cafe can change today

    Items, prices, a short note, and a way to mark something unavailable without deleting it. The website and the table QR read the same menu, so there is one place to correct it.

  2. 02

    QR ordering that produces a ticket

    The guest opens the code, chooses, and sends the order. The counter or the kitchen sees a ticket and accepts or adjusts it. Payment can stay at the counter or with the provider the cafe already uses. We do not become the cafe's bank.

  3. 03

    A pass view for the rush

    New, in the kitchen, ready, served. Sized to a single site or a small group, not to a chain's head office. The point is that the ticket exists once.

  4. 04

    A reservation request that does not interrupt service

    A request for a time, a party size and a phone number, if the cafe does not already have a reservation tool it likes. Confirmed bookings are visible before service, not in a personal phone.

How the system has to behave

Practical constraints, decided before the build.

  • A fast page on a phone, because that is where the menu is opened
  • A menu update that does not need a developer
  • A clear choice to keep the existing POS when it already matches service

Answers that sit behind this work

FAQ

Questions from Restaurants and cafes teams.

Can a cafe take QR orders without replacing its POS?

Often, yes. The QR flow can send a ticket the counter still enters, or it can connect where the POS allows an order in. We look at the till before recommending a second system of record.

How do guests pay?

Usually the way they pay today: at the counter, or through a payment provider the cafe already has. Building a new payment gateway is a different project and rarely the point of a menu.

Can we turn items off when they sell out?

Yes. That is the main reason to own the menu. An item can be hidden or marked unavailable without republishing a PDF.

Is this only for large restaurants?

A single cafe feels the PDF problem as much as a group does. The build stays small: one menu, one QR, one ticket view. Multi-branch reporting is a later step if the group actually needs it.

Not every operational issue needs custom software. See when Sunbeam is not the right fit, compare practical options in our decision guides, or .