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.

→ 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:

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:

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.

E. Sign-off

• Every field above is either filled or explicitly UNKNOWN with the impact note reviewed
• All remaining UNKNOWNs 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: _______________