[ANCHOR] Create Ticket & Auto-Associate from CDP (Cross-Platform)
Product Requirements Document · ANCHOR v1.0
HEADER BLOCK
| Field | Value |
|---|---|
| PM | Zhelia Alifa |
| PRD Version | 1.0 |
| Status | DRAFT |
| PRD Type | ANCHOR |
| Epic | TBD — add once Epic is created |
| Squad | CDP Squad (web) + Mobile/CRM Squad (mobile) |
| RFC Link | CRM BE RFC — Embed Ticket · CRM FE RFC — Embed Ticket |
| Figma Master | TBD |
| Labels | epic:qontak-cdp | module:customers | feature:create-ticket-from-cdp |
| Last Updated | 2026-06-26 |
This is an ANCHOR PRD. It frames one cross-platform initiative — let a CDP user create a ticket directly from a customer/contact and have it auto-associated — and indexes the per-platform Phase/SUPPORT PRDs that deliver it. The two platforms take deliberately different technical approaches (web embeds the CRM iframe component; mobile reuses its own native ticket-create screen), so each has its own PRD. Initiative-level problem, personas, north-star metrics, and cross-cutting decisions live here; UI specs and stories live in the child PRDs.
Phase / Component Index
The initiative is delivered as two platform tracks, same user goal, different approach:
ANCHOR: Create Ticket & Auto-Associate from CDP (cross-platform)
│
├── SUPPORT — Web (CDP) qontak-customer-fe
│ approach: EMBED the CRM-owned iframe ticket form (/embed/ticket/create)
│ → contact passed via EMBED_INIT (qontakCustomerId); CRM auto-associates
│
└── SUPPORT — Mobile (CDP) mobile-qontak-crm
approach: NATIVE create screen (CreateTicketScreen already exists)
→ on return, auto-associate via PUT /v2.8/tickets/{id} (qontak_customer_ids)
↳ reuses the Mobile Ticket Module (TF-3053) native create + the existing
company/deal/product "From Existing / Create New" bottom-sheet pattern
| Track | Squad / Repo | Approach | Lead-squad dependency | PRD | Status |
|---|---|---|---|---|---|
| Web | CDP / qontak-customer-fe | Embed CRM iframe component | CRM Omnichannel embed (BE RFC / FE RFC) — CDP reuse currently OUT of Phase 1 | prd-create-ticket-embeddable-web.md | DRAFT |
| Mobile | Mobile/CRM / mobile-qontak-crm | Native create screen + auto-associate | Mobile Ticket Module native create (TF-3053 / Ticket Module in Mobile App PRD) | prd-create-ticket-mobile.md | DRAFT |
Why two approaches, not one shared component? The CRM embeddable component is a web Nuxt layer (iframe). Mobile already ships a native ticket-create screen (
CreateTicketScreen) and a native association flow — embedding a webview there would be a regression in UX and performance. So mobile consumes its own native building blocks; web consumes the CRM iframe. Same outcome, platform-appropriate means.
1. One-liner + Problem
One-liner: Enable a CDP user to create a ticket directly from a customer/contact — on web and mobile — and have it auto-associated to that customer, instead of only associating an already-existing ticket.
Problem: CDP today is associate-only for tickets on both platforms. To raise a new ticket on a customer, the user must leave the customer context (web: go to the Ticket Dashboard / Omnichannel; mobile: go to the Ticket module, create, then come back to associate). The equivalent Deal flow is already create-enabled in CDP web, so the experience is both asymmetric across modules (Deal vs Ticket) and asymmetric across platforms (web vs mobile). Support agents lose time and context switching out to create a ticket — daily, high-frequency pain for frontline CS.
2. Target Users + Persona Context
| Persona | Role | Goal | Pain | Workaround |
|---|---|---|---|---|
| Primary — Support / CS Agent (desktop) | Agent working a customer in CDP web | Raise a ticket on the customer without leaving the record | CDP web can only associate existing tickets | Opens Ticket Dashboard / Omnichannel in another tab, creates, returns to associate |
| Primary — Support / CS Agent (mobile / field) | Agent on the move using mobile-qontak-crm | Raise + link a ticket from the contact on a phone | CDP mobile can only associate existing tickets (no create-from-contact) | Leaves the contact, opens the Ticket module, creates, comes back to associate |
| Secondary — Sales / CRM Admin | Manages a customer's records | Keep ticket + deal creation consistent in one place | Deal embeds/creates in CDP; Ticket doesn't | Treats tickets as a separate, out-of-context task |
11. North-Star Success Metrics
| Metric | Definition | Baseline | Target |
|---|---|---|---|
| ⭐ Create-from-CDP adoption | % of tickets on CDP customers that are created from the CDP customer/contact context (web + mobile) within 30 days of GA | 0 (capability is net-new on both) | ≥ X% (set with squads at beta) |
| ⭐ Cross-platform parity | Create-from-contact available wherever associate-existing is, on both web and mobile | Associate-only today | 100% of CDP customer-detail surfaces |
| Auto-association success | created-from-CDP tickets successfully linked / created-from-CDP tickets | N/A | ≥ 99% |
| Context-switch reduction | Median time to "ticket raised + linked" from a CDP customer | (baseline to measure) | ↓ vs the leave-and-return workaround |
14. Key Decisions + Alternatives Rejected
14a — Decisions Made
| ID | Decision | Rationale (grounded) |
|---|---|---|
| AD-1 | One initiative, two platform PRDs. | Same user goal; the technical means legitimately differ by platform (web iframe vs mobile native). Keeping it one anchor preserves a single north-star + decision log. |
| AD-2 | Web = embed the CRM-owned iframe component. | CDP web has no native ticket form; the CRM Omnichannel embed (FE RFC) is the reuse path, matching the shipped Deal embed. |
| AD-3 | Mobile = reuse the native CreateTicketScreen, not a webview. | mobile-qontak-crm already ships native ticket create (CreateTicketScreen, POST /v2.8/tickets) + a native associate flow (PUT /v2.8/tickets/{id}, qontak_customer_ids). Embedding a webview would regress UX/perf. |
| AD-4 | Mobile reuses the existing "From Existing / Create New" bottom-sheet pattern. | That pattern already exists for companies/deals/products (AssociationBottomSheet) but not tickets — so mobile extends a proven pattern, not a new one. |
| AD-5 | Do not fold the mobile work into the Mobile Ticket Module PRD; cross-link instead. | The native create form is owned there (TF-3053); CDP-mobile's contribution (contact entry point + auto-associate) is its own SUPPORT PRD that depends on it. Avoids dual ownership / dual spec. |
14b — Alternatives Rejected
| Alternative | Why Rejected |
|---|---|
| One shared embeddable component for web + mobile | The CRM embed is a web Nuxt-layer iframe; reusing it inside the native mobile app would mean a webview — worse UX/perf and no offline/native field support. |
| Put everything in one giant cross-platform PRD | Web and mobile differ in approach, repo, squad, and dependencies; one PRD would blur ownership and bloat the stories. The anchor + child-PRD split is the AI-SDLC pattern for exactly this. |
| Build a native ticket form in CDP web (instead of embedding) | Duplicates CRM ticket logic and perpetuates the parity-lag the CRM embed initiative exists to remove. |
15. Open Questions
| # | Type | Question | Mitigation / Default | Owner | Deadline |
|---|---|---|---|---|---|
| AOQ-1 | Risk (blocking — web track) | CRM embed CDP reuse is OUT of Phase 1 in both RFCs. When will CRM commit a CDP-reusable embed? Until then the web track cannot ship. | Escalate to CRM/Omnichannel; the mobile track can proceed independently. | PM + CRM | 2026-07-04 |
| AOQ-2 | Coordination | Should both tracks ship together for a unified "Create from CDP" GA message, or ship mobile first (less blocked) and web when CRM unblocks? | Default: decouple — ship per-track when ready; market jointly when both land. | PM | 2026-07-04 |
| AOQ-3 | Decision | A consistent origin label for CDP-created tickets. Mobile: settled — native create keeps data_source: "Mobile Flutter", no embed_source (see mobile PRD MD-5). Web (open): needs a CDP embed_source value added to the BE allow-list (web OQ-3). | Web track: add a CDP embed_source to the CRM allow-list. Mobile: no action. | Data + Web (CDP) + CRM BE | 2026-07-11 |
| AOQ-4 | Open Question | Permission model differs (web: CanCan permission key TBD; mobile: feature flag isTicketEnabled + contact permission.update). Acceptable to differ per platform? | Default: each platform uses its native model; document both. | PM + squads | 2026-07-11 |
PRD CHANGELOG
| Version | Date | By | Section | Type | Summary |
|---|---|---|---|---|---|
| 1.0 | 2026-06-26 | Initial draft | All | CREATED | Created the ANCHOR for Create Ticket & Auto-Associate from CDP (cross-platform). Indexes two platform tracks — Web (embed CRM iframe) and Mobile (native create + auto-associate) — with initiative-level problem, personas, north-star metrics, decisions (AD-1..AD-5), and open questions (AOQ-1..AOQ-4, headline: CRM CDP-reuse blocks the web track only; mobile labeling settled). |