A customer hub starts with CRM code you own

One commercial record chain, from lead to service

People ask this as: customer hub with a single customer view across crm, marketing, delivery and billing

Accordo supports the audited lead-to-service record chain, plus bounded customer imports, deterministic matching, logical canonical identity and a consolidated profile over composed packages. Marketing, billing and a complete cross-channel timeline remain outside the implemented foundation.

Where this stops

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

  • This page describes a buildable CRM foundation, not a ready-made Customer Hub product. The commercial chain is merged in slices, and each slice keeps the boundary stated below.
  • 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).
  • This is not a customer data platform, and nothing here softens that refusal. The comparison page states it in full and this page inherits it; no product in that category is named, because the competitor research this site may cite carries none.
  • Marketing and billing runtimes remain absent. A consolidated customer profile exists for composed packages, but a complete cross-channel timeline does not.
  • The framework enforces authorization and one tenant per application instance; the deployment supplies authentication. Self-hosted SQLite and dedicated-database PostgreSQL compositions exist, but are not a general production-readiness claim (L-01, L-02). 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 (L-09).
  • Nothing here is measured against another product, and no page on this site ranks this against a named vendor. The build benchmark has not been run.

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.

Working record chainOne customer, six connected operating recordsStored identifiers preserve the commercial chain. Customer Data Foundation adds logical identity links without rewriting those source records.
  1. Validated path Lead intelligence Capture, qualify, enrich, score and route under versioned policy.
  2. Validated path Company · Contact · Opportunity Convert atomically, then advance the deal through server-owned pipeline actions.
  3. Validated path Quote · Approval · Order Price on the server, gate discounts and freeze immutable commercial evidence.
  4. Partial domain Contract · Subscription Activate operational terms and lines from the signed Order snapshot.
  5. Partial domain Delivery Handover work, record execution and economics, govern change and acceptance.
  6. Partial domain Service Activate entitlements, record support cases and retain elapsed-time SLA evidence.

Start from a CRM foundation that already runs

A reader who typed customer hub or single customer view is asking for something wider than CRM, and the honest first answer is the narrower word. CRM is the part of this framework that is merged and proved: a lead is captured, scored, routed, qualified and converted into a Company, a Contact and an Opportunity through explicit actions, each one atomic and audited (C-06); that opportunity moves through code-first pipeline stages under a server-authoritative action (C-05); a quote is priced on the server from a catalog, and a discount that crosses the policy threshold stops and waits for a named human, with an agent actor refused a 403 (C-08, C-21). Everything wider on this page is measured against that, and none of it replaces it.

The job catalogue is the arbiter for every status below, not this page. Of the seventeen rows in the core CRM section of docs/benchmarks/jobs.json, eight read validated end to end, four partially supported and five not supported. That file is generated from docs/benchmarks/CRM_JTBD_MATRIX.md and held in step with it by tests/jobs-json.test.js, which also asserts that every test named as evidence still exists on disk — so a status quoted here is checkable rather than asserted.

One commercial chain, not an identity graph

Audited CRUD and service APIs remain public write paths alongside named actions. The commercial record chain retains explicit identifiers: contacts and opportunities link to company, contracts to signed orders and quotes, delivery and service to contracts, and support cases to their coverage. The consolidated customer profile reads those composed packages under one logical customer identity.

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 consolidated profile reads composed packages and explicitly reports unavailable sections. It is not a complete cross-channel timeline or a full CDP.

The customer foundation does not establish the full CDP category. It supports bounded imports and deterministic logical identity, but no streaming ingestion, audience segmentation or destination activation (L-06).

Customer Data Foundation exposes a read-only consolidated profile and an Admin customer-data surface. A package that is not composed is reported unavailable; the profile is not a complete cross-channel activity timeline.

Each operating domain has a precise boundary

CRM and lead intelligence — merged, several jobs validated end to end. Capturing, qualifying and converting a lead (JTBD-04, JTBD-05, JTBD-05b) and moving a deal through pipeline stages (JTBD-03) read validated end to end, as do enrichment with snapshot and provenance, explainable scoring, automatic routing under a published policy, and policy versioning (JTBD-LI-01, JTBD-LI-02, JTBD-LI-04, JTBD-LI-07). Four further lead rows read partially supported, and manual reassignment with permission and reason (JTBD-LI-06) reads not supported. Where it stops: the enrichment provider is a checked-in fixture with no external data source wired, routing targets are application identifiers rather than authenticated users, and the Lead model belongs to the starter rather than to the framework core.

Quote, discount approval, signature and order — merged, several jobs validated end to end. Creating a quote from a price book (JTBD-CO-01), requesting a discount under a deterministic policy (JTBD-CO-03) and creating an immutable signed Order snapshot (JTBD-CO-07) read validated end to end; synchronising an external catalog, obtaining the required commercial approval and the two signature rows (JTBD-CO-02, JTBD-CO-04, JTBD-CO-05, JTBD-CO-06) read partially supported. Where it stops: every catalog and signature provider is an offline fixture, no envelope has ever been sent to a real signer, the signed document is canonical JSON rather than a PDF, and the phrase quote-to-cash stops at the quote.

Contract activation and subscriptions retain explicit signed or operational term provenance. Terms frozen into the signed quote document retain signed-order provenance; legacy orders without signed terms can use explicitly labelled post-signature operational metadata. Operational dates are never promoted to signed terms. Governed renewal and amendment execution creates a successor agreement from its own signed Order, with immutable lineage and a derived line delta. Historical contracts and subscriptions are not edited. There is no automatic renewal, cancellation execution, billing or customer notification. JTBD-CS-04, CS-09 and CS-10 remain partial; in-place seat changes, price-uplift execution and full renewal scheduling do not inherit support from successor execution.

Delivery and service — merged, partial. Handing a won deal to delivery, tracking hours and costs, and managing a change request with impact and approval (JTBD-DS-01, JTBD-DS-06, JTBD-DS-08) read validated end to end; seven further rows read partially supported, including activating a service contract with entitlements and SLA (JTBD-DS-11) and managing support cases and escalation (JTBD-DS-12). Restricting partner access to assigned work (JTBD-DS-04) and activating billing on accepted milestones (JTBD-DS-10) read not supported. Where it stops: nothing schedules, staffs or computes percent complete; customer acceptance is testimony a user actor recorded rather than an authenticated customer's signature; the SLA clock is elapsed wall-clock minutes with no business-hours calendar and no pause; and nothing escalates, routes or notifies by itself.

Marketing, billing and ERP remain separate

The optional MK1 marketing package records supplied funnel observations, derives a drop insight and prepares a complete-or-refused proposal for human review. Approval creates local immutable evidence. Audiences, consent enforcement, sending, publishing, spending, journeys, experiments and attribution remain outside this package (L-11). The remaining Marketing strategy describes target work, and JTBD statuses require separate reviewed evidence.

Billing does not exist in any form. There is no invoice, no payment, no dunning, no tax, no usage rating, no proration and no revenue recognition anywhere in the repository, and MRR, ARR and TCV are not derived from contract data. Activating billing on accepted milestones (JTBD-DS-10) and calculating MRR, ARR and TCV from real contract data (JTBD-CS-05) both read not supported. The subscription module's own description states what it is instead: a commercial activation record, not a billing engine, with no invoice schedule, usage rating, proration, payment, renewal or cancellation state. docs/strategy/EXECUTION_ROADMAP.md lists invoicing, billing, payment, usage rating, proration, tax and FX as explicitly deferred (L-10).

ERP is not a goal either, and docs/strategy/RECOMMENDATION_MAP.md says to say so plainly rather than leave it open. The closest thing to a money figure that does exist is deliberately not one: delivery records append-only time and expense evidence costed by a versioned policy and returns a delivery contribution estimate grouped by currency, which is not a margin, not revenue and not an accounting figure — and a project carrying any recurring obligation returns no estimate at all, with a named reason (C-12).

The boundary every build still inherits

The framework enforces authorization and one tenant per application instance; the deployment supplies authentication. Self-hosted SQLite and dedicated-database PostgreSQL compositions exist, but are not a general production-readiness claim (L-01, L-02). Durable jobs, a transactional outbox and scheduled asks exist for self-hosted applications that explicitly start a worker. Nothing autostarts; a timer opens an ask, never makes a decision, and no managed worker service or recurrence is included (L-04). 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 (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-05 Opportunities move through code-first pipeline stages under a server-authoritative action — the client asks, the server decides.

    LimitPipelines are proven on the built-in Opportunity module. Configurable pipelines for generated custom objects are not claimed.

  • C-08 Quotes price on the server from a catalog — one-time and recurring, flat, per-unit, volume and graduated tiers — and freeze into an immutable version when a discount goes for approval.

    LimitCatalog sync runs against a fixture provider; no real external catalog (Stripe, Zuora, ERP) is connected. Money is integer cents with no FX — currencies are never summed.

  • C-21 The same refusal holds where the money is: an agent actor asking to approve a discounted quote is refused with a 403, and only a human user actor can decide.

    LimitThe assertion lives inside a composite end-to-end test rather than a test named for it, so the citation is a file and a line rather than a test name. Extracting it into a named test is tracked in docs/strategy/GO_TO_MARKET.md; until then, cite the line.

  • C-09 A signature envelope produces verified events and a hashed signed artifact, and exactly one immutable Order is built from the approved quote version.

    LimitA fixture signature provider with a test-only webhook key. No DocuSign, Adobe Sign or Dropbox Sign adapter exists, and the artifact hash is provider-reported rather than independently recomputed.

  • C-10 A signed Order activates into a Commercial Contract, an immutable contract version, a Subscription and explicitly pending delivery and service obligations — every component classified, never guessed.

    LimitTerms frozen into the signed quote document retain signed-order provenance; legacy orders without signed terms can use explicitly labelled post-signature operational metadata. Operational dates are never promoted to signed terms. Governed renewal and amendment execution creates a successor agreement from its own signed Order, with immutable lineage and a derived line delta. Historical contracts and subscriptions are not edited. There is no automatic renewal, cancellation execution, billing or customer notification.

  • C-11 Pending obligations hand over into a Delivery Project with work packages, milestones and an optional partner — atomically, idempotently, and across a package boundary the kernel never learns about.

    LimitIt hands work over and runs it through human-driven transitions. Nothing schedules, staffs, computes percent complete or bills. Deliverables and recorded customer acceptance exist as of M14b2, and acceptance there is evidence a user actor recorded — never an authenticated customer, a legal signature or authorization to bill.

  • C-12 Delivery records what it consumed: append-only time and expense evidence, costed server-side by a versioned fingerprinted policy, with a reproducible contribution estimate grouped by currency.

    LimitDeliberately not a margin: no revenue recognition, no cost of goods sold, no ARR/MRR/TCV, no annualization, no FX. A project carrying a recurring obligation returns no estimate at all and says why.

  • 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-04 Timers exist; a service that runs them for you does not. Durable jobs, a transactional outbox and scheduled asks exist for self-hosted applications that explicitly start a worker. Nothing autostarts; a timer opens an ask, never makes a decision, and no managed worker service or recurrence is included.
  • 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-08 Ownership means vendored source: there is no framework dependency to bump. The published create-accordo@0.1.0 scaffolds vendored source; it is the August 19 snapshot, not the current repository feature set. Use a current source checkout for the capabilities described here; upgrades require merging source (L-08). The framework is copied into the project, not installed as a framework library dependency. The accordo npm name is an empty reservation; the @accordo scope is claimed and deliberately empty.
  • 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.
  • L-10 Nothing bills. No invoice, payment, tax, usage rating, proration or revenue recognition exists, and MRR, ARR and TCV are not derived from contract data.
  • L-11 Marketing proposals are local evidence; campaign execution is absent. The optional MK1 package records supplied funnel counts, derives a drop insight and prepares a complete-or-refused proposal for human approval. It performs no audience execution, consent enforcement, sending, publishing, spending, scheduling or attribution. JTBD row promotion remains a separate review.

Jobs it covers

Documented in

Proved by