# 00 — Internal Context Intake

**Step:** 0 (human, blocking)
**Owner:** Head of Product
**Status:** ⚠️ **AWAITING HUMAN INPUT** — all fields `UNKNOWN` as of 2026-07-26
**Rule:** No internal number in this file may be invented. Every `UNKNOWN` carries an impact note stating how the missing value changes the recommendation, and is mirrored into `99-open-questions.md`.

---

## How to use this file

Replace each `UNKNOWN` with a value, a band (e.g. "800–1,200/mo"), or `N/A — reason`. A band is acceptable and useful; a guess presented as a fact is not. If a field is genuinely unknowable today, leave it `UNKNOWN` and the downstream sizing switches to a **break-even threshold** instead of a currency forecast (per plan §7.4).

**Priority order if you only have time for some:** `{{AI_INVENTORY}}` → `{{SKU_ROADMAP}}` + `{{GROWTH_PLAN}}` → `{{SCALE}}` → `{{COST_BASE}}` → `{{PASS_ECON}}`. The first two are load-bearing for the entire register.

---

## A. CURRENT STATE (D0)

### `{{MODEL_TYPE}}` — Business model
**Value:** `UNKNOWN`
**Asked for:** marketplace / reseller / merchant-of-record / hybrid. Who holds the customer contract, who holds inventory risk, who is the merchant of record for the USD charge.
**Impact if missing:** Determines whether "GMV lift" and "take-rate expansion" are even distinct mechanisms for SatuSatu. A merchant-of-record model puts refund/chargeback/FX loss on SatuSatu's P&L and makes leakage-reduction opportunities (mechanism *e*) materially more valuable; a pure agency model makes them nearly worthless. Also sets the legal shape of D2/D3 net-rate contracts.

### `{{MARGIN}}` — Take rate / gross margin band
**Value:** ✅ **ANSWERED 2026-07-26 — "very thin at the moment, relying on the third party nett price."**

**Interpretation:** SatuSatu is largely **reselling on third-party net rates**, so margin is the spread over a net price it does not set. Consistent with the T&C position (reseller/marketplace, not principal) and with the GlobalTix-sourced branded inventory observed in the catalog.

⚠️ **Still needed for sizing:** a numeric band, and — critically — **split by supply source**, because the two pools almost certainly have very different margins:
- **(a) Aggregator/feed-sourced** (GlobalTix: USS, Singapore Oceanarium, River Wonders, Waterbom, GWK, Taman Safari) — thin, set by someone else
- **(b) Direct-contracted long-tail Balinese** (ATV, jeep, snorkel, spa, transfer, temple/dance, car charter) — presumably materially better
- **(c) Bali All-Access Pass** — bundle economics plus breakage, different again

**Why the split matters more than the blended number** — this is the highest-consequence finding of Step 0:
1. **It sets the AI feasibility screen.** Thin margin means inference cost per booking is measured against a small denominator. Many AI opportunities will simply fail the Step 5a cost test **on pool (a)** while passing comfortably on (b) and (c). Without the split, we would wrongly kill or wrongly approve across the board.
2. **It may break D3 on aggregated inventory.** A reseller spread has to come out of the margin. If pool (a) is already thin, **there is little or nothing left to give a reseller** — so D3 economics likely only work on pool (b).
3. **It converges with §6(b) of `00-scope.md`.** The only *exclusive* inventory (direct-contracted long-tail, unreachable via Bókun/GlobalTix) is probably also the only *high-margin* inventory. **Exclusivity and margin point at the same asset.** That is a strong strategic signal and it should drive sequencing.

### `{{SCALE}}` — Monthly orders, GMV band, MAU, live SKU count, active suppliers
**Value:** `UNKNOWN`
**Asked for:** each as a band is fine.
**Impact if missing:** Determines whether any D0 opportunity clears a materiality floor. Public catalog sold-counts (plan §1, tier A-observed) bound the order of magnitude only and are explicitly `[INFERENCE]`. If real monthly order volume is in the low hundreds, most percentage-based ROI claims are noise on a base too small to fund an engineer — which is exactly the Step 5c kill test.

### `{{PASS_ECON}}` — Bali All-Access Pass economics
**Value:** `UNKNOWN`
**Asked for:** units sold to date, attractions actually consumed per pass, breakage %, concierge minutes per pass, supplier settlement basis (pay-per-redemption vs fixed net rate vs revenue share).
**Impact if missing:** The Pass is the differentiated product and the concierge is its cost driver. Breakage % *is* the Pass margin. Concierge minutes per pass is the driver metric for the highest-value D0 opportunity in the plan's own worked example (OPP-04). Without these, OPP-04 and every concierge-automation row size against nothing.
**Note:** Pass launched ~May 2026 — approximately 2 months of data. Per risk §1.3(5), these numbers are probably **not yet stable**. State the observation window alongside the values.

### `{{COST_BASE}}` — Cost structure
**Value:** `UNKNOWN`
**Asked for:** CS + concierge headcount and fully-loaded cost; tickets/month; content-ops headcount; supplier onboarding cost and days-to-live; refund/no-show leakage %.
**Impact if missing:** Cost-to-serve reduction (mechanism *d*) is likely to be the largest and most credible opportunity class for a business at SatuSatu's scale, because it sizes against a cost that exists today rather than a revenue that doesn't. Every row in that class needs this. Fully-loaded cost per concierge FTE is the single most reused number in the register.

---

## B. TARGET STATE (D1 / D2 / D3) — drives every `TARGET`-basis sizing

### `{{SKU_ROADMAP}}` ⭐ **HIGHEST PRIORITY**
**Value:** `UNKNOWN`
**Asked for:** live SKUs today → target SKU count and by when; which destinations and categories; curated vs bulk split.
**Impact if missing:** Every D1 opportunity is sized against an imaginary denominator. Per plan §7.4 the fallback is mandatory and non-negotiable: express D1 impact as *"break-even at N ingested SKUs, where N = fixed build cost ÷ margin per SKU per year"* and state N. A threshold is honest; an invented forecast is not. Also decides whether the curation-vs-completeness tension (risk §1.3(2)) is a 2026 problem or a 2027 one.

### `{{FILL_STRATEGY}}`
**Value:** ✅ **ANSWERED 2026-07-26 — BOTH, and distribution-in is already live.**
- **Aggregator feed: GlobalTix** — currently ingesting
- **Manual onboarding** of offline tour operators and agents
- **Actively seeking a second aggregator** of GlobalTix's type

**This confirms the `[INFERENCE]` in `00-scope.md` §2.1** (drawn from Universal Studios Singapore displaying "99k+ sold" — inherited feed values, not SatuSatu transactions). Three consequences, all already anticipated in the scope doc:

1. **Spine stage 3 is retagged `D0 D1` — a live workstream, not a hypothetical.** Amendment A in `00-scope.md` §3 is **confirmed**, not contingent.
2. **The mapping / dedup / taxonomy-normalisation / quality-gate cluster sizes on `CURRENT` basis**, not TARGET. This pulls an entire opportunity class out of the plan's two-clock trap (risk §1.3(1)) — these rows can be sized against inventory that exists.
3. **A second aggregator makes cross-supplier deduplication a near-term requirement, not a scale problem.** With one feed there is no overlap to resolve. With two, **the same attraction will arrive twice with different names, images, pricing and cancellation terms** — and the first duplicate pair reaching the storefront is a visible quality failure. Step 4b should treat dedup as a **prerequisite to onboarding aggregator #2**, and Step 6 should sequence it that way.

⚠️ **GlobalTix's role must be re-cut across the research.** It is no longer "most likely partner *or* competitor" (plan §4 Group 3) — **it is the incumbent supplier**. It also holds the **Borobudur mandate from InJourney**, an Indonesian SOE (2025-10-07/08, Tier A), and carries Waterbom Bali, GWK and Taman Safari. That makes it simultaneously: current supplier, gatekeeper to major Indonesian attractions, and a direct competitor to D3. **Concentration risk on a single feed partner is now a live question** — see `99-open-questions.md`.

### `{{D2_PLAN}}` — Partner dashboard
**Value:** `UNKNOWN`
**Asked for:** target partner segments (agents / DMCs / hotels / corporate), target partner count, expected GMV per partner, launch date.
**Impact if missing:** Cannot meet the plan's §5 coverage requirement of ≥3 credible D2 candidates with any sizing basis. Also gates the hedge question in risk §1.3(7): D2 is the stated hedge against inbound-arrival dependency, and whether it actually hedges depends entirely on whether the target partners are domestic or foreign.

### `{{D3_PLAN}}` — Partner API / reseller
**Value:** `UNKNOWN`
**Asked for:** target integrator profile, expected volume, pricing model (net rate / commission / SaaS fee), launch date, current build status.
**Impact if missing:** D3's viability turns on integrator profile more than on volume. Selling to a channel manager, to individual tour operators, or to a foreign OTA are three different products with three different cost structures. "Build status" also matters defensively — if an API already exists in some form, Step 5c's "is this already live?" kill test needs it.

### `{{B2B_PRICING}}`
**Value:** ✅ **ANSWERED 2026-07-26 — TIER BY SUPPLY SOURCE.**

| Pool | Source | Margin | B2B offer | Rationale |
|---|---|---|---|---|
| **A** | Aggregator-sourced (GlobalTix, + a planned second aggregator) | Thin, set by a third party | **Parity with D2C, or withheld from B2B** | No spread left to give a reseller — and the partner can reach this inventory through GlobalTix directly anyway. Subsidising a partner to resell non-exclusive inventory is negative-value. |
| **B** | **Direct-contracted Balinese long-tail** (ATV, jeep, snorkel, spa, transfer, temple/dance, car charter) | Materially better *(band still to confirm)* | **Real net rate, tiered by volume** | The only inventory that is **both exclusive and high-margin**. A partner cannot get it elsewhere. ⚠️ **Blocked on real-time availability — spine stage 5.** |
| **C** | Bali All-Access Pass | Bundle + breakage | **Fixed allocation, no discounting** | Protects the differentiated product and its float economics from channel erosion. |

> **→ D2/D3 is built on Pool B. Pool A is catalog filler for coverage, not a B2B product.**

**This resolves risk §1.3(3)** and gives Step 5c a stated policy to test against rather than a worst case to assume. Three things follow:

1. **Channel conflict is structurally avoided rather than managed.** Because the pools are disjoint on exclusivity, D2/D3 and D2C are not competing for the same margin. That is a stronger position than rate-parity rules, which cap D2C margin to protect partners.
2. 🔴 **It sharpens the §6(b) crux in `00-scope.md` into a hard dependency.** D2/D3's entire commercial rationale now rests on **Pool B** — and Pool B is precisely the inventory with **no real-time availability**, because those operators sit on no booking system. **Spine stage 5 is no longer one prerequisite among several; it is the gating dependency for the whole B2B strategy.** Step 6 must sequence it first, ahead of any partner-facing surface. A partner dashboard that cannot quote live Pool B availability is a quote form; an API that cannot confirm is a catalogue feed.
3. **It raises a supply-strategy question the research should surface** — if D2/D3 monetises Pool B, then **growing Pool B is the revenue lever**, not growing total SKU count. That partially re-frames D1: horizontal expansion via aggregators buys *coverage and search-success*, but not B2B revenue. The two goals need separating in the register.

**Still to establish:** credit terms, deposit requirements, and settlement timing for Pool B partners — these drive working-capital exposure and belong in the Step 5 risk column.

### `{{GROWTH_PLAN}}` ⭐ **HIGHEST PRIORITY**
**Value:** `UNKNOWN`
**Asked for:** the overall growth plan that TARGET-basis sizings anchor to — revenue/GMV/order targets and horizon.
**Impact if missing:** Risk §1.3(1) — the two-clock problem — becomes unmanageable. Without this, TARGET-basis rows cannot be honestly ranked against CURRENT-basis rows, and the Now/Next/Later assignment in Step 6 loses its anchor. Fallback is the same break-even-threshold treatment as `{{SKU_ROADMAP}}`.

---

## C. ASSETS & CONSTRAINTS

### `{{DATA_ASSETS}}`
**Value:** `UNKNOWN`
**Asked for:** booking history depth (how many months, how many rows); WhatsApp/CS transcript corpus (retained? how long? structured?); review corpus; catalog corpus; itinerary/concierge logs; supplier performance data; search & clickstream logs.
**Impact if missing:** Step 5a scores "data readiness Y/N/Partial" per candidate, and data readiness is the most common silent killer of an AI roadmap. Specifically: **WhatsApp transcript retention** decides whether concierge automation is a 90-day build or a 9-month one that starts with instrumenting a data pipeline. **Search/clickstream logs** decide whether ranking and relevance work is possible at all.

### `{{AI_INVENTORY}}` ⭐ **HIGHEST PRIORITY**
**Value:** ✅ **ANSWERED 2026-07-26 — "AI Event Business Sales Forecasting."**

**This confirms the Step 1 verification finding and closes Q1/Q2.** The one AI system in production is **event/ticketing sales forecasting** — the TipTip-side capability, not a SatuSatu one. Combined with the Tier A observation that **SatuSatu's live product exposes zero AI surfaces** (keyword search only, no semantic search, no personalisation, human concierge), the position is now settled:

| | Finding |
|---|---|
| **AI in SatuSatu's product today** | **None.** Greenfield. |
| **AI at group level** | Event business sales forecasting — entertainment ticketing |
| **Transferred to TAA?** | **No.** No public source claims it, and the user's own answer names it as event-business forecasting. |
| **Transferable?** | ⚠️ **Structurally hard, not merely undemonstrated.** Concert ticketing = few high-value, date-fixed, single-shot events with a pre-sale demand curve. TAA = 253 evergreen, daily-departure, low-ASP SKUs with no comparable pre-sale signal. **A different forecasting problem, not a port.** |
| **The +50% margin claim** | `[ANNOUNCED]`, **correlational not causal** — every Tier A/B source says "after"/"following"; the only causal phrasing is a Tier C aggregator's rewrite. Single-source (one release, 2026-05-04). Two competing non-AI explanations in the same release. |

**Two consequences for the register:**
1. **Nothing is at risk of being re-recommended** — the Step 5c "is this already live?" kill test will not fire on any SatuSatu candidate. The greenfield is real.
2. **No AI capability may be scored as an existing SatuSatu asset.** What *is* genuinely reusable is **organisational**, not technical: a team that has shipped a forecasting model to production, inside the same legal entity. That is a real advantage for `{{CAPACITY}}` and for build-vs-buy — but it is people and process, not a model.

**Original ask (retained for reference):** every AI system in production, at SatuSatu **and** inherited/reusable from TipTip — what it does, where it runs, what it measurably moved, and who owns it.
**Impact if missing:** Two distinct failures. (1) The register may recommend something **already shipped** — an automatic Step 5c kill and a credibility loss in front of the CEO. (2) The register may **assume reuse that has not been demonstrated**. TipTip has publicly credited a *ticket-demand prediction* deployment for entertainment ticketing with a +50% contribution-margin improvement (Tier B, plan §1). Per plan §1.2(d), until this field is filled that capability is treated as **ticketing-specific with unproven transferability** to SatuSatu's concierge, catalog, supply, or B2B workflows. Getting this wrong in either direction distorts build/buy and effort estimates across the whole register.

### `{{CAPACITY}}` 🔴 **BINDING CONSTRAINT**
**Value:** ✅ **ANSWERED 2026-07-26 — "None dedicated. The D2/D3 platform build consumes the team."**

**This is the single most shaping answer in Step 0.** The pre-registered impact note anticipated it exactly: *"if D2/D3 platform work already consumes the entire team, then every AI opportunity competes with the strategy rather than supporting it — which would change the recommendation from 'which AI bets' to 'which AI bets fit in the gaps.'"* That condition now holds.

**Effort is the binding constraint, not impact.** Consequences the register must respect:

| # | Consequence |
|---|---|
| 1 | **Every AI candidate now has a real opportunity cost measured in displaced D2/D3 platform work.** A candidate is not competing against other AI candidates for a budget; it is competing against the company's stated strategy for the same engineers. Step 5b must state what each row displaces. |
| 2 | **Buy/partner becomes the default; build must be argued for.** Step 5a's build/buy/partner call inverts its burden of proof. |
| 3 | **The "Now (≤90 days)" lane is restricted to near-zero-engineering interventions** — vendor-delivered, configuration-only, or ops-process changes with an AI component. Anything needing a sprint is Next at the earliest. |
| 4 | **RICE will mislead if applied naively.** With effort as the binding constraint, ranking on RICE alone will surface high-impact/high-effort rows that cannot be staffed. Step 5 should rank on **impact per eng-week** and state the displacement explicitly. |
| 5 | ⚠️ **Tension with plan §5's coverage requirement** (≥3 candidates each for D1/D2/D3). Generating 9+ candidates against zero dedicated capacity risks producing exactly the feature wishlist plan §7.3 forbids. **Resolution:** keep the coverage requirement — it guards against D0 gravity, which is a real bias — but every D1/D2/D3 row must carry an explicit staffing statement. Rows that cannot be staffed inside two quarters are labelled **`[UNSTAFFABLE — documented for sequencing, not proposed]`** rather than padded into the ranked table. |

**Compounding constraints — the three stack:**
- **No dedicated engineering capacity** (this field)
- **Thin margin** on aggregator-sourced inventory (`{{MARGIN}}`) → small denominator for every inference-cost test
- **Capital discipline** `[INFERENCE]` — no disclosed raise since **November 2022**, ~3.7 years, alongside a just-achieved EBITDA-positive position

→ Together these argue strongly for **cheap, fast, bought-not-built interventions against costs that already exist**, and against anything with a long pre-revenue build. Cost-to-serve reduction (mechanism *d*) and leakage reduction (mechanism *e*) are the classes that survive this filter best, because they size against money already being spent.

**Still worth establishing:** whether TipTip's event-forecasting team can be **borrowed**. Not for the model — that is a different forecasting problem — but for the **people and process**: someone who has already shipped production evals, monitoring and a retraining loop, inside the same legal entity. That is the one genuinely reusable group asset identified so far, and it is organisational rather than technical.

### `{{CONSTRAINTS}}`
**Value:** `UNKNOWN`
**Asked for:** budget ceiling; PII / third-party-processor policy (can traveller WhatsApp content leave the tenancy? can it reach a US LLM provider?); latency requirements; vendor lock-in position; group platform dependencies and mandates.
**Impact if missing:** The PII/third-party question is binary and decisive for concierge automation, which is the highest-value D0 area. If traveller conversation data cannot be sent to an external model provider, build/buy flips for a large share of the register at once.

### `{{AI_FIRST_DEFINITION}}`
**Value:** `UNKNOWN`
**Asked for:** what "AI-first" means to leadership — new revenue, better product, or lower opex. **Ranked, not weighted.**
**Impact if missing:** This is the tie-breaker that decides the shape of the final recommendation. Cost-to-serve reduction is the best-evidenced opportunity class at SatuSatu's current scale, but if leadership means "new revenue line" then a register topped by opex savings will read as having missed the question entirely — regardless of its analytical quality.

### `{{HORIZON}}`
**Value:** `UNKNOWN`
**Asked for:** time horizon for the first measurable result.
**Impact if missing:** Sets the Now/Next/Later boundaries in Step 6. The plan's default is Now ≤90 days / Next 2–3 quarters / Later = bets; confirm or override.

---

## D. Group assets inherited from TipTip *(context only — never an opportunity target)*

Per plan §0, TipTip appears here strictly as an asset/constraint inventory. No opportunity in the register may have a P&L that lands on TipTip's line.

| Asset | Detail | Status |
|---|---|---|
| Capital | ~$23M raised, East Ventures-led | Tier B/C — plan §1 |
| Group financial health | EBITDA-positive Q1 2026; 56% QoQ gross revenue growth | Tier B — plan §1 |
| Deployed AI capability | Ticket-demand prediction for entertainment ticketing; credited with +50% contribution margin | Tier B — **transferability to TAA unproven**, see `{{AI_INVENTORY}}` |
| Payment rails | `UNKNOWN` — does SatuSatu use TipTip's gateway? IDR settlement, USD acceptance, FX handling | To fill |
| Engineering capacity | `UNKNOWN` — shared or separate teams? see `{{CAPACITY}}` | To fill |
| Ops team | `UNKNOWN` — shared CS/ops or separate? | To fill |
| Audience for cross-sell | `UNKNOWN` — TipTip's Indonesian creator/ticketing audience is *domestic*; SatuSatu's customer is *inbound international*. Overlap may be near zero. Worth one line, not a workstream. | To fill |

---

## E. Sign-off

- [ ] Every field above is either filled or explicitly `UNKNOWN` with the impact note reviewed
- [ ] All remaining `UNKNOWN`s mirrored into `99-open-questions.md`
- [ ] Head of Product has confirmed the D1/D2/D3 direction statements in plan §1.1 are still current as of the fill date

**Filled by:** _______________
**Date:** _______________