One scan. Infinite experiences. Vision, product & architecture — the whole story.
From the universal core, inward to a fully-explained hotel example.
What This Deck Covers
The whole product, in order.
01 The Vision & Why Now
02 The Universal Core
03 Accounts & Structure
04 Onboarding a Hotel
05 Configuration & Setup
06 QR & Dynamic Resolution
07 The Guest Experience
08 Order Authorization
09 The Staff / Ops Experience
10 Payments
11 Feedback · 2nd Use Case
12 Future Scope & Architecture
01 — The Vision
01 / 12
The Big Idea
A QR code isn't the product. It's the doorway.
Anyone can make a QR code for free. The value is everything behind it — the experience people land on, the power to change it anytime without reprinting, and the data on what they actually do.
Why it matters: the QR is a commodity; the experience, the changeability, and the intelligence are the defensible product. Inavo owns those, not the square.
01 — The Vision · Why Now
01 / 12
Why Now
Every physical space wants to go digital — without an app.
📱
No downloads
Guests won't install an app for a two-night stay. A scan works instantly.
🖨️
Print once
Dynamic codes let content change while the printed square stays put.
📊
Real data
Every scan, order & request becomes insight the business can act on.
🧩
One platform
Menus, service, feedback, payments — unified, not scattered.
The strategy: build for hotels first to prove the platform end-to-end; then extend the same engine to cafés, products, pets & beyond. Architect for all, build for one.
02 — The Universal Core
02 / 12
The Outer Foundation
One thick core that every industry shares.
⚙️
What lives in the core
The QR engine · accounts & organizations · users, roles & multi-tenancy · subscriptions & billing · scan analytics. It knows nothing about "hotels."
🧩
What sits on top
Industry products — hotels now, others later. Each its own layer, reusing the core, designed on its own terms.
Why this way: a thin core rebuilds accounts/billing per industry (wasteful); a rigid do-everything framework forces every industry into one mould (brittle). A thick core + separate products avoids both.
02 — The Universal Core
02 / 12
The Decoupled QR Engine
The QR engine stands on its own.
At the very base sits the QR engine — code generation, dynamic resolution, scan capture. It depends on nothing above it and is reached only through a clean API.
Why fully decoupled: so it can be shared or sold to external partners tomorrow — a standalone package now, a separate service the day there's a real external consumer, with zero rework.
🏨 Hotel product
☕ Future products
🌐 External partners (future)
↓ all call the same API ↓
⚙️ QR ENGINE · standalone
03 — Accounts & Structure
03 / 12
How a Business Is Organized
From one hotel to a hundred — one model.
Organization — the legal business · billing · isolation
Property — a hotel (one, or many)
Area — guest rooms · café · spa · bar
Room / Table — each with its own dynamic code
Why a hierarchy: a hotel isn't one flat space. A café inside a hotel has tables with their own menu — so "Area" sits between the property and its scannable points. A café is not a separate business.
Three cases, one structure
One business/one property · one business/many properties · one owner with several legal entities (separate billing, unified login).
03 — Accounts & Structure
03 / 12
People & Permissions
Who can do what, and where.
👤
Authority roles (fixed)
Owner · Billing Admin · Property Manager · Staff. A membership can hold several roles; access is the union. Guests have no account; Platform Admin sits separate.
🏷️
Departments (extensible)
Kitchen · Front-desk · Housekeeping now — laundry, plumbing, electrical, QC later. A staff member = Staff role + department + property scope.
The key idea: "what you can do" (role), "where" (scope) and "which queue" (department) are separate axes — so the model never explodes into dozens of bespoke roles as you grow.
04 — Onboarding
04 / 12
How a Hotel Gets Started
Sign-up to first property, in four steps.
01
Sign up
Create the login (the User).
02
Create business
The Organization is born; creator becomes Owner.
03
Add property
The first hotel, under the Organization.
04
Trial starts
Time-limited free trial to explore & set up.
Why a trial, not freemium-forever: a clock creates urgency to convert. Small customers feel none of the structure's complexity — it's just "set up your hotel."
05 — Configuration & Setup
05 / 12
Making the Property Operational
Guided to the first scan — then a flexible dashboard.
A
Areas & rooms
Define areas; add rooms/tables single or bulk.
B
Codes
Auto-bound, printable dynamic codes per point.
C
Menus
Per-area; new, copy, or share an existing one.
D
Modules
Food · Service · Emergency · Feedback toggles.
🎨 Branding
Logo, name, accent colour on the guest hub.
🕒 Hours
Per-area open/close so ordering reflects reality.
🧾 Tax & charges
GST & service charge shown correctly in the cart.
Why "guided then flexible": the magic moment is a working scan. Get them there fast, then let deeper config happen in any order.
06 — QR & Dynamic Resolution
06 / 12
How the Code Works
The code never changes. What it shows always can.
A printed code holds only a stable pointer. On scan, the resolver decides what to show — so menus, prices and content update live, without reprinting.
Practical wins: damaged sticker? reprint the same code. Leaked code? issue a new one. Renovated room? re-point it. The printed square stays; the destination is yours to control.
📷 Guest scans the code
↓
⚙️ Resolver: "what does this point to now?"
↓
🍽️ Serves the room's current experience
↓
📊 Scan recorded (async, never blocks)
07 — The Guest Experience
07 / 12
Scan → Hub
The hotel comes to the guest.
No app, no login. The code already knows the room. A branded hub shows only the modules the property enabled.
Guest model: a sessioned anonymous visitor — persistent for the stay, with order history & multiple concurrent orders. Optional name; no phone in v1 (OTP login comes later).
Welcome to The Grand
Room 304
🍽️
Order Food & Beverage
🛎️
Request Service
🚨
Emergency
⭐
Leave Feedback
07 — The Guest Experience
07 / 12
In-room · scan to begin
Food & Beverage · The Flagship Flow
A Swiggy-class experience, in the room.
BROWSE
Rich menu
Photos, veg/non-veg, prices, per-area menus.
CART
Customise & place
Modifiers, instructions; tax shown upfront.
TRACK
Live status
Kitchen to door, in real time.
Received→Accepted→Preparing→On the way→Delivered
08 — Order Authorization
08 / 12
The Trust Layer
Only real guests, really there, can order.
⏱️
Session
Short-lived; stale links expire.
📍
Geofence
Far-away orders flagged — never hard-blocks a denied prompt.
🛏️
Active-stay
Room "armed" only when a guest is checked in.
👤
Staff confirm
The human backstop; orders route to the real room.
Why layered: no single check is airtight (a photo of a code can be scanned anywhere). Together — and because orders only ever reach the real room — misuse is reduced and capped. Active-stay is the strong fix; the rest are guards.
09 — The Staff / Ops Experience
09 / 12
The Fulfillment Side
Where orders never get missed.
Live department queues — Kitchen, Front-desk, Housekeeping — on any screen or phone. Loud, clear, reliable.
Reliability backstop: orders persist in the database, so a dropped connection never loses an order — the queue reconciles on reconnect. In hospitality, a missed order is lost trust.
🔔 Never-miss alerts
Audible + visual, repeating until acknowledged; unclaimed work escalates to the manager.
✋ Claim & fulfil
Anyone in the department picks up work; status flows live back to the guest.
⚡ On-the-fly control
Mark items sold-out instantly · accept/reject with reason · auto-accept toggle per property.
10 — Payments
10 / 12
How Money Moves
Two options — and Inavo never holds the money.
🧾
Add to bill / pay at checkout
Phase 1. No gateway needed — the order goes on the room folio, settled the hotel's usual way. Works day one.
💳
Pay now
Phase 2. Appears only if the hotel connects their own gateway. Money flows hotel-direct.
Why this stance: if Inavo routed funds it would become a regulated payment aggregator — huge legal/operational weight. Hotels connecting their own gateway keeps Inavo a software platform. The order model already carries payment-mode & status, so Phase 2 is additive.
11 — Feedback · Use Case 02
11 / 12
The Second Use Case
Catch the problem while the guest is still in the room.
A one-tap rating and comment, routed privately to management in real time — resolve unhappy guests on-site, nudge happy ones toward public reviews.
Why it's more than a feature: feedback lives close to the core, so the same engine serves a café table, a product, or any future industry — proof the platform model pays off.
⭐
One-tap
Fast, no login.
🔒
Private
To management, not the internet.
⚡
Real-time
Act before checkout.
📈
Trends
Patterns by room & time.
12 — Future Scope
12 / 12
The Expansion Map
One core. Endless verticals.
🏨
Hotels
Live first
☕
Cafés
Table ordering
🍾
Products
Authenticity, reorder
🐾
Pet Tags
Lost-pet, medical
🏠
Real Estate
Listings, tours
🔧
Assets
Manuals, upkeep
🎟️
Events
Badges
➕
Anywhere
Wherever possible
How a new industry is added: define its entity type and its modules; the core (accounts, billing, QR, analytics) is untouched. Reuse a similar product's patterns, or build fresh when truly different.
12 — Future Scope · Spotlight
12 / 12
Packaged goods · scan to verify
Future Use Case · Products
A code on every bottle.
Scan to verify authenticity, learn how to use it, register a warranty, or reorder in one tap — and the brand sees exactly where and when its product gets scanned.
Same core, new pack: millions of codes, claim-on-scan, scan-location intelligence — all on the engine the hotel product already proved.
12 — How It's Built
12 / 12
The Architecture, In Plain Terms
Four layers, each with one job.
04
Experience
The industry products — hotels first. What guests & staff use.
03
Business Intelligence
Each business's own analytics — seen only by them, inside their walls.
02
Foundation
Accounts, roles, multi-tenancy & billing — the substrate.
Dependencies point downward only. Thousands of businesses on one system, walled by tenant (with an escape hatch to isolate a big client). And two intelligences — business (per-tenant) vs platform (Inavo-only, cross-tenant, audited).
12 — How It's Built · Principles
12 / 12
The Guiding Principles
Architect for all. Build for one. Scale additively, never destructively.
🧱
Boring & proven
Mainstream, type-safe tech any engineer — or AI — reads instantly. Clarity over cleverness.
🧩
Clean boundaries
The pieces with real reasons to be separate, are. New industries plug in; no rebuilds.
📈
Staged growth
Start simple; add replicas, caching & dedicated services only when real load calls.
Inavo · The Complete Picture
Inavo
Wherever a physical thing meets a digital need — we are the bridge.