Nest.IQ — Financial Framework & Model

A framework, not a forecast. May 2026 · Audience: investors and JV partners (Embassy lead).

This document is a driver-based model skeleton. Every cell is one of two things: a sourced benchmark range (cited with Brief-D financial source IDs [Sn], all defined in Source definitions below and in the TAM/SAM/SOM report §8), or an ⟨INPUT⟩ the founder must supply. All arithmetic shown is ILLUSTRATIVE — it demonstrates the formula and order of magnitude using sourced inputs, not a prediction. No raise size, valuation, capital amount, or JV split is asserted anywhere. Where the canon already published illustrative figures (§7), they are reused unchanged so every Nest.IQ deliverable agrees.

0. Principles (read before any number)

1. No assumptions. Per the Strategy Canon Hard Rule #1, every figure is sourced or flagged ⟨INPUT⟩. We never invent investor amounts, raise size, capital, costs, or a JV split.
2. Ranges + confidence, not false precision. India has no public serviced-apartment-only operating dataset [Source 7]; the deepest India primary data is for branded hotels (Hotelivate, Horwath HTL), used as a flagged proxy because Hotelivate states branded serviced apartments "incurred development expenses similar to that of the Upscale segment" [S1].
3. Three layers of certainty: (a) sourced market structure (HIGH), (b) sourced operating benchmark ranges (mostly HIGH at property/gross level), (c) the venture's own decisions (⟨INPUT⟩, unknown until set).
4. Property-level vs corporate. Almost every margin benchmark below is property-level / gross. Corporate G&A must be deducted separately as an explicit ⟨INPUT⟩ — do not read property EBITDA as enterprise EBITDA.
5. JV lens on capital. In a developer JV, land + building + construction capex sit with the developer; Nest.IQ contributes brand + enterprise demand + operations + tech. This materially changes the capital base and ROCE — see §6.

1. Input Register — the ~12 cells the founder must set

The model runs on these inputs. Each row gives a sourced reference range as a starting anchor and a blank your value cell. Until these are filled, the model produces illustrative output only.

The same register appears in the TAM/SAM/SOM report §6 and Brief D's "Inputs the User Must Supply." Filling these twelve cells is what converts this framework into a forecast.

2. Single-property (pilot) model — driver-based skeleton

This is the engine that every property and the portfolio inherit. The pilot is the canon's Phase 1: Bengaluru, 50–80 keys, near ORR / Embassy Tech Village / Whitefield. Capex is borne by the developer in the JV — Nest.IQ's pilot P&L is an operating statement, not a development pro forma.

2.1 The formula (transparent driver chain)

Keys                          ⟨INPUT⟩  (pilot 50–80)
  × Occupancy %               ⟨INPUT⟩  (sourced 72% base → 78–82% stabilized)
  × ADR (₹/night)             ⟨INPUT⟩  (sourced ₹8,500 blended; city-specific)
  × 365
  = Room revenue             ── the core line
  + Ancillary (laundry/F&B/transfers/parking)   = Room rev × ancillary %  ⟨INPUT⟩
  + Cross-sell (relocation/immigration/destination/concierge — IKAN)  ⟨INPUT attach rate⟩
  = Total property revenue
  − Operating cost ratios (payroll, utilities, FF&E reserve, mktg, R&M…)  ⟨INPUT⟩
  = Property GOP / EBITDA   (sourced range 28–40% net; pre-corporate G&A)
  × Stabilization ramp factor (months → stabilized)  ⟨INPUT 18–24 base⟩
  − JV economic split to developer (fee or rev/profit-share)  ⟨INPUT⟩
  = Nest.IQ share of property economics

RevPAR = Occupancy × ADR is the single most useful derived metric (illustrative: 0.72 × ₹8,500 = ₹6,120 RevPAR).

2.2 Pilot skeleton with sourced inputs + ILLUSTRATIVE arithmetic

Reading guide: the only firmly-sourced pilot output is the room-revenue band (~US$1.3–2.1M) — it uses sourced ADR/occupancy and the canon's key count. Everything below room revenue (ancillary %, cross-sell attach, exact opex, the JV split) is ⟨INPUT⟩; the EBITDA figures shown are illustrative consequences of choosing a 30–40% margin, not a claim.

3. Portfolio / scale view — across the three roadmap phases

Built bottom-up from keys delivered (canon §8 roadmap), not top-down from SAM. Formula identical to §2: annual room revenue = keys × occupancy × ADR × 365. FX ₹85, ADR ₹8,500, occ 72% base — all ⟨INPUT⟩; figures reused verbatim from the canon §7 / TAM-SAM-SOM §4 so all deliverables agree.

Arithmetic check (illustrative): 1,500 × 0.72 × ₹8,500 × 365 = ₹335cr ÷ 85 ÷ 1e6 = US$39.4M. Verified.

These are illustrative scale checks, not forecasts. They assume one blended ADR, flat occupancy, no stabilization ramp, no per-city mix, no ancillary/cross-sell uplift, and no JV-split deduction — each is an Input Register cell. Real portfolio revenue will differ once §1 is populated. Room revenue is the floor; ancillary + IKAN cross-sell sit on top (⟨INPUT⟩), JV split comes off the bottom (⟨INPUT⟩).

4. Valuation framework — comps → defensible base, narrative ceiling

A range with logic, not a target. Multiples are sourced; the conclusion mirrors the canon §7 and the two reports' pressure-tests.

4.1 Comparable multiples (sourced)

4.2 The valuation logic (illustrative, mid-portfolio)

At ~1,750 keys (canon's Phase-3 mid), illustrative room revenue ≈ US$46–51M (§3). At a 30–40% property EBITDA margin [S5][S3] that is ~US$14–20M EBITDA.

• Hospitality multiple (12–15×): US$14–20M × 12–15× → ~US$168–300M → the defensible base of US$150–300M.
• US$500M ceiling requires either (a) a proptech/SaaS multiple (6–10× revenue, or 25–30× EBITDA OYO-style [S7][S15]) applied to the tech/cross-sell layer, or (b) real-estate equity participation in the JV assets. Narratively achievable (OYO, Stanza precedent) but not supported by Nest.IQ actuals today.

Verdict (canon §7): defensible base US$150–300M (hospitality multiple); US$500M is a venture/strategic ceiling, not a promise — gated on the tech-premium thesis (⟨INPUT #9⟩) and/or captured real-estate equity (⟨INPUT #2⟩). Confidence: Medium.

5. Capital & working-capital framework

No raise number is stated — it is ⟨INPUT #12⟩. What we can do honestly is name the drivers of the capital need and the favourable working-capital traits that make this model less capital-hungry than transient hospitality.

5.1 What drives the capital need

5.2 The favourable working-capital traits (the model's edge)

1. Deposits as float. Commercial security deposits up to 6 months' rent (New Rent Law 2025) [S16] — from corporate tenants, a source of float, not a use of cash. Policy is ⟨INPUT #11⟩.
2. Contracted, recurring billing. Enterprise contracts shorten DSO vs OTA-dependent hotels and avoid the 15–30% OTA/CAC drag of hospitality-led peers (canon §3). Captive IKAN demand fills homes before they open.
3. Demand precedes doors. Pre-secured enterprise occupancy (canon §8) compresses the ramp and de-risks the receivables build.

Net: corporate-housing WC is structurally favourable vs transient hotels [S16] — large refundable deposits offset the enterprise-receivables drag. Payback/return context (owned, for sizing only): India hotel ROI ~10–15%, payback 7–10 yrs [S1]; the JV's land-light structure (⟨INPUT #2⟩) is what can bend ROCE above the owned-hotel norm.

6. Sensitivity — what moves Nest.IQ's take

The decision-relevant metric is not gross room revenue — it is Nest.IQ's own take: property economics × the share Nest.IQ retains. This section flexes that, in three steps: (6.1) the one-lever revenue swing; (6.2) the two-variable grid on Nest.IQ's take; (6.3) a ranked-driver view of which of the twelve inputs move the outcome most.

6.1 Single-lever revenue swing (the top line)

Illustrative, single 80-key pilot, ADR ₹8,500, base occupancy 72% → base room revenue ₹17.9cr. Each lever moved independently:

Room revenue is linear in ADR and near-linear in occupancy; because opex is substantially fixed, property EBITDA is more sensitive than revenue. But revenue is only the input to what Nest.IQ actually earns — for which two levers must move together.

6.2 Two-variable grid — Nest.IQ's take (stabilized occupancy × economic split)

This is the sensitivity the model says matters most, and the one a single-lever table cannot show: Nest.IQ's take is the product of two independent inputs — stabilized occupancy (which sets property EBITDA) and the negotiated economic split (which sets Nest.IQ's share of it). The formula:

Nest.IQ take  =  keys × occupancy × ADR × 365            (room revenue)
              × property EBITDA margin   ⟨INPUT #8⟩       → property EBITDA
              × Nest.IQ effective economic share ⟨INPUT #6⟩ → Nest.IQ take

The grid below holds 80 keys, ADR ₹8,500, and an illustrative 35% property-EBITDA margin (mid of the sourced 28–40% band [S3][S5][S9][S10]), then flexes stabilized occupancy (rows) against Nest.IQ's effective economic share of property EBITDA (columns). The "effective share" is a single ⟨INPUT⟩ proxy that collapses the real fee-plus-incentive or revenue-share structure (⟨INPUT #6⟩) into one retained-take rate; the four column values are illustrative reference points, not a quoted fee schedule. Every interior cell is ILLUSTRATIVE — Nest.IQ take in ₹cr (~US$k at ₹85).

Read the grid. Moving down a column (occupancy 67%→82%) lifts Nest.IQ's take ~22%; moving across a row (effective share 8%→20%) lifts it 2.5×. The economic split dominates the occupancy lever for Nest.IQ's own economics — which is why ⟨INPUT #6⟩ is the single highest-leverage cell in the entire register, and why the JV negotiation, not the occupancy ramp, is the value fulcrum at pilot scale. (Occupancy compounds far more once it drives the portfolio key count in §3; here it is held at a single property.) These cells are per-property and per-annum at stabilization; they are not a forecast, and they ignore ancillary, cross-sell, and corporate G&A — all ⟨INPUT⟩.

6.3 Ranked drivers — which of the twelve inputs move the outcome most

A qualitative "tornado" ordering of the Input Register (§1) by leverage on Nest.IQ's take. Bar order is the signal; bar length is a relative, illustrative weight — no magnitude is asserted (the model has no populated inputs yet). It answers "where does negotiating energy and diligence pay off most?"

Read the ranking. ■ The top three — JV split, occupancy, ADR — are the direct multipliers of Nest.IQ's take and deserve the most negotiating and diligence energy. ■ Margin, cross-sell attach, and the ramp shape the conversion of revenue to take over time. ■ The tech-premium share, land treatment, working-capital terms, and capex/FX matter for valuation and capital structure (§4, §5) more than for property-level take — capex/key ranks last precisely because it is developer-borne in the JV and FX is a unit conversion, not a driver. The order, not the bar length, is the takeaway; populating §1 replaces this qualitative ranking with a quantified one.

Bengaluru's supply-heavy 64.8% market occupancy [S3] is the key downside watch-item for the pilot (it pulls the grid toward its top-left); pre-let enterprise contracts are the mitigant.

7. How to use this model

1. Fill the Input Register (§1). Twelve cells. Until then, output is illustrative only.
2. Run the pilot engine (§2) with your Bengaluru ⟨INPUT⟩s → property P&L and Nest.IQ share.
3. Replicate across phases (§3) with per-city ADR/occupancy/capex.
4. Apply the valuation logic (§4) once an EBITDA base exists; decide the tech-premium thesis (⟨INPUT #9⟩).
5. Size capital (§5) from pre-opening + WC + central G&A; net the deposit float; then set the raise (⟨INPUT #12⟩).
6. Stress with §6 on occupancy, ADR, and the JV split.

Honesty footer. Sourced ranges carry Brief-D financial source IDs ([S1]–[S16]), whose master registry is the TAM/SAM/SOM report §8 Sources; every ID used in this document is also defined in the block below. Illustrative arithmetic is labelled as such and reuses the canon's published figures. No raise size, valuation, capital amount, or JV split is asserted. This is a framework to be populated — not a forecast.

Source definitions (citations used here)

Every [Sn] ID appearing in this document resolves below. The financial-benchmark registry (Brief D) is maintained in the TAM/SAM/SOM report §8; that registry numbers S1, S3, S5, S7–S12, S15, S16 but does not separately list S2, S13, S14, so those three are defined here in full against real, dated, public sources to ensure no citation dangles.