[PRD][Ad-Hoc] Multi-BSUID Support for Single Customer (CDP & CRM Contact)

Imported from Confluence (page 51173098459) — the live page is the source of truth and retains all embedded screenshots. PRD content preserved as-is (no reformatting).


Product Module	CDP, CRM Contact
One-liner / Elevator Pitch	Enable a single customer to store and manage multiple BSUIDs (with WA username and phone bindings) to ensure data consistency across Chat, CDP, and CRM, while preventing data corruption caused by editable phone fields tied to identity.
Team	CDP - Task Force CRM
* PM	@Zhelia Alifa
* Designer	@Nur Asmara @Rizky Surur
* Engineers	@Puji Triwibowo
* QA	@Muhammad Izzul @Gregorius Hendry
* Analyst	-
* PMM	-
Status	validationRed
Type of Product Work	Feature ImprovementsGreen Feature ExpansionPurple Customer ExperienceYellow
Last Updated	* Updated Date: * Updated By: @Zhelia Alifa * Update Summary: -
Links [Figma] • [Research] • [Dashboard] • [Tickets] • [Google Chat Channel]	Parent PRD: [PRD][Strategic] - [META Changes] WA Phone to BSUID adjustment

Table of Contents760none

TL;DR

Currently, CDP and CRM allow one customer to have multiple phone numbers. However, the system only supports single BSUID per customer, creating inconsistencies when:

A customer interacts via multiple WA channels/accounts
Phone numbers are edited/deleted in CRM
Chatpanel sync relies on BSUID as identity

This initiative introduces:

Multi-BSUID support per customer
Structured identity model:
- BSUID + WA Username
- BSUID + WA Username + Phone (cause shared by customer via broadcast)
Auto-disable phone field when linked to BSUID (to prevent breaking identity mapping)

Outcome

One customer can store multiple BSUID identities
Prevent data inconsistency between Chat ↔ CDP ↔ CRM
Eliminate breaking changes caused by phone edits via CRM UI
Improve reliability of customer resolution & association

Target Release (GTM)

Target Release in Q2	Criteria
General release with toggle feature = OFF	* All non-Qontak One clients that already enabled sync contact * All Qontak One clients

What Happens If We Don't Build This

Continued data inconsistency across systems
High risk of:
- Duplicate customers
- Incorrect association
- Lost chat history linkage
Phone edits in CRM will continue to break identity mapping

Problem Alignment

Problem Statement

CDP and CRM Contact currently supports only one BSUID per customer, while real-world Chatpanel might generate multiple BSUIDs per user across WA channels. Additionally, CRM allows editing/deleting phone numbers, which can break identity mapping when phone is tied to BSUID.

Why It Matters


Business Impact	* Inaccurate customer data → impacts segmentation, campaign targeting * Broken identity → affects automation & personalization * Increased support cost due to manual fixes
User Impact	* Confusing customer records (duplicates / mismatched data) * Loss of chat continuity * Manual effort to fix associations

Supporting Evidence

1. Current Condition

Existing mismatch after sync

Problem Frequency & Severity

Area	Description
User Frequency	HIGHRed → Daily — occurs in: * Chat inbound creation * Broadcast interactions * CRM edits
User Severity	highRed → High — directly causes: * Data inconsistency * Broken associations * Operational inefficiency

Target Population


Role impacted	1. Sales Representatives 2. Customer Success Managers
Behavioral Triggers / Entry Points	1. Chat inbound (new / existing) 2. CRM contact update (edit/delete phone) 3. Broadcast → customer shares phone

Opportunity & Strategic Fit


Opportunity Summary	Revamp logic to stored BSUID per customer level
Why now	* BSUID already introduced but not scalable * Current model is fragile
Strategic Alignment / OKRs	Company OKR * Increase NDR Product OKR * Improve data reliability * Reduce data inconsistency issues after BSUID has released

Decision Type

Commitment — Foundational Identity Layer Fix

Strategic Alternatives Considered

Option	Description	Why Not Chosen
Keep single BSUID	Current approach	❌ Not scalable
Use phone as primary identity	Replace BSUID	❌ Phone is editable
Multi-BSUID per customer (Chosen)	Flexible identity mapping	✅ Scalable & consistent

Final Recommendation

note8a0130ccde79

Implement multi-BSUID support per customer with structured identity binding and field protection logic.

Product Narrative


Before	After
* One customer = one BSUID * Phone editable → breaks mapping * Multiple identities → duplicate records	* One customer = multiple BSUIDs * Each BSUID linked with WA username (+ optional phone) * Phone tied to BSUID → protected (disabled) * Accurate identity resolution

Goals


Business Goals	* Reduce duplicate customer rate * Improve data consistency
User Goals	* Reliable customer profile * No broken associations

Success Metrics


Primary KPI	1. Duplicate customer rate decreased
Secondary KPIs	-

Scope & Solution Hypothesis

Proposed Solution

Scope 1: Multi-BSUID Data Model

Customer can store:

wide760customer_id ├── BSUID_1 │ ├── WA username │ ├── phone (optional) ├── BSUID_2 ├── WA username ├── phone (optional)

Scope 2: Identity Pattern Handling

Pattern A: BSUID + WA Username

Used when no phone is available
System still tracks identity

Pattern B: BSUID + WA Username + Phone

When phone is available
Phone is bound to BSUID

Scope 3: Phone Field Protection

If phone is linked to a BSUID:
- Phone field becomes auto-disabled
- Cannot be edited/deleted manually in CRM/CDP

Scope 4: Sync Logic Enhancement

Lookup priority:
1. BSUID
2. Phone (if exists)
3. Email (fallback if applicable)

Scope 5: Update vs Create Logic

If BSUID is exists → update customer data (example: phone has added)
If BSUID is not found but phone is exist → create new BSUID under customer
If BSUID && phone is not found → new customer

User Experience Flow

Chatpanel sends BSUID + WA username (+ phone if available)
CDP checks:
- Existing BSUID? → update
- Not found → attach to customer / create new
If phone exists:
- Bind phone to BSUID
- Disable phone editing

User Stories and Acceptance Criteria

User Story	Importance	Acceptance Criteria	Approved by PM Domain	JIRA Ticket
Multi-BSUID Storage & Identity Handling - CDP As a PM, I want the system to support multiple BSUID identities per customer and correctly resolve identity using BSUID, WA username, and phone, so that customer data remains consistent and does not break when identifiers change or are incomplete.	must haveRed	Scenario 1 — Data Model Structure (Multi-BSUID per Customer) Given a customer exists in CDP When the system stores identity data Then the system should allow multiple BSUID under one `customer_id` Expected Result: customer_id ├── BSUID_1 │ ├── WA username │ ├── phone (optional) ├── BSUID_2 ├── WA username ├── phone (optional) * Each BSUID acts as a unique identity node * Phone is optional but if exists → must be attached to a BSUID * One customer can have: + Multiple BSUIDs + Multiple phones (via BSUID mapping) --- Scenario 2 — Identity Pattern A (BSUID + WA Username) Given an inbound event from Chatpanel When the payload contains BSUID and WA username without phone Then the system should still create or update identity under the same customer Expected Result: * System creates/updates BSUID node with: + BSUID + WA username * Phone field remains empty * Customer identity is still trackable --- Scenario 3 — Identity Pattern B (BSUID + WA Username + Phone) Given an inbound event contains BSUID, WA username, and phone When the system processes the data Then the system should bind the phone to the BSUID Expected Result: * Phone is attached to the specific BSUID node * Phone cannot exist independently without BSUID * Data consistency is maintained across CDP & CRM --- Scenario 4 — Update Existing BSUID (Add Phone Later) Given a BSUID already exists under a customer When a new event comes with the same BSUID but includes a phone Then the system should update the existing BSUID node Expected Result: * No new BSUID created * Existing BSUID is updated with phone * Customer_id remains unchanged --- Scenario 5 — New BSUID but Existing Phone Given a phone number already exists in the system under a customer When a new BSUID is received with that same phone Then the system should create a new BSUID under the same customer Expected Result: * New BSUID node is created under existing `customer_id` * Phone is associated with the new BSUID * No new customer is created --- Scenario 6 — No Match (BSUID & Phone Not Found) Given incoming data where BSUID and phone are not found in the system When the system processes the data Then the system should create a new customer Expected Result: * New `customer_id` is created * New BSUID node is created * Phone (if provided) is attached to that BSUID --- Scenario 7 — Handling Phone Removal or Edit from CRM Given phone data can be edited or removed from CRM When phone is modified or deleted Then the system should not break BSUID identity mapping Expected Result: * BSUID remains as the primary identity anchor * Historical mapping is preserved * System avoids orphan or duplicated customer creation --- Edge Cases * Same WA username across different BSUID → treated as separate identities * Phone reused across BSUID → must always attach to one BSUID at a time * Missing WA username but BSUID exists → still valid identity * Incoming event with inconsistent mapping → system prioritizes: BSUID → Phone → WA username	Alma Syafira 95 a2be6c5d-3262-48b5-a827-f6894367e54f incomplete Date:	TEMP-59b4d68a-8fb7-4a53-af80-1ccbed9979d2
Multi-BSUID Storage & Identity Handling - CRM Contact As a PM, I want the system to support multiple BSUID identities per customer and correctly resolve identity using BSUID, WA username, and phone, so that customer data remains consistent and does not break when identifiers change or are incomplete.	must haveRed	Scenario 1 — Data Model Structure (Multi-BSUID per Customer) Given a customer exists in CDP When the system stores identity data Then the system should allow multiple BSUID under one `customer_id` Expected Result: customer_id ├── BSUID_1 │ ├── WA username │ ├── phone (optional) ├── BSUID_2 ├── WA username ├── phone (optional) * Each BSUID acts as a unique identity node * Phone is optional but if exists → must be attached to a BSUID * One customer can have: + Multiple BSUIDs + Multiple phones (via BSUID mapping) --- Scenario 2 — Identity Pattern A (BSUID + WA Username) Given an inbound event from Chatpanel When the payload contains BSUID and WA username without phone Then the system should still create or update identity under the same customer Expected Result: * System creates/updates BSUID node with: + BSUID + WA username * Phone field remains empty * Customer identity is still trackable --- Scenario 3 — Identity Pattern B (BSUID + WA Username + Phone) Given an inbound event contains BSUID, WA username, and phone When the system processes the data Then the system should bind the phone to the BSUID Expected Result: * Phone is attached to the specific BSUID node * Phone cannot exist independently without BSUID * Data consistency is maintained across CDP & CRM --- Scenario 4 — Update Existing BSUID (Add Phone Later) Given a BSUID already exists under a customer When a new event comes with the same BSUID but includes a phone Then the system should update the existing BSUID node Expected Result: * No new BSUID created * Existing BSUID is updated with phone * Customer_id remains unchanged --- Scenario 5 — New BSUID but Existing Phone Given a phone number already exists in the system under a customer When a new BSUID is received with that same phone Then the system should create a new BSUID under the same customer Expected Result: * New BSUID node is created under existing `customer_id` * Phone is associated with the new BSUID * No new customer is created --- Scenario 6 — No Match (BSUID & Phone Not Found) Given incoming data where BSUID and phone are not found in the system When the system processes the data Then the system should create a new customer Expected Result: * New `customer_id` is created * New BSUID node is created * Phone (if provided) is attached to that BSUID --- Edge Cases * Same WA username across different BSUID → treated as separate identities * Phone reused across BSUID → must always attach to one BSUID at a time * Missing WA username but BSUID exists → still valid identity * Incoming event with inconsistent mapping → system prioritizes: BSUID → Phone → WA username	Alma Syafira 96 6e3006cd-4a96-495b-b032-4a54f408bb86 incomplete Date:	TEMP-d51a8727-7421-43ca-a531-de7c570b4797
Disable Phone Editing if Linked to BSUID - CDP UI As a user, I want the system to prevent editing of phone numbers that are already linked to a BSUID, so that identity consistency is preserved and data conflicts are avoided.	must haveRed	Scenario 1 — Disable Edit for Linked Phone Given a phone number is already associated with a BSUID When a user attempts to edit the phone number Then the system should disable the edit action Expected Result: * Phone field becomes read-only / disabled --- Scenario 2 — Allow Adding New Phone Given a user wants to add another phone number When the user inputs a new phone Then the system should allow adding it as a new entry Expected Result: * New phone can be added * System will: + Either create new BSUID (if needed), OR + Attach to existing BSUID based on logic * Existing linked phone remains unchanged --- Scenario 3 — API Enforcement (Backend Validation) – Optional Given an API request attempts to update a phone linked to BSUID When the request is processed Then the system should reject the update Expected Result: * API returns error (e.g., `400 / 403`) * Error message: "Phone is linked to BSUID and cannot be modified" --- Edge Cases * If BSUID is deleted → phone becomes editable again (if allowed by system rules)		TEMP-1e9d4371-c02a-49a6-9cc7-aeb5af41a447
Disable Phone Editing if Linked to BSUID - CRM Contact UI As a user, I want the system to prevent editing of phone numbers that are already linked to a BSUID, so that identity consistency is preserved and data conflicts are avoided.	must haveRed	Scenario 1 — Disable Edit for Linked Phone Given a phone number is already associated with a BSUID When a user attempts to edit the phone number Then the system should disable the edit action Expected Result: * Phone field becomes read-only / disabled --- Scenario 2 — Allow Adding New Phone Given a user wants to add another phone number When the user inputs a new phone Then the system should allow adding it as a new entry Expected Result: * New phone can be added * System will: + Either create new BSUID (if needed), OR + Attach to existing BSUID based on logic * Existing linked phone remains unchanged --- Scenario 3 — API Enforcement (Backend Validation) – Optional Given an API request attempts to update a phone linked to BSUID When the request is processed Then the system should reject the update Expected Result: * API returns error (e.g., `400 / 403`) * Error message: "Phone is linked to BSUID and cannot be modified" --- Edge Cases * If BSUID is deleted → phone becomes editable again (if allowed by system rules)		TEMP-583231a4-d5bb-4165-b69f-6f058bab86a2

Technical Requirements

Required backend logic
API changes
Platform-specific behavior
Schema updates
Rollback plan

…

QA & Acceptance Criteria

QA Scenarios

Flows to validate
Edge conditions to test
Performance risks

…

Acceptance Criteria

In Gherkin Format

Security & Privacy

Any PII or sensitive data?
Compliance concerns?
Third-party integrations?

…

Instrumentation Plan

Events to Track

Properties

Dashboard / Owner

Link:
Data owner:

Constraints & Limitations

Platform, infra, or vendor constraints
Package/plan-level availability
Known trade-offs

…

Risks & Dependencies

Risk	Impact	Mitigation

Launch Plan

Milestones

Week	Task	Owner

Stage Gates

Stage	Purpose / Focus	Requirements to Advance
Internal Release	Work closely with <20 early users, validate core concept	No major bugs or blockers identified
Alpha – Evaluation Stage	Test the MVP, iterate, determine viability	* 80% of early users find value * Commercialization planning started with PMM
Closed Beta – Scale Stage	Fit to market, validate adoption across segments	* Key KPIs met * Clients across verticals are live and loving it * Leadership sign-off * GTM plan + pricing finalized * Messaging tested
Open Beta – Unleash Sales	Controlled release, sales and self-serve enabled	* KPIs sustained at scale * GTM plan in motion * Self-serve UI being tested * Localized marketing live
GA – Full Global Launch	Product available to all customers	* Full launch plan executed globally * No outstanding high-priority bugs or blockers

Operational Checklist

Area	Owner	Notes
Analytics		Tracking in place
Support		Updated macros
PMM		GTM checklist ready
Legal		Privacy impact approved
Globalization		Any localization work?

Change Log

Date	Owner	Summary

Key Decisions

Date	Decision	Owner	Rationale

TL;DR​

Outcome​

What Happens If We Don't Build This​

Problem Alignment​

Problem Statement​

Why It Matters​

Supporting Evidence​

1. Current Condition​

Problem Frequency & Severity​

Target Population​

Opportunity & Strategic Fit​

Decision Type​

Strategic Alternatives Considered​

Final Recommendation​

Product Narrative

Goals​

Success Metrics​

Scope & Solution Hypothesis​

Proposed Solution​

Scope 1: Multi-BSUID Data Model​

Scope 2: Identity Pattern Handling​

Pattern A: BSUID + WA Username​

Pattern B: BSUID + WA Username + Phone​

Scope 3: Phone Field Protection​

Scope 4: Sync Logic Enhancement​

Scope 5: Update vs Create Logic​

User Experience Flow​

User Stories and Acceptance Criteria

Technical Requirements​

QA & Acceptance Criteria​

QA Scenarios​

Acceptance Criteria​

Security & Privacy​

Instrumentation Plan​

Events to Track​

Properties​

Dashboard / Owner​

Constraints & Limitations​

Risks & Dependencies​

Launch Plan​

Milestones​

Stage Gates​

Operational Checklist​

Change Log​

Key Decisions​

Supporting Docs​

Open Questions​

FAQs​