Open source. Not deployable to production. This page states what the tests prove and what is missing — nothing else.

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 sits entirely on the CRM-process side: it ingests nothing, resolves no identities and builds no segments, and any bridge between the two layers is application code the owner writes, because no connector ships in either direction.

Where this stops

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

  • This page defines a category split. It does not claim Accordo implements the CDP half in any form: no ingestion, no identity resolution, no segmentation, no destination sync.
  • 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.
  • The CRM half described is a local development framework: no authentication, tenancy or RBAC (L-01), and no path to service a data-subject request (L-09).
  • Import, export, deduplication and merge do not exist on the CRM side either (L-06). The process layer's integrity claims are about mutations, not about data completeness.

No authentication, tenancy or RBAC. The server is local-development-only. An actor header is an assertion, not an identity. Do not expose it to a network. 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

If the job is collect events from product, billing and support, unify identities and build audiences, it is CDP work — and none of it exists in Accordo: importing records, detecting duplicates, creating audiences and syncing them to a provider all read not supported in the job catalogue, and no ingestion pipeline of any kind exists (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 is the process layer only. It ships no connector, importer, scheduler or external adapter in either direction — every provider in this repository is an offline fixture (L-05) — so a CDP-to-CRM bridge is application engineering the owner writes: a selected profile mapped into an explicit CRM command, validated by the service and governed by the same policy as any other caller. The clean hand-off happens after selection, not before identity.

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 or tenancy (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, tenancy or RBAC. The server is local-development-only. An actor header is an assertion, not an identity. Do not expose it to a network.
  • L-05 No email, calendar or marketing integrations. An in-memory notification provider contract exists. No adapter sends anything to anyone.
  • L-06 No import, export, dedupe, merge, bulk edit, saved views or global search. Table stakes in every commercial CRM, and none of them has a milestone yet. This is recorded deliberately rather than left for you to discover.
  • L-09 You cannot put real customer data in this yet. A CRM is a personal-data system by definition, and this one has no authentication, no tenancy, no export and no erasure path — so there is no way to service a data-subject access or deletion request with it. Data governance is designed and unimplemented. The one thing that does hold today: lead scoring is deterministic, versioned and explainable, not a model's judgement about a person.

Jobs it covers

  • JTBD-DO-01 Import records from CSV — not supported
  • JTBD-DO-02 Detect duplicates on import or entry — not supported
  • JTBD-MK-01 Create a dynamic audience from CRM data — not supported
  • JTBD-MK-06 Sync an audience to a provider — not supported
  • JTBD-04 Capture a lead — validated end to end

Documented in

Proved by