Qontak | AI Agent | AI Spam Gatekeeper — ANCHOR
ANCHOR PRD — the initiative master index. It orchestrates all phases beneath it and carries no acceptance criteria of its own (ACs live in each phase PRD). Reconciled against the actual codebases: chatbot BE (Rails — inbound routing, existing
spam_protection,Gpt::Completion), hub-core / hub-chat (Omnichannel — contact block system, inbound billing short-circuit), chatbot-fe + qontak-designer (settings UI — confirmed P0 design gap).Scope: AI Spam Gatekeeper = a tenant-defined, AI-classified spam filter for inbound WhatsApp conversations. The tenant defines what spam means to their business; the AI classifies each new conversation against that definition; high-confidence spam is auto-resolved and the contact is blocked so all future messages from that sender cost nothing. Phase 1 ships silent classification + block + settings UI; Phase 2 adds clarifying interrogation, a review queue, and Meta-level blocking.
HEADER BLOCK
| Field | Value |
|---|---|
| PM | Dimas Fauzi Hidayat (Product Manager, Mekari Qontak) |
| PRD Version | 1.0 |
| Status | DRAFT |
| PRD Type | ANCHOR |
| Anchor | Yes — this IS the Anchor |
| Labels | epic:qontak-chat | module:ai-agent | feature:ai-spam-gatekeeper |
| Last Updated | 2026-07-14 |
Status values:
DRAFT→ACTIVE→DEPRECATED
Table of Contents
- HEADER BLOCK
- 1. PHASE INDEX
- 2. One-liner + Problem
- 3. Target Users + Persona Context
- 4. Success Metrics (Initiative-level)
- 5. Key Decisions + Alternatives Rejected
- 6. Open Questions
- PRD CHANGELOG
1. PHASE INDEX
| Phase | Goal | PRD Link | Epic Key | Status | Shipped |
|---|---|---|---|---|---|
| Phase 1: Silent Classification & Block | Classify new inbound WhatsApp conversations against a tenant-defined spam policy at the shared inbound hook, silently resolve + block high-confidence spam (source: ai_agent, distinct RESOLVE_AI_SPAM reason), tag ambiguous cases as "suspected spam" (fail-open), alert a supervisor on every auto-block, and ship the channel-level settings UI (currently non-existent) | Phase 1 — Silent Classification & Block | TBD | 📝 Draft | — |
| Phase 2: Interrogation & Meta Blocking | Add ≤3-turn AI clarifying interrogation for ambiguous cases (AI Agent tenants only), a human review queue for suspected-spam tags, a tenant-definition feedback loop, and Meta Block Users API integration for delivery-level suppression | — | — | ⏳ Not started | — |
Status options: 📝 Draft · 🔄 In Progress · ✅ Shipped · ⏸ Paused · ❌ Cancelled
2. One-liner + Problem
One-liner: Let a Qontak tenant define what spam means to their business and have the AI Agent silently resolve and block spam conversations before any billable reply is sent, so tenants stop paying to answer spam once Meta charges for every WhatsApp service message.
Problem:
From 1 October 2026, Meta bills every free-form WhatsApp service message a business sends — including replies produced by Qontak's AI Agent — with no volume discount. Internal analysis (Bifrost squad, meta-whatsapp-pricing-oct-2026, Epic BIF-8755) sizes the exposure at ~42.85M free service messages/month across Qontak's client base becoming billable, an estimated ~14–15B IDR/month in new cost (~332 IDR/message average; median client ~487K IDR/month). Every spam conversation the AI Agent currently answers — unsolicited B2B pitches, scam/phishing attempts, bulk blasts, gibberish, and tenant-specific junk — is pure negative margin once this billing starts: a spammer costs nothing until the bot replies. Qontak has no spam-handling product today: the only existing mechanism (chatbot BE's spam_protection) is a dormant, heuristic (repeated-intent-count) feature with no tenant-facing UI, invisible to every customer. Tenants have independently asked for this — an agentic-AI early-access interview (Feb 2026) explicitly requested "autonomous junk tagging" to cut manual triage.
3. Target Users + Persona Context
Primary Persona: Tenant Admin / Business Owner (Qontak customer)
| Field | Detail |
|---|---|
| Role | Owner or admin of a Qontak WhatsApp inbox, responsible for the business's Meta messaging cost and inbox quality |
| Goal | Stop paying to answer spam/junk inbound once Meta service-message billing starts, without blocking real customers by mistake |
| Pain | No way to define or act on "spam" today; every inbound conversation — spam or not — gets a billable AI reply once Oct 2026 pricing lands |
| Workaround | None systemic — some tenants manually block contacts one at a time from the inbox after the fact, well after cost was already incurred |
Secondary Persona: CS Supervisor / Team Lead
| Field | Detail |
|---|---|
| Role | Supervisor overseeing the shared inbox and the human agents who back up the AI Agent |
| Goal | Trust that auto-blocked contacts really were spam, and be able to review/reverse a wrong call quickly |
| Pain | An opaque auto-block system that silently loses real customers is worse than the spam problem it solves |
| Workaround | Today, none — no auto-block exists. When agents manually block a contact, there is no audit trail visible to the supervisor beyond the block record itself |
4. Success Metrics (Initiative-level)
Efficiency & Impact:
| Metric | Definition | Baseline | Target |
|---|---|---|---|
| ⭐ Billable AI messages avoided per month | Count of AI Agent replies not sent because the triggering conversation was auto-resolved as spam (silent classification, zero-reply path) | N/A — no spam measurement exists today (Phase 1 tag mechanism becomes the baseline instrument) | Establish baseline in Phase 1 first 30 days; reduce spam-driven billable messages by ≥80% among opted-in tenants within 90 days of GA |
| Estimated Meta cost avoided | Avoided messages × applicable per-message rate (published by Meta 1 Sep 2026), aggregated per tenant | N/A — new | Report a non-zero, tenant-visible savings figure within 30 days of Phase 1 GA |
Quality & Accuracy:
| Metric | Definition | Baseline | Target |
|---|---|---|---|
| False-positive rate (confirmed) | Share of AI auto-blocks reversed via "Bukan spam" within 7 days, of all auto-blocks | N/A — new | ≤2% within 60 days of GA (auto-block only fires on high-confidence verdicts by design) |
| Suspected-spam tag precision | Share of "suspected spam"-tagged conversations a human later confirms as spam | N/A — new | ≥50% within 90 days of GA (validates the ambiguous-case fail-open design and feeds the Phase 2 definition-tuning loop) |
Adoption & Usage:
| Metric | Definition | Baseline | Target |
|---|---|---|---|
| Tenant opt-in rate | Share of eligible tenants (active WhatsApp channel) with the Spam Gatekeeper enabled | 0 | ≥25% of eligible tenants within 60 days of GA |
5. Key Decisions + Alternatives Rejected
5a — Decisions Made
| Date | Decision | Rationale |
|---|---|---|
| 2026-07-14 | Config lives at channel/tenant level, not per-AI-Agent | Classification must protect tenants regardless of whether they run an AI Agent, a bot-tree flow, or route everything to humans — only ~20–26k of ~620–695k monthly cohort rooms even touch AI (Tableau, Jun 2026), so per-agent config would exclude most of the spam-exposed base. Only Phase 2's clarifying interrogation requires an AI Agent |
| 2026-07-14 | Classifier is chatbot-squad-owned (reuses Repositories::Gpt::Completion, the direct-OpenAI flow already behind room summarization + agent scorecards) — no DSAI/AI-Service dependency in Phase 1 | Cross-team dependencies (esp. DSAI) are slow and unreliable per PM; the squad already owns a working direct-AI call pattern with per-org prompt config and token logging, sufficient for a bounded single-shot classification call |
| 2026-07-14 | Block provenance recorded as separate source (actor) and reason (cause) fields — never a combined ai_spam value | Enables clean, independent audit queries ("all AI blocks" vs "all spam blocks") using the existing ContactBlock/ContactBlockLog schema, which already supports source + reason natively |
| 2026-07-14 | Ambiguous classification fails open (conversation proceeds, tagged "suspected spam") — auto-block only fires on high-confidence verdicts | Asymmetric risk: a false negative costs a few hundred rupiah in avoidable messages; a false positive permanently blocks a real customer who then cannot even message back to complain (the exact failure mode competitors' silent-discard designs hit) |
| 2026-07-14 | Every high-confidence auto-block fires a supervisor alert (new 5th signal for the AI Agent Live Monitoring initiative) | Keeps a human in the loop on every irreversible action the AI takes, consistent with the trust model already established for that initiative |
| 2026-07-14 | Phase 1 excludes Meta-level blocking (Block Users API) | Qontak-level block already captures the full cost saving (hub-core's inbound short-circuit drops blocked contacts before billing); Meta's API adds delivery-level suppression only, has a 24h-since-last-message constraint and a 64k-contact cap per number, and is not required to hit Phase 1's KPI |
5b — Alternatives Rejected
| Alternative | Why Rejected | Date |
|---|---|---|
| Per-AI-Agent spam configuration (agent editor "Spam filter" section) | Excludes bot-tree-only and human-only tenants — the majority of the exposed cohort by room volume; would also allow contradictory definitions across multiple agents on one channel | 2026-07-14 |
Route classification through DSAI/AI-Service (skill_pack spam_policy contract) | Introduces a cross-squad dependency for a bounded, single-shot classification call the chatbot squad can already make directly; slower and less reliable per PM decision, see [[dependency-relevancy-check]] | 2026-07-14 |
Reuse is_blocked alone with source: 'ai_spam' | Conflates actor and cause in one enum value, breaking clean audit/reporting queries; the existing block interactor already supports separate source/reason params, so there is no cost to doing it correctly | 2026-07-14 |
| Auto-block on ambiguous verdicts (no fail-open tier) | A false positive permanently silences a real customer with no way to complain — unacceptable risk for an irreversible, unattended action. Fail-open + tag preserves the signal for human review without the downside | 2026-07-14 |
| Ship Meta Block Users API integration in Phase 1 | Adds a second blocking mechanism with a 24h-window constraint and 64k-cap before the core Qontak-level mechanism (which already achieves the cost saving) has shipped or been validated in production | 2026-07-14 |
6. Open Questions
| # | Type | Question | Owner | Deadline |
|---|---|---|---|---|
| 1 | Open Question | Exact per-message Meta service rate for Indonesia (needed to convert "messages avoided" into a rupiah savings figure shown to tenants) | Dimas + Bifrost squad | 2026-09-01 (Meta's published rate-card date) |
| 2 | Assumption | Repositories::Gpt::Completion's existing OpenAI request budget/rate limits can absorb one additional classification call per new inbound conversation across all opted-in tenants without needing new capacity | Dimas + Chatbot BE | 2026-08-01 |
| 3 | Risk | If the tenant's free-text spam definition is too broad or ambiguous, the classifier may over-trigger the "suspected spam" tag, creating alert/tag fatigue that erodes trust before auto-block accuracy can be proven — mitigation: Phase 1 ships tag-only visibility first in the closed beta before wider rollout, and the settings UI includes example definitions | Dimas | 2026-08-15 |
| 4 | Risk | Design has zero existing spam/moderation UI pattern in qontak-designer — Phase 1 timeline depends on a net-new design change-request spec being scoped and delivered in time for the pre-Oct-2026 launch window | Dimas + Design (Wulan's team) | 2026-08-01 |
Types:
Assumption·Open Question·Risk
PRD CHANGELOG
| Version | Date | By | Section | Type | Summary |
|---|---|---|---|---|---|
| 1.0 | 2026-07-14 | Claude | All | CREATED | Initial ANCHOR for the AI Spam Gatekeeper initiative, grounded in chatbot BE inbound pipeline + hub-core contact-block system + chatbot-fe/qontak-designer settings gap; motivated by the Bifrost meta-whatsapp-pricing-oct-2026 exposure |