Qontak | Chatbot | AI Agent — Native Integration — ANCHOR
ANCHOR PRD — the initiative master index. It orchestrates all providers/phases beneath it and carries no acceptance criteria of its own (ACs live in each provider's Phase PRD). Synced with the canonical Confluence Native Integrations ANCHOR (QON 51173589337, v1.3) and the Midtrans Native Integration Confluence page (QON 51218415627); reconciled against the actual codebase (
chatbot,chatbot-fe,qontak-designer).Scope: Native Integration = letting the AI Agent take real-world actions in third-party apps outside the Mekari ecosystem (Google, Calendly, Salesforce, Zoho, Midtrans …), so the agent can close the loop inside a conversation (book the appointment, write the lead to a CRM, take the payment) instead of handing off to a human. Authentication is per-provider — OAuth for the SaaS providers, a provider token flow for Midtrans. At the drawer, these rows live in the
Other integrationgroup.Sibling initiatives (shared Action drawer, different target + auth):
- Mekari Action — other Mekari products (Talenta/Jurnal/Desty), HMAC + SSO Super Admin approval.
- Qontak Action — Qontak's own features, company token.
Repo note: this umbrella folds in the former standalone
midtrans-native-integration/initiative (renamed 2026-06-17). Midtrans is the inaugural payment provider; the OAuth SaaS providers come from the Confluence Native Integrations program.
HEADER BLOCK
| Field | Value |
|---|---|
| PM | Dimas Fauzi Hidayat |
| PRD Version | 2.0 |
| Status | ACTIVE |
| PRD Type | ANCHOR |
| Labels | epic:qontak-chatbot | module:ai-agent | feature:native-integration |
| Last Updated | 2026-06-17 |
Provider Index
Native Integration is organized by provider; each provider has its own PRD(s) and rolls out in its own phases. (Confluence numbers the OAuth-SaaS providers as Phases 1–6; Midtrans tracks its own P0/P1/P2 payment phases. They are merged here as a provider catalog.)
| Provider | Auth | Goal | PRD Link | Epic | Status |
|---|---|---|---|---|---|
| Midtrans (payment) | Midtrans token (redis-cached) | Native payment actions — check/create/cancel/refund (P0), billing & subscription (P1), advanced (P2) | prds/midtrans-phase-1-p0-core-actions.md | BOT-4340 | PRD draft; midtrans_oauth auth shipped (BOT-4243) |
| Google Calendar | Google OAuth2 (calendar.events) | In-conversation appointment booking | prds/google-calendar-phase-1-in-conversation-booking.md | TBC | OAuth + calendar provider shipped (BOT-4278, BOT-4292); booking action + drawer not yet in production |
| Calendly | Calendly OAuth2 | In-conversation self-booking via Calendly | prds/calendly-phase-2-in-conversation-booking.md | TBC | PRD draft; depends on Phase 1 OAuth + action runtime |
| Google Sheets | Google OAuth2 (reuses Google Calendar's) | Lead capture (append row) + lookup (read rows) | TBD | TBD | managed_google_sheet_oauth2 credential shipped; actions pending |
| Salesforce | Salesforce OAuth2 + per-org schema mapping | Lead / Opportunity / Contact actions | TBD | TBD | Planned |
| Zoho | Zoho OAuth2 | CRM + Books + Desk actions | TBD | TBD | Planned |
| Gmail / Drive / Docs / Outlook 365 / Apple Calendar | OAuth2 per provider | Based on demand | TBD | TBD | Planned |
Development Status (reconciled with code — 2026-06-17)
Real-world counterpart to the Provider Index, grounded in
chatbot(BE),chatbot-fe(production FE), andqontak-designer(prototype FE). The OAuth foundation for Native Integration is the most code-complete of the three action initiatives.
✅ Built & merged (backend OAuth / provider foundation):
| Capability | Epic / commit |
|---|---|
| Server-managed OAuth2 credential type | BOT-4285 (PR #2326) |
| Google OAuth2 credential + token management, dedicated token store, token cache, token refresh | BOT-4278 (PR #2314) |
google_oauth2 added to auth_type_enum; OAuth connection status + start-response entities | 12e104f3c, 39190fc81 |
| Google Calendar resource lookup provider | BOT-4292 (9a5fe9213) |
managed_google_sheet_oauth2 credential type | 382e889a3 |
Midtrans midtrans_oauth auth type + redis token caching | BOT-4243 (PR #2302, 524f811d3) |
🟡 In progress / prototype only (qontak-designer, not yet in production chatbot-fe):
Other integrationdrawer group —qontak-designer/.../NewActionDrawer.vueACTION_GROUPSlistsAPI Integrations+Google Calendar(lines 188–213).Google SheetsandGet nearest locationrows are present but commented out; Calendly/Salesforce/Zoho rows are not in the drawer yet.- Per-action config forms for the native providers — Pixel-MCP-generated, not yet in production.
🔲 Not yet built (next):
- Google Calendar booking action end-to-end in production (OAuth + calendar provider exist; the
function-callable booking action + config drawer need to land in
chatbot-fe). - Calendly, Salesforce, Zoho OAuth + actions.
- Midtrans payment action executors (P0 core actions) —
midtrans_oauthauth shipped, but the check/create/cancel/refund action layer is at PRD/draft stage (BOT-4340). - Google Sheets append/read actions on top of the shipped
managed_google_sheet_oauth2credential.
Gap summary: The OAuth + provider-token connectivity foundation is shipped for Google and Midtrans; what remains is exposing each provider's function-callable actions in production and extending OAuth to Calendly/Salesforce/Zoho. Because the credential/token machinery is now a shared primitive, each new provider's actions are an incremental build on top of it.
S1 — One-liner + Problem (Initiative-level)
One-liner: Enable Qontak chatbot builders to grant their AI Agent direct access to external apps (Google, Calendly, Salesforce, Zoho, Midtrans …) via OAuth / per-provider auth, so the agent can take real-world actions inside customer conversations across any industry.
Problem: Today, when a Qontak AI Agent collects a high-intent inbound conversation, the agent can qualify the lead but cannot complete the action that closes the loop — booking the appointment, writing the lead to a CRM, taking the payment, scheduling a follow-up — without handoff to a human. The handoff loses an estimated ~40–60% of high-intent leads (Assumption — needs validation). Today's workaround is the generic API Integration action, which requires Engineering to write custom REST setups per customer per provider. The result: Qontak's AI Agent shows up as "another chatbot that qualifies leads" instead of "an AI Agent that closes the loop." Native Integration makes third-party connectivity a connect-once, use-always configuration step for non-technical builders.
IA Surface (drawer placement, canonical):
In the shared Action drawer (single-column, right-side), native integration actions appear as
rows inside the existing Other integration group — the sibling group at the bottom of the
drawer, alongside the per-Mekari-product groups owned by Mekari Action
and Qontak Action. Other integration already contains
API Integrations and Get nearest location; Native Integration adds provider rows (Google
Calendar, Calendly, Google Sheets, Salesforce, Zoho, Midtrans).
⚠️ "Native Integration" is the program / feature / SKU label, not a drawer group. Its rows live in
Other integration. It is not a new top-level drawer group, and it is not nested under "Mekari Action" — Native uses OAuth/provider consent, Mekari Action uses HMAC + SSO Super Admin approval. They are intentionally sibling initiatives that share infrastructure.
S8 — Key Decisions + Alternatives Rejected (Initiative-level)
S8a — Decisions Made
| Date | Decision | Rationale |
|---|---|---|
| 2026-05-06 | Native Integration is a sibling initiative to Mekari Action, not an extension of it | Different auth model (OAuth / provider token vs HMAC), different approval flow, different team dependencies. |
| 2026-05-06 | A single "Native Integration" add-on SKU covers all providers (not per-provider SKUs) | Simpler upsell story: "AI Agent as a conversion engine across your stack." |
| 2026-05-06 | First OAuth provider = Google Calendar (not Sheets) | Stronger closed-loop conversion demo; OAuth foundation reusable for later Google-family providers. |
| 2026-05-06 | Compound entitlement (AI Agent feature + Native Integration add-on SKU) | Matches the Mekari Action monetization model. |
| 2026-06-05 | Inserted Calendly ahead of the planned Google-family extensions | Active demand from scheduling-heavy segments; reuses the shared OAuth + drawer pattern. |
| 2026-05-22 | Native rows surface under the existing Other integration drawer group | Other integration is the canonical bucket for non-Mekari-product actions (confirmed via Figma LJ6ePL0PjxKbHYZZdNK4LX). |
| 2026-06-17 | Repo restructure: fold the former standalone midtrans-native-integration/ initiative into this umbrella as the Midtrans payment provider | Midtrans is a third-party app outside Mekari, so it belongs under Native Integration by the target+auth taxonomy. Keeps one umbrella per action category. |
S8b — Alternatives Rejected
| Date | Alternative | Why Rejected |
|---|---|---|
| 2026-05-06 | Extend the Mekari Action ANCHOR to cover external actions | Auth/architecture divergence (OAuth vs HMAC) makes a single anchor misleading. |
| 2026-05-06 | Per-provider SKUs | Fragments the pricing story; over-engineered for current volume. |
| 2026-05-22 | Surface Native Integration as a new top-level drawer group | Duplicates the existing Other integration group. |
| 2026-05-22 | Nest native rows under a "Mekari Action" namespace | "Mekari Action" is the sibling initiative's SKU umbrella, not a drawer group. |
| 2026-06-17 | Keep Midtrans as a separate top-level initiative | Per the new taxonomy, Midtrans is a third-party native provider; a separate initiative would fragment the Native Integration umbrella. |
S9 — Open Questions (Initiative-level)
| Theme | Resolution path |
|---|---|
| Validation of the ~40–60% drop-off assumption | Closed Beta measures pre-vs-post conversion (per-provider). |
| Google Sensitive Scope verification timing | Test mode covers Closed Beta if Google verification slips. |
| Native Integration add-on SKU readiness | Sales Ops dependency — must be ready before Open Beta. |
| Midtrans P0 action executors not yet built | midtrans_oauth auth is shipped (BOT-4243); the payment-action layer is the next build (BOT-4340). |
| Provider brand assets (logos + hex) for drawer rows | Pending PM provision per the brand-asset hard rule (must be code-gen-ready before Wireframes/S11). |
PRD CHANGELOG (ANCHOR)
| Version | Date | By | Section | Type | Summary |
|---|---|---|---|---|---|
| 1.0 | 2026-06-15 | Claude | All | IMPORTED | (As midtrans-native-integration-anchor.md) imported the Midtrans Native Integration ANCHOR from Confluence. |
| 1.1 | 2026-06-15 | Claude | Phase Index | MODIFIED | Wired the Midtrans Phase 1 PRD link into the Phase Index. |
| 2.0 | 2026-06-17 | Claude | All | RESTRUCTURED | Generalized from "Midtrans Native Integration" to the "Native Integration" umbrella. Folded the former standalone Midtrans initiative in as the inaugural payment provider; added the OAuth SaaS providers (Google Calendar, Calendly, Google Sheets, Salesforce, Zoho) from the Confluence Native Integrations ANCHOR (51173589337) as a Provider Index. Added a code-grounded Development Status (Google OAuth2 BOT-4278, Google Calendar provider BOT-4292, Sheets OAuth credential, server-managed OAuth2 BOT-4285, Midtrans OAuth BOT-4243 all shipped). Rewrote S1/S8/S9 at the umbrella level; positioned as a sibling to Mekari Action + Qontak Action. |