DrinkPrime — COIL: Discovery & Solution Report

Status: Product discovery + solution design (chat-only). COIL — one intelligence layer behind every digital
support interaction. Grounded in independent web research (sourced & flagged below) and in our proven, already-running LLM-orchestration and
WhatsApp stack. Nothing here is built on DrinkPrime's systems — this is an outside-in analysis and a proposal. ·
Scope locked: chat only (WhatsApp + website chat + technician scheduling); voice is explicitly out of scope for now.
· Companion docs: Executive Summary · Technical Solution Architecture
· Proof-docs: RE-DEMO · LC-Telegram
· WhatsApp production setup · Vocily Labs · GVM dossier

North Star: The objective is not to automate customer support — it is to make every supported customer
interaction instant, consistent, and measurable.

0. TL;DR — what this is

• DrinkPrime is a real, well-funded, growth-stage "water-as-a-service" company — founded 2016 (Bengaluru), $18M+
  raised, ~₹340 Cr valuation, ~287 employees, ~3 lakh households, scaling toward 20 cities / 1M households. [VERIFIED]
• Their single most-documented customer complaint is support unresponsiveness — "impossible to reach. They never
  pick calls. NEVER." — followed by refund/deposit delays, technician no-shows, and filter-maintenance gaps. [VERIFIED]
  Based on publicly available evidence, customer-support responsiveness appears to be one of DrinkPrime's most visible
  operational challenges. This proposal focuses on that specific surface; the internal priority is DrinkPrime's to confirm.
• They have already gone "chat-first" — but with no AI and no clear escalation path. Their own blog says chat is
  "available during designated support hours" and they'll "do our best to respond as quickly as possible" — not
  instant, not 24/7, still all-human. Based on publicly observable customer-facing capabilities, we found no
  evidence of an AI-powered support layer with booking, reasoning, and contextual escalation among India's major
  water-purifier players. That gap is the wedge. [VERIFIED]
• The fix is COIL (Customer Operations Intelligence Layer) — the intelligence layer that sits between
  customers and business systems, making every digital support interaction instant, consistent, and measurable. Delivered
  here as an instant, 24/7 layer (WhatsApp + website widget) that answers, books, tracks, and escalates with context,
  attacking the exact #1 complaint — built on a working reference implementation that already runs, so the DrinkPrime
  work is configuration, integration, and rollout, not core product invention (§13).
• This is infrastructure, not a feature. It is the layer through which every routine digital support interaction
  flows — the operations backbone of a subscription business, working across customer support and field service, not
  just a widget bolted onto a website. Think of it as the customer-facing equivalent of a data layer or an API
  gateway: customers never touch business systems directly; every supported interaction flows through one operational
  intelligence layer. COIL is operational intelligence for a subscription business — it owns the continuous customer
  lifecycle (recharge · filter · refund · relocation · technician), not just a chat reply.
• Honest business framing: we do NOT know DrinkPrime's support headcount — so there is no salary-savings
  math here. The case rests on the verified CX gap + per-conversation operational leverage + 24/7 instant response,
  with the headcount stated as an explicit unknown and the value measured by KPIs, not guesses.

DrinkPrime's own homepage: "Unlimited Water starting at ₹399/mo," "48hr Installation" — a subscription promise that
runs 24/7 while support does not.

1. The actual scenario — who DrinkPrime is

In one line: A funded, fast-growing subscription water-purifier company whose product is loved enough to scale, but
whose service experience is its most public weakness.

DrinkPrime sells "water as a service" — you don't buy a purifier, you subscribe to one. An IoT-enabled RO/UV purifier
is installed in your home; you pay monthly; installation, lifetime maintenance, and filter replacement are included.

Plans & policy (drinkprime.in, cross-checked against review sites) [VERIFIED]:

• Security deposit: ₹1,500, refundable — but only fully refunded after the lock-in period with no dues;
  cancelling inside lock-in forfeits the ₹1,500. Refund processed 5–7 business days after device pickup. [VERIFIED]
• Included: installation, lifetime free maintenance, free filter replacement, 7-day risk-free trial, free relocation.

Why this matters for support: the subscription model means the customer relationship is continuous — recharges,
relocations, filter changes, service requests, cancellations, refunds. Support isn't a one-time event; it's a recurring
operational surface that scales linearly with households. At 1M households that surface is enormous — exactly why it
needs an operations layer, not a bigger inbox.

2. Executive Business Case — the case in one table

In one line: Five business objectives, the current human-bound state, and the state COIL delivers.

Each row maps to a verified gap in DrinkPrime's current operation (see §3, §6, §7) and to a capability already proven in
our stack (see §13). The rest of this report is the evidence and the build behind this table.

3. Current operational scenario — how support runs today

In one line: Every routine chat — FAQ, billing, pricing, refunds, filters, installation, technician booking,
cancellation — funnels through a human on Freshchat, only during business hours, one conversation at a time.

DrinkPrime has already declared "chat-first" — but it is human chat over Freshdesk + Freshchat, with no AI
layer, no stated response time, and no published escalation logic. Their own blog tells customers chat is
"available during designated support hours" and that they'll "do our best to respond as quickly as possible" — i.e.
not instant, not 24/7, and every conversation lands on a person. [VERIFIED]

DrinkPrime has publicly committed to chat as the primary channel — but the engine behind it is humans on Freshchat,
during designated hours, with no AI and no published SLA.

The correction, stated up front: an earlier internal draft assumed a specific support headcount and computed salary
savings from it. That headcount is an assumption, not a fact — there is no public number for DrinkPrime's support team
[❌ UNVERIFIED]. What is verifiable: ~287 total employees and active hiring for chat-support roles. This report therefore
contains no headcount and no salary-savings figure and frames value differently (see §6 Financial Impact and §18 KPIs).

Channels they expose today [VERIFIED]:

What DrinkPrime itself says chat handles (their blog, direct framing) [VERIFIED]: "Service and maintenance
requests · Filter replacement updates · Water quality concerns · Subscription and billing queries · Product information
and general account questions." Chat "does not replace the human element"; customers "still interact with trained
support professionals." No escalation criteria, no response-time SLA, and no tool name are disclosed in the blog.

The funnel today — every category lands on a human, inside business hours:

        RECURRING CHAT CATEGORIES (relative load, not absolute volume)
   ┌───────────────────────────────────────────────────────────────────┐
   │  FAQ / product info      ███████████ (high)                        │
   │  Filter replacement      ███████████ (high)                        │
   │  Billing / recharge      ████████    (med-high)                    │
   │  Pricing / plans         ████████    (med-high)                    │
   │  Installation booking    ███████     (med)                         │
   │  Technician / service    ███████     (med)                         │
   │  Refund / deposit        █████       (med)                         │
   │  Cancellation            ████        (lower)                       │
   └───────────────────────────────────────────────────────────────────┘
                                   │
                                   ▼
                        ┌─────────────────────┐
                        │   HUMAN AGENT(S)     │   ◄── business hours only
                        │   on Freshchat       │       (10 AM–7 PM stated for phone;
                        │   one chat at a time │        chat = "designated hours")
                        └─────────────────────┘
                                   │
                                   ▼
                        Freshdesk ticket / CRM note
                                   │
                                   ▼
                        (maybe) follow-up — customer often chases

Engineering estimate based on the documented support surface — not DrinkPrime internal data; replace with real
numbers once shared. The bars above are relative category load inferred from the blog's own list + the complaint
mix; they are not message counts.

The structural fact: the categories at the top of that funnel are deterministic — known answers, known procedures.
Routing them through a scarce, business-hours human adds latency and cost without adding judgment. That is the gap COIL
closes as a front door. The split of which intents the layer absorbs versus which stay with a human is the canonical automation boundary in §11.2.

4. Capability Maturity Model — where DrinkPrime is, where this takes them

In one line: Customer-operations maturity runs from email-only to predictive; DrinkPrime sits at Level 1 today, and
this proposal moves them to Level 3 — past the rule-based-bot trap most companies fall into.

Read the model honestly. DrinkPrime has already done the hard work of moving customers to chat (Level 1) — that is a
real step beyond Level 0 email/phone. The trap is Level 2: most companies "add a chatbot," wire up a keyword /
decision-tree menu, and it dead-ends customers into frustration (see §10 — why most support bots fail). This proposal
skips that trap and goes straight to Level 3: COIL — a reasoning Brain with memory, a knowledge base, the ability to
take action, and a clean human escalation path. Level 4 (Predictive Customer Operations) — where the layer
anticipates filter-due, lock-in-ending, and churn-risk events before the customer asks — is on the roadmap (Phase 3, §16) once integrated with their data.

5. Customer lifecycle — where COIL helps at each stage

In one line: A DrinkPrime subscriber touches support across a dozen predictable lifecycle stages, and COIL adds value
at almost every one — instantly and at any hour.

Because this is water as a service, the relationship is a loop, not a sale. Here is the full lifecycle, then a
stage-by-stage map of where the AI helps.

   Website visit ──▶ Plan selection ──▶ Subscribe ──▶ Installation ──▶ Using purifier
        ▲                                                                     │
        │                                                                     ▼
     Renewal                                                              Recharge
        ▲                                                                     │
        │                                                                     ▼
      Refund ◀── Cancellation ◀── Technician visit ◀── Filter replacement ◀── Service request
                                          ▲                                    │
                                          └────────────────────────────────────┘
                                          (relocation / annual service re-enter the loop)

The point: support is not a one-time event in this model — it recurs at every loop. An operations layer that is
instant and always-on compounds across the whole lifecycle, not just at the front door.

5.1 Customer personas — who the AI serves

In one line: Every DrinkPrime customer is in one of three states — joining, staying, or leaving — and COIL adopts a
distinct persona for each.

The leaving customer persona is the highest-leverage one: on a subscription product, a clean, honest, instant answer
about lock-in and refund timeline at the moment of cancellation is the difference between a recoverable retention
conversation and a public "Water as a Service Trap" review.

6. Financial Impact — operational economics (no money math)

In one line: We do not know DrinkPrime's costs, so we make no rupee claim — but the operational mechanics are simple:
every FAQ the AI resolves is one fewer interruption for a support agent.

• Before: customer asks → a human spends ~5 minutes → the company pays for agent time + management overhead + a
  Freshchat seat + training + QA.
• After: customer asks → the AI answers in ~15 seconds → a human is involved only if judgment is required.
• Principle: every FAQ the AI resolves is one fewer interruption for a support agent. This is operational leverage,
  not a rupee saving. (Replace with real economics once DrinkPrime shares volume/team data.)

   BEFORE (per routine query)              AFTER (per routine query)
   ┌──────────────────────────┐           ┌──────────────────────────┐
   │ customer asks            │           │ customer asks            │
   │   → human ~5 min         │           │   → AI ~15 sec           │
   │   + management overhead  │    ──▶    │   (human only if         │
   │   + Freshchat seat       │           │    judgment required)    │
   │   + training + QA        │           │                          │
   └──────────────────────────┘           └──────────────────────────┘
        one agent-interruption                 zero agent-interruption
        (every single time)                    on the deterministic share

Engineering estimate based on the documented support surface — not DrinkPrime internal data; replace with real
numbers once shared.

Why no rupee figure? Because the two numbers that would make it concrete — chat volume and support-team size — are
both unknown (§19 Assumptions). The honest version of the financial case is leverage, not savings: at hundreds of
thousands of households the routine share is large, and on a subscription model that surface grows linearly with the
20-city / 1M-household goal. Give us real volume and team data and this becomes a concrete model.

7. The issue — what actually breaks

In one line: Every routine query is routed through a human, during business hours, reactively — so volume,
after-hours demand, and consistency all break at scale.

1. Human-in-the-loop on deterministic work. Recharge help, plan/pricing questions, "is my filter due?", "where's my
   refund?", booking a technician — these have known answers and known procedures. Routing them through a person adds
   latency and cost without adding judgment.
2. Business-hours-bound. Their own blog admits "designated support hours." A subscriber whose purifier stops at 10 PM
   waits until morning. The subscription is 24/7; the support is not.
3. Reactive, not proactive. Filters, refunds, and recharges are predictable events. Today the customer chases the
   company ("Nobody called"). The system should reach out first.
4. Fragmented context. Customers report re-explaining the same issue to different agents. There's no single,
   structured memory of the conversation following the customer.
5. A "chat-first" promise without an AI engine. Going chat-first raises the expectation of speed while the back-end
   is still humans on Freshchat — which widens the gap between promise and reality.

8. The pain & suffering (sourced)

In one line: The complaints are remarkably consistent across platforms, and they're about service responsiveness,
not the water — which is precisely what COIL can address.

Based on publicly available evidence, customer-support responsiveness appears to be one of DrinkPrime's most visible
operational challenges. This proposal focuses on that specific surface; the internal priority is DrinkPrime's to confirm.
The "most-documented complaint" framing below is sourced and directional — it is not a claim about DrinkPrime's top
internal bottleneck.

Sample-size honesty: ConsumerComplaints.in shows 11 structured complaints — a small set, so treat the
percentages as directional, not statistical. The heavier volume signal is the Google Play rating of 3.9★ across ~4.6k
reviews — "good product, frustrating service" is the dominant pattern across both. [VERIFIED]

Representative public complaints on ConsumerComplaints.in — the recurring theme is unresponsiveness and unresolved
requests, not water quality.

The recurring themes, with verbatim customer quotes [VERIFIED] (ConsumerComplaints.in / CancelMates):

The customer's lived experience: good water, then a wall of silence the moment something goes wrong — unanswered
calls, promised callbacks that never come, deposits stuck for weeks, technicians who don't show. CancelMates frames the whole thing as a "Water as a Service Trap."

Google Play: 3.9★ across ~4.6k reviews — the volume signal behind the "good product, frustrating service" pattern.

8.1 Pain matrix — customer pain → company pain → AI opportunity

8.2 Volume distribution (relative load by category)

Engineering estimate based on the documented support surface — not DrinkPrime internal data; replace with real
numbers once shared. Stars are relative category load inferred from the blog's own chat-scope list + the complaint
mix — not message counts and not DrinkPrime data.

The company's cost of this pain:
- CSAT / brand: 3.9★ and public "trap" framing on a subscription product where churn is the whole business.
- Churn & refund-chasing loops: every "where's my refund / why am I charged" cycle is pure cost and a cancellation risk.
- Competitive bleed: Livpure Smart (founded 2018, premium, ₹429+) is independently reviewed as faster on
after-sales and more reliable on the app / TDS monitoring — DrinkPrime's price advantage is undercut by its service
reputation. [VERIFIED — review sites]

9. Root-cause analysis

In one line: It's not a water problem or even a "bad agents" problem — it's an architecture problem: deterministic
work flows through a scarce, business-hours, human bottleneck with no shared memory.

Customer query
      │
      ▼
Human reads it ── searches knowledge ── replies ── creates ticket ── updates CRM ── escalates ── (maybe) follows up
      ▲                                                                                              │
      └──────────────────────────── only during support hours, one conversation at a time ──────────┘

• Most of that chain is deterministic, not judgment-intensive — so the human is the bottleneck, not the value-add.
• It doesn't scale with households. More subscribers = linearly more routine chats = more hires or longer waits.
• It's reactive. Predictable events (filter due, lock-in ending, recharge date, refund pickup) aren't pre-empted.
• Context is lost between agents, forcing customers to repeat themselves — the thing they hate most.

10. Why most support bots fail (and this doesn't)

In one line: The water-purifier sector's idea of a bot is a keyword/decision-tree menu that dead-ends; COIL is a
reasoning Brain with memory, a knowledge base, the ability to take action, and a clean escalation path.

This is the Level 2 → Level 3 jump from the maturity model (§4): a rule-based chatbot is exactly the dead-end most
companies settle for, and exactly what COIL is not. Every row above is already running in our stack (see §13). The clinic
booking bot books on a deterministic numbered-slot menu at verified ~100% booking accuracy; the real-estate Brain
reasons, scores, captures, and escalates with context; the Config+FAQ pattern lets non-engineers change behavior by editing a sheet.

11. The solution — COIL (chat only)

In one line: COIL sits between customers and business systems — one layer in front of WhatsApp and the website that
resolves the routine instantly, captures and schedules technician visits itself, and hands the hard 20% to a human with the full story attached.

Scope boundary (locked): chat only — WhatsApp + website chat + technician scheduling. No voice in this phase.

COIL is one layer with five plain capabilities (on a modern LLM orchestration layer) — a Brain (Gemini decision engine, one decision per turn) · a Knowledge Base (Config + FAQ) · Actions (reply / ticket / booking) · Human Assist (handoff with full context) · Customer Operations Analytics (every turn becomes a structured operational event in the Event Store; the aggregate — intent distribution, escalation %, resolution type, cancellation/refund signals — is product feedback, not just support data).

COIL resolving a real DrinkPrime issue end-to-end: answer → troubleshoot → book → ticket, in seconds, without a human
in the loop.

What COIL resolves end-to-end:

Anti-hallucination is a feature: anything outside the knowledge base (an exact dispute amount, an approval) is
deferred to a human, never fabricated. The KB is the single source of truth — editing it changes COIL's answers with no
code change.

The durable asset isn't the chat — it's the event. COIL doesn't just answer and forget: every turn is upserted as one
structured operational event (who, channel, intent, lifecycle stage, and the action flags it raised — see the
Operational Event Store).
A real recorded event makes this concrete — a website visitor's cancellation came back as
Intent: Cancel Subscription · Stage: Escalated · NeedsHuman: Yes · AlertRep: Yes · OptOut: Yes, with the summary
"Customer wants to cancel subscription due to security deposit requirement." That single row isn't just a support
ticket — it's product feedback: at volume, rows like it become a measurable signal that the security-deposit policy is
driving cancellations — an insight a chat transcript buried in an inbox can never surface.

11.1 Intent library — the canonical taxonomy

In one line: Every customer message is classified into one of these seven families, used consistently across all
three documents in this suite.

• Sales / Onboarding — pricing · plans · offers · cities & availability · how-it-works · plan recommendation · book installation.
• Subscription / Account — recharge · top-up · plan upgrade/downgrade · pause/vacation · renewal · login · invoice.
• Billing / Payments — deposit · refund status · billing dispute · charge/cycle query · payment failure.
• Technical / Device — no water · low pressure · leakage · bad taste · WiFi/connectivity · app sync after recharge · error light · filter health.
• Service / Field — book technician · reschedule · track engineer · filter replacement · annual service · relocation · uninstallation.
• Policy — lock-in · cancellation · water quality/TDS · maintenance/warranty terms.
• Meta — greeting · smalltalk · human-handoff request · complaint/escalation · opt-out/STOP.

11.2 Automation boundary — who handles what

In one line: COIL absorbs the deterministic majority; humans keep the judgment — and COIL escalates to them with
full context.

   ┌──────────────────────────────────────┐   ┌──────────────────────────────────────┐
   │           AI HANDLES                  │   │   HUMAN HANDLES                       │
   │     (instant, 24/7, KB-only)          │   │ (AI escalates WITH full context)      │
   ├──────────────────────────────────────┤   ├──────────────────────────────────────┤
   │ • Pricing / plans / offers            │   │ • Refund approval                     │
   │ • FAQ / how-it-works                  │   │ • Payment-dispute resolution          │
   │ • Cities & availability               │   │ • Policy exceptions                   │
   │ • Policy explanations                 │   │ • Angry / abusive customers           │
   │   (lock-in, deposit, refund TIMELINE) │   │ • Legal                               │
   │ • Booking / reschedule / track        │   │ • Anything account-specific           │
   │ • Recharge guidance                   │   │   not in the knowledge base           │
   │ • Ticket creation + (post-int) status │   │                                       │
   │ • Device troubleshooting tree         │   │   ▲                                   │
   │ • Filter status / requests            │   │   │  full conversation + structured   │
   │ • Relocation capture                  │───┼───┘  summary handed over —            │
   │ • Plan recommendation                 │   │      customer never re-explains       │
   └──────────────────────────────────────┘   └──────────────────────────────────────┘

11.3 Estimated conversation coverage (per intent → AI %)

Engineering estimate based on the documented support surface — not DrinkPrime internal data; replace with real
numbers once shared. Percentages are per-intent resolution capability of the AI, not a share of total volume.

Engineering estimate based on the documented support surface — not DrinkPrime internal data; replace with real
numbers once shared.

Read this honestly: the AI's job is to resolve the deterministic ~60–80% of conversations instantly and escalate
the judgment 20% with full context — not to "replace the team."

12. Before / After workflow

In one line: Today every routine chat waits for a human inside business hours; tomorrow COIL resolves the routine
instantly and hands only the judgment 20% to a human — with the full story attached.

BEFORE — human-first, business-hours, reactive:

 Customer (any hour)
        │
        ▼
   ┌──────────────┐   queued, business hours only
   │  Freshchat   │ ───────────────────────────────┐
   │   inbox      │                                 │
   └──────────────┘                                 ▼
        │                               ┌────────────────────────┐
        │ wait...                       │   HUMAN AGENT           │
        ▼                               │  • reads & re-reads     │
   (after-hours →                       │  • searches knowledge   │
    next day, or lost)                  │  • types reply          │
        │                               │  • opens ticket         │
        ▼                               │  • updates CRM          │
   Customer often                       │  • (maybe) follows up   │
   chases again ◀───── re-explains ─────│  one chat at a time     │
                                        └────────────────────────┘
        Result: "They never pick up." · re-explaining · next-day · 3.9★

AFTER — AI-first, 24/7, proactive, context-preserving:

 Customer (any hour, WhatsApp OR website)
        │
        ▼
   ┌─────────────────────────────────────────────┐
   │                  C O I L                    │  ◄── Config + KB (plans, prices,
   │  (Gemini — one decision/turn, KB-only,       │       deposit/lock-in/refund, FAQ)
   │   per-user memory, multilingual)             │
   └─────────────────────────────────────────────┘
        │            │              │                 │
        ▼            ▼              ▼                 ▼
   Instant      Open / track   Book technician   Escalate to HUMAN
   answer       a ticket       slot (deterministic   WITH full context
   (~seconds,   (CRM upsert)   numbered menu)        summary attached
    24/7)                                            (refund approval,
        │                                             dispute, abuse, legal)
        ▼
   Proactive cron: filter-due · lock-in-ending · recharge · refund-pickup
   (reaches out FIRST; honors STOP / opt-out)
        Result: instant · always-on · proactive · human handles only judgment

13. What's real today — a working reference implementation

In one line: COIL is built on a product that already runs — validated through internal production-grade workflows and
a live customer-support demonstration. The DrinkPrime-specific work is configuration, integration, and rollout, not
core product invention. This is the honest answer to the one question every buyer asks: "how much of this actually
exists?"

Why this distinction matters. "Proven components" undersells it: these aren't loose parts waiting to be assembled —
they run together, today, as one decision pipeline (message → normalize → Brain → decision JSON → deterministic
rules → booking / ticket / escalation → reply). The regression suite in coil-build/TEST-CASES.md,
grounded in the live Brain (coil-build/brain.js), exercises exactly these boundaries — including
what COIL refuses to do (approve refunds, invent dates/slots/cities/prices, leak the prompt, change roles).

The left column already exists; DrinkPrime is integration + configuration of a product that runs. The reference
implementation is documented in the proof-docs: WhatsApp setup ·
RE-DEMO · LC-Telegram ·
Vocily Labs.

The orchestration layer is a modern LLM orchestration layer (our internal engine — n8n on a GCP VM + Gemini 2.5 Flash Brain) — the
same internal engine behind the labs, clinic, and real-estate bots. COIL is the customer-facing product built on it. See
GVM system dossier.

13.1 Competitive matrix — capability vs. the sector

In one line: Based on publicly observable customer-facing capabilities, we found no evidence of an AI-powered
support layer with booking, reasoning, and contextual escalation among India's major water-purifier players; COIL is a
clean superset of what DrinkPrime and Livpure expose today.

Cells reflect publicly observable customer-facing capability as of research date; [⚠️] where inferred. DrinkPrime
may have internal pilots we can't see.

14. Architecture at a glance

In one line: Two front doors, one brain, four actions, one proactive loop.

COIL: two channels normalize into one Gemini Brain backed by a Config + Knowledge Base, with four actions and a
proactive follow-up loop.

                         Customer
                  ┌──────────┴───────────┐
            Website chat              WhatsApp
                  └──────────┬───────────┘
                         Normalize          (channel → canonical {channel, userId, text, lang})
                             │
              Config + Knowledge Base  ◄──  Google Sheet
                             │              (DrinkPrime facts · plans · prices · deposit/lock-in/refund policy · FAQ)
                             │
                          B R A I N         (Gemini 2.5 Flash — one decision per turn;
                             │               answers ONLY from the KB; defers unknowns to a human)
        ┌────────────┬───────┴────────┬───────────────────┐
     Reply        Ticket / CRM      Visit              Human handoff
   (instant,    (create + track,   scheduling         (+ rep alert with
    24/7)        Google Sheet)     (technician slot)    full context summary)
                             │
                     Follow-up cron           (filter-due · lock-in-ending · recharge · refund-pickup nudges;
                                               honors STOP / opt-out)

(Full node-level build spec lives in the companion Technical Solution Architecture.)

15. New / additive for DrinkPrime (the small delta)

In one line: Most of the work is configuration, not engineering; the genuinely new pieces are small and additive.

• Knowledge-base config — DrinkPrime's plans, prices, deposit/lock-in/refund policy, water-quality facts, relocation
  rules, and a curated FAQ, loaded into the Config/FAQ sheet. (This is data entry + curation, not code.)
• A DrinkPrime "intent set" for the Brain — the seven-family taxonomy in §11.1 (service request · filter status ·
  recharge/billing · refund/deposit · relocation · cancellation · device troubleshooting · human handoff).
• Technician scheduling tuned to visits — slot menu + confirmation (reusing the clinic booking pattern).
• Ticket-status & refund-status patterns — captured + handed off in Phase 1; live status once integrated (Phase 3).
• Website chat widget — a thin embed pointing at the same Brain the WhatsApp number uses.

(Per the locked scope, this stays at design level here — the node IDs and build spec live in
Technical Solution Architecture, modelled on RE-DEMO.)

16. Product Roadmap (all chat-only)

In one line: Three phases — prove instant resolution, harden for production, then close the loop on live status —
each building on proven parts.

   PHASE 1 — Chat MVP            PHASE 2 — Production            PHASE 3 — Deep integration
   (demo-grade, days)            (safe at volume)                (close the loop on status)
   ┌────────────────────┐        ┌────────────────────┐         ┌────────────────────────┐
   │ • FAQ              │        │ • Freshdesk wiring  │         │ • Analytics            │
   │ • Pricing          │  ──▶   │ • CRM               │   ──▶   │ • Sentiment            │
   │ • Booking          │        │ • WhatsApp Cloud API│         │ • Prediction           │
   │ • Ticket           │        │ • Notifications     │         │ • Auto-escalation      │
   │                    │        │   (proactive nudges)│         │ • Dashboard            │
   └────────────────────┘        └────────────────────┘         └────────────────────────┘
     Prove instant                 Make it safe at                Level 4: Predictive
     resolution                    volume + proactive             Customer Operations

• Phase 1 — FAQ · Pricing · Booking · Ticket. Website widget + WhatsApp (WAHA for the pilot) · KB of DrinkPrime
  facts/plans/policy · FAQ resolution · service-ticket capture · technician slot booking · human handoff with context.
  Goal: prove instant resolution, days not months.
• Phase 2 — Freshdesk · CRM · WhatsApp Cloud API · Notifications. Meta WhatsApp Cloud API (opt-in, approved
  UTILITY templates, 24-h window rules) · proactive nudges (filter-due / recharge / refund-pickup) · STOP/opt-out
  compliance · quality-rating watch. Goal: make it safe at volume.
• Phase 3 — Analytics · Sentiment · Prediction · Auto-escalation · Dashboard. Wire to their Freshdesk/ticketing +
  billing/subscription so the layer reads/writes real ticket, recharge, and refund status (vs. capture-and-handoff) ·
  support analytics · sentiment-driven auto-escalation. Goal: close the loop on status and reach Level 4 (Predictive
  Customer Operations, §4).
• Where it can go (future, not this scope). The same layer can later extend to pre-sale guidance, voice, predictive
  maintenance, and other verticals — explicitly future, out of this engagement's scope. Today's scope is firmly
  customer support and field service, chat only.

17. Business case (honest)

In one line: The case is the verified experience gap + per-conversation operational leverage + 24/7 instant response —
not a headcount-reduction number we can't substantiate.

• No fabricated savings. We do not know the support team size; there is no headcount and no salary-savings figure in
  this report. If DrinkPrime shares actual chat volume and team size, the model becomes concrete — until then, value is
  framed by KPIs.
• Operational leverage. Each routine chat the AI auto-resolves (FAQ, ticket status, recharge, booking) is one fewer
  agent interruption instead of an agent-minute (§6). Across hundreds of thousands of households, the routine share is large.
• 24/7 instant first response. Their own blog concedes "designated support hours" and "do our best to respond as
  quickly as possible." Instant + always-on is a step-change on the exact complaint customers raise.
• Consistency & transparency. Policy-accurate deposit/lock-in/refund answers, every time, in the customer's language —
  this shrinks the refund-chase loop that drives both cost and churn.
• Cheap to run. Gemini + n8n + WhatsApp messaging fees (UTILITY templates ~₹0.115/msg on the official API) — low and
  predictable relative to support cost.
• Strategic leverage. Support that scales with configuration, not hiring — directly serves the 20-city / 1M-household
  plan.
• Why now, not next year. Waiting doesn't de-risk this — it raises the cost of the same decision: the first-mover
  window narrows as AI support commoditizes; support volume compounds toward the 1M-household goal; customer expectations
  have already shifted to instant; and every month of silence compounds the public 3.9★ reputation cost.

18. KPIs — the numbers that matter

In one line: Measure the gap closing; don't guess the headcount. The KPIs span support responsiveness and the
broader business outcomes COIL moves.

Engineering estimate based on the documented support surface — not DrinkPrime internal data; replace with real
numbers once shared.

18.1 Expanded success metrics — beyond support

In one line: Because the layer touches the whole lifecycle (§5), it moves metrics well past first-response time — and
every one of these is measured, not guessed.

• Lead-to-subscription conversion — the layer answers pricing/plan questions and books installs 24/7, at the moment
  of intent.
• Technician-booking completion rate — share of booking conversations that end in a confirmed, deterministic slot.
• Repeat-contact rate — how often a customer has to come back about the same issue (structured memory should drive
  this down).
• Customer Effort Score (CES) — how hard it was to get the answer; the core experience metric.
• Knowledge-base utilization — which KB entries resolve the most conversations (and which gaps need curation).
• AI containment rate — share of conversations resolved without escalation to a human. The headline operational KPI.

All of these are measured from the layer's own logs and the CRM — none are guessed. They are the inputs that, once joined
to DrinkPrime's volume and team data, turn the operational-leverage story (§6) into a concrete model.

19. Risk register

In one line: Each material risk has a built-in mitigation already proven in our stack.

20. Assumptions (separate from verified facts — these are NOT commitments)

In one line: These are explicit working assumptions, clearly fenced off from the verified-fact canon in §25 — none of
them is a fact or a commitment.

• DrinkPrime's internal ticket / chat volumes are unknown.
• Freshdesk (and billing) API availability is assumed for Phase-3 live status.
• Technician scheduling integration depends on DrinkPrime's scheduling & dispatch process.
• The existing knowledge base / FAQ content can be exported for curation.
• Support-team size is unknown [❌ UNVERIFIED].

21. Honest limits & risks

In one line: COIL fixes responsiveness, transparency, and booking — it does not fix the physical service.

• The layer can't perform field ops. Technician no-shows, slow refund processing, and filter-replacement
  execution are field-ops/finance problems. The layer books, tracks, nudges, and escalates with context — but a
  no-show stays a no-show until operations and finance deliver. Be candid about this with DrinkPrime: chat removes the
  silence, not the truck roll.
• Real-time status needs integration. Live ticket/recharge/refund status requires wiring into their Freshdesk +
  billing systems (Phase 3). Until then the layer captures and hands off — still a large improvement, but not live status.
• Knowledge-base quality gates resolution. Anti-hallucination means anything not in the KB is deferred to a human.
  Resolution rate is only as good as the curated KB.
• WAHA is demo-only (unofficial WhatsApp, ban risk) → Meta WhatsApp Cloud API for production (opt-in + templates).
• Gemini free-tier quota (~250 req/key/day, 6-key rotation, shared with other bots) → enable billing on one key for
  production volume.
• Support headcount is unknown [❌ UNVERIFIED] — every DrinkPrime-internal number (chat volume, team size, ticket
  mix) is unknown until they share it; the solution scope is firm, the ROI specifics are pending their data.
• This is an outside-in proposal. It touches none of DrinkPrime's systems and nothing on our VM.

22. Procurement comparison — why not just buy Freshworks / Zendesk / Intercom AI?

In one line: Those are excellent general-purpose support-AI platforms — but COIL is not competing with them on breadth; it's a purpose-built operations layer for a subscription business, and it sits in front of a stack like Freshworks rather than replacing it.

It's the right question to ask, and the honest answer is: if the goal were a broad, horizontal helpdesk AI, the incumbents are strong, mature, and well-integrated. The reason a different tool earns its place here is category, not price. Freshworks Freddy, Zendesk AI, and Intercom Fin are designed to deflect tickets and draft replies across any industry. COIL is designed around the specific shape of DrinkPrime's business: a recurring purifier subscription where the customer relationship is continuous (recharge, filter, refund, relocation, technician visit) and where the high-value action is deterministic field-service booking, not just a good answer.

The comparison below is at the level of category posture — what each kind of tool is built to optimize for. It does not assert competitor internals: any modern platform can be configured toward many of these with enough services work. The point is what each is purpose-built for out of the box. Cells marked [⚠️] are inferences about typical posture, not claims about a specific tenant's deployment.

Where the incumbents are genuinely stronger — and we'll say so. Breadth of channels, depth of integrations, marketplace ecosystems, and battle-tested scale are real advantages of the big platforms, and we're not going to pretend otherwise. If DrinkPrime wants a single horizontal helpdesk spanning email, phone, social, and chat across every team, that is squarely their territory. COIL is intentionally narrower: chat-only, support + field service, today.

Where COIL earns its place — honestly, on category. The water-as-a-service model means the most valuable interaction isn't "answer the FAQ," it's "diagnose the device, open the ticket, and book the technician end-to-end without a human." That deterministic booking, plus subscription-lifecycle intents (recharge/filter/refund/relocation) treated as first-class, plus a knowledge-first stance that refuses to invent a price or a refund status, plus proactive lifecycle nudges, plus the ability to sit in front of an existing Freshdesk/CRM rather than demand a migration — that's an operations layer, not a horizontal helpdesk. A general platform can be configured toward some of this; COIL is built for it.

The deciding distinction is posture, not feature count. A horizontal platform optimizes ticket deflection across all customers; an operations layer optimizes the lifecycle of one subscription relationship. The question isn't "which has more features" — both can grow features. It's "which is shaped like DrinkPrime's actual problem." For a continuous-relationship subscription where field service is the hard part, the operations-layer shape fits.

The wedge, in one line: COIL is not a cheaper Freshworks — it's a different category. It's an operations layer for a subscription business, and it deploys in front of Freshworks/Zendesk/Intercom, not instead of them.

23. Operational safeguards — "what if the AI gives a wrong refund answer?"

In one line: The honest answer to "what could go wrong" is that money, legal, the unknown, and the
low-confidence case never resolve on the AI's word — they route to a human, and the AI is built to defer rather
than invent.

This is the procurement-grade restatement of the automation boundary (§11.2): not a promise that nothing goes
wrong, but a set of hard rules that decide which failures are even possible. Each rule below is written as a
direct answer to a skeptical founder's question.

23.1 The rules — each as an answer to "what could go wrong"

• "What if it gives a wrong refund answer?" → Money goes to a human. COIL explains the refund policy and
  timeline from the knowledge base, and it can capture the request — but it never approves, quotes, or
  confirms a refund amount, a payment-dispute outcome, or a deposit settlement. Every money decision escalates
  to a human with the full thread attached. The AI's coverage on refund approval and billing-dispute
  resolution is 0% by design (§11.3).

• "What if it makes a policy or legal commitment we can't honour?" → Legal goes to a human. Anything that
  reads as a legal position, a contractual exception, or a policy exception (versus the published policy) is
  escalated, never decided. Legal coverage is 0%.

• "What if a customer asks something we never told it about?" → Unknown / off-KB goes to a human. COIL is
  KB-only. If a question falls outside the curated knowledge base — an account-specific status it can't see,
  a scenario nobody loaded — it does not improvise an answer. It says it will get a human, and escalates with
  context. Anything account-specific that isn't in the knowledge base is a human's call.

• "What if it's only 60% sure?" → Low-confidence goes to a human. When the Brain's reasoning doesn't clear
  the confidence bar for a turn, the default is to escalate, not guess. The design bias is always toward the
  human when in doubt — a deferred answer is recoverable; a confident wrong answer is not.

• "What if it just makes up a number?" → It can't — KB-only, never invents. The Brain answers only from the
  knowledge base. It never invents a price, a plan, a status, an amount, or a date. If the knowledge base
  doesn't contain it, the AI doesn't state it — it defers. This is the single anti-hallucination rule the whole
  layer is built around: "Anything outside the KB (a dispute amount, an approval) is deferred to a human, never
  fabricated." (§10).

• "What if a customer wants us to stop?" → STOP / opt-out is honored instantly. Any opt-out is respected
  immediately, including on the proactive nudge channel (filter-due / recharge / refund-pickup). The customer is
  never trapped in an automated loop.

• "What if the customer just wants a person?" → Human chat stays available. COIL assists; it never forces.
  A human-handoff request is a first-class intent in the taxonomy (Meta family). The existing human chat path
  (Freshchat) stays on; COIL sits in front of it and escalates into it with a structured summary — the customer
  never re-explains, and a person is always reachable.

• "What if the AI starts saying the wrong thing tomorrow?" → Nothing reaches customers without KB curation and
  approval. The AI's answers are bounded by the knowledge base, and the knowledge base is curated and approved
  before publish — non-engineers change behaviour by editing a reviewed Config + FAQ sheet, not by the model
  deciding on its own. What the layer is allowed to say is a controlled, reviewable artifact.

• "What if COIL itself goes offline?" → Chat falls back to humans; nothing is lost. COIL sits in front of the
  existing human support. If it is down or disabled, chat automatically routes to that human support, DrinkPrime's
  current setup keeps working untouched, COIL can be switched off instantly, and no customer data is lost — it is
  outside-in, so DrinkPrime's systems remain the source of record. There is no degraded mode to design for.

23.2 Trigger → action

Read this honestly: safeguards don't make failure impossible — they make the expensive failures
(a wrong refund, a bad legal commitment, an invented number) structurally out of reach, because those paths
are routed to a human by design rather than left to the AI's discretion. And because the layer is outside-in
(chat only, touching none of DrinkPrime's systems), the ultimate safeguard is the simplest one: human chat is
always on, and COIL can be flipped off instantly with nothing to unwind.

24. How soon can we pilot it? — rollout & success criteria

In one line: We don't go big-bang — we earn each step. COIL starts on a contained cohort, every gate has a one-flip
rollback, and we expand only on evidence; because it's outside-in, there is nothing to unwind if we stop.

How soon? Three horizons. A working demo on DrinkPrime's own plans/prices/policy is days away — the engine already
runs and the pilot is outside-in, so there is nothing to integrate. A contained live pilot for a ~100-customer cohort
follows the short build (indicative ~7 weeks, §24.1; most of it configuration, not construction). First measured
results land ~2 weeks into the pilot, against the binary gates in §24.3. The longest pole is not engineering — it is
curating DrinkPrime's knowledge and agreeing the success bar; share the FAQ/plans/policy content and book a discovery call,
and the clock starts.

24.1 Rollout path — a rollback at every gate

The build is the ~7-week implementation estimate (§16); the rollout is what happens after it goes live. Each gate is a
decision point, not a milestone we sail through — we expand only when the prior stage clears its success criteria, and we
can step back at any point without disturbing DrinkPrime's existing support.

   BUILD (~7 weeks, indicative — sharpens after discovery)
   ┌──────────────────────┐   ┌──────────────────────┐   ┌──────────────┐   ┌──────────────┐
   │ Discovery + KB        │ ▶ │ COIL layer + channels │ ▶ │ Booking       │ ▶ │ Testing       │
   │ (1 wk)                │   │ (Brain + chat) (2 wk) │   │ (1 wk)        │   │ (1 wk)        │
   └──────────────────────┘   └──────────────────────┘   └──────────────┘   └──────────────┘
                                                                                     │
                                                                                     ▼
   ROLLOUT (earn each step — expand only on evidence)
   ┌──────────────────┐  gate  ┌──────────┐  gate  ┌──────────┐  gate  ┌──────────┐  gate  ┌──────────┐
   │ PILOT             │  ───▶  │ MEASURE   │  ───▶  │ EXPAND    │  ───▶  │ ONE CITY  │  ───▶  │ SCALE     │
   │ contained cohort  │        │ against   │        │ widen the │        │ full-city │        │ multi-city│
   │ ~100 customers    │        │ binary    │        │ cohort    │        │ rollout   │        │ / national│
   │                   │        │ criteria  │        │           │        │           │        │           │
   └──────────────────┘        └──────────┘        └──────────┘        └──────────┘        └──────────┘
        │                            │                   │                   │                   │
        └──── ROLLBACK ──────────────┴───────────────────┴───────────────────┴───────────────────┘
        At ANY gate: human chat is always on · flip COIL off instantly · outside-in, so nothing to unwind.

• Pilot — contained cohort (~100 customers). COIL goes live for a small, defined set of customers (or a single
  channel / single city slice DrinkPrime chooses). Routine intents — FAQ, pricing, plans, policy, ticket capture,
  technician booking — flow through COIL; everything else escalates to a human with full context. Nobody else is touched.
• Measure. Run the cohort against the binary success criteria below. This is the gate, not a status meeting — the
  numbers decide, not optimism.
• Expand. Only if the criteria clear, widen the cohort. If they don't, we tune the knowledge base and intent set and
  re-measure — we do not expand on a maybe.
• One city. A full-city rollout once the wider cohort holds the same bar at higher volume.
• Scale. Multi-city / national once one city is steady — the same layer, more configuration, no new build.

24.2 Rollback — why this is low-risk by construction

In one line: The fallback isn't a plan we'd have to execute under pressure — it's the default state the system never
leaves.

• Human chat is always on. COIL sits in front of the existing human support, never replacing it. If COIL is paused,
  customers land exactly where they do today — there's no degraded mode to design.
• COIL can be switched off instantly. It's a layer, not a rebuild of DrinkPrime's stack — turning it off is a flip,
  not a migration.
• Outside-in, so there's nothing to unwind. The pilot touches none of DrinkPrime's systems and nothing is migrated
  into ours; stopping leaves DrinkPrime's environment exactly as it was. The risk of trying COIL is bounded by the pilot
  cohort, and the cost of stopping is effectively zero.

24.3 Pilot success criteria — binary gates (targets, not proof)

In one line: We agree the bar before the pilot, in pass/fail terms, and we expand only when the evidence clears it —
the figures below are targets to measure against, not claims of results.

These are targets, not proven outcomes. They are the bar the live pilot is measured against on DrinkPrime's own
traffic — not data DrinkPrime has shared, and not a guarantee. Proof is the measured pilot.

• Pass/fail, not vibes. Each gate is measured from COIL's own logs and the booking records — every number is observed,
  none is guessed.
• Gate #4 is non-negotiable. Anti-hallucination is a hard boundary, not a target: anything outside the knowledge base
  is deferred to a human, never invented (§11.2). A single fabricated price or policy is a fail.
• Expand only on evidence. Clearing the gates is the only trigger to widen the cohort. If a gate fails, we tune the
  KB / intent set and re-measure on the contained cohort — the next stage waits.
• The bar is DrinkPrime's to sharpen. These thresholds are a sensible starting point on the documented support
  surface; once real volume and intent mix are shared, we set the final pass marks together.

25. Sources & confidence

This document is a strategy/discovery asset only. It changes nothing on any system. The single source of truth for facts
is the table in §25; if deeper research corrects a number, the table and report are updated — never guessed. Companion
docs: Executive Summary · Technical Solution Architecture.