03 — Operations Scan

Subject: SatuSatu (satusatu.com), PT Tiptip Network Indonesia. 253-SKU Bali TAA platform. Bali All-Access Pass launched 2026-05-06 (1/2/3-day, 40–50+ experiences, dedicated human concierge, 90-day activation, eSIM bundled). Prepared: 2026-07-26. All sources accessed 2026-07-26 from raw dumps in research/raw/.

Evidence tiers — A = filings, official docs, published case studies with disclosed methodology, live product. B = credible trade press and analysts. C = vendor marketing, blogs, LinkedIn, SEO compilations. Labelling — every number is [VERIFIED] (stated in a collected source) or [INFERENCE] (derived here, band shown). Where the raw files do not support a claim: "unverified — not found in collected sources."

Document status. This file is open for additions. Section 4a below is complete. Sections 4b and 4c will be appended by later steps. Do not renumber.

Contents

• 4a — Concierge & Service Automation (complete)
• 4b — (pending)
• 4c — (pending)

4a — Concierge & Service Automation

4a.0 Source quality warning — read before using any number below

This section synthesises nine raw search dumps. Their quality is highly uneven, and the unevenness maps directly onto which findings are safe to act on.

Two consequences, stated up front rather than buried:

1. Every deflection number in §4a.2 rests on Tier C. There is no independently audited deflection or resolution benchmark anywhere in the collected sources. The single most useful line in the entire deflection dump is a vendor's own caveat: the widely-repeated ~41% tier-1 figure is "reported by secondary compilations whose definitions vary… treat it as a directional floor, not an audited resolution median" (aissist.io, Tier C). That caveat is more reliable than the number it caveats.
2. Three items asserted in the research brief are not corroborated by these files and are therefore carried as brief-asserted, not source-verified: Canary Technologies' $80M Series D of 2025-06-12 (no funding data of any kind in s4a-canary.md); the Elite Havens acquisition month of September 2018 (raw confirms the year and a $15m deal value, Tier B, but not the month); and the Klook F-1 gross profit at 11.2% of GTV anchor (not in this step's files — carried from prior steps).

4a.1 Concierge job decomposition

4a.1.1 What the Pass actually promises

The Pass is marketed as "access to a real Bali local who plans your days." Three load-bearing words: real (a person, not a system), local (destination knowledge, not catalog knowledge), and plans (an active, forward-looking act, not reactive Q&A). Each is a separate automation problem with a different risk profile, and the marketing copy commits SatuSatu to all three.

Note also the delivery architecture: two separate WhatsApp queues — general (+628-7878-111-111) and Pass concierge (+62 878-9897-8780) — plus support.satusatu.com. Two human queues with different SLAs, already. Any automation must decide whether it merges those queues or preserves the split; merging them destroys the entitlement boundary that justifies the Pass premium, and preserving them means building or buying twice.

4a.1.2 Decomposition table

⚠️ The entire minutes column is [INFERENCE]. No collected source gives minutes-per-pass for a travel concierge, and SatuSatu's own figure is a known unknown. These are structural estimates derived from the task shape (number of SKUs to sequence, number of suppliers to contact, number of days covered), not from measurement. They exist so the formulas in §4a.5 can be run the moment real numbers land. Replace them; do not cite them.

Classification key — Deflectable = can complete end-to-end with no human in the loop. Assistable = human stays accountable, AI compresses their time (draft, retrieve, pre-fill, summarise). Irreducibly human = must not be automated at current capability, regardless of what a vendor demo shows.

4a.1.3 What the decomposition says

• Deflectable tasks (3, 8, 9) total 3 / 8 / 21 minutes — roughly 8% of base-case concierge time. The tasks that are safe to fully automate are the tasks that barely cost anything.
• Assistable tasks (1, 2, 4, 5, 6) total 29 / 80 / 195 minutes — 80% of base-case time. This is where the money is, and none of it is deflection. It is all human-in-the-loop time compression.
• Irreducibly human (7) is 0 / 12 / 60 minutes — small on average, unbounded in the tail, and the single reason a traveller values the Pass.

The strategic reading: the concierge is not a deflection problem. It is an assist problem with a small deflection fringe. Any vendor pitch built on a deflection percentage is pitching against the 8%, not the 80%. See §4a.2, where this distinction is the whole game.

4a.2 Deflection benchmarks — and the definitional fraud underneath them

4a.2.1 The four numbers vendors call "deflection"

These are not synonyms, they are not measured the same way, and the spread between them is 20–40 points. Intercom's own product documentation defines three of them separately, which is itself evidence that the conflation is deliberate elsewhere.

Two measurement defects are documented in the collected sources and both inflate the headline in the same direction:

• "Assumed resolved" counts silence as success. Intercom's own support engineer, on Intercom's community forum: "a resolution is counted if the customer clicks 'that helped' or does not respond to the answer and leaves the conversation." [VERIFIED] Tier B — community.intercom.com. An Intercom customer on the same forum reports confirmed resolution 6–7% against assumed resolution ~60% [VERIFIED] Tier C.
• Human rescue is counted as AI success. A support manager reported a 12% real resolve rate while being billed for far more, because Fin marked conversations "assumed resolved" when a human agent stepped in before the customer clicked "speak to human" — and the agent was stepping in precisely because the AI had given wrong steps mid-crisis [VERIFIED] Tier C — pageloop.ai. A second lead: dashboard 84.5%, real number "roughly half that."

🔴 For SatuSatu this defect is not cosmetic, it is inverted-severity. A traveller who goes silent after a bad in-destination instruction is not a resolved ticket. They are a person walking toward the wrong temple. The industry-standard resolution metric would score that as a success.

4a.2.2 Vendor claim vs. measured reality

Central finding: across every vendor in the set, the claimed figure exceeds the measured figure by 16–40 percentage points. This is not noise; it is systematic and unidirectional. Treat any vendor-quoted deflection rate as claimed − 25 points [INFERENCE] until proven otherwise on SatuSatu's own intent mix.

4a.2.3 Bands, with the denominator stated

4a.2.4 Travel and WhatsApp-first specifically

The travel-specific evidence is thin and entirely vendor-authored. Stating that plainly:

⚠️ The easyJet 62% and the easyJet 28% are not the same measurement. 62% is of cases across two chat channels; 28% is of total call-centre volume. Quoting them together as "easyJet automated 62%" overstates by conflating denominators. This is the exact error the vendor case-study format invites.

No source in the collected set reports a measured deflection rate for an Indonesian, Bali, or in-destination travel-concierge operation. Unverified — not found in collected sources. Every travel number above is European airline/insurance customer service, which is high-volume, high-structure, and post-hoc (baggage, claims) — the opposite of in-destination itinerary coordination.

4a.2.5 Consumer acceptance, which cuts the other way

• 64% of customers say they would prefer companies did not use AI for customer service (Gartner survey, n=5,728, Dec 2023) [VERIFIED] Tier C reporting a Tier B primary.
• 89% believe companies should always offer the option to speak with a human (SurveyMonkey 2025) [VERIFIED] Tier C.
• 67.7% agree that getting a response from an AI chatbot is helpful (WhatsApp/Kantar 2026) [VERIFIED] Tier C.
• 79% of Americans still prefer humans; 51% prefer bots when they want immediate service [VERIFIED] Tier C — lorikeetcx.ai.

These reconcile as: customers accept AI when it resolves the issue and a human is reachable. For SatuSatu the tension is sharper than for a generic SaaS, because the human is not a fallback — the human is the advertised product. A Pass buyer who paid a premium for "a real Bali local" and reaches a model has a mis-selling grievance, not a CSAT dip.

4a.3 Failure modes and blast radius

4a.3.1 Why the generic framing does not apply

A chatbot returning a bad answer to a SaaS user costs a re-ask. A wrong in-destination instruction puts a paying traveller at the wrong place, at the wrong hour, in a foreign country, on a schedule they cannot re-run. The relevant precedent in the collected sources is not a support metric — it is Cursor, April 2025: an AI support bot told users their accounts were restricted to one device per subscription; the policy had never existed; users cancelled; the story hit Hacker News and Reddit within hours; the cofounder apologised publicly. The bot invented an explanation because no article documented the real behaviour [VERIFIED] Tier C — pageloop.ai. A confident, fluent, entirely fabricated instruction, issued at machine speed, into a gap in the knowledge base. That is the exact shape of the risk here.

4a.3.2 Failure classes

4a.3.3 The architectural consequence

F1 and F2 flip between "mandatory HITL" and "safely automated" depending on one design decision: whether the outbound message is generated or rendered.

• Generated (model writes the meeting instruction in prose): every message is a fresh opportunity for F1 and F6. HITL mandatory, and the automation saves nothing because a human reads every message anyway.
• Rendered (model selects a template and fills slots from the confirmed booking record; it never authors the instruction): the failure surface collapses to slot-selection, which is testable, enumerable, and gate-able. HITL becomes optional.

🔴 Recommendation: in-destination messages must be rendered, never generated. This is the single highest-value constraint in this section, it costs almost no engineering (template library + slot mapping), and it converts the two highest-volume risky tasks into safe ones.

4a.3.4 The Klarna lesson, read correctly

Klarna is usually cited as the AI-CS success case. The collected sources contain both halves, and the second half is the one that matters:

• Feb 2024 [VERIFIED, Tier A — Klarna press release]: two-thirds of chats, ~700 FTE-equivalent, 11 min → under 2 min, 25% fewer repeat inquiries, $40M profit improvement.
• May 2025 [VERIFIED, Tier B — Forbes reporting Bloomberg]: CEO Sebastian Siemiatkowski says the company cut too deep and reopens hiring for premium support roles. His own framing: "an overemphasis on cost — not AI itself — led to lower quality."
• Klarna's rebuttal [VERIFIED, Tier B, quoted in full in the raw]: "Klarna never eliminated human support. We still work with several thousand outsourced agents. The current pilot involves just two new agents… it's an addition, not a rehire or reversal." The AI assistant now performs the work of 800+ full-time roles, not 700.

Read together, the rebuttal reframes the original number. The 700-FTE figure was never a replacement count — it was incremental capacity layered on top of a retained human floor of several thousand outsourced agents. Klarna's actual architecture is, and always was, AI-plus-humans. The public story of replacement was a misreading that Klarna itself had to correct, at reputational cost.

Corroborating detail from the same period: a well-known engineer testing the assistant at launch called it "underwhelming. It recites exact docs and passes me on to human support fast" [VERIFIED] Tier B — Business Insider. Fast, correct escalation was the design. That is the transferable lesson.

For SatuSatu, with one concierge queue and an unknown headcount, there is no "several thousand outsourced agents" floor to fall back on. Klarna could absorb a quality dip because it had depth. SatuSatu cannot.

4a.3.5 Kill criterion

Design principle: never gate on deflection. Per §4a.2, deflection rewards abandonment, and abandonment in this product means a stranded traveller. The gate must be built on error rate and re-contact, with deflection as a reporting metric only.

Primary kill metric — In-Destination Instruction Error Rate (IDIER)

IDIER = (AI-issued in-destination instructions that resulted in a traveller at the wrong
         place/time/date, OR a booking with no supplier record)
      ÷ (total AI-issued in-destination instructions)

Measured by 100% manual QA audit of a random sample, not by customer complaint volume (F8 means complaints undercount).

Justification of 0.5% as a formula, not a round number. The threshold should be set where expected incident cost exceeds labour saved:

kill when:   IDIER × cost_per_stranding_incident  >  minutes_saved_per_pass × cost_per_minute

With base-case inputs from §4a.5 (cost_per_minute = $0.079) and an optimistic 40 minutes saved per pass, the labour saved is $3.16/pass. cost_per_stranding_incident is unverified — not found in collected sources, but it is bounded below by the Pass refund ($59.95–$144.95) and is realistically several multiples of that once re-accommodation, goodwill and a public review are included. At a conservative $600/incident, break-even IDIER is 0.53%. 0.5% is that number, rounded down. Re-derive it the moment a real stranding cost and a real minutes-saved figure exist.

Secondary guardrails — all four measured together, any one breaching triggers the Hold gate

Dates. Expressed relative to pilot start T₀, with a worked example against SatuSatu's "now ≤ 90 days" constraint:

No in-destination automation ships before Gate 1 clears. Pre-trip failures are caught before the traveller acts; in-destination failures are not.

4a.3.6 ⚠️ Liability asymmetry — flagged, not opined on

SatuSatu's T&C disclaims operator performance. That posture fits a reseller/marketplace: the operator ran the tour badly, not us.

A concierge instruction is not an operator act. It is SatuSatu's own act — authored by SatuSatu, sent from SatuSatu's own WhatsApp number, delivered as a paid Pass entitlement. Two directions in which automating it may expand exposure rather than contain it:

1. The operator disclaimer does not reach it. The thing that went wrong was written by SatuSatu, not performed by a third party. The existing disclaimer is aimed at a different actor.
2. The marketing describes a person. "A real Bali local who plans your days" is a specific representation about who the traveller is dealing with. Substituting a model may create a gap between what was sold and what was delivered — distinct from, and additional to, any question of whether the instruction was correct.

A third, structural point that the Elite Havens comparable makes sharp (§4a.6.2): Elite Havens can make a concierge promise because it is the exclusive owner representative and controls the supply. SatuSatu is a reseller and does not control Pool A supply. A concierge promise made over supply you do not control is a structurally different commitment.

This is a flag, not a legal opinion, and no legal conclusion should be drawn from it. Route to counsel before any in-destination automation ships — not after the pilot, because the pilot itself issues real instructions to real travellers. Note also that this and the PII question in §4a.5.4 are the same governance question in different clothing, and should go to counsel together.

4a.4 The three-way split the strategy forces

Assumption stated explicitly: D0 = SatuSatu's own premium direct product (the Pass). D1 = SatuSatu self-serve. D2/D3 = partner / platform / white-label tiers. This reading is inferred from the brief ("the D2/D3 platform build consumes the team"; "a human concierge per booking cannot scale to D1/D2/D3"). If the taxonomy differs, the row logic holds but the column labels move.

The forcing constraint: a human concierge per booking is an O(n) cost against an O(1) platform revenue model. At D0's price point ($59.95–$144.95 with a bundled eSIM) it is already tight (§4a.5.5). At D1 self-serve prices it is impossible. At D2/D3, SatuSatu would be underwriting an unbounded human liability on a partner's traffic, over supply the partner controls, with no visibility into the traveller relationship.

4a.4.1 What the split actually means

The D0 premium reduces to two jobs: #2 (itinerary build) and #7 (exception handling). Everything else either automates cleanly or is plumbing. That is a much narrower and much more defensible product than "a dedicated human concierge," and it is honest about where the value is.

D1's viable offer is the pre-validated template itinerary. It captures most of #2's value at none of #3/#6's risk, because the risky sequencing decision was made once by a human and then reused. It requires a template library, not a model.

D2/D3 receive rendered messages and API-backed booking — never a human queue. The queue is the unbounded cost and the unbounded liability, and it is the one thing that cannot be priced into a platform take rate.

🔴 Marketing consequence, unresolved: the Pass is currently sold on the concierge, and the concierge is a Pass entitlement while base-catalog buyers get only "Dedicated support." Narrowing D0 to #2 and #7 does not change what the product is worth — but it does change what the copy can honestly claim. That is a positioning decision, not an ops one, and it should be made deliberately rather than discovered by a customer.

4a.5 Cost model inputs

4a.5.1 Statutory wage floor — Bali 2026 [VERIFIED, Tier A]

Bali Governor's Decree No. 1021/03-M/HK/2025 (UMK/UMSK) and No. 1011/03-M/HK/2025 (UMP), signed 2025-12-23, effective 2026-01-01. Corroborated across ANTARA, Kompas.TV, NusaBali, GoodStats and the Badung regency's own channel — the strongest-sourced data in this entire step.

Methodology per PP No. 49/2025: economic growth + inflation + an alfa coefficient of 0.5–0.9; Badung's wage council voted 18–0–1 for alfa 0.8 [VERIFIED] Tier B — NusaBali.

⚠️ UMK is minimum wage. It is a legal floor on base salary only. It is not a market rate, not a competent-bilingual-concierge rate, and above all not a fully-loaded cost. The gross-up is done explicitly below. Wage escalation is a live planning input: +6–7.3% per year, two years running.

4a.5.2 Market base salary — Indonesia CS/concierge [Tier C throughout]

Selected base band for an English-fluent, tourism-sector Bali concierge [INFERENCE] — above generic CS (destination expertise + English + traveller-facing), anchored on KantorKu's hotel band and MixWork's mid-level band:

4a.5.3 The gross-up — UMK → fully-loaded, multiplier shown

⚠️ This is the step that is most often skipped and most often wrong. Each factor is itemised so it can be corrected independently when real payroll data lands.

Resulting fully-loaded cost per concierge FTE (FX: IDR 15,500 / USD 1 [VERIFIED] Tier C — MixWork, stated as approximate for 2026; no better rate exists in the collected sources — all USD figures below are FX-sensitive and should be re-run at the live rate):

Triangulation — two independent Tier C sources bracket the base case:

• Stealth Agents: a 10-person Jakarta tier-1 CS team costs $60,000–90,000/yr fully loaded = $6,000–9,000 per FTE. Base case $8,455 sits inside it. ✅
• Plane: median remote Indonesian CS rep, total employment cost $9,989/yr ($8,999 base + 11% tax). Between base and high. ✅

4a.5.4 Cost per concierge-minute — the number everything else hangs off

Productive hours: 40h/week statutory [Tier C — remotepeople] = 2,080 gross. Shrinkage (annual leave, Indonesia's substantial public-holiday calendar, training, breaks, admin) 12–18% [INFERENCE].

4a.5.5 🔴 The finding that inverts the business case

Vendor AI support is priced per resolution, in USD, against a US/EU labour baseline:

The $6–13.50 human baseline is a US/EU number. SatuSatu's human baseline is $0.079 per minute.

Break-even average handle time — the point above which a per-resolution AI vendor becomes cheaper than an Indonesian concierge:

Conclusion: US-priced per-resolution AI does not clear an Indonesian labour arbitrage on short interactions. At the base case, a Fin-priced resolution only pays for itself if it replaces more than ~12.5 minutes of concierge time. Most deflectable tasks in §4a.1.2 (Pool A booking: 3 min; upsell: 3 min; post-trip: 2 min) are far below that line — the AI would cost 3–5× the human it replaces.

Therefore the business case for AI here cannot be cost per contact. It must rest on: 24/7 coverage (a human queue in one time zone cannot serve a 110-country inbound market), latency (Canary's LINE SF: median response 10 min → under 1 min; Klarna: 11 min → under 2 min), language breadth (Klarna: 35+ languages at zero marginal cost; Elite Havens draws from 110+ countries), and headcount avoidance at growth rather than headcount reduction today. Any model that shows AI saving money on cost-per-contact against Indonesian labour has the wrong baseline in it.

4a.5.6 Cost per AI conversation — structure given, price input missing

Model and token pricing for 2026 is unverified — not found in collected sources. No file in this step contains provider list prices. The structure below is therefore given with the price left as a variable, to be filled from the provider's current price list. Do not substitute a remembered price.

Assumed shape of a multi-turn WhatsApp support interaction [INFERENCE]:

cost_per_conversation = (input_tokens × $/Mtok_input  ÷ 1e6)
                      + (output_tokens × $/Mtok_output ÷ 1e6)
                      + whatsapp_platform_conversation_fee
                      + retrieval/vector infrastructure amortised per conversation

Two cost lines in that formula are missing entirely from the collected sources and are real, non-trivial gaps:

• WhatsApp Business Platform per-conversation fees. Nine files, several of them entirely about WhatsApp Business API, and not one price. Indonesia is a distinct pricing market. This must be sourced before any model is built.
• Retrieval/vector infrastructure. Not addressed anywhere.

Observable market proxy, in place of a computed figure: vendor-priced, all-in, $0.50–$0.99 per resolution [Tier C], or $1–3 for AI-native platforms [Tier C]. Cross-check any computed token cost against this band — a computed figure far below it is missing infrastructure, margin, or the platform fee.

4a.5.7 Concurrency — unverified

No collected source reports concurrent-chats-per-agent, with or without AI assist. Unverified — not found in collected sources. This is a genuine gap and it matters, because concurrency is the mechanism by which assist (not deflection) produces savings, and §4a.1.3 established that assist is 80% of the opportunity.

The only adjacent proxies available:

Planning note: the +13.8% throughput figure is the honest one to plan against, and it is far below what any deflection headline implies. If assist delivers +13.8% and deflection realistically delivers 30–50% of a small deflectable fringe (8% of concierge minutes), the combined labour saving is modest. Model it that way and be pleasantly surprised, rather than the reverse.

4a.5.8 ⚠️ The PII constraint — unresolved, and it flips build/buy

Whether traveller WhatsApp content may be sent to a third-party model provider is not answered by any collected source. The only trace is a truncated analyst prompt — Mordor Intelligence flags "How does the Personal Data Protection Law affect providers?" as a material question for Indonesian BPO — with no substantive treatment. So: Indonesia's PDP Law is flagged as material by industry analysts; its actual application here is unverified — not found in collected sources.

Because it flips the answer, both paths are costed:

Path A — traveller content MAY go to a third-party model provider

• Vendor SaaS is available: $0.50–0.99 per resolution, configuration-only, no engineering. Fits the "now ≤90 days, near-zero engineering" constraint exactly.
• Buy is the default and the decision is easy.
• But per §4a.5.5, the cost case is negative at short AHT. Buy for coverage, latency and language, and say so in the business case rather than dressing it as cost reduction.
• Residual risk: vendor lock-in on a per-resolution meter whose definition of "resolution" the vendor controls (§4a.2.1) — negotiate the definition into the contract, or the meter and the value diverge.

Path B — traveller content MAY NOT leave SatuSatu's control / Indonesian jurisdiction

The vendor route closes at the egress point. Four options, three of which fail the constraint:

🔴 The PII answer determines whether this is a configuration purchase or an engineering project — and only one of those fits the stated constraints. Resolve it first, before vendor selection, before pilot design, before any scoping. It is the highest-leverage open question in this section and it costs one legal opinion to close. Route it to counsel together with the liability question in §4a.3.6; they are the same governance question.

4a.6 Two comparables

4a.6.1 Canary Technologies — hotel AI concierge

Corporate. 20,000+ hotels, 125+ countries; customers include Marriott, Four Seasons, Wyndham, IHG, Choice, BWH [VERIFIED] Tier C — Canary's own pages. The brief's $80M Series D of 2025-06-12 is not corroborated — no funding data of any kind appears in s4a-canary.md.

What it automates [all VERIFIED, all Tier C, all Canary's own marketing unless noted]:

Published outcome metrics:

⚠️ Two internal inconsistencies worth recording:

• The LINE SF upsell conversion multiple is stated as 4× on Canary's site, "four times better" in the HotelTechReport transcript, and "14 times higher than traditional EPS links" in the same video. A 3.5× discrepancy inside one case study.
• Canary's own pages say 80–82% automation; the third-party HotelTechReport review video says "up to 70% of inbound questions." A 10–12 point vendor-vs-reviewer gap, consistent with the systematic pattern in §4a.2.2.

What Canary explicitly leaves to humans: ⚠️ Unverified — not found in collected sources. Canary publishes no exclusion list anywhere in the collected material. The only signal is directional framing: "freeing staff to focus on high-touch service" and "steps in when the front desk is busy." The absence is itself the finding — a mature, 20,000-hotel vendor with nine industry awards does not publish a boundary of competence. Any procurement conversation must force that boundary into writing, because it will not arrive in the marketing.

Transferability to SatuSatu — limited, and in a specific way. Canary's automated surface is in-property, low-stakes, high-frequency: spa hours, restaurant recommendations, loyalty policy, early check-in, towels. A wrong answer means a mildly annoyed guest who is already inside a building with staff in it. None of Canary's published automation covers in-destination instruction issued to a guest who has left the property. The failure classes in §4a.3 — F1, F3, F5 — have no analogue in Canary's evidence base. Canary demonstrates that hotel-adjacent FAQ automates well. It demonstrates nothing about whether a day-plan automates safely.

4a.6.2 Elite Havens — the real Bali analogue, running 28 years

Corporate. Founded 1998 [Tier C]. Acquired by Dusit Thani PCL via LVM Holdings Pte Ltd in 2018, deal value ~$15m [Tier B — Breaking Travel News]; at acquisition, "more than 200 fully staffed properties" [Tier A — Dusit newsroom]. The brief's September 2018 month is not corroborated in these files.

How the concierge function is structured — this is the part that transfers:

1. The Elite Concierge is a separate, centralised layer, distinct from in-villa staff. The in-villa team (Villa Manager, senior butler, chef, housekeepers, gardeners, drivers, villa attendants) runs the property. The Elite Concierge books restaurants, cooking classes, in-villa massage, personal trainers, pre-stocked groceries, and performers [VERIFIED] Tier C — elitehavens.com.
2. Its job description matches SatuSatu's concierge almost exactly. Dusit AR2018 [Tier A]: "Villa managers and concierges use their local knowledge to source and plan such experiences on-demand… spa therapies to Balinese kite-flying lessons; yacht charters to visiting local artisans; personalized private ski-guides to last-minute reservations at top local restaurants." This is the closest published description of the SatuSatu concierge job in any collected source.
3. Continuity is the explicit product promise: "Our guests are managed by the same professional team from the initial booking, and throughout their stay" [Tier C]. Note this is a claim about one team across the whole journey — which is precisely what SatuSatu's two-queue architecture (general + Pass concierge) does not deliver.
4. The concierge is organised by source market, not by destination. Contact lines are AU +61, ID +62 361 737 498, TH +66, SG +65, plus an "other countries" line [Tier C]. For a 110-country guest base, the routing dimension chosen was language/time zone, not destination. That is a directly applicable design signal for a business serving inbound international travellers from one Indonesian time zone.

Staffing and cost: ⚠️ Elite Havens' concierge headcount and concierge cost are unverified — not found in collected sources. Dusit reports Elite Havens only inside a combined "Hotel Management" line (THB 788m in 2023, +73.2% YoY, driven by Kyoto openings, Middle East/Guam properties and Elite Havens together) [Tier A]. There is no segment disclosure and no cost line.

What can nonetheless be inferred, and it is the important part:

• The labour is in the property, not in the concierge. ~250–300 villas × ~12 staff ≈ 3,000–3,600 in-villa staff [INFERENCE from Tier A villa count × Tier B CEO quote], which reconciles with LinkedIn's 1,001–5,000 band. The concierge layer is thin enough to be invisible in a headcount that size. After 28 years, the closest real-world operator of "human concierge, curated by locals, in Bali" does not put its people in the concierge. It puts them in the delivery of the experience and runs coordination as a light central layer.
• Elite Havens is not a cost analogue and must not be used as one. Twelve staff per villa is supportable at luxury-villa ADR. SatuSatu's Pass is $59.95–$144.95 including a bundled eSIM. Elite Havens is a service-shape analogue — what the job consists of, how it is organised, what is centralised versus local — and nothing more.
• 🔴 The structural difference that matters most: Elite Havens is principal, SatuSatu is not. "Elite Havens is the only owner representative, exclusively marketing and managing all properties. All other agents must go via us for each elite haven" [Tier C — villamana.com]. Elite Havens can promise a concierge experience because it controls the supply, the staff, and the standard. SatuSatu is a reseller whose T&C disclaims operator performance, and whose Pool A supply arrives via GlobalTix. A concierge promise made over supply you do not control is a different and larger commitment than the one Elite Havens makes — and automating that promise (§4a.3.6) compounds the difference rather than reducing it.
• Scale reference for capacity planning: Elite Havens serves ~80,000 guests/year with a concierge layer small enough to be undisclosed. The relevant question for SatuSatu is not "how many concierges per pass" but "what did Elite Havens automate, standardise or simply decline to offer, in order to keep that layer thin over 28 years?" The collected sources do not answer it. It is the single best follow-up interview in this research.

4a.7 Benchmark summary table — everything Step 5 needs

Every row carries low/base/high and a tier. [V] = VERIFIED, [I] = INFERENCE.

Labour cost

Concierge workload

AI performance

AI and channel cost

Comparables

Consumer acceptance

4a.8 Open questions this step could not close

Ordered by how much they change the answer.

End of section 4a. Sections 4b and 4c to be appended below.