Qontak | Chatbot | AI Agent — Qontak Action — ANCHOR

ANCHOR PRD — the initiative master index. It orchestrates all phases/actions beneath it and carries no acceptance criteria of its own (ACs live in each Phase PRD). Created 2026-06-17 when the original broad "Mekari Action" initiative was split into three by target + auth.

Scope: Qontak Action = letting the AI Agent do what Qontak's own features already do (create/update deals & tickets, create tags, assign agents, resolve conversations, send attachments) — invoked via function-calling and authenticated with the company's Qontak token (not HMAC, not OAuth). These are first-party actions: no cross-product credential approval is required, the builder simply enables them.

Sibling initiatives (shared Action drawer, different target + auth):

• Mekari Action — other Mekari products (Talenta/Jurnal/Desty), HMAC + SSO Super Admin approval.
• Native Integration — third-party apps (Google/Calendly/Salesforce/Zoho/Midtrans), OAuth / per-provider.

HEADER BLOCK

Field	Value
PM	Dimas Fauzi Hidayat
PRD Version	1.0
Status	ACTIVE
PRD Type	ANCHOR
Labels	epic:qontak-chatbot | module:ai-agent | feature:qontak-action
Last Updated	2026-06-17

Action / Phase Index

Qontak Action is a catalog of first-party actions rather than a strict linear rollout. Each action (or group) gets its own PRD with its own ACs → its own child Jira Epic.

Epic model — one umbrella + per-action child Epics. Because this is a catalog, the initiative spans several Epics, and Jira's BOT project is flat (no tier above Epic). The initiative is anchored by an umbrella Epic — BOT-4597 — AI Agent — Qontak Native Actions (umbrella) (the initiative README's jira_epic) — with each action group tracked by the child Epic in the table's Epic column below. The umbrella is a naming anchor only: the flat project cannot re-parent the child Epics beneath it. The README declares jira_epic_model: umbrella, so the delivery linter (CHECK GROUP H, umbrella mode) validates each action PRD's Epic against the child-Epic allow-set in the README ## Jira Epics family table — a declared child Epic passes; an undeclared one still fires PRD_EPIC_NOT_IN_FAMILY. Keep this table's Epics in sync with that family table.

Action group	Goal	PRD Link	Status	Shipped	Epic
Qontak CRM actions (create deal, update deal, create ticket, update ticket)	Execute Qontak CRM writes mid-conversation via function-calling, using the company token.	prds/qontak-crm-actions.md (reverse PRD)	Backend shipped (4) — Create deal/ticket + Update ticket in legacy FE picker; Update deal backend-only	Yes (BE; 3 in FE)	BOT-3350 (tasks 3476/3496/3662)
Qontak Chat actions (assign agent, resolve conversation, create tag)	Operate on the conversation room via internal workers; no external token.	prds/qontak-crm-actions.md (reverse PRD §5–6)	Backend shipped (3) — mekari_qontak_chat executor + specs; not in legacy FE picker	Yes (BE)	BOT-3350
Send Attachment	Native action that sends the actual file/image to a customer, reusing the existing send-attachment bot-response function.	prds/phase-4-send-attachment-action.md	IN REVIEW	—	BOT-4341
Send WhatsApp Flow	Native action that lets the AI Agent send an already-published WhatsApp Flow (structured form), consume the customer's submission, and fire a tenant-configured next action (resolve / send via API / assign to agent) — reusing the existing Flow Builder send + completion-capture plumbing.	prds/send-whatsapp-flow-action.md	DRAFT	—	TBD
Appointment Booking actions (create booking, find booking)	Native qontak_booking_create / qontak_booking_find actions against the Qontak Appointment service, so the agent books real slots (idempotent create, server-side round-robin staff) and answers "when is my appointment?" mid-conversation — company token; appointment API already AI-whitelists these server-side.	prds/appointment-booking-actions.md	DRAFT	—	TBD

Naming note: the Send Attachment PRD keeps its original SENDATT-PH4-* story ids and phase-4-… filename from when it lived under the Mekari Action anchor — left unchanged to avoid re-keying its (child) Jira epic BOT-4341. The "PH4" label is historical; under Qontak Action it is one action in the catalog, not a fourth sequential phase.

---

Development Status (reconciled with code — 2026-06-17)

Real-world counterpart to the index above, grounded in chatbot (BE), chatbot-fe (production FE), and qontak-designer (prototype FE).

✅ Built & merged:

Capability	Evidence
CRM actions (4) — backend executors on master: Create deal, Update deal, Create ticket, Update ticket	BE mekari_qontak_crm/execute.rb:18-23 (ACTION_TYPE_MAPPING); BOT-3476 / BOT-3662 / BOT-3496. 3 of the 4 are also in the legacy FE picker (bot-automation-actions-constants.ts); Update deal is backend-only (not in the static picker).
Chat actions (3) — backend executors on master: Assign agent, Resolve conversation, Create tag	BE mekari_qontak_chat/execute.rb → AssignAgent*Worker / ResolveRoomWorker / BulkTagsRoomWorker; spec …/mekari_qontak_chat/execute_spec.rb; commits 2796c8c73 (assign, 2026-03-12), a72ddfea3 (resolve, 2026-05-12). Not in the legacy FE picker.
Company-token auth (CRM actions)	chatbot/config/auth_providers/qontak_crm_company_token.yml; crm_http_client.rb:107-160. (Chat actions are internal — Sidekiq workers on the org's Room, no external token.)
AI Agent action/tool data model + CRUD + AI-service sync (shared infra; v2 capability agent registers tools from the DB rather than the static FE list)	chatbot/app/models/ai_agent_action.rb, ai_agent_tool.rb; migrations 20251001024149, 20260525142508 — BOT-4230, BOT-4293

Full as-built detail + per-action specs: prds/qontak-crm-actions.md.

🟡 Backend shipped, frontend exposure incomplete:

• Update Deal, Assign agent, Resolve conversation, Create tag — executors are on master with specs, but they are not in the legacy static action picker (bot-automation / ai-agent constants, which list only Create deal / Create Ticket / Update Ticket + api). The v2 capability agent loads tools from the DB (ai_agent_tools), so it can surface them — but the legacy picker exposure gap should be closed deliberately. See the reverse PRD §2 + §8.
• Send Attachment action config — SendAttachmentDrawer.vue prototype in qontak-designer; PRD in review. Reuses the existing bot-response send-attachment function.
• Production action drawer — chatbot-fe legacy drawer still branches mainly on action_type === "api"; the per-product groups live in the qontak-designer prototype.

🔲 Not yet built (next):

• Close the FE-exposure gap for the 4 shipped-but-unlisted actions (Update Deal + the 3 chat actions): either add legacy ACTION_LIST entries or confirm v2 capability-tool registration.
• Ship the Send Attachment action end-to-end (tracked by its own PRD).
• Productionize the Mekari Qontak action picker into chatbot-fe from the prototype.

---

Key Decisions

Date	Decision	Rationale
2026-06-17	Split Qontak-native actions into their own initiative, separate from Mekari Action	Different target (Qontak's own features vs other Mekari products) and different auth (company token vs HMAC + SSO approval). A single anchor conflated two distinct security/monetization models.
2026-06-17	Qontak Action requires no cross-product credential approval — builder enables the action directly	First-party capability; the company token already authorizes Qontak's own APIs. Unlike Mekari Action, there is no SSO Super Admin two-party check.
2026-06-17	Modeled as a catalog of actions, not a linear phase rollout	The CRM actions and Send Attachment are independent capabilities that ship on their own timelines on top of the shared action framework.

PRD CHANGELOG (ANCHOR)

Version	Date	By	Section	Type	Summary
1.0	2026-06-17	Claude	All	CREATED	Initial ANCHOR for the Qontak Action initiative, split out of the original broad Mekari Action anchor. Scope = Qontak-native actions via company token. Catalog seeded with Qontak CRM actions (executor shipped) + Send Attachment (PRD moved in from Mekari Action). Development Status reconciled against chatbot / chatbot-fe / qontak-designer.
1.1	2026-07-09	Claude	Action / Phase Index	MODIFIED	Added "Send WhatsApp Flow" to the action catalog (DRAFT) — a native action that sends an already-published WhatsApp Flow, consumes the customer's submission, and fires a tenant-configured next action, reusing the existing Flow Builder WhatsApp Flow send/capture plumbing. New PRD: prds/send-whatsapp-flow-action.md.