# 04 — Opportunity Register

**Step:** 5  
**Prepared:** 2026-07-26  
**Status:** Gate 2 artifact. Requires human review before roadmap execution.  
**Important constraint:** `{{SCALE}}`, `{{PASS_ECON}}`, `{{COST_BASE}}`, `{{SKU_ROADMAP}}`, `{{D2_PLAN}}`, `{{D3_PLAN}}`, `{{DATA_ASSETS}}`, `{{CONSTRAINTS}}`, `{{AI_FIRST_DEFINITION}}`, and `{{HORIZON}}` remain partly or fully unknown. Currency impact is therefore expressed as formulas, break-even thresholds, or bands tagged `[ASSUMPTION]`. Do not present these as forecasts.

## Scoring Notes

- **Money mechanism:** exactly one primary mechanism per row.
- **Sizing basis:** `CURRENT` means it can be sized from the live business once internal denominators are filled; `TARGET` means it depends on a planned SKU/partner/API volume.
- **Capacity rule:** there is no dedicated AI engineering capacity. `Now` is limited to configuration, procurement, analytics, copy/content workflows, or changes that fit inside the already-planned D2/D3 platform work.
- **Default build stance:** buy/partner unless the asset touches Pool B exclusivity, curation quality, or SatuSatu-owned data.

## Survivors

| ID | Opportunity | Direction | Stage | Customer | Money mechanism | Driver metric | Sizing basis | Impact low-base-high | Key assumptions | Data required & status | Build-Buy-Partner | Effort | Confidence | RICE | Horizon | Defensibility | Top risk | Kill criterion |
|---|---|---|---|---|---|---|---|---|---|---|---|---:|---:|---:|---|---|---|---|
| OPP-01 | Concierge drafts itinerary plans so one human handles more Pass guests without losing the "real local" promise | D0 | 13, 14, 17 | Traveller / internal | (d) Cost-to-serve reduction | Concierge minutes per pass; passes per concierge FTE | CURRENT | `passes/yr × minutes_saved/pass × $0.048–0.138/min − AI/vendor cost` = needs `{{PASS_ECON}}`; base only clears if >12.5 min saved per Fin-priced resolution | Base workload estimate 100 min/pass; assistable 80 min/pass [INFERENCE]; Indonesian labour base $0.079/min | WhatsApp transcripts, itinerary logs, supplier confirmations: **Partial/UNKNOWN** | Buy workflow layer or use existing LLM tooling; build only templates/evals | 2–4 eng-weeks, mostly ops | 55% | 62 | Now if PII cleared | Medium: Bali supplier graph + transcripts | Wrong generated instruction strands traveller | No expansion if IDIER >0.5% at n≥400 or CSAT drops below baseline |
| OPP-02 | In-destination messages are rendered from confirmed booking slots, not generated prose | D0 D1 D2 D3 | 14, 17 | Traveller / partner | (e) Risk / leakage reduction | Instruction error rate; re-contact rate | CURRENT | `bad_instruction_incidents avoided × cost/incident`; break-even at `N incidents = template_setup_cost / cost_per_incident`; cost/incident currently [ASSUMPTION] $150–600–1,500 | Ops scan estimates stranding lower bound is pass refund and likely several multiples | Confirmed booking state, meeting-point templates: **Partial** | Build light template/rendering layer inside existing booking ops | 1–2 eng-weeks | 75% | 84 | Now | Medium: local operating knowledge | Template data wrong or stale | Kill if any safety-adjacent instruction is model-authored rather than slot-rendered |
| OPP-03 | Generic support and post-trip follow-up move to AI-assisted WhatsApp/email without touching itinerary execution | D0 D1 | 16, 17 | Traveller / internal | (d) Cost-to-serve reduction | Tickets deflected; confirmed resolution, not assumed resolution | CURRENT | `tickets/yr × eligible_share × confirmed_resolution_rate × AHT × $0.048–0.138/min − vendor_cost`; only profitable when replaced AHT exceeds 6–23 min depending vendor price | Deflectable fringe is small; use for coverage/latency/language more than labour saving | FAQ KB, ticket logs, WhatsApp policy: **UNKNOWN** | Buy BSP/helpdesk AI if PII allows | 0–1 eng-week | 60% | 58 | Now | Low: vendor commodity | Vendor "assumed resolved" overstates success | Stop if confirmed resolution <30% by day 60 or 72h re-contact >1.5× human baseline |
| OPP-04 | Pass composition engine shifts redemptions toward Pool B/high-margin inventory without breaking perceived value | D0 | 6, 12, 18 | Traveller / internal | (b) Take-rate / margin expansion | Pool B share of pass redemptions; breakage; gross margin/pass | CURRENT | `pass_units/yr × (PoolB_mix_shift × GBV/pass × (27%-10%)) − tooling_cost`; needs pass units and redemption mix | Pool A gross ~10%, Pool B gross ~27% [INFERENCE]; Klook Pass funds discounts via redemption mix | Pass purchase/redemption logs: **UNKNOWN** | Build simple rules/BI first; no model until data volume exists | 2–3 eng-weeks | 50% | 51 | Next | Medium: Pool B supply and pass packaging | Over-optimising margin lowers guest value | Kill if refund/review complaints rise or attach/conversion falls >5% vs baseline |
| OPP-05 | Pool B supplier confirmation state machine turns WhatsApp/phone confirmations into auditable availability | D0 D1 D2 D3 | 5, 18 | Supplier / internal | (e) Risk / leakage reduction | Booking confirmation SLA; no-record-at-arrival incidents | CURRENT | `manual_booking_count/yr × no_show_or_no_record_rate × incident_cost + minutes_saved × $/min`; threshold until count known | Pool B is the margin pool and lacks real-time availability; this is D2/D3 gating dependency | Supplier contact graph, confirmation history: **Partial/UNKNOWN** | Build as part of D2/D3 platform; avoid standalone AI | 4–8 eng-weeks | 70% | 78 | Now/Next | High: local supplier operating graph | Operators ignore structured confirmations | Kill if >10% suppliers fail to acknowledge within SLA after 60 days |
| OPP-06 | AI-assisted Pool B listing production makes direct-contracted suppliers live faster | D0 D1 | 1, 2, 18 | Supplier / internal | (a) GMV lift | Days-to-live; listings per ops FTE/week | CURRENT | `new_PoolB_SKUs/mo × margin/SKU/yr × acceleration_months/12 − QA_cost`; if margin/SKU unknown: break-even SKUs = fixed_cost / margin_per_SKU | GYG proved supplier GenAI catalog workflow; first experiment failed on UX, so human QA required | Existing listing corpus, brand tone, rejected-listing examples: **Partial** | Buy/use general LLM + human editor; build workflow later | 0–2 eng-weeks | 65% | 72 | Now | Medium: local curation standard | Hallucinated inclusions cause refunds | Kill if human edit time is not reduced by ≥30% after 50 listings |
| OPP-07 | Aggregator feed dedup and quality gate prevents duplicate, off-brand, or unsellable SKUs before second feed launch | D1 | 3, 4, 19 | Internal / traveller | (e) Risk / leakage reduction | Duplicate rate; bad-SKU incidents; auto-pass rate | CURRENT because GlobalTix live and second aggregator planned | `bad_SKU_incidents avoided × incident_cost + QA_minutes_saved × $/min`; break-even at `N ingested SKUs = fixed_cost / (manual_QA_cost/SKU + avoided_incident_cost/SKU)` | Second aggregator makes dedup near-term; GlobalTix fields and Prioticket/OCTO likely overlap | Curated catalog, GlobalTix feed sample, second-feed sample: **Partial** | Partner for feed; build SatuSatu quality rules/evals | 4–6 eng-weeks | 75% | 80 | Now/Next | Medium: curation gate specific to brand | Bad feed degrades local curation promise | Stop second-feed ingestion if auto-pass <70% after 500 SKUs or bad-SKU incidents exceed curated baseline |
| OPP-08 | Machine-readable catalog feed makes SatuSatu visible to LLM/agent discovery surfaces | D1 D3 | 4, 11, 12 | Traveller / partner | (a) GMV lift | Search-success rate; LLM referral clicks; indexed exclusive SKUs | CURRENT | `incremental_sessions × CVR × AOV × margin`; until baseline exists, success = ≥X qualified LLM referrals/month by day 90 | AI disintermediates discovery, not booking; Klook ChatGPT flow hands off to Klook checkout | Clean SKU metadata, schema, image rights, sitemap/feed logs: **Partial** | Build structured data/feed inside existing catalog work; no agentic checkout | 2–4 eng-weeks | 60% | 64 | Now/Next | Medium on narrow Bali/Pool B intents | Generic Bali intents dominated by Klook/Viator | Kill if no measurable LLM/referral impression growth by 90 days after indexation |
| OPP-09 | Search/ranking separates Pool A filler from Pool B exclusive value so horizontal expansion does not bury the margin pool | D1 | 4, 12 | Traveller | (a) GMV lift | Search-success rate; Pool B click/share; conversion | TARGET | `searches/mo × failed_search_recovery × CVR × AOV × margin`; if logs unknown, first milestone is instrumentation only | Search/clickstream availability unknown; catalog still small | Search logs, clickstream, SKU pool labels: **UNKNOWN/PARTIAL** | Build instrumentation now; model later | 2–6 eng-weeks | 40% | 38 | Next | Medium if Pool B labels proprietary | No traffic volume for ranking to learn | Kill if search volume < threshold for statistically useful evaluation after 90 days |
| OPP-10 | Supplier performance risk score flags Pool B operators likely to cancel, overbook, or create refunds | D0 D1 D2 D3 | 18, 19 | Internal / supplier | (e) Risk / leakage reduction | Refund/no-show leakage; supplier incident rate | CURRENT | `bookings/yr × baseline_incident_rate × reduction_rate × incident_cost`; needs incident history | Pool B manual ops create hidden leakage; quality gating is D1 prerequisite | Supplier incident, refund, review, complaint logs: **UNKNOWN** | Start rules/BI; ML only after labelled events | 1–3 eng-weeks | 50% | 44 | Next | High if incident corpus becomes proprietary | Too few labelled incidents | Kill if labelled incident count <100 after instrumentation period |
| OPP-11 | D2 partner quoting assistant creates Pool B itineraries and quote PDFs faster for agents/drivers | D2 | 8, 9, 17 | Partner | (c) New revenue line | Quotes/partner/week; quote-to-book rate; Pool B B2B GMV | TARGET | `partners × quotes/mo × quote_to_book × AOV × net_spread`; if D2 plan unknown: break-even partners = fixed_cost / contribution_per_partner | D2 built on Pool B only; Pool A parity/withheld | Partner segments, net rates, availability state, quote history: **UNKNOWN/PARTIAL** | Build only after D2 workflow exists; LLM drafts not confirms | 4–8 eng-weeks | 45% | 42 | Next | Medium: Pool B exclusivity | Assistant quotes unavailable inventory | Kill if quote-to-book uplift <10% after 30 active partners |
| OPP-12 | Driver/guide micro-partner recommender pays commission only on Pool B SKUs where spread survives | D2 | 8, 9, 11 | Partner / traveller | (c) New revenue line | Active drivers; bookings/driver/month; Pool B commission margin | TARGET | `drivers × bookings/driver/mo × AOV × (PoolB_margin − driver_commission)`; example: 27% gross can pay 15–18% commission and still beat Pool A | Driver commission ~20% claim [Tier C]; volume unknown | Driver network, commission policy, Pool B rates: **UNKNOWN** | Partner/process first; AI recommends/ranks from approved SKUs | 2–6 eng-weeks | 50% | 56 | Next | Medium-high if driver network exclusive | Fraud/self-booking/commission leakage | Kill if active drivers fail to produce ≥1 booking/month after 60 days |
| OPP-13 | B2B rate and parity guardrail prevents partners from selling non-exclusive Pool A at negative contribution | D2 D3 | 7, 15, 18 | Partner / internal | (b) Take-rate / margin expansion | Negative-margin booking count; rate override exceptions | CURRENT/TARGET | `bad_rate_bookings avoided × loss/booking`; low cost control, high downside protection | B2B pricing answered: Pool A parity/withheld; Pool B net-rate tiered; Pass fixed allocation | Pool labels, net rates, partner tiers: **Partial** | Build rules inside D2/D3 pricing; no AI needed initially | 1–3 eng-weeks | 80% | 88 | Now | Medium: policy clarity | Sales overrides rules to win partners | Kill if any Pool A B2B sale clears below minimum contribution threshold |
| OPP-14 | Partner onboarding copilot turns KYC, contract setup, training, and first booking into a self-serve checklist | D2 | 8, 9, 17 | Partner / internal | (d) Cost-to-serve reduction | Days to first booking; onboarding touches/partner | TARGET | `partners_onboarded/yr × touches_saved × cost/touch`; if partner plan unknown: threshold = vendor/config cost / cost_saved_per_partner | D2 likely high-volume, low-ACV; human-assisted sales may not clear | Contracts, KYC, training docs, support tickets: **UNKNOWN** | Buy CRM/helpdesk automation; build checklist in portal | 1–3 eng-weeks | 55% | 46 | Next | Low: workflow commodity | Partner ACV too low to support any onboarding support | Kill if median time-to-first-booking not reduced 30% after 20 partners |
| OPP-15 | D3 API documentation assistant and sandbox examples reduce integration support per reseller | D3 | 10, 17 | Partner / internal | (d) Cost-to-serve reduction | Integration-support hours per reseller; time to first booking | TARGET | `integrators/yr × support_hours_saved × cost/hour − docs_assistant_cost`; if D3 plan unknown, document as unstaffable | Viator/GYG show docs are table stakes; support cost hidden | API spec, sandbox, error logs: **UNKNOWN** | Use docs generator/LLM over OpenAPI only after API stabilises | 2–4 eng-weeks | 35% | 28 | Later | Low: easy to copy | API itself not stable/valuable yet | Kill if first 3 integrators still require bespoke engineering support |
| OPP-16 | Prioticket/ETG second-feed evaluation uses AI-assisted field mapping only if Bali depth beats GlobalTix gaps | D1 | 3, 4, 10 | Internal | (a) GMV lift | Incremental sellable Bali SKUs; dedup pass rate | CURRENT/TARGET | `incremental_sellable_SKUs × margin/SKU/yr − integration_cost`; gate before build: ETG Bali SKU count and overlap sample | Prioticket is best candidate on docs/OCTO; Indonesia depth unverified | ETG sample feed, GlobalTix overlap, SKU margin: **UNKNOWN** | Partner first; build only SatuSatu mapper/QA | 2–6 eng-weeks after commercial sample | 50% | 50 | Next | Low-medium: table stakes | Second feed adds duplicates not value | Kill if unique sellable Bali SKU uplift <20% over current feed |
| OPP-17 | Pool B supplier mini-portal captures live allotments from offline operators without forcing a full booking system | D1 D2 D3 | 5, 18 | Supplier / partner | (c) New revenue line | Pool B bookable inventory; B2B GMV enabled | TARGET | `incremental_confirmable_PoolB_bookings × AOV × net_spread − supplier_support_cost`; depends on D2/D3 plans | Full SaaS like rezio/GlobalTix is too heavy; SatuSatu needs minimal allotment capture | Supplier adoption, allotment rules, settlement terms: **UNKNOWN** | Build only as part of committed platform; no standalone AI | 8–16 eng-weeks | 45% | 45 | Later | High if adopted by exclusive suppliers | Operators refuse to maintain availability | Kill if <30% targeted Pool B suppliers update allotments weekly after 90 days |
| OPP-18 | Finance reconciliation assistant matches GlobalTix credits, supplier settlements, partner invoices, refunds, and FX lines | D0 D1 D2 D3 | 15, 18, 20 | Internal | (e) Risk / leakage reduction | Unreconciled items; FX/payment leakage | CURRENT | `transactions/yr × leakage_rate × recovery_rate + finance_hours_saved × cost/hour`; leakage unknown | GlobalTix prepaid credit and 1.5% FX markup make reconciliation material | Transaction exports, bank/payment data, GlobalTix reports: **Partial/UNKNOWN** | Buy spreadsheet/accounting automation before model | 1–4 eng-weeks | 60% | 60 | Now/Next | Medium: internal data | Bad match creates accounting errors | Kill if false-match rate >1% in first 500 matched transactions |
| OPP-19 | Review and complaint summarisation turns traveller feedback into supplier improvement actions | D0 D1 | 16, 18, 19 | Supplier / internal | (e) Risk / leakage reduction | Supplier incident recurrence; review score | CURRENT | `incidents_reduced × cost/incident + retention/conversion lift`; use qualitative action rate until volume known | Klook merchant feedback loop produced one merchant product at 24% of revenue [self-reported] | Reviews, tickets, WhatsApp complaints by supplier: **UNKNOWN/PARTIAL** | Buy/use LLM summarisation with human owner | 0–2 eng-weeks | 65% | 66 | Now | Medium: local feedback corpus | Insights not acted on by suppliers | Kill if <50% supplier summaries produce an accepted action within 30 days |
| OPP-20 | Multilingual Pool B content generation targets India, China, Korea, Japan without hand-translating every SKU | D1 | 2, 4, 11 | Traveller | (a) GMV lift | Non-English SKU impressions and bookings | TARGET | `localized_sessions × CVR × AOV × margin − translation_QA_cost`; start with break-even language/SKU pairs | India/China/Korea/Japan are material inbound markets; English-first covers ~39% only | Source listings, language QA, traffic by locale: **Partial/UNKNOWN** | Buy translation/LLM; human QA top SKUs | 1–3 eng-weeks | 55% | 52 | Next | Low-medium: local tone + Pool B | Bad translation misstates inclusions/safety | Kill if localized pages do not improve non-English conversion or produce >0.5% content defects |

## Killed or Downgraded

| Candidate | Verdict | Why |
|---|---|---|
| Fully autonomous AI concierge for in-destination execution | **Killed** | The Pass sells "a real Bali local"; wrong instructions have high blast radius; deflection metrics reward silence; liability/PII unresolved |
| AI dynamic pricing for Pool A | **Killed** | GlobalTix minimum selling price floor and non-exclusive retail competition cap upside; SatuSatu cannot optimise out of vendor-set economics |
| Standalone AI trip planner as consumer hero feature | **Downgraded** | Klook/K.AI and generic LLM planners already exist; SatuSatu's advantage is local confirmation and Pool B access, not generic planning prose |
| Build a SatuSatu channel manager / rezio competitor | **Killed** | GlobalTix offers merchant booking system at USD100 setup + 1–3%; rezio shows SaaS revenue ceiling is small; no engineering capacity |
| D3 API for generic Pool A inventory | **Killed** | GlobalTix, Viator, TBO, and others already sell this to agents; SatuSatu has no price or content advantage on non-exclusive supply |
| AI model transfer from TipTip event-demand forecasting | **Killed** | Ticketing forecast problem is structurally different from evergreen TAA SKUs; no evidence of transfer |
| White-label pass platform | **Later / unstaffable** | iVenture precedent exists, but SatuSatu has not proven Pass unit economics, breakage, or fulfilment at current scale |

## Gate 2 Review Questions

1. Which opportunities may use traveller WhatsApp data with third-party AI processors?
2. What are real `{{PASS_ECON}}`, `{{COST_BASE}}`, and `{{SCALE}}` bands?
3. Does leadership want the top three bets ranked by **new revenue**, **product quality**, or **lower opex**?
4. Is D2's first target **drivers/guides**, **hotels/villas**, **travel agents**, or **DMCs**?
5. Does D3 need to be a real revenue line in 2026, or only proof that Pool B inventory is distributable?