What Should Be Included In A CDP Implementation Statement Of Work?

A CDP implementation statement of work, or SOW, is the contract document that defines the scope, deliverables, timelines, acceptance criteria, payment terms, client responsibilities, assumptions, change management process, and post launch services for a customer data platform implementation.

A CDP implementation SOW is not the same as a standard IT implementation SOW.

A general SOW template may cover scope, deliverables, timelines, payment terms, acceptance criteria, change orders, and assumptions. Those sections are necessary, but they are not specific enough for a CDP implementation. CDP programs create disputes in places where general templates are usually silent.

• The first dispute is scope expansion. One party believes a source system, activation destination, or remediation task was included. The other party believes it was not.
• The second dispute is data quality. The implementation partner discovers during the data audit that source data is incomplete, inconsistent, duplicated, or missing required identifiers. The partner says remediation is outside the SOW. The client says the CDP cannot be implemented without it.
• The third dispute is go live acceptance. The client says the CDP does not work as expected. The partner says the system meets the specification that was agreed.

A strong CDP implementation SOW prevents those disputes before work begins. It does that by naming the specific source systems in scope, defining the initial use cases, listing deliverables by phase, setting measurable acceptance criteria, documenting client responsibilities, adding data quality assumption language, defining the change order process, tying payment to deliverable milestones, and specifying what happens after launch.

The goal is not to make the contract longer. The goal is to make the contract clear enough that both parties know what success means.

Why A CDP Implementation SOW Requires Different Language From A Standard IT SOW

A CDP SOW needs different language because a CDP implementation is built into a customer data environment that is often not fully understood when the agreement is signed.

That does not mean the project is impossible to scope. It means the SOW has to acknowledge where uncertainty exists and define what happens when that uncertainty becomes visible.

The Data Discovery Problem

Most standard IT implementation SOWs assume the current environment is understood before the contract is finalized.

A CDP implementation often does not work that way. The SOW may be signed after use case workshops, stakeholder interviews, and a high level data environment review. The true condition of the source data is usually discovered during the Phase 2 data audit after the engagement has started.

That audit may reveal that key fields are missing, customer IDs are inconsistent, consent values are not accessible, duplicate records are widespread, or source systems do not share a reliable identifier.

The SOW needs a data quality assumption provision. That provision should specify the data completeness threshold the project estimate assumes, what happens when the threshold is not met, and who is responsible for remediation.

Without that language, data quality becomes a contract dispute instead of a managed project decision.

The Acceptance Criteria Specificity Problem

A general IT SOW may say that the system must meet documented functional requirements.

A CDP SOW needs more specific acceptance criteria because many CDP components are not binary. Identity resolution does not simply work or fail. It achieves a match rate. Data integration does not simply work or fail. It reaches a record count and field completeness threshold. A Profile API does not simply work or fail. It responds within a p99 latency target at a defined load.

Weak language says, “Identity resolution is working.”

Strong language says, “Identity resolution achieves an 85 percent or higher match rate on the validation dataset across the three priority source systems, with a false positive rate below 2 percent, measured 30 days after initial ingestion.”

That level of specificity gives both parties a measurable delivery standard.

The Parallel Run Problem

Enterprise CDP implementations often involve a transition from an existing platform, warehouse based segmentation process, or manual marketing operations workflow.

For a period of time, the legacy process and the new CDP may run in parallel while the team compares segment counts, activation outputs, identity matches, and business results.

The SOW must define the parallel run period and exit criteria. Otherwise, the old platform may remain in place indefinitely because no one agreed on when the new CDP is trusted enough to take over.

A strong parallel run provision defines when the period starts, what outputs must be validated, what variance is acceptable, how long the run lasts, and who approves decommissioning the legacy process.

The Ten Required Sections Of A CDP Implementation SOW

A complete CDP implementation SOW should include ten sections. Each section should contain CDP specific detail, not just general contract language.

Section 1: Scope Definition

The scope definition section should name exactly what is included.

For a CDP implementation, scope should be itemized by phase, source system, integration, activation destination, and use case. It should not say “all necessary integrations.” That phrase creates ambiguity because “necessary” means different things to different teams.

A strong scope section should name:

• Source systems in scope, such as CRM, ecommerce, POS, loyalty, mobile app, web events, support platform, and consent system
• Activation destinations in scope, such as email platform, paid media destinations, mobile messaging, CRM, call center tools, and personalization systems
• CDP capabilities in scope, such as identity resolution, segmentation, activation, consent enforcement, Profile API, and reporting
• Out of scope items, such as source system data remediation, custom connectors for systems not listed, new use cases not named in the agreement, and post launch maintenance unless covered by a separate retainer

The most important rule is that anything not named in scope should be treated as out of scope until added through a change order.

Section 2: Use Case Definition And Priority

The SOW should define the first use cases the implementation is designed to deliver.

A vague use case like “personalization” is not enough. The SOW should name the business outcome, success metric, required data, activation channel, and use case owner.

A strong use case definition might say: “Launch a cart abandonment journey for customers who add an item to cart but do not purchase within two hours, using web behavior, ecommerce order status, consent status, and email platform activation, with a target conversion lift measured against the pre implementation baseline.”

The SOW should also include a Phase 2 backlog. This is the list of use cases that are valuable but not included in the first engagement. The backlog reduces scope pressure because stakeholders can see where future requests will go without forcing them into the current SOW.

Section 3: Deliverables By Phase

The SOW should list named deliverables for each implementation phase.

Generic language like “implementation documentation” is too weak. Every deliverable should have a name, owner, due milestone, review period, and acceptance mechanism.

Examples include:

• Use case briefs
• Data source inventory
• Data readiness report
• Identity strategy document
• Architecture decision record
• Integration test report
• Segment validation report
• Go or no go recommendation memo
• Signed go live checklist
• Soft launch report
• Operational runbook
• Data governance operating model
• Adoption metrics dashboard

The SOW should also include a deemed acceptance clause. If the client does not provide documented feedback within the review window, the deliverable is deemed accepted. This prevents deliverables from sitting in an ambiguous status because no one formally approved or rejected them.

Section 4: Acceptance Criteria

Acceptance criteria should be objective, measurable, and tied to each major milestone.

For CDP implementations, acceptance criteria should include thresholds for data integration, identity resolution, segmentation, Profile API performance, activation delivery, consent enforcement, and go live readiness.

A strong acceptance criteria section might include:

• Source system record counts must reconcile within a defined tolerance.
• Key fields must meet a defined completeness threshold.
• Identity resolution must meet the agreed match rate and false positive threshold.
• Segment counts must reconcile against expected source system logic within a defined variance.
• Profile API p99 latency must remain below the agreed threshold at the agreed concurrent request volume.
• Activation destinations must receive test audiences successfully.
• Consent enforcement must suppress ineligible records.
• Go live cannot proceed until the checklist is signed item by item.

Avoid subjective language like “high quality,” “client satisfaction,” or “working as expected.” Those phrases create opinion based acceptance instead of evidence based acceptance.

Section 5: Timeline And Milestones

The timeline should be tied to deliverable completion, not only calendar dates.

A fixed date timeline may look clean in the contract, but CDP implementations depend on upstream approvals, access, data audits, identity strategy, integration testing, privacy review, and stakeholder sign off. If one phase slips, every downstream date becomes unrealistic.

A stronger timeline uses milestone based language.

For example: “Phase 3 begins upon client sign off of the Phase 2 data readiness report and identity strategy document, targeted for Week 5.”

The SOW should also include timeline float language. If Phase 2 sign off happens later than the target date, Phase 3 and all subsequent milestones shift proportionally unless both parties sign a change order to compress the timeline.

This prevents teams from advancing into integration before the required gate criteria are complete.

Section 6: Client Responsibilities

Client responsibilities should be explicit, named, dated, and tied to consequences.

Weak language says, “Client will cooperate as necessary.”

Strong language names exactly what the client must provide and when. That may include:

• System access for every named source system
• Named technical contacts for CRM, ecommerce, POS, loyalty, app, web, and consent systems
• Privacy and legal review before activation
• UAT participants for segment validation
• Written approval of the identity strategy document
• Data remediation work identified during the audit
• Timely review of deliverables within the agreed review window

The SOW should also define what happens if the client does not meet a responsibility. If system access is delayed, the timeline should extend. If remediation is not completed, the source system may move to a later phase. If approvals are late, downstream milestones should float.

Client responsibilities without consequence provisions are project wishes, not contract obligations.

Section 7: Assumptions And Constraints

Assumptions are where many CDP implementation disputes begin.

A vague assumption like “client data is in good condition” is not useful. The SOW should define what “good condition” means.

A stronger data quality assumption says: “This engagement assumes that priority source systems achieve 80 percent or above completeness on the key fields required for the three initial use cases. If the Phase 2 data audit reveals completeness below 80 percent on any key field for any priority source system, the parties will agree in writing within 10 business days on whether the partner will perform additional remediation under a change order, the client will perform remediation before Phase 3 begins, or the affected source system will move to a subsequent engagement.”

Other assumptions should address:

• Identifier consistency across priority sources
• Consent data availability
• API or export access
• Client engineering capacity
• Availability of subject matter experts
• Timeliness of legal and privacy approvals
• Platform licensing and environment readiness

Every assumption should be specific enough for the delivery team to verify.

Section 8: Change Management Process

A CDP implementation SOW must define how scope changes are handled.

The change management section should explain what counts as a scope change, how requests are submitted, how they are evaluated, who approves them, and when work can begin.

A strong process includes:

• Written change request from either party
• Description of the requested work
• Impact assessment for cost, timeline, risk, and dependencies
• Signed change order before out of scope work begins
• De minimis threshold for small changes that can be approved by the project manager
• Escalation path for changes above the threshold

The key rule is that verbal approvals should not authorize out of scope work. Without signed change orders, every small request can become a billing dispute later.

Section 9: Payment Terms And Milestone Based Billing

Payment should be tied to deliverable milestones, not only calendar months.

A monthly payment schedule may be simple, but it does not always reflect project progress. A milestone based structure ties billing to accepted deliverables.

For example:

• Payment after signed use case briefs
• Payment after signed data audit and identity strategy
• Payment after signed integration test report
• Payment after signed go or no go memo
• Payment after soft launch completion
• Payment after delivery of post launch governance artifacts

The SOW may also include a holdback provision. A holdback withholds a percentage of the total fee until the soft launch report is signed. This gives the client leverage during the most important validation point and gives the partner a financial incentive to complete the soft launch successfully.

Section 10: Post Launch Services And Engagement Closure

The SOW should define what happens after go live.

A CDP implementation does not become successful the moment the first use case launches. The internal team still needs operational handoff, governance, training, support, and adoption tracking.

The post launch section should specify:

• Support period duration
• Named support contacts
• Response time expectations
• Warranty period for implementation defects
• Knowledge transfer deliverables
• Operational runbook
• Data pipeline runbook
• Data governance operating model
• Champion user training
• Adoption metrics dashboard
• Engagement closure condition

• Process for Phase 2 expansion

The engagement should not simply “end at go live.” The SOW should name the signed document or milestone that closes the engagement and starts the warranty period.

CDP Specific SOW Provisions Most Teams Miss

Teams using a general IT SOW template often miss the same CDP specific provisions.

Data Quality Assumption Language

The SOW should specify the data quality threshold assumed in the project estimate and what happens if the audit reveals that source data falls below that threshold.

Without this provision, both parties may disagree about whether remediation is included.

Identity Resolution Acceptance Criteria

The SOW should define the validation dataset, match rate threshold, false positive rate threshold, and measurement timing.

Without this provision, identity resolution acceptance becomes a subjective decision.

Source System Integration Completeness

The SOW should define expected record count variance, field completeness threshold, and required source systems.

Without this provision, integration can be called complete even when the data is too incomplete to support the use case.

Profile API Latency Threshold

For real time use cases, the SOW should define the Profile API p99 latency threshold at a specified load.

Without this provision, the system may technically work but fail the customer experience latency requirement.

Parallel Run Exit Criteria

The SOW should define when the legacy CDP or segmentation process can be retired.

Without this provision, the parallel run can continue indefinitely.

Phase 2 Backlog

The SOW should list out of scope use cases and integrations in a backlog.

Without this provision, stakeholders may treat every new use case as a missed requirement instead of a future phase.

Client Responsibility Consequences

The SOW should define what happens when the client does not provide access, approvals, contacts, or remediation on time.

Without this provision, client side delays often become partner execution disputes.

Post Launch Knowledge Transfer Deliverables

The SOW should name the documents and training artifacts the partner must provide before the engagement closes.

Without this provision, the client inherits a CDP without the operating knowledge required to sustain it.

MSA Vs SOW For CDP Implementations

Legal teams often ask which terms belong in the master services agreement and which belong in the statement of work.

The MSA governs the ongoing relationship between the client and implementation partner. The SOW governs the specific engagement.

What Belongs In The MSA

The MSA should include the relationship level legal terms, including:

• Liability limits
• Indemnification
• Intellectual property ownership
• Confidentiality
• Payment mechanics
• Dispute resolution
• Data processing obligations
• Subprocessor rules
• Security obligations
• Data retention and deletion after engagement closure

For CDP implementations, the data processing agreement is especially important because the partner may access customer data during integration, testing, validation, and support.

What Belongs In The SOW

The SOW should include project specific content.

That includes the scope, named source systems, activation destinations, deliverables, timeline, assumptions, acceptance criteria, payment milestones, client responsibilities, change order process, post launch services, and engagement closure conditions.

The SOW should reference the MSA where needed, but it should not try to recreate the full legal relationship. Its job is to make the CDP implementation specific, measurable, and enforceable.

How Stable Kernel Structures CDP Implementation SOWs

Stable Kernel structures CDP implementation SOWs around clear scope, measurable acceptance criteria, explicit client responsibilities, and post launch operating readiness.

The goal is to prevent ambiguity before it becomes project conflict.

SOWs Built Around CDP Specific Risk

Stable Kernel SOWs include the CDP specific provisions that general IT templates often miss: data quality assumption language, identity resolution acceptance criteria, parallel run exit criteria, source system integration completeness, Profile API latency thresholds, phase gate deliverables, and post launch knowledge transfer requirements.

These provisions are not included only to protect Stable Kernel. They protect both parties by defining the project reality before the project reaches a dispute point.

Deliverables And Gates Before Integration Begins

Stable Kernel ties implementation phases to named deliverables and sign off criteria.

Integration does not begin just because the calendar says it is time. It begins when the required data audit, identity strategy, scope definition, and use case briefs are complete enough to proceed.

This keeps the project from advancing into technical build before the requirements and responsibilities are clear.

Complimentary SOW Review

Stable Kernel also helps enterprise teams review CDP implementation SOWs produced by other partners.

A review can identify missing provisions, vague language, weak acceptance criteria, unclear client responsibilities, missing data quality assumptions, absent parallel run language, and post launch gaps before the SOW is signed.

Stable Kernel helps enterprise CDP programs structure implementation engagements that are clear on scope, specific on acceptance criteria, and explicit on responsibilities before the project begins, not after the dispute arises.

Reflection Questions For Executives

1. Does the SOW name every source system and activation destination included in scope?
2. Does the SOW define the three initial use cases with business outcomes, success metrics, required data, activation channels, and owners?
3. Are deliverables named by phase with owners, review periods, and acceptance mechanisms?
4. Does identity resolution have a measurable match rate threshold and false positive threshold?
5. Does the SOW include data quality assumption language with a threshold and consequence process?
6. Are client responsibilities named, dated, and tied to consequences if they are not met?
7. Does the SOW define a signed change order process before out of scope work begins?
8. Does the SOW specify post launch support, knowledge transfer deliverables, and engagement closure conditions?

FAQ

What Should Be Included In A CDP Implementation Statement Of Work?

A CDP implementation statement of work should include scope definition, use case definition, deliverables by phase, acceptance criteria, timeline and milestones, client responsibilities, assumptions and constraints, change management process, payment terms, and post launch services. Each section should include CDP specific detail, such as named source systems, activation destinations, data quality assumptions, identity resolution thresholds, Profile API latency requirements, parallel run exit criteria, and post launch knowledge transfer deliverables.

How Is A CDP Implementation SOW Different From A Standard IT SOW?

A CDP implementation SOW is different because it must account for data quality uncertainty, identity resolution thresholds, and parallel run requirements. A standard IT SOW may define general scope and deliverables, but a CDP SOW must specify what happens if source data quality is lower than assumed, what match rate is acceptable for identity resolution, and when the legacy platform can be decommissioned after the new CDP is validated.

What Data Quality Provisions Should A CDP SOW Include?

A CDP SOW should include a data quality assumption with a specific completeness threshold for key fields, the method for measuring that threshold during the data audit, and the consequence if the threshold is not met. The SOW should state whether remediation will be handled by the partner through a change order, by the client before integration begins, or by moving the affected source system into a later phase.

What Acceptance Criteria Should A CDP SOW Specify?

A CDP SOW should specify acceptance criteria for source system integration completeness, identity resolution match rate, false positive rate, segment validation, Profile API latency, activation delivery, consent enforcement, and go live readiness. These criteria should be measurable rather than subjective. Avoid language such as “client satisfaction” or “working as expected” without objective thresholds.

How Should Client Responsibilities Be Documented In A CDP SOW?

Client responsibilities should be named, dated, and tied to consequences. The SOW should specify what the client must provide, such as system access, technical contacts, data remediation, legal review, privacy review, UAT resources, and deliverable approvals. It should also define what happens if those responsibilities are not completed on time, such as timeline extension or change order.

What Should A CDP SOW Say About Scope Changes?

A CDP SOW should define a formal change management process. It should state that any work not explicitly included in scope requires a written change request, impact assessment, and signed change order before work begins. It should also define who can approve small changes and when executive approval is required.

What Is Parallel Run Language In A CDP SOW?

Parallel run language defines the period when the new CDP and legacy platform or process operate at the same time. It should specify when the parallel run begins, what outputs will be compared, what variance is acceptable, how long the period lasts, and who approves decommissioning the legacy platform. Without this language, the parallel run can extend indefinitely.

Should A CDP SOW Include A Holdback Provision?

Yes, many CDP implementation SOWs should include a holdback provision. A holdback withholds a portion of the engagement fee until the soft launch report is signed and the first use case is confirmed to be working within the agreed data accuracy, activation delivery, and performance parameters. This ties final payment to verified implementation quality.

Can Stable Kernel Review Or Produce A CDP Implementation SOW?

Yes. Stable Kernel can review a CDP implementation SOW against the ten section standard and identify missing provisions, vague language, weak acceptance criteria, unclear client responsibilities, and CDP specific gaps. Stable Kernel can also produce a CDP implementation SOW as part of a Phase 0 architecture and scope engagement before implementation work begins.