Skip to content
CAPPATERY
Sign up
Counter Ops

Everything between the first tray out of the oven and the last cup of the day.

A café day has a shape that table-service and delivery software were not drawn around. Stock expires by evening. The queue is the constraint. The same faces return four mornings out of five, and tomorrow's production has to be decided tonight.

Counter Ops is the five areas that shape covers, and they are built to feed each other - what sold sets what gets baked, and what gets baked sets who needs to be on shift.

Areas
Five
Screens to learn
One, per role
Counter hardware
Use what you have
Runs offline
Order entry, yes
The loop

Four movements, one after the other, every trading day.

This is the whole product in one sentence: count what is in the case, keep the line moving, project tomorrow from today, and catch what is falling behind before it becomes waste.

Counter Ops, live
08:14

Today's bake

Left / baked

  • Butter croissant18 / 24
  • Banana bread5 / 20
  • Almond danish11 / 16
  • Sourdough loaf9 / 12
  • Flat whiteOn tap

Counter queue

3waiting
~120s to serve

Watching the till for a returning face

Track / mid-morning

Butter croissant11 / 24
Almond danish4 / 16
Sourdough loaf7 / 12
Counts move with the till. No separate stocktake.

Forecast / tomorrow

Butter croissantbake 26
Banana breadbake 14
Cinnamon rollbake 18
A prep list to confirm, not an instruction to the oven.

Close / 17:40

Almond danish6 at risk
Banana bread3 at risk
Butter croissantclear
Flagged with time left to sell rather than discard.
The five areas

What each part of Counter Ops is responsible for.

01

Order & POS

Take the order in as few taps as the order deserves

Quick keys for the lines that carry the morning, modifiers that do not bury themselves in submenus, split and part payments, and a queue timer that shows you when the line is slipping rather than telling you afterwards.

  • Quick keys
  • Split payments
  • Queue timing
  • Receipt printing
02

Daily bake inventory

Perishable stock counted properly, for once

Each baked line carries a same-day quantity that only falls, a low threshold you set, and an aging point. When something is behind its normal pace you hear about it with hours to spare, not at close.

  • Live countdown
  • Low alerts
  • Aging flags
  • Discount prompts
03

Loyalty & regulars

The order they always place, already on screen

Repeat customers are matched at the till and their established order staged for confirmation. Rewards accrue against actual repeat behaviour instead of a punch card nobody remembers to stamp.

  • Usual order
  • Visit history
  • Rewards
  • Group-wide identity
04

Staff scheduling

Rosters built against the rush you will actually get

Shifts are planned on the same forecast that sets bake quantities, so cover matches demand instead of matching last month. Attendance and per-shift sales sit alongside the roster.

  • Forecast-led rosters
  • Attendance
  • Shift sales
  • Cover gaps
05

AI demand forecasting

Tomorrow, worked out line by line

Every baked item is projected on its own curve from its own history, the weekday, and comparable trading days. You get a prep list to confirm or override - never an automatic change to what goes in the oven.

  • Per-item numbers
  • Weekday patterns
  • Confidence shown
  • Prep list
Why a café-specific build

A general till can sell a croissant. It cannot reason about one.

Restaurant software is largely organised around a table: seat it, take a course order, hold the kitchen, turn the cover. Delivery software is organised around a rider and several marketplaces. Both are legitimate shapes. Neither describes a café.

At a counter the constraint is the queue, and the inventory is hostile - it exists for one day and then it is a loss. Recognition matters more than it does anywhere else, because the same twenty people account for a disproportionate share of a café's month.

So Counter Ops treats a same-day tray as a first-class object with a life span, treats the queue as the thing to optimise rather than cover turns, and treats a returning customer as something the system should already know.

CAPPATERY is deliberately narrow. It covers one operational shape, the café and bakery counter, because that day does not fit software built around table service or delivery dispatch. Cafés and bakeries got their own build rather than a configuration flag.

Common questions

Practical answers about running this on a real counter.

Do we have to adopt all five areas at once?
No. Most counters start with order entry and daily bake inventory, because those two produce the sales history everything else runs on. Loyalty recognition and forecasting become useful once there are a few weeks of that history to work from, and scheduling follows the forecast.
What happens to order entry if the internet drops?
Order taking and payment recording continue on the terminal and sync when the connection returns. Forecasting and cross-outlet views need connectivity, since they read from more than the one counter.
How long before the forecast is worth trusting?
Early forecasts lean on weekday patterns and are labelled as low confidence on screen. They firm up as the per-item history builds. We would rather show you a hedged number honestly than a confident one that is wrong.
Can staff override what the system suggests?
Always, everywhere. Suggested bake quantities are a prep list you confirm. A staged usual order is confirmed before it is charged. Nothing is committed on a prediction alone.

Start where it pays back fastest

Put your bake lines in and the rest of Counter Ops has something to work with.

Order entry and bake counting produce the history that forecasting, recognition and rostering all read from. That is the sensible first week.

Sign upTalk to us
  • Bake lines and quick keys mapped to how your case is actually laid out
  • Existing terminal and receipt printer kept where they are compatible
  • Forecasting switched on once there is history worth forecasting from