Why FORNEBU

Built in restaurants. Designed for restaurant operators.

FORNEBU was shaped around the realities of running restaurants — busy counters, changing demand, inventory movement, staffing decisions, kitchen execution and the need to understand the entire operation from one place.

Book a DemoExplore the Platform

Built in restaurants

Built in our restaurants. Designed for yours.

FORNEBU grew out of operating real restaurant businesses. Instead of designing software around how we thought restaurants worked, we began building around how our restaurants actually worked.

  1. Enterprise Technology
  2. Restaurant Founder & Operator
  3. Real Restaurant Operations
  4. Restaurant Technology
  5. FORNEBU
01 · Enterprise technology

Technology taught us how systems connect.

Before entering the restaurant business, founder Kanwal Kalra spent many years working in enterprise technology and large-scale systems — where the hard part is rarely a single application, but how everything is meant to fit together.

02 · Restaurant founder & operator

Restaurants changed the problem.

Operating restaurants introduced a different reality. Orders, kitchens, recipes, inventory, employees, schedules, hours, customers, reporting and multiple locations all have to work together every single day.

03 · Rolly Polly Cow + Pizza Tavola

The restaurants became the operating environment.

Rolly Polly Cow and later Pizza Tavola provide real restaurant operations in which FORNEBU can be developed around actual workflows, constraints and operational problems rather than hypothetical ones.

  1. Rolly Polly Cow + Pizza Tavola
  2. Real Restaurant Operations
  3. Real Workflows + Operational Problems
  4. FORNEBU
04 · FORNEBU

So we started building the system we wanted to operate.

FORNEBU is being built to connect the restaurant instead of adding another disconnected application beside it — the counter, the kitchen, stock, customers, the team and the numbers management reviews.

  • POS
  • Kitchen
  • Inventory
  • Loyalty
  • Workforce
  • Smart Schedule
  • Time
  • Knowledgebase
  • Reporting
  • Intelligence
The founder

Kanwal Kalra

Restaurant Founder & Operator

“Technology taught me how systems scale. Restaurants taught me what those systems need to solve.”

Kanwal's background spans enterprise technology and hands-on restaurant operations. He founded Rolly Polly Cow and later Pizza Tavola. FORNEBU brings those two experiences together: systems thinking applied to the everyday realities of running restaurants.

WHY THE NAME FORNEBU

A name that goes back to where my journey began.

The first time I left India to study at the University of Oslo in Oslo, Norway, I landed at Fornebu Airport. I still vividly remember that arrival — a new country, a new chapter and the beginning of a journey that would eventually take me through technology, entrepreneurship and restaurant operations.

Years later, when it came time to name the restaurant operating system I was building, I returned to that memory.

FORNEBU represents the beginning of one journey — and now, the beginning of another.

Kanwal Kalra

Restaurant Founder & Operator

FORNEBU Airport in Oslo, Norway — the inspiration behind the FORNEBU Restaurant Operating System name.

Why FORNEBU is broad

The restaurant is the system.

FORNEBU is not being built around the cash register. It is being built around the restaurant. A restaurant does not experience POS, inventory, workforce, kitchen, loyalty and reporting as separate businesses — they are parts of the same operation.

  • Orders affect kitchens.
  • Sales affect inventory.
  • Demand affects labour.
  • Employees affect service.
  • Customers affect growth.
  • Management needs to understand all of it together.

FORNEBU's objective is to connect them as one restaurant operating system.

One operating system

The restaurant should be connected before the software is.

A restaurant already operates as one business. The order affects the kitchen. The kitchen affects inventory. Sales affect labour. Customers build loyalty. Every shift becomes part of the numbers the owner eventually sees. FORNEBU is designed around those relationships rather than treating them as separate software products.

  1. 01Sell
  2. 02Serve
  3. 03Stock
  4. 04Grow
  5. 05Team
  6. 06Control

One operation. One connected data foundation.

Operator first

Software should follow the operation — not make the operation follow the software.

FORNEBU is shaped around what actually happens during a restaurant day: opening the register, serving guests, routing preparation, receiving inventory, managing availability, building schedules, clocking the team, reviewing exceptions and closing the business day.

01

At the counter

Fast ordering, customer identification, modifiers, payments and receipts without unnecessary steps.

02

During the shift

Kitchen execution, inventory movement, employee availability, time clock and operational communication remain connected to the same restaurant.

03

At the end of the day

Sales, labour, cash, inventory and exceptions become part of the same operational record the owner can review.

Connected by design

Enter it once. Let the operation carry it forward.

When a transaction happens, the rest of the restaurant should not need to recreate it. FORNEBU is designed so operational events can move through the system rather than being repeatedly entered, reconciled or exported between disconnected tools.

  1. 1

    Customer identified

  2. 2

    Order taken

  3. 3

    Kitchen routed

  4. 4

    Inventory affected

  5. 5

    Loyalty progressed

  6. 6

    Reporting updated

The transaction becomes part of the operation as it happens.

Beyond POS

The point of sale is the beginning of the data — not the end of the system.

FORNEBU connects the transaction to the operating decisions around it. That means the same restaurant data can support kitchen execution, stock movement, customer relationships, workforce planning and management reporting.

Less duplicate work

Operational information is captured where the work happens and reused across the system.

More context

Sales, products, customers, labour and locations can be understood together rather than as isolated reports.

Fewer disconnected workflows

Core restaurant operations share one foundation instead of requiring a separate tool for every problem.

Better operational visibility

Owners and managers can see what happened without manually assembling the story from multiple systems.

Staff around the business

Staff for the restaurant you're expecting — not just the week you're filling.

FORNEBU uses the restaurant's own historical demand in 30-minute intervals together with operating hours, labour requirements, employee availability, skills and proficiency to create a recommended schedule for manager review.

  1. 01Restaurant demand
  2. 02Required coverage
  3. 03Availability + skills
  4. 04Recommended schedule
  5. 05Manager review

The objective is not simply to fill shifts. It is to match labour to the operation while respecting who can work and what coverage the restaurant requires.

Explore FORNEBU Smart Schedule →

One location to many

Keep local operations local. Keep control in one place.

A restaurant group should not become harder to understand simply because another location or concept is added. FORNEBU is structured so products, employees, permissions, reporting and operational controls can remain appropriately scoped while management retains a connected view of the business.

Location control

Store-specific menus, availability, staff, inventory and operational settings.

Multi-brand structure

Different restaurant concepts can retain their own products and identity while sharing the operating platform.

Central visibility

Management can review the business across stores and brands without flattening the differences between them.

The FORNEBU approach

Built for the realities of restaurant operations. Intelligent where intelligence adds value.

FORNEBU is designed around operational usefulness: fewer unnecessary steps at the counter, clear preparation routing, accountable inventory movement, practical workforce controls and reporting that reflects what actually happened. Intelligence should support the operator's decision — not hide the operation behind a black box.

Operator reviewed

Important operational recommendations remain visible and reviewable.

Explainable

Managers should be able to understand why the system reached an operational recommendation.

Configurable

Different locations and restaurant concepts do not have to operate identically.

Accountable

Permissions, exceptions and important operational changes are recorded rather than assumed.

See what one connected restaurant operating system feels like.

Walk through FORNEBU using real restaurant workflows — from the counter and kitchen to inventory, workforce and management.

Book a DemoExplore the Platform