Inside Dasvio's revenue centre engine: 7 design decisions
Separating dine-in, takeaway, delivery and bar revenue meant not making the cashier's job harder and not making the manager's report messier. Seven decisions that held that balance.
A revenue centre is a simple idea for accounting: separate where the money came from. In the field, every separation risks becoming one more tap on the cashier's screen. All seven decisions come out of that tension.
1. Derive the revenue centre from how the order opened
The cashier never answers "is this a delivery order?". The revenue centre is assigned from the channel the order opened on: from a table, it's dine-in; from a QR code, it's QR; from an aggregator, it's that platform.
2. Treat the bar as a prep point, not a channel
A bar item is sold at the table and also goes out for delivery. So we didn't make the bar a separate channel; we modelled it as a prep-point tag at product level. On the reporting side the two dimensions cross-tabulate.
- 3. An order can belong to exactly one revenue centre — multiple assignment made the report unreadable.
- 4. Revenue-centre changes aren't retroactive; corrections happen as void plus reopen.
- 5. Each revenue centre can have its own printer and KDS target.
- 6. Staff permissions can be restricted per revenue centre.
- 7. Reports open broken down by revenue centre by default — opt-out, not opt-in.
What the seventh decision cost
Defaulting reports to a breakdown meant a busier first screen, and it met resistance in internal testing. After it shipped, the time managers spent inside reports fell — because getting to the breakdown they wanted required no clicks.
