---
title: "Customer Experience Platform Requirements: The Checklist to Write Before You Shortlist"
date: "2026-08-13"
description: "Customer experience platform requirements are the documented, testable capabilities an organization needs a CX platform to deliver — functional (what it must do), non-functional (how securely, quickly, and reliably it must do it), and integration (what it must connect to) — written down before any vendor demo."
keywords: ["customer experience platform requirements"]
author: "Perspective AI Team"
category: "AI Conversations at Scale"
slug: "customer-experience-platform-requirements-checklist-to-write-before-you-shortlist"
excerpt: "Customer experience platform requirements are the documented, testable capabilities an organization needs a CX platform to deliver — functional (what it must…"
image: "https://getperspective.agency/assets/5b20eacf-2ca0-4633-8121-a6db194b5cca"
tags: ["how-to", "customer research", "guides", "product management"]
lastModified: "2026-08-13"
definition: "Customer experience platform requirements are the documented, testable capabilities an organization needs a CX platform to deliver — functional (what it must do), non-functional (how securely, quickly, and reliably it must do it), and integration (what it must connect to) — written down before any vendor demo. A complete requirements set assigns each line an owner, a priority, and an acceptance test that proves the requirement was actually met, so evaluation compares products against your operation rather than against each other's marketing."
faqs: [{"question": "How long should customer experience platform requirements gathering take?", "answer": "Two to three weeks is the right timebox for most mid-market programs. That covers 15 to 25 stakeholder interviews, a draft, one review round, and sign-off. Enterprise programs with multiple regions or regulated data may need four to six weeks, mostly for security and privacy review. If it runs past a quarter, the blocker is usually unclear decision rights rather than missing information."}, {"question": "What is the difference between functional and non-functional requirements for a CX platform?", "answer": "Functional requirements describe what the platform must let someone do; non-functional requirements describe the conditions under which doing it is acceptable. \"Alert the account owner when an account logs two negative responses\" is functional. \"Store all EU customer data in the EU, encrypt it at rest, and delete it within 30 days of an erasure request\" is non-functional. Both are mandatory, but non-functional requirements are the ones that most often stall a deal when written late."}, {"question": "How many requirements should a CX platform RFP contain?", "answer": "Between 40 and 80 total requirements, with no more than 20 marked as must-haves. Below 40 the document is too vague to discriminate between vendors; above roughly 100, reviewers skim and vendors answer generically. The must-have cap matters more than the total, because a document where everything is mandatory cannot resolve a trade-off — which is the only reason to write it."}, {"question": "Who should own the customer experience platform requirements document?", "answer": "A single named owner should hold it, usually the CX or customer operations lead, with contributing owners for security, data, and each functional team. Shared ownership produces a document nobody arbitrates. The owner's job is not to write every line but to enforce the priority cap, reject requirements with no traceable source, and hold the scoring weights fixed once demos begin."}, {"question": "Should requirements specify AI capabilities directly?", "answer": "Yes, but specify the outcome and the guardrail rather than the technique. \"The platform must ask unscripted follow-up questions and return a reason for at least 60% of completed responses\" is testable; \"must use generative AI\" is not. Pair every AI capability requirement with a governance requirement covering training-data use, PII redaction, output traceability, and human review before executive reporting."}, {"question": "How do you keep requirements vendor-neutral?", "answer": "Write them before any demo, phrase each one as a job with a measurable completion condition, and ban product-specific nouns from the document. If a requirement uses a term you first heard from a salesperson, rewrite it in your own operational language. A useful test: if only one product on the market could plausibly satisfy a line, that line is a preference, not a requirement."}]
---

## What are customer experience platform requirements?

Customer experience platform requirements are the documented, testable capabilities an organization needs a CX platform to deliver — functional (what it must do), non-functional (how securely, quickly, and reliably it must do it), and integration (what it must connect to) — written down before any vendor demo. A complete requirements set assigns each line an owner, a priority, and an acceptance test that proves the requirement was actually met, so evaluation compares products against your operation rather than against each other's marketing.

A finished requirements document contains five things:

- **A scope statement** — which journeys, channels, regions, and teams are in and out of scope.
- **Functional requirements by team**, phrased as jobs, not features.
- **Non-functional requirements** — security, data residency, retention, identity, performance, accessibility.
- **Integration requirements** — the specific systems that must read from and write to the platform.
- **An acceptance test per requirement** — the demo task or trial task that settles whether it works.

If you have not written this before you build a shortlist, you are not evaluating platforms. You are ranking sales presentations. This guide is for the CX, operations, and IT leads who will own that document — and it assumes you already know [what a customer experience platform is and how the category is changing](/blog/what-is-a-customer-experience-platform-cxp-and-why-ai-is-replacing-the-survey-suite), so it goes a level deeper into how to specify one.

## Why Do Requirements Written After Demos Fail?

Requirements written after demos fail because they inherit the vendor's vocabulary, and vocabulary determines what you are able to ask for. Once a team has watched three polished walkthroughs, its requirements document quietly becomes a transcript of the demo it liked best: the same module names, the same workflow sequence, the same reporting nouns. Every other option now scores badly on a rubric that was reverse-engineered from one product's architecture.

The cost is not theoretical. McKinsey and the University of Oxford's study of large IT projects found that, on average, they [run 45% over budget and 7% over time while delivering 56% less value than predicted](https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value), with 17% going badly enough to threaten the organization itself. The study's most consistent failure cause is not technology — it is unclear objectives and requirements that shifted after selection.

Three symptoms tell you your requirements are demo-shaped:

1. **They name features, not outcomes.** "Sentiment dashboard with drill-down" is a feature. "A CX manager can explain a 6-point CSAT drop in a specific segment within one business day" is a requirement.
2. **Every requirement is a "must have."** When nothing is ranked, the document cannot arbitrate a trade-off, which is the only job it exists to do.
3. **No requirement has an acceptance test.** If you cannot describe the five-minute task that proves it, you will accept a screenshot as proof.

Write the requirements cold — before the first call, using only your own operating reality. Then let vendors argue with the document instead of authoring it.

## How to Gather Requirements From the People Who Will Use the Platform

You gather requirements by interviewing the people who will operate the platform daily about what they did last week, not about what they want. Wish lists produce feature lists; incident recall produces requirements, because a real event carries its own constraints — the system it started in, the data that was missing, the handoff that broke, the deadline that made it urgent.

Interview at least one person from each of these groups, and prefer practitioners over their managers:

| Role | What to ask about | Requirement class it surfaces |
|---|---|---|
| Frontline support or service agent | The last escalation that should have been caught earlier | Functional, real-time alerting |
| Customer success manager | The last renewal that surprised them | Functional, account-level signal |
| CX or voice-of-customer program owner | The last insight leadership ignored | Reporting, evidence quality |
| Product manager or researcher | The last roadmap decision made without customer input | Depth of qualitative data |
| Data or analytics engineer | The last time they hand-joined CX data to revenue data | Integration, export, identity |
| Security, privacy, or legal | The last vendor review that stalled | Non-functional, compliance |
| Procurement or finance | The last renewal negotiated blind | Commercial, usage metering |

Five to eight interviews per role is enough to reach saturation for this kind of work. Nielsen Norman Group's long-standing finding that [five participants surface roughly 85% of usability problems](https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/) holds for requirements discovery too: the sixth conversation in a role mostly repeats the third. Spend the saved time widening coverage across roles rather than deepening it within one.

Ask the same four questions every time, then follow the answers:

1. Walk me through the last time you needed to understand why a customer did something. What did you actually do?
2. Where did you get stuck, and what did you do instead?
3. What did you decide without the evidence you wanted?
4. If that had been easy, what would have changed?

That fourth question is where non-obvious requirements live. It is also the moment most requirements projects run out of budget, because interviewing thirty people across seven roles is expensive in calendar time. This is a legitimate use of conversational AI internally: teams run the same discovery with an AI interviewer that probes each answer and returns a coded transcript set, which is how Perspective AI is often used before a buying decision rather than after one. Whichever method you choose, the output must be quotes and incidents, not a survey summary — and if you are deciding who convenes this at all, settle [who owns customer experience and which reporting line the program sits in](/blog/who-owns-customer-experience-operating-models-reporting-lines-and-first-hires) first.

## Functional Requirements by Team

Functional requirements describe what the platform must let a specific person accomplish, expressed as a job with a measurable completion condition. Write them per team, because a requirement that satisfies a support operations lead frequently fails a researcher, and averaging the two produces a requirement neither can test.

| Team | Job to be done | Requirement statement | Acceptance test |
|---|---|---|---|
| CX / voice of customer | Explain a metric movement, not just display it | The platform must attribute a change in a tracked score to underlying reasons with supporting verbatim evidence | Given last quarter's largest score drop, produce the three driving reasons and five supporting quotes in under 30 minutes |
| Customer success | See account-level risk before renewal | The platform must surface unresolved negative signals by account and push them to the account owner | Trigger a real alert on a seeded at-risk account and confirm delivery to the owner's working queue |
| Support / service ops | Route and resolve without re-asking the customer | The platform must pass full prior context into the service workflow at handoff | Complete one handoff end to end and confirm zero repeated questions to the customer |
| Product and research | Get decision-grade qualitative depth on demand | The platform must run open-ended, follow-up-capable research on a defined segment within five business days | Field one study to 100 customers and return coded themes with quote-level traceability |
| Marketing / lifecycle | Match message to lifecycle phase | The platform must segment by lifecycle stage and expose those segments to campaign tooling | Build one segment and confirm it appears in the downstream system within the agreed sync window |
| Analytics / data | Analyze CX data alongside revenue data | The platform must export raw, row-level records with stable customer identifiers | Export one month of records and join to the warehouse on the first attempt |

Two disciplines make this table useful rather than decorative. First, cap the "must have" count — twenty is a workable ceiling for a mid-market program — and force everything else into "should," "could," or "won't this cycle." Second, tie each requirement to a stated outcome, which is far easier if you have already set [customer experience goals and OKRs with measurable targets](/blog/customer-experience-goals-and-okrs-turning-cx-ambition-into-measurable-targets). A requirement that maps to no objective is a preference.

### The requirement most teams forget: depth of listening

The listening layer is where platforms are thinnest, and it is the requirement most commonly left unwritten. Most suites are excellent at collecting a score and mediocre at collecting a reason — they will capture a 6 out of 10 across a million responses and leave you guessing at why. Because a demo always shows the dashboard rather than the raw input, teams evaluate the display layer and inherit the collection layer by accident.

Specify it explicitly. A serviceable depth requirement reads: *the platform must ask unscripted follow-up questions based on the respondent's previous answer, and at least 60% of completed responses must contain a reason attributable to a specific cause.* That single line separates the tools that measure sentiment from the tools that explain it, and it is the requirement behind both the argument that [an AI-first program cannot start with a web form](/blog/ai-first-cannot-start-with-a-web-form) and the broader shift in [why AI is replacing the survey suite inside the CX platform category](/blog/what-is-a-customer-experience-platform-cxp-and-why-ai-is-replacing-the-survey-suite). Score selection is a related but separate decision — if it is still open, resolve [whether CSAT, NPS, or CES is the right metric for each use case](/blog/csat-vs-nps-vs-ces-which-customer-metric-to-use-when) before writing measurement requirements, and use the [12 capabilities that separate a CX platform from a survey tool](/blog/customer-experience-platform-features-12-capabilities-that-separate-a-cxp-from-a-survey-tool) as a checklist for the rest of the functional set.

Harvard Business Review's analysis of journey-level measurement found that [measuring satisfaction across a whole journey is about 30% more predictive of overall satisfaction than measuring individual interactions](https://hbr.org/2013/09/the-truth-about-customer-experience) — so write requirements at journey scope, and use your inventory of [lifecycle touchpoints and what to ask at each one](/blog/customer-lifecycle-touchpoints-where-to-listen-and-what-to-ask) to define which journeys are in scope.

## Non-Functional Requirements: Security, Residency, Retention, and SSO

Non-functional requirements define the conditions under which functionality is acceptable, and they are the requirements that kill deals late when they are written late. Security review, privacy review, and identity integration routinely add six to twelve weeks to a purchase when they start after a preferred vendor is chosen. Write them at the same time as the functional set, and send them out with the same document.

### Security and access control

State the attestation you require and the control model you expect. Ask for a current SOC 2 Type II report or [ISO/IEC 27001 certification](https://www.iso.org/standard/27001), whose 2022 revision specifies 93 Annex A controls across four themes, and map your own control expectations to a published framework rather than inventing one — the [NIST Cybersecurity Framework 2.0](https://www.nist.gov/cyberframework) organizes them into six functions (Govern, Identify, Protect, Detect, Respond, Recover). At minimum, specify encryption in transit and at rest, role-based access control with named role definitions, audit logging of every export, and a documented breach notification window in hours.

### Data residency

Name the regions where customer data may be stored and processed, and require the vendor to state where each data class physically lives — including backups, logs, and any subprocessors used for AI inference. If you operate in the EU, your requirement should reference the conditions on [international transfers of personal data under Chapter V of the GDPR](https://gdpr-info.eu/art-44-gdpr/); penalties under Article 83 reach €20 million or 4% of total worldwide annual turnover, whichever is higher, which is why this belongs in requirements rather than in contract redlines.

### Retention and deletion

Specify a retention period per data class — raw responses, transcripts, derived analytics, and PII often differ — plus a maximum deletion turnaround in days for individual erasure requests and a defined end-of-contract data return format. "Configurable retention" is not a requirement; "retention configurable between 30 and 1,095 days per data class, with verified deletion within 30 days of request" is.

### Identity, SSO, and provisioning

Require SAML 2.0 or OIDC single sign-on on your standard plan rather than as a paid add-on, SCIM-based automated provisioning and deprovisioning, enforced MFA, and role granularity that matches your org chart. Deprovisioning is the one people skip and then regret: if removing a leaver is manual, every offboarding becomes an access risk.

### AI-specific requirements

Any platform doing AI analysis or AI-led conversations needs its own non-functional block: whether your data can be used to train shared models (the default answer should be no), how PII is detected and redacted, whether outputs are traceable to source responses, and what human review exists before an AI-generated insight reaches an executive. Draft these alongside your [CX AI governance policy decisions](/blog/cx-ai-governance-policy-decisions-2026), and run a [CX AI readiness assessment before you buy anything](/blog/cx-ai-readiness-the-assessment-to-run-before-you-buy-anything) so you are not writing capability requirements your data cannot yet support.

## Integration Requirements

Integration requirements specify which systems must exchange which records with the platform, in which direction, and how often — named by system role, not by product. Four classes cover nearly every CX deployment:

| Integration class | What it does | Requirement to write |
|---|---|---|
| Identity resolution | Ties a response to a known customer and account | The platform must accept and preserve an external customer ID and account ID on every record |
| Inbound triggers | Starts a conversation from an event elsewhere | The platform must initiate outreach from a webhook or event within a stated latency |
| Outbound actions | Turns a signal into work in the system that owns it | The platform must create or update a record in the CRM or service desk on a defined condition |
| Analytical export | Makes CX data joinable to revenue data | The platform must deliver scheduled row-level exports to the warehouse with stable keys |

The failure mode is under-specifying direction. Teams write "integrates with our CRM," discover post-purchase that the integration reads contacts but cannot write outcomes back, and end up with a closed-loop process that is a person copying and pasting. Requirements should always name the direction, the object, the trigger, and the frequency. For the mechanics of each class, see the deeper treatment of [connecting CX data to the rest of the stack](/blog/customer-experience-platform-integrations-connecting-cx-data-to-the-stack) and the [map of the CX technology stack and where each layer sits](/blog/customer-experience-technology-in-2026-mapping-the-cx-stack).

Two adjacent decisions belong in this section. First, ownership boundaries: if it is unclear which system holds the customer record, resolve [whether the CXP, the CRM, or the CDP owns the customer relationship](/blog/cxp-vs-crm-vs-cdp-which-system-owns-the-customer-relationship) before writing sync requirements, or you will specify a two-way sync between two systems that both believe they are the master. Second, data quality: an integration requirement is only as good as the field it moves, so audit your [CX data sources and the gaps that break analysis](/blog/customer-experience-data-sources-quality-and-the-gaps-that-break-analysis) first, and write a requirement for [closing the loop from feedback score to retention workflow](/blog/closing-the-loop-on-customer-feedback-scores-into-retention-workflow) rather than assuming the platform does it.

## The Requirements Document Template

A workable CX platform requirements document is eight sections long and fits in fifteen pages. Longer documents do not get read by vendors or by your own reviewers; shorter ones cannot arbitrate a trade-off.

1. **Context and scope** — business objective, journeys and regions in scope, explicit out-of-scope list, target go-live date.
2. **Current state** — systems in place, what each does today, what is being replaced versus kept.
3. **Functional requirements by team** — the table format above, one row per requirement.
4. **Non-functional requirements** — security, residency, retention, identity, performance, accessibility, AI governance.
5. **Integration requirements** — system role, direction, object, trigger, frequency.
6. **Commercial requirements** — pricing model, usage metering, contract term, exit and data return.
7. **Evaluation method** — scoring weights, who scores, how ties break, the trial protocol.
8. **Acceptance tests** — one concrete task per must-have requirement.

Each requirement record carries the same seven fields:

| Field | Example |
|---|---|
| ID | FR-CS-04 |
| Requirement statement | The platform must alert the account owner when an account logs two negative responses in 30 days |
| Priority | Must |
| Owner | VP Customer Success |
| Rationale | Renewal surprises in the last two quarters both had prior negative signals |
| Acceptance test | Seed two negative responses on a test account; alert reaches the owner's queue within 15 minutes |
| Source | Interviews CS-02, CS-05 |

Weight your scoring before you see any product. A defensible default for a mid-market program is 40% functional fit, 20% depth of listening, 15% integration, 15% security and compliance, and 10% commercial terms — adjust the split to your context, but agree it in writing first, since post-demo reweighting is how a favorite gets rationalized. Timebox the whole exercise to two or three weeks; requirements gathering that runs a quarter is usually a decision-rights problem wearing a research costume.

Then hand the document to the evaluation stage. It feeds directly into a [vendor-neutral scoring framework for evaluating CX platforms](/blog/how-to-evaluate-a-customer-experience-platform-vendor-neutral-scoring-framework), and the same acceptance tests become your trial plan and your definition of success for [what the first 90 days of a CX platform should produce](/blog/customer-experience-platform-time-to-value-what-the-first-90-days-should-produce). If a material share of your must-haves turn out to be unique to your operation, that is also the signal to run a [build versus buy decision framework](/blog/build-vs-buy-a-customer-experience-platform-decision-framework) before shortlisting anything.

## Common Mistakes in CX Platform Requirements Gathering

Five mistakes account for most unusable requirements documents:

- **Copying a generic RFP template.** Boilerplate requirements produce boilerplate answers; every vendor says yes, and the document discriminates nothing. Keep only the lines you can trace to an interview.
- **Specifying tomorrow's maturity.** Requirements written for a program two stages ahead of yours buy capability you cannot staff. Calibrate against a [CX maturity model](/blog/customer-experience-maturity-model-2026) and specify one stage up, not three.
- **Leaving out the people who will run it.** If the CX operations team sees the document first at signature, adoption is already at risk — and the [teams who live in it every day](/roles/cx-teams) are the ones whose requirements are most concrete.
- **Treating reporting as the whole product.** Dashboards demo well and are the easiest layer to replace later. Decide [what belongs on the CX dashboard and what does not](/blog/customer-experience-analytics-metrics-what-belongs-on-the-dashboard) rather than letting the reporting module define the requirement set.
- **Skipping the cost side.** Requirements without a value model cannot justify their own price; pair the document with a [CX AI business case and ROI model](/blog/customer-experience-ai-business-case-roi-model-2026) so trade-offs have a currency.

## Frequently Asked Questions

### How long should customer experience platform requirements gathering take?

Two to three weeks is the right timebox for most mid-market programs. That covers 15 to 25 stakeholder interviews, a draft, one review round, and sign-off. Enterprise programs with multiple regions or regulated data may need four to six weeks, mostly for security and privacy review. If it runs past a quarter, the blocker is usually unclear decision rights rather than missing information.

### What is the difference between functional and non-functional requirements for a CX platform?

Functional requirements describe what the platform must let someone do; non-functional requirements describe the conditions under which doing it is acceptable. "Alert the account owner when an account logs two negative responses" is functional. "Store all EU customer data in the EU, encrypt it at rest, and delete it within 30 days of an erasure request" is non-functional. Both are mandatory, but non-functional requirements are the ones that most often stall a deal when written late.

### How many requirements should a CX platform RFP contain?

Between 40 and 80 total requirements, with no more than 20 marked as must-haves. Below 40 the document is too vague to discriminate between vendors; above roughly 100, reviewers skim and vendors answer generically. The must-have cap matters more than the total, because a document where everything is mandatory cannot resolve a trade-off — which is the only reason to write it.

### Who should own the customer experience platform requirements document?

A single named owner should hold it, usually the CX or customer operations lead, with contributing owners for security, data, and each functional team. Shared ownership produces a document nobody arbitrates. The owner's job is not to write every line but to enforce the priority cap, reject requirements with no traceable source, and hold the scoring weights fixed once demos begin.

### Should requirements specify AI capabilities directly?

Yes, but specify the outcome and the guardrail rather than the technique. "The platform must ask unscripted follow-up questions and return a reason for at least 60% of completed responses" is testable; "must use generative AI" is not. Pair every AI capability requirement with a governance requirement covering training-data use, PII redaction, output traceability, and human review before executive reporting.

### How do you keep requirements vendor-neutral?

Write them before any demo, phrase each one as a job with a measurable completion condition, and ban product-specific nouns from the document. If a requirement uses a term you first heard from a salesperson, rewrite it in your own operational language. A useful test: if only one product on the market could plausibly satisfy a line, that line is a preference, not a requirement.

## From Requirements to Shortlist

Good customer experience platform requirements are boring, specific, and written before anyone sees a demo. They come from incidents rather than wish lists, they are capped and prioritized so they can settle arguments, they cover the non-functional and integration ground that stalls deals late, and every must-have carries an acceptance test that turns a sales claim into a pass or fail. Most importantly, they specify depth of listening explicitly — because the layer that captures the reason behind a score is the layer demos never show and the one teams most often inherit by accident.

Once the document exists, the shortlist becomes mechanical: score, trial against the acceptance tests, and buy the platform that passes. If your requirements include capturing the reason behind every score rather than the score alone, test that requirement directly — [run a live AI interview study](/research/new) with the [Perspective AI interviewer agent](/agents/interviewer) against your own customers, and see how much of your functional set a conversational layer clears before you sit through a single demo.