Qontak | Chatbot | AI Agent — Mekari Action — 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). Synced with the canonical Confluence ANCHOR (QON 51159335062, v1.3, 2026-05-22) and reconciled against the actual codebase (chatbot, chatbot-fe, qontak-designer) — see Development Status below.

Scope (narrowed 2026-06-17): This initiative is Mekari Action only — letting the AI Agent take actions in other Mekari products (Talenta, Jurnal, Desty), authenticated via HMAC with one-time SSO Super Admin approval. Two sibling initiatives split off from the original broad scope:

Qontak Action — actions in Qontak's own features (create deal, ticket, tag, resolve conversation, send attachment), authenticated via company token. The Send Attachment action (formerly "Phase 4" here) moved there.

Native Integration — third-party apps outside Mekari (Google, Calendly, Salesforce, Zoho, Midtrans …), authenticated via OAuth / per-provider.

All three share one Action drawer (the IA); they are separate initiatives because they differ in what they target and how they authenticate.

Import note: Phase 1's full PRD lives in Confluence (QON 51158450589) and is not yet imported to this repo — to be added under prds/ by the PM.

HEADER BLOCK

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

Phase Index

Phase	Goal	PRD Link	Epic Key	Status	Shipped
Phase 1: Action Picker + One-Time Approval	Enable Qontak chatbot builders to grant their AI Agent one-time, scope-limited access to Mekari Actions across the Mekari ecosystem during agent configuration.	Confluence — Phase 1 PRD (not yet imported to `prds/`)	BOT-4210 (HMAC foundation)	IN PROGRESS — HMAC auth foundation shipped; per-product action picker in prototype; SSO approval flow not yet built (see Development Status)	Partial (foundation only)
Phase 2 (planned): Credential Rotation, Revocation, Re-Consent on Scope Change	Add proactive credential rotation, admin-driven revocation UI, and auto re-consent prompts when Mekari publishes new scopes for already-approved actions.	TBD	TBD	PLANNED	—
Phase 3 (planned): Multi-Credential per Company + Audit Log	Support multiple credential sets per company (per-team or per-purpose isolation) and surface a runtime audit log of which Mekari Actions the AI Agent has called.	TBD	TBD	PLANNED	—

Scope note: The Send Attachment action (formerly "Phase 4" here) is a Qontak-native capability, not a cross-product Mekari Action — it moved to the Qontak Action initiative on 2026-06-17.

Product Action Catalog (per-product PRDs)

Per-product action PRDs sit on top of Phase 1's picker + one-time approval + credential plumbing — each registers one Mekari product's actions, their HMAC scopes, and their executors (the catalog Phase 1 delegates to the MCP servers per its S7 #1/#5). They are not new phases; they light up the per-product drawer groups named in S1. The HMAC foundation being shipped (BOT-4210) is what makes each of these an incremental registration rather than a custom build.

Product	Actions	PRD	Status
Mekari Jurnal	Create sales order, Create sales invoice	`prds/jurnal-create-sales-order-invoice.md`	DRAFT — scored 8.9/9.0, READY (all gates pass; diagram polish only). Ready for RFC.
Mekari Talenta	Approve reimbursement, Generate payslip	TBD	Planned
Mekari Desty	Check product stock, Check payment status, Check voucher	TBD	Planned

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

This section is the real-world counterpart to the Phase Index above. It records what has actually been built, what is in flight, and what is next — grounded in the chatbot (BE), chatbot-fe (production FE), and qontak-designer (prototype FE) repos. The planning sections below (S1–S9) describe the target design; this section is the ground truth.

Strategic frame: What Q2 2026 delivered is the HMAC authentication foundation — a shared, reusable cross-product auth layer. Outbound calls into any Mekari product are now signed via the common mekari_hmac mechanism rather than a per-customer bespoke integration. That is the load-bearing bet of this initiative: once auth is a shared primitive, each new Mekari-product action (Talenta, Jurnal, Desty …) becomes an incremental action registration on top of an already-shipped auth layer, not a custom build. This is what makes "Mekari Action" sellable as a bundled add-on across the Mekari ecosystem (Qontak + Talenta, Qontak + Jurnal) in support of the PUMA cross-tribe selling KR.

✅ Built & merged (the HMAC foundation — shared across the Mekari ecosystem):

Capability	Evidence	Epic / commit
HMAC signer (HMAC-SHA256, cavage-style: `date` + request-line)	`chatbot/lib/mekari_hmac/signer.rb`	BOT-4210 (PR #2291, `cfa815bb7`)
`mekari_hmac` auth strategy (decrypts payload → `client_id`/`client_secret` → signs outbound request)	`chatbot/lib/auth/plugins/mekari_hmac_strategy.rb`	BOT-4210
`mekari_hmac` as an `auth_type_enum` on the connection model	`chatbot/app/models/organization_connection.rb`	BOT-4210
HMAC credential entry form (client id/secret, validation, round-trip) + 40+ tests	`chatbot-fe/modules/settings/views/api-integration/forms/api-credential-form.vue`	BOT-4210
AI Agent action/tool data model (`ai_agent_actions`, `ai_agent_tools` + CRUD + AI-service sync) — shared infra, also used by Qontak Action	`chatbot/app/models/ai_agent_action.rb`, `ai_agent_tool.rb`; migrations `20251001024149`, `20260525142508`	BOT-4230, BOT-4293

🟡 In progress / prototype only (qontak-designer, not yet in production chatbot-fe):

Talenta / Jurnal / Desty drawer groups — in qontak-designer/app/components/bot-automation/actions/NewActionDrawer.vue (ACTION_GROUPS), the Mekari Talenta, Mekari Jurnal, and Mekari Desty groups are scaffolded but commented out (lines 163–187). Only the Mekari Qontak group is live — and that group belongs to the Qontak Action initiative, not this one.

🔲 Not yet built (next):

SSO Super Admin one-time approval flow + approval-link delivery (M2 auto-email / E1 SSO data-sync auto-fetch / E2 manual fallback). No code found for super_admin entitlement, approval_link generation/validation, or the one-time per-agent grant. This is the Phase 1 headline value prop and is still pending.
Agent-scoped one-time credential grant. Credentials today are stored org-level (OrganizationConnection / ai_agent_tools.credentials), not as per-AI-Agent-config approval state — so the "one-time approval per agent configuration" semantics in S8a are not yet enforced.
Talenta / Jurnal / Desty action executors. No backend executors for the other Mekari products' actions yet (only the Qontak-native CRM actions are wired, under Qontak Action).
Credential rotation / revocation / multi-CID / runtime audit log — Phase 2–3 scope, deferred as planned.

Gap summary: Mekari Action is foundation-complete, flow-incomplete — the HMAC primitive (the shared cross-product auth layer) and the action/tool data model are shipped, but the self-service SSO approval flow and the Talenta/Jurnal/Desty action catalog that make it a configurable, sellable add-on are still ahead. Because HMAC is already a shared primitive, the fastest path to GA value is (1) build the SSO Super Admin approval flow + approval-link delivery, then (2) light up Talenta/Jurnal/Desty drawer groups + action executors on top of the existing HMAC layer — at which point cross-product agent journeys can be sold bundled (Qontak + Talenta, Qontak + Jurnal) per the PUMA cross-tribe KR.

SECTION 1 — One-liner + Problem (Initiative-level)

One-liner: Enable Qontak chatbot builders to grant their AI Agent one-time, scope-limited access to Mekari Actions across the Mekari ecosystem during agent configuration.

Problem: Today, when a Qontak AI Agent needs to take an action in another Mekari product (e.g., create an invoice in Jurnal, look up an employee in Talenta, send a broadcast in Qontak Chat), there is no self-service way for a chatbot builder to grant the agent permission — every cross-product capability requires a manual, per-customer integration ticket. This blocks Qontak's ~10 active AI Agent customers and the broader pipeline from delivering multi-action agent journeys, and directly constrains the PUMA cross-tribe selling KR (Qontak + Talenta or Qontak + Jurnal bundles), because Qontak cannot demonstrate a working agent that consumes a sister product's actions without engineering involvement. Without a one-time, scope-limited approval flow, every cross-product agent expansion is a custom build — not a configuration — and the cross-sell motion stalls at the integration step.

IA Surface (drawer placement, canonical): The AI Agent's Action drawer (right-side, single-column) is a single shared IA across all three action initiatives. It groups actions per Mekari product — Mekari Qontak, Mekari Talenta, Mekari Jurnal, Mekari Desty — plus a sibling Other integration group at the bottom. Ownership splits by initiative:

This initiative (Mekari Action / HMAC) owns the Mekari Talenta group (Approve reimbursement, Generate payslip), Mekari Jurnal (Create sales order, Create invoice), and Mekari Desty (Check product stock, Check payment status, Check voucher).
The Mekari Qontak group (Assign agent, Create deal, Create ticket, Resolve conversation, Update deal, Update ticket, Create tag) is owned by Qontak Action (company token).
The Other integration group (API Integrations, Get nearest location, + Google/Calendly/Salesforce/Zoho/Midtrans rows) is owned by Native Integration (OAuth / per-provider).

⚠️ "Mekari Action" is the program / feature / SKU umbrella label used in PRDs, monetization, and the SSO Super Admin approval flow. It is NOT a drawer group label. Surfacing "Mekari Action" as a single drawer group would duplicate the existing per-product IA. The drawer's canonical groups remain per Mekari product.

Canonical Figma frame for the Action drawer: file LJ6ePL0PjxKbHYZZdNK4LX (✨ Bot - AI), node TBC per V1 verification. Per-action details form is generated by Pixel MCP prompts — not Figma-specified. (Code reference for the current drawer grouping: qontak-designer NewActionDrawer.vue ACTION_GROUPS — see Development Status.)

SECTION 2 — Target Users + Persona (Initiative-level)

Primary Persona 1 — CS Ops Lead / Bot Manager (B)

Role:         Customer-side CS Ops Lead or Bot Manager. Owns AI Agent quality and
              day-to-day configuration in Qontak Chatbot. Common at enterprise
              customers with dedicated bot operations.
Goal:         Add Mekari Actions (Talenta, Jurnal, Qontak Chat) to an AI Agent's
              allowed action set during configuration — without filing an engineering
              ticket or hand-rolling a REST integration.
Pain:         Every cross-product capability today requires either an engineering
              implementation ticket OR a self-built API Integration action repeated
              per product, per agent. Slow, error-prone, doesn't compose.
Workaround:   Configure Qontak's existing API Integration action type manually,
              one Mekari product at a time. Or escalate to Engineering / Mekari
              Implementation Consultant on a paid contract. Lead time: weeks.

Primary Persona 2 — Mekari Implementation Consultant (C)

Role:         Internal Mekari implementation consultant delivering paid implementation
              service to customers buying multiple Mekari products (Qontak + Talenta,
              Qontak + Jurnal). Configures AI Agent on the customer's behalf during
              onboarding.
Goal:         Deliver a working cross-product AI Agent in onboarding hours, not weeks.
              Make Mekari Actions a configuration step, not a custom build.
Pain:         Every new customer onboarding repeats the same API Integration setup
              from scratch — there is no reusable Mekari-aware action layer. Caps
              onboarding throughput and bottlenecks PUMA cross-tribe selling.
Workaround:   Manual API key provisioning per customer + writing API Integration
              action setups by hand. Often requires Engineering review. No standardized
              template across implementations.

Secondary Persona — Qontak Admin (Non-Technical, A)

Role:         General-purpose Qontak admin at SME / mid-market customers. Single-hat
              owner of the chatbot. Frequently non-technical.
Goal:         "I bought Talenta + Qontak — I expect them to work together out of the box."
Pain:         API Integration action assumes the admin can read API docs, manage tokens,
              debug 4xx/5xx errors. Non-technical admins don't try — and the
              cross-product use case never materializes.
Workaround:   Most don't attempt it. A few escalate via support ticket. Cross-sell
              motion stalls before reaching value.

Design constraint inherited from Persona A: The Mekari Action picker + approval flow must be operable end-to-end by a non-technical user. No knowledge of HMAC, scopes, OAuth, API versioning, or webhook semantics may be required.

SECTION 6b — Success Metrics (North-Star, Initiative-level)

Adoption & Usage:

⭐ Primary KPI: % of active AI Agent customers who attach ≥1 Mekari Action to ≥1 AI
   Agent configuration within 60 days of GA
   Definition: (# customers with ≥1 mekari_action_credential_stored event in their
                account / # customers with ≥1 active AI Agent) × 100, measured at 60d
   Baseline:   0% — feature does not exist today (Assumption captured in S9)
   Target:     ≥30% by end of Q4 2026 (90 days post-GA)

- # of PUMA bundles closed citing "Mekari Action availability" as a buying reason
   Definition: Count of new closed-won deals in Q3-Q4 2026 where the deal CRM record
               tags "mekari-action" as a contributing factor
   Baseline:   0
   Target:     ≥5 deals in Q3-Q4 2026 (contribution to PUMA cross-tribe KR)

Quality & Accuracy:

- HMAC credential failure rate
   Definition: (mekari_action_credential_failed / total approval requests) × 100
   Baseline:   N/A (new feature)
   Target:     ≤2% within 60 days of GA

Efficiency & Impact:

- Time-to-configure first Mekari Action (picker_opened → credential_stored)
   Baseline:   Multiple weeks (current API Integration manual workaround)
   Target:     ≤10 minutes (median) within 30 days of GA

SECTION 8 — Key Decisions + Alternatives Rejected (Initiative-level)

8a — Decisions Made

Date	Decision	Rationale
2026-04-27	Plan scope = AI Agent feature + Mekari Action add-on (compound entitlement)	Monetize PUMA cross-tribe expansion; not free. Both flags must be true for picker to render.
2026-04-27	Approval is one-time per AI Agent configuration, not per-call	Matches HMAC tech doc design; minimizes friction at runtime; the headline value prop.
2026-04-27	Web only — no mobile config UX	All three personas configure on web; no mobile config UX exists for AI Agent today.
2026-04-27	Phase 1 excludes credential rotation, revocation, multi-CID, audit log UI	HMAC tech doc explicitly defers these; faster time to market for PUMA Q3 GA target.
2026-04-27	Requestor = Qontak Admin/Spv; Approver = Mekari SSO Super Admin	Matches existing Qontak RBAC + Mekari SSO governance. Two-party check is intentional security boundary.
2026-04-27	No SUPPORT PRD for Platform; depend on parent RFCs	Platform team is delivering against the RFC Mekari Internal MCP and HMAC tech doc independently.
2026-04-27	Runtime fallback owned by parent AI Agent runtime layer	Out of scope per S3 #11 (LLM/runtime is not in this PRD); this PRD ensures fallback signal is logged.
2026-04-27	Primary KPI target = 30% adoption in 90 days post-GA	Paid SKU realism; supply-side bet posture.
2026-04-27	Feature flag scope = per-company	Matches Mekari Action add-on SKU sold at company level. Simplifies entitlement check.
2026-04-27	Approval link delivery = (M2) auto-email via Qontak with (E1) SSO data sync auto-fetch and (E2) manual entry fallback	One-time-per-config justifies email build cost; SSO data sync is canonical source for Super Admin email.
2026-05-22	IA placement (canonical): Action drawer is single-column right-side with 5 groups — `Mekari Qontak`, `Mekari Talenta`, `Mekari Jurnal`, `Mekari Desty`, `Other integration`. "Mekari Action" is the feature / SKU umbrella label, not a drawer group.	Confirmed via canonical Figma (file `LJ6ePL0PjxKbHYZZdNK4LX`). Per-product groupings already exist in the drawer; surfacing "Mekari Action" as a separate group would duplicate the existing per-product IA.
2026-05-22	Native Integrations rows surface under the existing `Other integration` drawer group, alongside `API Integrations` and `Get nearest location`.	Matches canonical Figma. Native rows are not Mekari-product actions, so they don't belong in the Mekari Qontak/Talenta/Jurnal/Desty groups. See sibling Native Integrations ANCHOR.

8b — Alternatives Rejected

Alternative	Why Rejected	Date
Per-call approval (every action invocation requires re-consent)	Defeats the value prop ("one-time approval" is the headline); too much UX friction for non-technical Persona A.	2026-04-27
Free for all AI Agent customers (Plan scope option (a) only)	Leaves PUMA monetization on the table; no signal that customer demand justifies free tier.	2026-04-27
PUMA-gated only (Plan scope option (c))	Requires real-time cross-product entitlement check that doesn't exist today; over-engineered for Phase 1.	2026-04-27
Build Qontak's own credential issuer rather than reuse HMAC + AL	Violates parent RFC architecture; duplicates Platform's work; longer time to market.	2026-04-27
Auto-rotation on a 90-day schedule	HMAC tech doc has no rotation API in MVP; would force re-consent UX that isn't yet designed.	2026-04-27
Build a custom approval page in Qontak instead of using AL	AL already provides the SSO Super Admin approval flow; building a custom one would require Qontak to authenticate SSO admins.	2026-04-27
Auto-prompt re-consent when Mekari adds new scopes to existing actions	Out of MVP per S3 #3; defer to Phase 2.	2026-04-27
(M1) Manual link copy only (no email)	Friction at the most fragile step of the flow; non-tech Persona A would lose the link or send it incorrectly.	2026-04-27
(M3) Hybrid manual + email	Complicates the picker UX with conditional states; (M2) covers most cases with E2 manual fallback already.	2026-04-27
Surface "Mekari Action" as a single drawer group (sibling to Mekari Qontak/Talenta/Jurnal/Desty)	Would duplicate the existing per-product IA. The drawer already exposes each Mekari product directly; collapsing them under one "Mekari Action" header buries the per-product mental model admins already know from the rest of the Mekari platform.	2026-05-22
Surface Native Integrations as a new top-level drawer group (5th sibling alongside the Mekari product groups)	Duplicates the existing `Other integration` group which already buckets non-Mekari-product actions. Wireframes v3.0–v4.0 incorrectly proposed this — reversed here.	2026-05-22
Nest Native Integrations rows under the "Mekari Action" namespace (verbal shorthand from earlier discussion)	"Mekari Action" is not a drawer group — it is the feature / SKU umbrella. The drawer surfaces actions per Mekari product or under `Other integration`.	2026-05-22

SECTION 9 — Open Questions (Initiative-level — see Phase PRDs for detailed tables)

The full Open Questions / Risks / Assumptions table lives in each Phase PRD. Initiative-level themes:

Multi-CID-per-company is open in the parent RFC Mekari Internal MCP — Phase 1 sidesteps via 1 credential per AI Agent; Phase 3 resolves.
Credential rotation/revocation gap accepted for Phase 1 — Phase 2 closes.
Mekari Action add-on SKU not started — must be ready before Closed Beta of Phase 1.
Canonical Figma frame node ID for the Action drawer still needs to be cited (V1 verification). Drawer IA confirmed via canvas screenshot 2026-05-22; the live grouping is encoded in qontak-designer NewActionDrawer.vue (ACTION_GROUPS).
Approval flow not yet implemented (see Development Status) — the SSO Super Admin one-time approval + approval-link delivery is the open build item gating Phase 1 GA.

PRD CHANGELOG (ANCHOR)

Version	Date	By	Section	Type	Summary
1.0	2026-04-27	Claude	All	CREATED	Initial ANCHOR PRD generated alongside Phase 1 NEW PRD from grooming session.
1.1	2026-06-15	Claude	Phase Index	MODIFIED	Imported into the documents repo; added Phase 4 (Send Attachment Action) to the Phase Index with link; noted Phase 1 PRD still to be imported.
1.2	2026-06-17	Claude	S1, S8a, S8b, S9	SYNCED	Synced with canonical Confluence ANCHOR v1.3 (2026-05-22 IA correction): added the IA Surface paragraph to S1 (drawer groups per Mekari product + `Other integration`; "Mekari Action" = feature/SKU umbrella, not a drawer group); added 2 S8a decision rows + 3 S8b rejected alternatives encoding the corrected IA; added the V1 Figma-node and Native-Integrations themes to S9.
1.3	2026-06-17	Claude	Phase Index, Development Status, S9	RECONCILED	Reconciled against the actual codebase (`chatbot`, `chatbot-fe`, `qontak-designer`). Added a Development Status section grounding what's shipped vs. next in file:line + Jira evidence: HMAC auth foundation shipped (BOT-4210 `MekariHmac::Signer`, `mekari_hmac` strategy, credential form + tests); AI Agent action/tool model + CRUD + AI-service sync shipped (BOT-4230/4293); Qontak CRM actions execute. Per-product Action drawer is prototype-only (Talenta/Jurnal/Desty groups commented out in `NewActionDrawer.vue`); SSO Super Admin approval flow not yet built; credentials are org-level, not agent-scoped. Updated Phase 1 Phase-Index status DRAFT → IN PROGRESS (foundation-complete, flow-incomplete).
1.4	2026-06-17	Claude	Scope, Phase Index, S1, Development Status	NARROWED	Split into three initiatives by target + auth. Narrowed this anchor to Mekari Action only (cross-product into other Mekari products — Talenta/Jurnal/Desty — via HMAC). Removed the Send Attachment row (Phase 4), which moved to the new Qontak Action initiative (Qontak-native, company token). Pointed the `Other integration` rows to the Native Integration initiative (third-party, OAuth/per-provider). Rewrote the S1 IA Surface to show the shared drawer with per-initiative ownership, and re-scoped Development Status so only HMAC/Mekari-product evidence remains here.
1.5	2026-06-20	Claude	Product Action Catalog	ADDED	Added the Product Action Catalog subsection and imported the first per-product PRD — Jurnal Create Sales Order & Sales Invoice (DRAFT, scored 8.7/9.0). It consumes the Phase 1 picker/approval/credential plumbing and fills the executor-catalog gap Phase 1 delegates to the MCP servers; the first action built on the shipped HMAC foundation.

HEADER BLOCK​

Phase Index​

Product Action Catalog (per-product PRDs)​

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

SECTION 1 — One-liner + Problem (Initiative-level)​

SECTION 2 — Target Users + Persona (Initiative-level)​

SECTION 6b — Success Metrics (North-Star, Initiative-level)​

SECTION 8 — Key Decisions + Alternatives Rejected (Initiative-level)​

SECTION 9 — Open Questions (Initiative-level — see Phase PRDs for detailed tables)​

PRD CHANGELOG (ANCHOR)​