V2 hub
RS Telogorejo · Pre-Visit Assistant · PRD v2.0

A scope-down
before we commit.

We're an AI assistant layer that sits in front of patients — not a CRM, not a workforce. v2 clarifies that offering on the smallest credible surface.
Prepared for
RS Telogorejo
Semarang · Tim Direksi
Status
Draft · 16 May 2026
Supersedes v1 for prototype scope
Owner
Renlester
Engineering & Product
§ 0 · Why v2 exists

We sell an AI assistant.
Not a CRM. Not a workforce.
v2 makes that boundary explicit.

"Better to argue it on paper than discover the problem in front of the client."
— PRD v2, opening note

What we are. A first-layer AI assistant that sits in front of patients — answering information queries, routing symptoms to the right doctor, and forwarding confirmed bookings to whatever the hospital already uses.

What we are not. Not a CRM replacement. Not a labour-replacement workforce. Not the system of record for appointments, patients, or revenue. v1's framing accidentally pulled toward all three — v2 doesn't.

Why clarify now. Before the hospital tops up the first credit pack, they should know exactly what they're buying. The smaller scope is the clarity. v2 is the smallest credible build that makes the offering concrete on a real surface, with real billing, against a real boundary.

§ 3 · v1 → v2 in one table

Eight changes. Three are commercial. Five are scope.

Area
v1 — PRD 1.0
v2 — this prototype
Primary surface
WhatsApp + web
Web only
Human handoff
Required — escalation to 12 CS agents
Deferred · no handoff in v2
Commercial model
Monthly subscription · labour-replacement framing
Prepaid credits · usage-based deduction
CRM / HIS
Existing CRM stays · booking write via API
Same · still routes through hospital CRM
Reviewability
"Supervisor dashboard"
Built-in trace explorer, self-hosted · concretises v1
Retrieval
Curated content surface
Lexical (BM25) + embedding hybrid on the same content
Work primitives, permission ladder, reminders
Specified end-to-end
Deferred to v3 · v2 uses a flatter RAG + tool-call flow
LLM & payments
Not specified
GPT-4o-mini default / GPT-4o escalation · card top-ups
§ 2 · The honest part

Three pillars of v1 get weaker
before they get better.

v2 is a deliberate narrowing — and we should name what that costs us, not bury it.
§ 2.1 – 2.3 · Tensions with v1

If we don't name these now, we'll discover them in front of the hospital.

Tension · ROI

v2 is additive cost, not substitutive.

WhatsApp is where most CS labour goes. A web-only assistant doesn't displace the 12-agent line item meaningfully. The hospital keeps paying for the agents and pays us for AI conversations on top.
— Mitigation
Pitch v2 as a prototype of the assistant, not of the commercial model. Use v2 telemetry to project the v3 labour-replacement case.
Tension · Anticipation

v1 self-audited 3/5. v2 is closer to 2/5.

Removing WhatsApp + reminders + cancellation recovery leaves only web entry. The product moves toward "chat widget that answers questions" — exactly the framing v1 was written to escape.
— Mitigation
Keep the page-aware opener from v1 § 6.1. Different greeting based on which page the visitor entered from. Some situation-driven behaviour beats none.
Tension · Emergency

The third step of v1's emergency flow is impossible in v2.

v1 escalated emergency cases to the on-shift CS team with the full transcript. v2 has no CS team integration. Detection + ED contact still happen — real-time human notification does not.
— Mitigation
Conservative detection (over-trigger), prominent admin-panel logging, clinical-lead sign-off on the v2 copy. First thing restored in v3.
§ 2.4 · What we are not giving up

Six lines from v1 do not move.

The shape of the product narrows. The standards it is judged against do not.

— AI-first frame

Judged on completed patient journeys, not message volume.

v2 still measures itself by the work it gets done, not the words it produces.

— The clinical line

No diagnosis. No treatment recommendation. Routing only.

Same wording, same restraint as v1 §8.1. Sign-off by clinical lead before launch.

— Confidence floor

Below threshold, the assistant says so. It does not guess.

"I don't have a reliable answer — please contact reception." Always with the phone number.

— Reviewability

Every action structurally logged into the trace explorer.

Hospital staff and we can audit any conversation, any decision, any retrieval result.

— KB discipline

Curated, versioned content. Not a vector dump of arbitrary PDFs.

The retrieval index is only as good as what the hospital admin curates into it.

— The non-goal

Not replacing the hospital's CRM. Firmly out of scope.

v3 may earn into modules. v2 stays well clear. CRM remains the system of record.

§ 6 · Architecture

One assistant gateway. Five concerns. A trace on every span.

— Patient surface
Web widget · BI / ENembedded on rs-telogorejo
Assistant API gateway
— Per-turn pipeline
Credit ledgercheck + deduct · hard stop at 0
Retrieval · BM25 + embeddingpostgres FTS + pgvector · RRF
LLM callgpt-4o-mini default · gpt-4o on escalation
— Side effects
CRM/HIS bookingoutbound POST · hospital owns truth
Trace explorerretrieval · llm · tool · spans
Conversation log30-day default · configurable
— Back office
Admin panelconversations · KB · credits · settings
Payment processorcredit pack top-ups
§ 7.2 · Token cost analysis · draft, locks Sunday

A 5-turn conversation
costs us $0.01–$0.06.

1
5 turns is representative — some are 1–2, some are 10+. The cumulative input grows with history; output stays steady.
2
Per-conversation: ~20.2k input tokens, ~2k output tokens. 4o-mini ≈ $0.004. 4o ≈ $0.056.
3
Embeddings, tracing, infra: negligible against LLM spend. Card fees apply on top-ups, not on conversations.
4
Sunday's job: run 30 representative conversations through the prototype, ground these numbers in measured data.
Per 5-turn conversation
Input
Output
Total
GPT-4o-mini
$0.0030
$0.0012
$0.004
GPT-4o escalation
$0.0404
$0.0160
$0.056
Typical mix (90/10)
≈ $0.020
At 5× markup, the hospital pays roughly $0.05–$0.30 per conversation. For ~10,000 conversations/month, that's $500–$3,000/month — comparable to the current 12-CS-agent line, but additive, not substitutive.
§ 7.3 · Proposed credit packs

Hospital pre-pays. Hard stop at zero. No silent overage.

Removes the "is the AI worth IDR X/month?" objection. The hospital pays only for what they use, sees the meter, and controls the cap.

Pack · Starter
$100USD
≈ 1,000–2,000 conversations
— no bonus credit
Pack · Scale
$2,000USD
≈ 20,000–40,000 conversations
— +20% bonus credit ($400)
— Hard stop
When credits reach zero, the assistant refuses to invoke the LLM and shows a fixed "please contact reception" message in the visitor's language. No grace period. No degraded mode. Service resumes immediately on top-up.
§ 11 · Roadmap to v3 — i.e. v1's Phase 1

v3 is v1. v2 is the gate that earns the right to ship it.

Q0 · now · v2

Web-only prototype

Web widget, hybrid retrieval, conversation tracing, credit billing, admin panel. The smallest credible build.
  • Web widget (BI/EN)
  • Curated KB + RAG
  • Built-in trace explorer
  • Prepaid credits
  • CRM/HIS booking writes
— validates the assistant
v3 · Phase 1A

WhatsApp surface

The channel where the bulk of CS labour actually sits. The ROI story becomes substitutive, not additive.
  • WhatsApp Business API
  • Conversation-ID storage
  • BI-first patient writing
— restores ROI
v3 · Phase 1B

Human handoff & emergency

Escalation queue. CS-supervisor dashboard. Real-time emergency notification — restoring v1's third step.
  • Escalation queue
  • CS dashboard
  • Emergency real-time push
— closes emergency gap
v3 · Phase 1C

Anticipation restored

Reminders, cancellation recovery, work-primitive state machine, permission ladder at the action layer.
  • 24h + 2h reminders
  • Cancellation recovery
  • Work-primitive state machine
  • Permission-ladder enforcement
— anticipation 4–5/5
§ 10 · Before we build

Five things I need from you
before the prototype goes further.

01
Confirm the pivot. Web-only, no human handoff, credit pricing, integrate with existing CRM — say yes or push back. Better to argue it now than rebuild it later.
02
Clarify the CRM cost figure. Pivot notes show ~$4,000/month. PRD v1 shows IDR 40M (~$2,100). I'd like to know which is right before any commercial framing uses the number.
03
Booking API surface. Can the hospital CRM accept a booking POST? Does it expose available slots? If not, v2 falls back to a formatted email to reception — and I'll document that as the default.
04
Clinical sign-off on the v2 emergency copy. The real-time notification step is gone. I want the clinical lead — not me — to write the message the patient sees, and to sign off that the gap is acceptable for the prototype.
05
Monthly inquiry volume by channel. A guess of ~10,000/month is propping up the credit-pack sizing. Real numbers tighten everything — the math, the cap, and the v3 labour-replacement case.