Same platform. Different priorities by venue type.
Cibus runs the same connected surfaces in every restaurant. What changes is which surface carries the shift, what the kitchen needs from it, and where the next order comes from.
- Order sent to kitchenPOS · table status
- Online order receivedStorefront · new
- Payment receivedPayment status · recorded
- Campaign draft readyReach · review
Why the setup differs even though the platform does not.
Every Cibus restaurant runs on the same operating layer: one menu, one order flow, one payment and receipt trail, one management workspace. Venue type does not change what is available — it changes what matters first. A café's constraint is throughput at a counter with drinks-heavy modifiers. A fine-dining room's is course sequencing and staying out of the guest's way. A takeaway's is a mixed queue arriving from several channels at once. A group's is keeping several restaurants comparable. The seven pages below start from those differences rather than from a feature list.
Seven starting points, one operating layer.
Each entry says who the page is written for and what genuinely changes for that venue type. Follow a link for the workflow, the shift story and the venue-specific FAQ.
Three venue types, five decisions.
The clearest way to see what venue type actually changes is to put three of them side by side against the decisions that shape a rollout. Nothing here is a different product — it is the same platform, prioritised differently.
| Decision | Café & bakery | Casual dining | Multi-location group |
|---|---|---|---|
| Where the order starts | At the counter, in a queue that has to keep moving. | At the table, split between a server's device and the diners' own phones. | In several places at once; every site needs the same order model. |
| What the kitchen needs | Drink modifiers landing cleanly on the bar station, not as notes. | Station routing plus an expediter who can sequence a whole table. | The same station model configured per site so the pass behaves consistently. |
| What payment looks like | Fast counter settlement; receipts issued digitally or printed. | Splits by item, by share or by method against one order. | The same drawer everywhere, reconciled per restaurant and reviewable together. |
| Where the next order comes from | Regulars returning — Storefront pickup and consent-aware Reach segments. | Visit context giving a reason to come back rather than a generic list. | Group leverage: Storefront and Reach configured per site, not a tool per venue. |
| The reporting question | Which items sell in which part of the day? | How service, kitchen and payment timing interact on a busy night. | Is the same night comparable across every restaurant in the group? |
Four questions that settle it faster than a feature list.
If more than one page above looks right, these are the questions a discovery conversation would ask anyway.
- 1Where does the order actually start today — a counter, a table, a phone in the diner's hand, or a marketplace you would rather not keep renewing?
- 2What breaks first at peak: the queue at the till, the sequence on the pass, or the bill at the end of the table?
- 3Where is the next order coming from — repeat visits, an ordering channel you own, delivery you run yourself, or another site?
- 4Who must be prevented from doing what, and does that answer change per restaurant?
Three ways into the same platform.
Solutions answer what a venue type should switch on first. The product pages answer what each surface does. The platform pages answer how they stay connected.
Choosing between venue types.
Is the product different for each venue type?
No. Every venue type runs the same platform and the same product range. What differs is which products are configured first, how the floor and kitchen are set up, and which growth surfaces are switched on.
We are a café that also delivers. Which page applies?
Both. These pages are entry points, not packages. Start with the one that matches how most of your orders arrive today, then add the surfaces the other channel needs. The actual configuration is settled in discovery.
Can a single site move to the multi-location model later?
Yes. Cibus supports location-specific settings with group-level oversight and role-based access for group and location teams, so a second restaurant is a configuration step rather than a second system.
Do we have to use QR ordering if we run table service?
No. QR Order & Pay is optional. The casual-dining setup assumes it because it removes ordering trips, but a server-only floor uses the same table, order and payment records.
We are a partner rather than a restaurant. Where do we start?
The Sales Partners page. Partner relationships are reviewed and agreed commercially before any onboarding activity, and Sales Agent Portal access is scoped to the restaurants assigned to that partner.
What does discussing fit actually involve?
A discovery conversation about how orders arrive, how the kitchen is organised, which payment methods your market needs, how many restaurants are in scope and what hardware already exists. It also sets the commercial shape, because Cibus is quoted after discovery rather than from a price list.
Tell us how your restaurant actually runs.
Discovery starts from your service model, your kitchen, your channels and your market — not from a package chosen off a page.