CDP vs CRM: profile systems and process systems

CDP vs CRM, the split

People ask this as: cdp vs crm difference, customer data platform versus crm

A customer data platform (CDP) assembles one profile per person or account from records and events ingested across many systems — identity resolution, audiences, destination sync. A CRM runs the commercial process on records the business itself works: leads, deals, quotes, approvals, contracts. The split is profile versus process, population versus record. Accordo provides the CRM process layer plus bounded JSON imports, deterministic duplicate matching and human-governed logical identity links. It supplies no streaming ingestion, segmentation or destination activation; a CDP bridge remains application code because no prebuilt connector ships.

Where this stops

Read this before the rest of the page. Every line below is a thing this does not do.

  • This category split does not claim a full CDP. Bounded JSON import and deterministic logical identity exist; streaming ingestion, segmentation and destination activation do not.
  • No bridge ships between the layers. Connecting a CDP to an Accordo application is code the owner writes, not configuration this framework performs (L-05).
  • No CDP vendor is named or evaluated here. The competitor research this site may cite carries no product-level claims in that category.
  • Customer Data Foundation supports bounded JSON imports with preview/apply, per-row receipts and idempotency, deterministic duplicate candidates, and human-governed canonical identity as logical links. It does not provide CSV ingestion, physical merge, complete export/erasure, bulk editing, saved views or global search (L-06).
  • The data-operation jobs remain partial: JSON import has no CSV parser, exact duplicate detection runs on import rather than manual entry, and canonical links preserve both records rather than physically merging them. Export remains unsupported (L-06); mutation integrity does not establish data completeness.

No authentication ships: the framework authenticates nobody. Production Spine v1 (ADR-038) gives the framework verified identity, organizations and memberships, server-authoritative authorization and one tenant per application instance — so tenancy and authorization now exist and are enforced. What does not exist is authentication: no login, password, session or OIDC implementation ships, and a deployment must supply the adapter that verifies the request. Production mode refuses to start without one. In local-development mode an actor header is accepted as an assertion and is not an identity, which is the default developer posture. This is not shared-database multi-tenancy and it is not a readiness claim. Every claim and every limitation is on one page.

Two questions, two systems

A customer data platform answers a population question: which records and events across all our systems belong to the same person, and which profiles match this audience? Its defining machinery is ingestion from many sources, identity resolution into one profile, and segment sync to destinations. A CRM answers a process question: what is allowed to happen to this lead, this quote, this contract now, under which rule, decided by whom, with what evidence left behind?

The two are routinely confused because both hold customer data, but their promises point in opposite directions. A CDP's promise is completeness of view — everything we know about this person, from everywhere. A CRM's promise is integrity of process — every commercial state change went through the rule, and the trail proves it. A system optimised for one is structurally poor at the other, which is why the honest architecture uses both and keeps them separate.

Which one a given job needs

For broad event collection, cross-system identity graphs and audiences, use a CDP. Accordo supplies bounded JSON imports and deterministic logical identity, but no streaming ingestion, audience builder or destination activation (L-06).

If the job is run a commercial process with rules that hold — capture and convert leads through atomic, audited actions (C-06), score under versioned explainable policies (C-07), stop a discount for human approval — it is CRM work, and it is what this framework builds as owned source, with every mutation audited and traced (C-16). If the job description contains both halves, that is not a tie to break: it is two layers, each doing the half it can actually answer for.

Where Accordo sits, and what the bridge costs

Accordo supplies the custom process layer plus bounded customer imports and logical identity. No prebuilt CDP connector ships: mapping a selected profile into an import or explicit CRM command remains application engineering, governed by services and policy (L-05, L-06).

The comparison and architecture pages carry the full versions of this argument: the CDP comparison states operationally what Accordo does not do, and the CDP-plus-CRM concept page describes the two-layer architecture where each side keeps its own question. Both inherit the same posture this page does: no authentication (L-01), and no export or erasure path, so real customer data does not belong in the current runtime (L-09).

The evidence this page rests on

Claims and limitations are printed from site/claims.json word for word. Job statuses come from docs/benchmarks/jobs.json; a job with no page of its own is listed with its status rather than linked.

Claims

  • C-06 A lead is captured, scored, routed, qualified and converted into Company, Contact and Opportunity through explicit actions, each one atomic and audited.

    LimitEnrichment runs against a fixture provider — no real external data source is wired. The Lead model is the starter's, not a built-in core module.

  • C-07 Scoring is explainable and versioned: every score carries the fingerprint of the model version that produced it, so a number from last quarter can still be accounted for.

    LimitDeterministic weighted rules, not a machine-learning model. Nothing trains, fits or backtests.

  • C-16 Every mutation goes through a module service or a named workflow, and leaves an audit event and a step-level trace behind it.

    LimitAudit records what the process did under an asserted actor. It is not a tamper-evident or externally attestable log, and it is not a compliance control.

Limitations

  • L-01 No authentication ships: the framework authenticates nobody. Production Spine v1 (ADR-038) gives the framework verified identity, organizations and memberships, server-authoritative authorization and one tenant per application instance — so tenancy and authorization now exist and are enforced. What does not exist is authentication: no login, password, session or OIDC implementation ships, and a deployment must supply the adapter that verifies the request. Production mode refuses to start without one. In local-development mode an actor header is accepted as an assertion and is not an identity, which is the default developer posture. This is not shared-database multi-tenancy and it is not a readiness claim.
  • L-05 No email, calendar or marketing integrations. An in-memory notification provider contract exists. MK1 marketing records supplied funnel observations and human-reviewed proposals only; it has no sending, publishing or spending path.
  • L-06 Bounded customer imports and logical identity; incomplete data operations. Customer Data Foundation supports bounded JSON imports with preview/apply, per-row receipts and idempotency, deterministic duplicate candidates, and human-governed canonical identity as logical links. It does not provide CSV ingestion, physical merge, complete export/erasure, bulk editing, saved views or global search.
  • L-09 Personal-data readiness requires deployment work beyond the foundation. Customer Data Foundation supplies bounded import and identity governance, not complete personal-data operations. Authentication must be supplied by the deployment, and complete subject export and erasure remain absent; the framework alone does not establish compliance or suitability for real customer data. Lead scoring remains deterministic, versioned and explainable.

Jobs it covers

Documented in

Proved by