[PRD] Customer Segmentation — Use-Case Activities

HEADER BLOCK

Field	Value
PM	Zhelia Alifa
PRD Version	1.6
Status	DRAFT
PRD Type	NEW
Epic	TF-2549 … TF-2555
Squad	CDP Squad
RFC Link	TBD
Figma Master	TBD — Figma link to be added once design is ready
Anchor	Yes — CDP | Customers | Customer Segmentation — ANCHOR
Labels	epic:qontak-cdp | module:customers | feature:customer-segmentation
Last Updated	2026-06-26

---

Table of Contents

• HEADER BLOCK
• 1. One-liner + Problem
• 2. What Happens If We Don't Build This
• 3. Target Users + Persona Context
• 4. Non-Goals
• 5. Scope Changes
• 6. Constraints
• 7. Rollout
• 8. Success Metrics
• 9. Dependencies
• 10. Open Questions
• 11. Feature Changes — Enhancement to the Segment Builder
• 12. API & Webhook Behavior
• 13. System Flow + User Stories + ACs
• PRD CHANGELOG

---

1. One-liner + Problem

One-liner: Enhance the CDP Segment Builder so users can segment customers by use-case activities — cross-module associations and aggregate metrics — building on the core builder delivered by the Basic Attributes initiative.

Problem: Sales and CS teams in Qontak CDP have no way to create dynamic, auto-updating customer segments. Today, users either export contacts to spreadsheets for manual classification or apply static tags individually — a process that takes hours per week per team, produces stale snapshots, and makes it impossible to run targeted bulk actions (campaigns, broadcasts, bulk task assignments) against the right audience. As a result, campaigns are sent to poorly targeted lists, team leaders spend disproportionate time on manual segmentation, and the CDP's contact data goes underutilised. This gap is felt most acutely by Growth and Enterprise accounts managing hundreds or thousands of contacts across multiple business units, where manual classification is operationally untenable.

---

2. What Happens If We Don't Build This

• CRM data in CDP (Deals, Tickets, Conversations, Companies) continues to go unused for audience selection, reducing CDP's strategic value as a customer intelligence platform.
• Enterprise accounts seeking automated audience management will evaluate competitor platforms (Freshdesk, Zendesk) that already offer this natively.

---

3. Target Users + Persona Context

Persona	Role	Goal	Pain	Workaround
Primary — Sales / CS Team Lead	Team leader responsible for contact management and campaign targeting in CDP	Maintain up-to-date, rule-defined customer groups (e.g. "Active Leads", "Loyal Customers", "Churn Risk") without manual effort	No dynamic grouping — every list must be manually rebuilt whenever contact data changes (new deals, resolved tickets, lapsed conversations)	Export contacts to spreadsheet weekly, apply filters manually, re-upload tags — takes 2–4 hours per cycle per team lead
Secondary — Marketing / Campaign Manager	Runs Broadcast or Campaign using CDP contact lists as audience	Target broadcasts/campaigns to precisely defined audiences (e.g. "customers with open deal > 30 days" or "contacts with no conversation in 90 days")	Cannot define audience by CRM activity attributes — must use static lists or send to all contacts	Build audience in external tool (spreadsheet / Mailchimp), upload as CSV — does not reflect real-time CDP data

---

4. Non-Goals

1. This PRD does not cover AI-generated or ML-suggested segments — segments are defined manually by users via rule builder.
2. This PRD does not cover segment-triggered automations (e.g. "when a contact enters segment X, trigger flow Y") — automation integration is a future phase.
3. Segments defined in CDP are not synced to Broadcast or Campaign audience lists in this phase — that integration is a separate initiative.
4. This PRD does not support real-time segment re-evaluation on every contact data change — segments are refreshed on a daily schedule (every day at 08.00 AM).
5. This PRD does not cover segment versioning, rollback, or audit history of segment membership changes.
6. This PRD does not apply to the Qontak One Mobile App — web only for set up / configuration.
7. Exception filters (excluding specific customers / segments from a result) are out of scope for now.
8. Sending a campaign from a segment is WhatsApp broadcast only for now — Email broadcast from a segment is not yet supported (and the WhatsApp send-campaign capability itself is delivered by the Basic Attributes initiative, TF-2545).

---

5. Scope Changes

Engineering surfaces this PRD touches (controlled vocab: Backend · Frontend · Mobile · Infra · Data · Design · Docs · None). Kept in sync with the scope_changes frontmatter in the repo .md version.

• Backend — contact-service: segment definition CRUD, rule/condition tree evaluation across customer fields + associations (Conversations, Campaigns, Company, Deals, Tickets), nightly batch evaluation + manual refresh (rate-limited), nested filter logic, segment permission keys (customers_segment_view/add/manage/archived).
• Frontend — qontak-customer-fe: extend the existing Segment Builder (delivered by Basic Attributes) with the use-case condition palette (associations + aggregate metrics + recency/RFM); add the Segment Detail Performance tab; permission gating.
• Data — segment evaluation engine query patterns over association tables; segment performance metrics (size growth, source/domicile/age/gender distribution); reachability-by-channel calculations.
• Design — Figma for Segment List, Builder, Detail/Performance, and campaign hand-off (TBD).

---

6. Constraints

Constraint	Value
Platform	Configuration menu is available only on Qontak CDP — Website.
Performance	Segment list page load ≤ 2s (P95). Segment preview (live contact count estimate) ≤ 5s. Full segment evaluation (nightly batch) must complete within 30s per segment for orgs with up to 50,000 contacts.
Capacity limits	• Maximum 3 nested filters in same criteria • Maximum 2 filter groups created • Component billing differentiation: Plus package — Max 5 segments per CID; based on default & custom fields. Ultimate package — Unlimited segments per CID; based on default & custom fields + use-case activities (Sales: Convo, Campaign, Company, Deal · Support: Convo, Campaign, Company, Ticket). 360 — Unlimited segments per CID; based on default & custom fields + use-case activities (Convo, Campaign, Company, Deal, and Ticket).
Plan scope	Growth and Enterprise only. Not available on Starter.
Read/write	Segment create: Org Admin and Team Lead roles. Segment view and contact list from segment: all agents with customers_customers_view ≥ OWNED ONLY.
Data refresh	Segment membership is recalculated daily (morning refresh cadence).

---

7. Rollout

Stage	Detail
Stage 1 — Internal Alpha	1–2 internal CDP accounts, 2 days
Stage 2 — Open Beta	All new Qontak One clients
Stage 3 — GA	All Qontak One clients (incl. existing)

---

8. Success Metrics

Metric	Definition	Baseline	Target
⭐ Adoption — segments created	% of CID that create at least 1 segment within 30 days of GA flag enable	N/A — feature does not exist	≥ 40% of GA accounts within 30 days

---

9. Dependencies

Dependency	Owning Team	Deliverable Needed	Blocking?
Segment Builder core (List / Builder / Detail + rule engine)	CDP Squad — Basic Attributes PRD	Core segment builder + engine live (segments save, AND/OR + nested, nightly refresh)	YES
CDP Contacts data model — Deal, Ticket, Conversation, Company association tables	Related squad	Association data available for query in segment evaluation engine	YES
Morning batch evaluation scheduler	BI team	Scheduler infrastructure capable of running per-segment evaluation jobs at configurable cadence	YES
CDP Role & Permission model	CDP Squad	Segment create/edit/delete gated by Org Admin / Team Lead roles	YES — built as part of this PRD

---

10. Open Questions

#	Type	Question	Owner	Answer	Deadline
1	Assumption	Association data (Deal, Ticket, Conversation, Company linked to a contact) is queryable from the segment evaluation engine without joins that degrade performance beyond acceptable limits. Needs engineering validation on real data volume.	CDP Engineering		2026-06-11
2	Open Question	Should segment membership be exportable as a contact list CSV/XLSX? If yes, this needs a data export endpoint and quota governance. Scoping decision needed before Closed Beta.	PM Qontak	Until CDP has an export feature, segment can be exported	2026-06-04

---

11. Feature Changes — Enhancement to the Segment Builder

The core segmentation backbone — Segment List, Segment Builder, and Segment Detail — is delivered by the Basic Attributes initiative (rule builder over default & custom fields, basic events, consent, and loyalty; saveable segments; nightly refresh; reuse as Broadcast recipients). This PRD does not rebuild those screens — it enhances the existing Segment Builder to extend its condition palette to use-case activities, plus the Segment Detail Performance tab.

Change ID: CHG-001 — Enhance Segment Builder condition palette + Segment Detail

Element	Before (delivered by Basic Attributes)	After (this PRD)
Builder condition palette	Default & custom fields, basic events (created/updated at/by), communication consent, loyalty	+ Customer Associations (Conversations, Campaigns, Company, Deals, Tickets) · + Aggregate use-case metrics (§13.2.6) · + Recency / RFM (§13.2.6 G)
Filter logic	AND/OR conditions, nested limit, single value per filter	+ advanced nested criteria groups (multiple filter groups)
Segment Detail	Overview + base data summary	+ Performance tab (size growth, source/domicile/age/gender) · + reachability by channel
Permissions	Segment view / create (base)	+ granular keys customers_segment_view/add/manage/archived (SEG-S15)

Already in Basic Attributes (not re-specced here): segment utilisation — Send Campaign (WhatsApp broadcast only for now; Email broadcast not yet supported) and reuse-as-Broadcast-recipient — is delivered by the Basic Attributes initiative (TF-2545); it is surfaced from the Segment List/Detail. Exception filters (exclude specific customers/segments) are descoped for now.

Figma: TBD — enhancement frames within the existing Segment Builder master.

Affected components (existing components built in Basic Attributes; ⟡ = added/enhanced by this PRD):

SegmentBuilderPage                         (existing)
└── ConditionGroupBuilder                  (existing — AND/OR, nested)
    └── ConditionRow                       (existing)
        ├── ContactAttributeCondition      (existing — default/custom fields, basic events, consent, loyalty)
        ├── ⟡ AssociationCondition         (added — Conversations / Campaigns / Company / Deals / Tickets)
        ├── ⟡ AggregateMetricCondition     (added — §13.2.6 per-domain metrics)
        └── ⟡ RecencyCondition             (added — §13.2.6 G days-since-last-X / RFM)
SegmentListPage                            (existing — Basic Attributes; unchanged)
SegmentDetailPage                          (existing)
└── ⟡ PerformanceTab                       (added — size growth, source/domicile/age/gender, reachability)

UI States: unchanged from the existing Segment Builder / List / Detail (see Basic Attributes PRD); the new condition types reuse the same loading / empty / error / success behavior. New error state: an invalid use-case metric value shows inline validation on that condition row (save blocked until resolved).

---

12. API & Webhook Behavior

Behavioral contracts in plain language — HTTP method, path, and schema are resolved during RFC.

#	Behavior	Entity Affected	Triggered By	Information Passed	Expected Behavior	Failure Behavior
1	Create a segment	Segment definition (new record)	User clicks "Save Segment" in Segment Builder	Segment name, condition groups (attribute / operator / value per condition), group logic (AND/OR)	• New segment record created with status "active" • Queued for initial evaluation (next nightly batch, or manual refresh) • Appears in /cdp/segments list	• At segment-limit: API 409, UI "Segment limit reached. Delete an existing segment to create a new one." • Malformed condition payload: API 400 with field-level validation errors
2	Evaluate segment membership (nightly batch)	Segment membership records for all active segments in the org	Nightly scheduled batch job (configurable, default 02:00 local org timezone)	Segment rule tree, full contact dataset for the org (with associations)	• Evaluates each segment's condition tree against all contacts • Membership records updated (contacts added/removed) • cdp_segment_evaluated logged per segment with member_count + evaluation_duration_ms	• Per-segment failure: cdp_segment_evaluation_failed logged, membership not updated, admin alerted • Org-level timeout: remaining segments skipped, alert triggered
3	Manual segment refresh	Single segment membership records	User clicks "Refresh Now" on a segment	Segment ID, requesting user ID	• Evaluation triggered immediately for that segment only • Rate-limited: if refreshed within last 30 min, rejected with friendly message	• Rate limit hit: API 429, UI "Segment was recently refreshed. Try again in {N} minutes." • Evaluation fails: UI "Refresh failed. Try again." + error logged

Claude to resolve during RFC: HTTP method/path/schema/error codes (B1); scheduler config, batch parallelism, timeout handling (B2); async vs sync evaluation, polling, rate-limit implementation (B3).

---

13. System Flow + User Stories + ACs

13.1 System Flow — User creates a dynamic segment

Flow: Team Lead creates a "High-Value Leads" segment · Type: User Journey

1. Team Lead navigates to /cdp/segments and clicks "New Segment".
2. SegmentBuilderPage renders with empty condition form.
3. Team Lead enters segment name: "High-Value Leads".
4. Team Lead adds Condition 1: AssociationCondition → "Has Deal" with status = "Open".
5. Team Lead adds Condition 2: ActivityCondition → "Last Conversation" within last 30 days.
6. PreviewPanel updates (debounced 500ms) to show estimated contact count.
7. Team Lead reviews preview count and clicks "Save Segment".
8. System calls POST /cdp/segments with rule tree payload.
9. Segment is created with status "active"; queued for next nightly evaluation.
10. User is redirected to /cdp/segments list; new segment appears with "Pending first evaluation" status.
11. Nightly batch runs, evaluates segment against all contacts, updates membership.
12. Segment status changes to "Active"; member count shown.

13.2 Operator Logic Reference

Supported operators per field type, by attribute group. Screenshots are linked from page attachments.

Operator Logic — Communication Consent

Field Type	Type	Supported Operators	Details	Example UI
Marketing opt-in status	Boolean	equals (true/false), is empty, is not empty	true = opt-in = allowed · false = opt-out = not allowed · is empty = null = user has not provided an opt-in/opt-out status yet.
Account business name for marketing opt-in	Single-line text	is, is not, contains, does not contain, starts with, ends with, is empty, is not empty	Return all values as value suggestions

Operator Logic — Member Loyalty

Field Type	Type	Supported Operators	Details	Example UI
Is Member	Boolean	is, is not
Member created at	Date	on, not on, before, after, between, is empty, is not empty	open date picker
Member last updated at	Date	on, not on, before, after, between, is empty, is not empty	open date picker
Current tier	Single-line text	is, is not, contains, does not contain, starts with, ends with, is empty, is not empty	Return all values as value suggestions
Total available balance	Number	equals, not equals, greater than, less than, between, is empty, is not empty	Return all value as value suggestions
Total balance pending	Number	equals, not equals, greater than, less than, between, is empty, is not empty	Return all value as value suggestions
Total lifetime earned	Number	equals, not equals, greater than, less than, between, is empty, is not empty	Return all value as value suggestions
Reward name	Single-line text	is, is not, contains, does not contain, starts with, ends with, is empty, is not empty	Return all values as value suggestions
Reward status	Single-line text	is, is not, contains, does not contain, starts with, ends with, is empty, is not empty	Return all values as value suggestions
Reward expired at	Date	on, not on, before, after, between, is empty, is not empty	open date picker

Operator Logic — Customer Associations: Conversations

Field Type	Type	Supported Operators	Details
Total conversations histories	Number	equals, not equals, greater than, less than, between, is empty, is not empty	Return all value as value suggestions
Conversation associated at	Date	on, not on, before, after, between, is empty, is not empty	open date picker
Conversation last activity at	Date	on, not on, before, after, between, is empty, is not empty	open date picker
Conversation status	Single-line text	is, is not, contains, does not contain, starts with, ends with, is empty, is not empty	Return all values as value suggestions
Conversation assignee	Single-line text	is, is not, contains, does not contain, starts with, ends with, is empty, is not empty	Return all values as value suggestions
Conversation channel	Single-line text	is, is not, contains, does not contain, starts with, ends with, is empty, is not empty	Return all values as value suggestions
Conversation account name	Single-line text	is, is not, contains, does not contain, starts with, ends with, is empty, is not empty	Return all values as value suggestions
Conversations tags	Single-line text	is, is not, contains, does not contain, starts with, ends with, is empty, is not empty	Return all values as value suggestions

Operator Logic — Customer Associations: Campaigns

Field Type	Type	Supported Operators	Details
Total campaign received	Number	equals, not equals, greater than, less than, between, is empty, is not empty	Return all value as value suggestions
Received campaign name	Single-line text	is, is not, contains, does not contain, starts with, ends with, is empty, is not empty	Return all values as value suggestions
Campaign open at	Date	on, not on, before, after, between, is empty, is not empty	open date picker
Campaign reply at	Date	on, not on, before, after, between, is empty, is not empty	open date picker
Campaign channel	Single-line text	is, is not, contains, does not contain, starts with, ends with, is empty, is not empty	Return all values as value suggestions
Campaign status	Single-line text	is, is not, contains, does not contain, starts with, ends with, is empty, is not empty	Return all values as value suggestions

Operator Logic — Customer Associations: Tickets

Field Type	Type	Supported Operators	Details
Total ticket associated	Number	equals, not equals, greater than, less than, between, is empty, is not empty	Return all value as value suggestions
Ticket associated at	Date	on, not on, before, after, between, is empty, is not empty	open date picker
Ticket last update at	Date	on, not on, before, after, between, is empty, is not empty	open date picker
Ticket due date at	Date	on, not on, before, after, between, is empty, is not empty	open date picker
Ticket SLA status	Single-line text	is, is not, contains, does not contain, starts with, ends with, is empty, is not empty	Return all values as value suggestions
Ticket pipeline	Single-line text	is, is not, contains, does not contain, starts with, ends with, is empty, is not empty	Return all values as value suggestions
Ticket stage	Single-line text	is, is not, contains, does not contain, starts with, ends with, is empty, is not empty	Return all values as value suggestions
Ticket owner	Dropdown selection	is, is not, contains, does not contain, is empty, is not empty	Return all user name as value suggestions
Ticket assignee	Dropdown selection	is, is not, contains, does not contain, is empty, is not empty	Return all user name as value suggestions
Ticket priority	Single-line text	is, is not, contains, does not contain, starts with, ends with, is empty, is not empty	Return all values as value suggestions

---

13.2.6 Best-Practice Aggregate Metrics — Default Segmentation Options (per domain)

Qontak provides these per-customer aggregate / derived metrics as ready-to-use segmentation options (no setup required) so clients can segment on outcomes directly. They are benchmarked from the CEBE "Metrics enabled per domain" (CEBE ANCHOR → Module Event Catalog) and common CDP practice (HubSpot, Salesforce, Intercom). Each metric is a typed field with its own operator logic and complements the field-level association operators above.

Availability: these aggregate use-case metrics follow package gating — Ultimate / 360 (see §6 Constraints). Excluded by design: org-level metrics that are not per-customer and therefore cannot define an audience (e.g. new-customer growth rate, customer acquisition by source, enrollment rate, tier distribution).

Operator legend — Number/Currency: equals, not equals, greater than, less than, between, is empty, is not empty · Percentage (0–100): greater than, less than, between, equals, not equals · Ratio: greater than, less than, between · Boolean: is (true/false), is empty, is not empty · Dropdown/Enum: is, is not, contains, does not contain, is empty, is not empty.

A. Communication — Chat & Call (from CEBE Communication metrics)

Metric (segmentation field)	Type	Supported Operators	Definition / best-practice use
Total conversations	Number	equals, not equals, greater than, less than, between, is empty, is not empty	Count of conversations associated; high = engaged, 0 = never contacted
Reply rate	Percentage	greater than, less than, between, equals, not equals	% of messages the customer replied to; low = unresponsive / re-engage
Total messages sent by customer	Number	equals, not equals, greater than, less than, between	Inbound message volume
Channel (used / preferred)	Dropdown (WhatsApp, Email, IG, …)	is, is not, contains, does not contain, is empty, is not empty	Channel preference for targeting
Avg customer response time (minutes)	Number	greater than, less than, between, is empty, is not empty	Responsiveness
Avg call duration (seconds)	Number	greater than, less than, between, is empty, is not empty	Call engagement depth
Avg CSAT score	Number (1–5)	greater than, less than, between, equals, is empty, is not empty	< 3 = at-risk → prioritize, avoid automation
Avg NPS score	Number (0–10)	greater than, less than, between, equals, is empty, is not empty	Detractor (≤6) vs promoter (≥9)
AI containment rate	Percentage	greater than, less than, between	% resolved by bot without human

B. Service — Tickets (from CEBE Ticketing metrics)

Metric (segmentation field)	Type	Supported Operators	Definition / best-practice use
Total tickets created	Number	equals, not equals, greater than, less than, between	Support load per customer
Resolution rate	Percentage	greater than, less than, between, equals, not equals	Low resolution = at-risk
Avg time to resolve (hours)	Number	greater than, less than, between, is empty, is not empty	Service speed
SLA breach count	Number	equals, not equals, greater than, less than, between	Repeated breaches = escalate
SLA breach rate	Percentage	greater than, less than, between	Reliability of service to this customer
Repeat issue flag	Boolean	is (true/false), is empty, is not empty	Same category re-raised → proactive outreach

C. Sales — Deals (from CEBE Deals metrics)

Metric (segmentation field)	Type	Supported Operators	Definition / best-practice use
Total deals created	Number	equals, not equals, greater than, less than, between	Pipeline volume per customer
Total deal size	Currency (IDR)	equals, not equals, greater than, less than, between, is empty, is not empty	High value = VIP / retention & upsell
Won rate	Percentage	greater than, less than, between, equals, not equals	Conversion strength
Lost rate	Percentage	greater than, less than, between, equals, not equals	Win-back targeting
Avg time to conversion (days)	Number	greater than, less than, between, is empty, is not empty	Sales cycle length
Rotten time breach count	Number	equals, not equals, greater than, less than, between	Stalled deals
Rotten time breach rate	Percentage	greater than, less than, between	Pipeline hygiene

D. Marketing — Broadcast & Ads (from CEBE Campaign metrics)

Metric (segmentation field)	Type	Supported Operators	Definition / best-practice use
Total campaigns received	Number	equals, not equals, greater than, less than, between	Contact fatigue / reachable
Delivery rate	Percentage	greater than, less than, between	Deliverability per customer
Reply rate	Percentage	greater than, less than, between, equals, not equals	Marketing engagement
Marketing opt-in status	Boolean	is (true/false), is empty, is not empty	Consent gating (see §13.2 Communication Consent)
Campaign-attributed revenue	Currency (IDR)	equals, not equals, greater than, less than, between	Marketing ROI per customer
Ad impressions	Number	equals, not equals, greater than, less than, between	Paid exposure
Ad clicks	Number	equals, not equals, greater than, less than, between	Paid engagement
Ads conversion rate	Percentage	greater than, less than, between, equals, not equals	% ads conversion
Cost per lead (CPL)	Currency (IDR)	greater than, less than, between	Acquisition efficiency
Cost per acquisition (CPA)	Currency (IDR)	greater than, less than, between	Acquisition efficiency
ROAS	Ratio (×)	greater than, less than, between	Return on ad spend; high ROAS = nurture

E. Commerce & Booking — Conversion (from CEBE Conversion metrics)

Metric (segmentation field)	Type	Supported Operators	Definition / best-practice use
Total bookings	Number	equals, not equals, greater than, less than, between	Booking volume
Booking completed rate	Percentage	greater than, less than, between	No-show / completion behavior
Total spend (LTV)	Currency (IDR)	equals, not equals, greater than, less than, between, is empty, is not empty	High LTV = VIP / loyalty
Avg order value (AOV)	Currency (IDR)	equals, not equals, greater than, less than, between	Upsell / premium targeting
Preferred payment method	Dropdown	is, is not, contains, does not contain, is empty, is not empty	Payment preference
Purchase frequency (orders / 90 days)	Number	equals, not equals, greater than, less than, between	Repeat-purchase behavior
Paid rate	Percentage	greater than, less than, between	Payment reliability

F. Loyalty (from CEBE Loyalty metrics; date/reward fields already in §13.2 Member Loyalty)

Metric (segmentation field)	Type	Supported Operators	Definition / best-practice use
Is loyalty member	Boolean	is (true/false), is empty, is not empty	Member vs non-member journeys
Total available points	Number	equals, not equals, greater than, less than, between	Burn / re-engagement triggers
Current tier	Dropdown / text	is, is not, contains, does not contain, is empty, is not empty	Tier-based offers

G. Cross-domain — Recency & RFM (best practice surfaced by the competitive benchmark below)

RFM is the most common segmentation framework across CDPs (Klaviyo, Salesforce, Zoho). Qontak's existing metrics already cover Frequency (total conversations / purchase frequency / total campaigns) and Monetary (LTV / total deal size / AOV); the Recency metrics below complete it. Recency is computed from the latest associated timestamp per domain.

Metric (segmentation field)	Type	Supported Operators	Definition / best-practice use
Days since last conversation	Number (days)	greater than, less than, between, is empty, is not empty	Service/engagement recency; > 90 = lapsed / re-engage
Days since last order / purchase	Number (days)	greater than, less than, between, is empty, is not empty	Commerce recency; win-back triggers
Days since last campaign engagement	Number (days)	greater than, less than, between, is empty, is not empty	Marketing recency; suppress recently-contacted / re-target dormant
Days since last activity (any module)	Number (days)	greater than, less than, between, is empty, is not empty	Overall recency; dormant / churn-risk detection
Customer tenure (days since created)	Number (days)	greater than, less than, between	Lifecycle age; onboarding vs mature cohorts

H. Customer base (CDP): per-customer base attributes (source, created/updated at/by, segment membership) are already covered by the Basic Attributes PRD and §13.2 above. CDP org-level metrics (new-customer growth, acquisition-by-source) are excluded as non-segmentable.

13.2.7 Competitive Benchmark — Segmentation Capabilities

Benchmarked against leading platforms that own customer groups / segmentation, to confirm which dimensions Qontak should provide by default and what to defer. Legend: ✓ native · ~ partial / add-on / enterprise tier · ✗ not offered.

Segmentation capability	HubSpot (Lists)	Salesforce (Data Cloud / MC)	Intercom	Klaviyo	Braze	Zendesk	Qontak CDP (this PRD)
Attribute / custom fields	✓	✓	✓	✓	✓	✓	✓ (Basic Attributes)
Firmographic (company)	✓	✓	✓	~	~	✓ (org)	✓ (Company assoc)
Messaging engagement (chat/email/SMS)	✓	✓	✓	✓	✓	~	✓ (Conversations + Campaign)
Service / support (tickets, CSAT, SLA)	✓	~	~	✗	✗	✓	✓ (Tickets + CSAT/SLA)
Sales / deal (pipeline, value, won-rate)	✓	✓	✗	✗	✗	✗	✓ (Deals)
Commerce (LTV, AOV, frequency)	~	✓	✗	✓	✓	✗	✓ (Commerce & Booking)
Loyalty (tier, points, membership)	~	~	✗	~	~	✗	✓ (Loyalty)
RFM (recency / frequency / monetary)	~	✓	~	✓	~	~	✓ (with §13.2.6 G — Recency)
Aggregate computed traits (count/sum over window)	✓	✓	✓	✓	✓	~	✓ (§13.2.6 metrics)
List / segment membership (in / not in)	✓	✓	✓	✓	✓	✓	~ (segment-as-recipient via Basic Attributes; exclusion deferred)
Nested AND/OR (exceptions deferred)	✓	✓	✓	✓	✓	~	✓ nested (SEG-S07/08); exceptions deferred
Predictive (CLV-predicted, churn risk, next-order)	~ (Ent)	✓	~	✓	✓	✗	✗ — deferred
Real-time re-evaluation	✓	✓	✓	✓	✓	~	Daily batch — by design

Decisions from the benchmark

• Added for parity (now): the §13.2.6 per-domain aggregate metrics + the §13.2.6 G Recency metrics complete RFM and match the engagement/commerce depth of Klaviyo/Braze/Salesforce.
• Qontak differentiator: very few platforms expose service (CSAT/SLA/tickets) + sales (deals) + commerce + loyalty + messaging in one segmentation engine — marketing tools (Klaviyo/Braze) lack service & sales depth; CRMs (Zendesk) lack messaging/commerce. This cross-module breadth is what CEBE unlocks.
• Deferred (post-MVP): predictive / ML metrics (predicted CLV, churn-risk score, predicted next-order) — consistent with Non-Goal #1 (rule-based only) and delivered later via the CEBE Customer Health Score (Q1 2027). Real-time re-evaluation stays out of scope (Non-Goal #4) — daily batch is the deliberate v1 trade-off; competitors' real-time is the upgrade path. Exception filters (exclude specific customers/segments) are descoped for now.

13.3 User Stories

User Story	Importance	Mockup	Technical Notes	Acceptance Criteria
[SEG-S01] — Configure Segment (Create/Edit): Customer Properties / Fields As a CDP user I want to define conditions based on customer information (default and custom fields), so that I can accurately segment customers using appropriate operators based on each field type.	Must Have	—	Jira: TF-2549 Operators per field type: see §13.2 Operator Logic Reference.	AC-1 (Single-line Text Field): • Given the user selects a Single-line text customer field • When the user selects an operator and inputs a text value • Then the system should filter customers based on string comparison; matching should be case-insensitive; customers with empty values should only be included if is empty is selected AC-2 (Multi-line Text Field): • Given the user selects a Multi-line text customer field • When the user selects an operator and inputs a text value • Then the system should evaluate the full text content; matching case-insensitive; empty values included only if is empty selected AC-3 (Dropdown Selection): • Given the user selects a Dropdown selection field • When the user selects an operator and selects one dropdown option • Then the system should include customers whose value exactly matches the selected option; only one value should be selectable AC-4 (Multiple Selection): • Given the user selects a Multiple selection field • When the user selects an operator and selects one or more options • Then contains any matches customers with at least one selected option; contains all matches customers with all selected options; order of selection should not affect results AC-5 (Number Field): • Given the user selects a Number field • When the user selects an operator and inputs valid numeric values • Then the system should compare values numerically (not as strings); invalid inputs (e.g. text) should be rejected AC-6 (Date Field): • Given the user selects a Date field • When the user selects an operator and selects valid date values • Then the system should evaluate dates based on system timezone; relative operators (e.g. in the last 7 days) should be recalculated dynamically AC-7 (URL Field): • Given the user selects a URL field • When the user selects an operator and inputs a URL or partial URL • Then the system should match based on string comparison; URL protocol (http, https) should not affect matching unless explicitly included AC-8 (File upload Field): • Given the user selects a File upload field • When the user selects an operator • Then the system should check whether at least one file exists for the field; file metadata (name/type) should not be required AC-9 (Signature Field): • Given the user selects a Signature field • When the user selects an operator • Then the system should evaluate based on signature presence; partial or invalid signatures should be treated as not signed AC-10 (GPS Field): • Given the user selects a GPS field • When the user selects an operator • Then the system should evaluate based on GPS presence
[SEG-S02] — Configure Segment (Create/Edit): Customer Associations — Conversations As a CDP user I want to define conditions based on customer associations, so that I can accurately segment customers using appropriate operators based on each data.	Must Have	—	Jira: TF-2550	AC-1 (Total number of conversations associated): • Given the user selects Associations → Conversations → Total conversations • When the user selects an operator and inputs a numeric value • Then the system should evaluate the total number of conversations associated with each customer; only conversations linked to the customer ID should be counted; the trigger should activate for matching customers; condition recalculated dynamically AC-2 (Conversation association date): • Given the user selects Conversation associated at • When the user selects an operator and defines a date or date range • Then the system should evaluate the first association timestamp between customer and conversation; relative date operators recalculated dynamically; timezone follows system configuration; condition recalculated dynamically AC-3 (Last conversation activity): • Given the user selects Conversation last activity at • When the user selects an operator and defines a date or date range • Then the system should evaluate the latest activity timestamp across all associated conversations; relative date operators recalculated dynamically; timezone follows system configuration; condition recalculated dynamically AC-4 (Conversation status): • Given the user selects Conversation status • When the user selects an operator and selects one status (e.g. open, closed, pending) • Then the system should match customers who have at least one associated conversation with the selected status; status values follow the conversation system enum; condition recalculated dynamically AC-5 (Conversation assignee): • Given the user selects Conversation assignee • When the user selects an operator and selects a user • Then the system should match customers with at least one conversation assigned to the selected assignee; unassigned conversations only match if explicitly supported; condition recalculated dynamically AC-6 (Conversation channel): • Given the user selects Conversation channel • When the user selects an operator and selects one channel (e.g. WhatsApp, Email, Live Chat) • Then the system should match customers who have conversations from the selected channels; channel values follow configured channel integrations; condition recalculated dynamically AC-7 (Conversation account name): • Given the user selects Conversation account name • When the user selects an operator and selects one account name • Then the system should match customers whose conversations are associated with the specified account; account name values follow configured channel integrations; condition recalculated dynamically AC-8 (Any vs All association logic): • Given a customer has multiple associated conversations • When a trigger condition is evaluated • Then the system should apply ANY-match logic by default; the customer is included if at least one associated conversation satisfies the condition; condition recalculated dynamically
[SEG-S03] — Configure Segment (Create/Edit): Customer Associations — Campaigns As a CDP user I want to define conditions based on customer associations, so that I can accurately segment customers using appropriate operators based on each data.	Must Have	—	Jira: TF-2551	AC-1 (Received Campaign Name): • Given the user selects Received Campaign Name • When the user selects an operator and selects or inputs a campaign name value • Then the system should evaluate whether the customer has received the specified campaign name; check campaign delivery records associated with the customer; if multiple campaigns exist, evaluate all associated delivery records; return customers whose campaign name matches the selected operator logic (equals / not equals / contains / in); recalculated dynamically whenever the segment is evaluated AC-2 (Total campaign associated): • Given a customer has one or more campaigns associated, each with a received_at timestamp, and the system tracks total campaigns received per customer • When a user defines Total campaigns associated, selects an operator, input value N • Then the system should evaluate the total count of associated campaigns; include the customer if the condition is met; count recalculated dynamically as new campaigns are received AC-3 (Campaign replied at): • Given the user selects campaign replied at • When the user selects an operator and defines a date or date range • Then the system should evaluate the timestamp of the customer's reply to the campaign message; if multiple replies exist, evaluate the latest reply timestamp; relative date operators recalculated dynamically; timezone follows system configuration; condition recalculated dynamically AC-4 (Campaign sent at): • Given the user selects Campaign Sent At • When the user selects an operator and defines a date or date range • Then the system should evaluate the timestamp when the campaign message was sent to the customer; if multiple campaigns were sent, evaluate all send records; relative date operators recalculated dynamically; timezone follows system configuration; condition recalculated dynamically AC-5 (Campaign channel): • Given a customer has one or more campaigns associated, each with a channel attribute (e.g. WhatsApp, Email) • When a user defines Campaign channel, selects an operator, value = selected channel • Then the system should evaluate the campaign channel field; include the customer if the channel condition matches per the selected association logic; recalculated dynamically AC-6 (Campaign status): • Given a customer has campaigns associated, each with a status (Sent, Delivered, Failed, Read, Replied) • When a user defines Campaign status, selects an operator, value = selected status • Then the system should evaluate the campaign status for each associated campaign; include the customer if met per the selected association logic; recalculated dynamically AC-7 (Any vs All association logic): • Given a customer has multiple associated campaigns • When a trigger condition is evaluated • Then the system should apply ANY-match logic by default; include the customer if at least one association satisfies the condition; recalculated dynamically
[SEG-S04] — Configure Segment (Create/Edit): Customer Associations — Company As a CDP user I want to define conditions based on customer associations, so that I can accurately segment customers using appropriate operators based on each data.	Must Have	—	Jira: TF-2552	AC-1 (Company's industry): • Given a customer is associated with one company, each company has an industry attribute • When a user defines Company industry, selects an operator, value = selected industry • Then the system should evaluate the company industry field; include the customer if the industry condition matches per the selected association logic; recalculated dynamically AC-2 (Number of employees): • Given a customer is associated with one company, each company has a number of employees attribute • When a user defines Number of employees, selects an operator, value = defined employee range or number • Then the system should evaluate the number of employees field; include the customer if the condition matches per the selected association logic; recalculated dynamically AC-3 (Company revenue): • Given a customer is associated with one company, each company has a company revenue attribute • When a user defines Company revenue, selects an operator, value = defined revenue range or number • Then the system should evaluate the company revenue field; include the customer if the condition matches per the selected association logic; recalculated dynamically
[SEG-S05] — Configure Segment (Create/Edit): Customer Associations — Deals As a CDP user I want to define conditions based on customer associations, so that I can accurately segment customers using appropriate operators based on each data.	Must Have	—	Jira: TF-2553	AC-1 (Total deal associated): • Given a customer is associated with one or more deals • When a user defines Total deal associated, selects an operator, value = defined number of deal • Then the system should calculate the total number of associated deals; include the customer if the deal count condition matches; recalculated dynamically AC-2 (Deal approval status): • Given a customer is associated with one or more deals, each with an approval status • When a user defines Deal approval status, selects an operator, value = selected approval status • Then the system should evaluate the deal approval status field; include the customer if it matches per the selected association logic; recalculated dynamically AC-3 (Deal pipeline): • Given a customer is associated with one or more deals, each belonging to a pipeline • When a user defines Deal pipeline, selects an operator, value = selected pipeline • Then the system should evaluate the deal pipeline field; include the customer if it matches per the selected association logic; recalculated dynamically AC-4 (Deal stage): • Given a customer is associated with one or more deals, each belonging to a stage • When a user defines Deal stage, selects an operator, value = selected stage • Then the system should evaluate the deal stage field; include the customer if it matches per the selected association logic; recalculated dynamically AC-5 (Deal size): • Given a customer is associated with one or more deals, each with a deal size/value • When a user defines Deal size, selects an operator, value = defined deal size or range • Then the system should evaluate the deal size field; include the customer if it matches per the selected association logic; recalculated dynamically AC-6 (Deal owner): • Given a customer is associated with one or more deals, each with a deal owner • When a user defines Deal owner, selects an operator, value = selected deal owner • Then the system should evaluate the deal owner field; include the customer if it matches per the selected association logic; recalculated dynamically AC-7 (Deal priority): • Given a customer is associated with one or more deals, each with a priority attribute • When a user defines Deal priority, selects an operator, value = selected priority • Then the system should evaluate the deal priority field; include the customer if it matches per the selected association logic; recalculated dynamically
[SEG-S06] — Configure Segment (Create/Edit): Customer Associations — Ticket As a CDP user I want to define conditions based on customer associations, so that I can accurately segment customers using appropriate operators based on each data.	Must Have	—	Jira: TF-2554	AC-1 (Total ticket associated): • Given a customer is associated with one or more tickets • When a user defines Total ticket associated, selects an operator, value = defined number of ticket • Then the system should calculate the total number of associated tickets; include the customer if the ticket count condition matches; recalculated dynamically AC-2 (Ticket pipeline): • Given a customer is associated with one or more tickets, each belonging to a pipeline • When a user defines Ticket pipeline, selects an operator, value = selected pipeline • Then the system should evaluate the ticket pipeline field; include the customer if it matches per the selected association logic; recalculated dynamically AC-3 (Ticket stage): • Given a customer is associated with one or more tickets, each belonging to a stage • When a user defines Ticket stage, selects an operator, value = selected stage • Then the system should evaluate the ticket stage field; include the customer if it matches per the selected association logic; recalculated dynamically AC-4 (Ticket reporter): • Given a customer is associated with one or more tickets, each with a reporter • When a user defines Ticket reporter, selects an operator, value = selected reporter • Then the system should evaluate the ticket reporter field; include the customer if it matches per the selected association logic; recalculated dynamically AC-5 (Ticket assignee): • Given a customer is associated with one or more tickets, each with an assignee • When a user defines Ticket assignee, selects an operator, value = selected assignee • Then the system should evaluate the ticket assignee field; include the customer if it matches per the selected association logic; recalculated dynamically AC-6 (Ticket priority): • Given a customer is associated with one or more tickets, each with a priority • When a user defines Ticket priority, selects an operator, value = selected priority • Then the system should evaluate the ticket priority field; include the customer if it matches per the selected association logic; recalculated dynamically AC-7 (Ticket SLA status): • Given a customer is associated with one or more tickets, each with an SLA status • When a user defines Ticket SLA status, selects an operator, value = selected SLA status • Then the system should evaluate the ticket SLA status field; include the customer if it matches per the selected association logic; recalculated dynamically
[SEG-S07] — Configure Segment (Create/Edit): Add Nested Filter in the Same Criteria As a CDP user, I want to add up to 2 filters within the same criteria group (nested conditions), so that I can define more precise segmentation logic using combinations of conditions such as AND / OR within the same criteria.	Must Have		—	AC-1 (Add Another Filter in the Same Criteria Group): • Given the user is configuring a segment criteria, and there is an existing filter condition in the criteria group • When the user clicks "Add Filter" within the same criteria group • Then the system should add a new filter row under the same criteria group. Expected: the new filter appears directly under the existing condition; belongs to the same criteria group; the user can configure Attribute / field, Operator, Value AC-2 (Apply Logical Operator Between Filters): • Given multiple filters exist within the same criteria group • When the user selects the logical operator • Then the system should allow choosing between AND / OR. Expected: the operator is displayed between filters; the selected operator defines how conditions are evaluated. Example: Customer City = Jakarta AND Customer Age > 25 AC-3 (Remove Filter Within Criteria Group): • Given the criteria group contains multiple filters • When the user removes one filter • Then the system should remove the selected filter without affecting the remaining filters. Expected: other filters remain intact; logical operators are automatically adjusted if necessary
[SEG-S08] — Configure Segment (Create/Edit): Advanced Criteria Builder (Nested & Multiple Filters) As a CDP user I want to add multiple filters and create nested criteria groups, so that I can build complex conditions using logical operators such as AND / OR to define more accurate segmentation rules.	Must Have		—	AC-1 (Apply Logical Operator Between Filters): • Given there are multiple filters in the same criteria group • When the user selects the logical operator • Then the system should allow choosing AND / OR. Example: (Customer Country = Indonesia AND Customer Tier = Gold) OR (Customer Country = Singapore AND Customer Tier = Gold) AC-2 (Remove Filter from Criteria): • Given a criteria group contains multiple filters • When the user removes one filter • Then the system should remove only that filter and keep the remaining conditions intact. Expected: logical operators automatically adjust; remaining filters stay within the same criteria group AC-3 (Remove Nested Criteria Group): • Given a nested criteria group exists • When the user deletes the nested criteria group • Then the system removes the entire group including all filters inside it
[SEG-S10] — Configure Segment (Create/Edit): Preview Customer As a CDP user I want to preview the list and total number of customers matching my filter criteria, so that I can validate whether the segmentation rules return the expected audience before applying the filter.	Must Have		—	AC-1 (Preview Customers Button): • Given the user has configured one or more filter criteria • When the user clicks "Preview customers" • Then the system should evaluate the filter conditions and display the Preview Customers panel on the right side. The panel should show: total number of matched customers, a short summary of the filter criteria, a preview list of customers (if applicable). Example: Filter results from 5,000 customers · 2,500 customers matched · Source is WhatsApp AND Province is Jakarta AC-2 (No Matching Customers): • Given the filter criteria return no customers • When the user clicks Preview customers • Then the preview panel should display an empty state. Example message: "No customers match your filters. Recheck the filters you have applied and refresh."
[SEG-S11] — Customer Segment Details — Overview — Active Segment As a CDP user, I want to view a detailed overview of a selected active customer segment, so that I can understand the segment information, matched customers, and take further actions such as sending campaigns or managing the segment.	Must Have		Jira: TF-2555	AC-1 (Open from Customer Index Menu): • Given I am on the Customer index page • When I click on a segment name • Then I am redirected to the Segment Details and the selected segment information is displayed AC-2 (Send Campaign from Segment Overview): • Given the user is viewing the Active Segment Details – Overview page • When the user clicks the Send Campaign button (capability delivered by Basic Attributes, TF-2545) • Then the system should open the Send-Campaign sidebar — WhatsApp broadcast only for now (Email broadcast not yet supported) AC-3 (Open More Actions Menu): • Given the user is viewing the Active Segment Details – Overview page • When the user clicks the More actions dropdown • Then the system should display: Edit segment (redirect to segment configuration/edit page); Archive segment (show a confirmation dialog before archiving) AC-4 (Display Segment Information): • Given I am on the Segment Details page • When the page loads • Then I see a Segment Info section containing: Segment status (Active / Archived), Segmentation name, Description, Filter pattern AC-5 (Display Segment Data Summary): • Given I am on the Segment Details page • When the page loads • Then I see: Total customers matched (count of unique customers meeting all conditions; e.g. 5,000); Percentage reach % = (Total Matched / Total Customers) × 100 (e.g. 5,000/10,000 = 50%); Last updated timestamp (based on user device timezone); Reachability by channel — WhatsApp = (customers with phone or bsuid AND chatroom) / Total Matched × 100; Email = (customers with email) / Total Matched × 100 AC-6 (Display Customer Matched Table): • Given the segment contains customers • When the page loads • Then I see a table containing: Customer name, Source, Last activity (user device timezone), Added by
[SEG-S12] — Customer Segment Details — Overview — Archived Segment As a CDP user, I want to view a detailed overview of a selected archived customer segment, so that I can understand the segment information, matched customers, and take further actions.	Must Have		Jira: TF-2555	AC-1 (Open from Customer Index Menu): • Given I am on the Customer index page • When I click on a segment name • Then I am redirected to the Segment Details and the selected segment information is displayed AC-2 (Display Segment Information): • Given I am on the Segment Details page • When the page loads • Then I see a Segment Info section containing: Segment status (Archived), Segmentation name, Description, Filter pattern AC-3 (Display Segment Data Summary): • Given I am on the Segment Details page • When the page loads • Then I can see: Total customers matched, Percentage reach % from total customers, Last updated timestamp; but I cannot see: Reachability by channel AC-4 (Display Customer Matched Table): • Given the segment contains customers • When the page loads • Then I see a table containing: Customer name, Source, Last activity (user device timezone), Added by
[SEG-S13] — Customer Segment Details — Performance As a CDP user, I want to view performance insights of a selected segment, so that I can understand how the segment grows over time and analyze its demographic and channel distribution.	Must Have	—	Jira: TBD	AC-1 (Metric #2: Segment Size Growth): • Display Growth Chart: on the Performance tab, a "Segment size growth" line chart shows the number of customers over time • Data Points: X-axis Date/time, Y-axis Total customers, plotted chronologically • Time Filter: All time / Last 7 days / Last 30 days updates the chart • Realtime Indicator: data updates once a day; "Last updated" refreshes; "Realtime" indicator displayed if applicable • Empty State: message when no historical growth data exists AC-2 (Metric #3: Segment Source): • Display Source Distribution chart by source channel (WhatsApp, Email, Instagram, etc.) • Source Summary List: source name, customer count, percentage of total • Percentage = (source count / total segment size) × 100; totals to 100% (± rounding) • Empty/Missing Source grouped under "Other" AC-3 (Metric #4: Segment Domicile): • Display Domicile Distribution chart • Summary list: Region name (province from address picker object), customer count, percentage • Missing location data grouped under "Unknown" AC-4 (Metric #5: Segment Age): • Display Age Distribution chart grouped into ranges (<21, 21-30, 31-40, 41-50, >51) • Age computed from date of birth vs current date, grouped into buckets • Missing DOB grouped under "Unknown" AC-5 (Metric #6: Segment Gender): • Display Gender Distribution chart • Categories: Male, Female, Unknown (if not provided); each shows count + percentage
[SEG-S15] — Permission Key for Segmentation Feature As an administrator I want to control user access to customer segmentation features based on permission keys, so that users can only view, create, manage, or archive customer segments according to their assigned role permissions.	Must Have	—	Permission keys: customers_segment_view, customers_segment_add, customers_segment_manage, customers_segment_archived	AC-1 (View Customer Segments): • Given the user tries to access Customer Segments • When the system checks customers_segment_view • Then: IF ALL ACCESS → view all segments; IF OWNED ONLY → view only segments created by themselves; IF DISABLED → Customer Segments section is hidden AC-2 (Add Customer Segment): • Given the user accesses the Customer Segments page • When they attempt to create a new segment • Then the system verifies customers_segment_add: IF ALL ACCESS → can create new segments; ELSE → Create Segment button hidden or disabled AC-3 (Manage Customer Segment (Edit)): • Given the user attempts to edit an existing segment • When the system checks customers_segment_manage • Then: IF ALL ACCESS → edit any segment; IF OWNED ONLY → edit only segments they created; IF DISABLED → edit actions hidden or disabled AC-4 (Archive Customer Segment): • Given the user attempts to archive/unarchive a segment • When the system verifies customers_segment_archived • Then: IF ALL ACCESS → archive/unarchive any segment; IF OWNED ONLY → only segments they created; IF DISABLED → archive/unarchive option hidden or disabled

---

PRD CHANGELOG

Version	Date	By	Section	Type	Summary
1.0	2026-05-21	Claude	All	CREATED	NEW PRD created for Customer Segmentation — Use-Case Activities. Rule-based dynamic segments with nightly evaluation, manual refresh, segment quota, nested/exception filters, Growth + Enterprise only.
1.1	2026-06-26	Claude	All	MODIFIED	Reformatted to write-prd skill: added Anchor link (Customer Segmentation ANCHOR) + Scope Changes section; renumbered sections; converted API behaviors to a table and stories to the 5-column story table (15 stories, all scenarios preserved, AC-numbered); operator-logic reference kept as tables; screenshots linked via page attachment URLs; cleaned flattened inline-link artifacts in AC text. No scenario content removed.
1.2	2026-06-26	Claude	S13.2	MODIFIED	Added §13.2.6 Best-Practice Aggregate Metrics — Qontak-default segmentation options per domain (Communication, Service, Sales, Marketing, Commerce/Booking, Loyalty), each typed with operator logic; benchmarked from CEBE "Metrics enabled per domain". Org-level (non-segmentable) metrics explicitly excluded.
1.3	2026-06-26	Claude	S13.2	MODIFIED	Added §13.2.6 G Cross-domain Recency/RFM metrics and §13.2.7 Competitive Benchmark (HubSpot, Salesforce, Intercom, Klaviyo, Braze, Zendesk) with parity decisions; deferred predictive/ML metrics to CEBE Customer Health Score and kept daily-batch (not real-time) by design.
1.4	2026-06-26	Claude	S1, S11, S13 (deps)	MODIFIED	Reframed §11 from "New Features" to "Feature Changes — Enhancement to the Segment Builder": the List/Builder/Detail backbone is delivered by the Basic Attributes initiative; this PRD enhances the existing builder's condition palette with use-case activities (associations + aggregate metrics + recency/RFM), exception filters, Performance tab, and send-campaign. Added Basic Attributes as a blocking core dependency; updated one-liner.
1.5	2026-06-26	Claude	S4, S5, S11, S13	MODIFIED	Descoped Exception filter (removed story SEG-S09 + builder/tree/benchmark refs; added Non-Goal #7). Reframed segment utilisation (Send Campaign WhatsApp/Email + reuse-as-Broadcast-recipient) as already delivered by Basic Attributes (TF-2545): removed duplicate story SEG-S14 and the §11 "added" claim, leaving a referencing note.
1.6	2026-06-26	Claude	S4, S11	MODIFIED	Clarified that segment-based Send Campaign is WhatsApp broadcast only for now (Email broadcast not yet supported); the WhatsApp capability is delivered by Basic Attributes (TF-2545). Updated §11 note + SEG-S11 AC-2; added Non-Goal #8.