What is a JTBD matrix, and how does it evaluate a CRM?

JTBD matrix, defined

People ask this as: what is a jobs to be done matrix for evaluating crm software

A JTBD (jobs-to-be-done) matrix is an evaluation instrument that lists the jobs a buyer hires software to do and records, per job, whether the system can complete it and on what evidence. It replaces the feature checklist's question — does it have X? — with a harder one: can it finish Y, and what proves that? Accordo publishes its own matrix of the catalogued CRM jobs, each with a status of validated end to end, partially supported or not supported, kept in step with the source by a test — and a status in a matrix is a self-assessment with evidence attached, not a benchmark result: the build benchmark has not been run.

Where this stops

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

  • A JTBD matrix is an evaluation instrument, and this one is a self-assessment. No row measures Accordo against another product, and no row implies a ranking.
  • Validated end to end means the repository's own suite completes the job against its own fixtures — every provider offline, everything local (L-01, L-05).
  • A status is not a promise. The matrix records the current checkout, changes only when the code does, and is not a roadmap.
  • The comparative instrument is the build benchmark, which is published as a protocol and has not been run (L-03).
  • All marketing jobs remain not supported (L-11). Import, duplicate detection and merge remain partially supported only through bounded JSON input, exact matching on import and logical canonical links; export remains not supported, and no partial row promises CSV parsing or physical record merge (L-06).

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.

The definition, against the feature checklist

A jobs-to-be-done matrix lists the outcomes a buyer actually hires software for — capture a lead, request commercial approval on a deal, merge two duplicate contacts — and records for each one whether the system completes the job, with the evidence named. The unit is the job, not the feature, because features overlap jobs badly: a product can have a contacts feature and still be unable to complete merge two duplicate contacts.

The matrix's discipline is in its honest middle values. A binary checklist invites yes; a matrix with validated end to end, partially supported and not supported forces the author to say which parts of a job work, and a row that reads not supported is information rather than embarrassment. For CRM evaluation, the not-supported rows are usually the most useful ones on the page.

Accordo's matrix, as it exists in this repository

The matrix lives at docs/benchmarks/CRM_JTBD_MATRIX.md and covers the catalogued CRM jobs across core CRM, marketing, analytics, data operations, governance, commercial operations, contract and subscription, delivery and service, and packaging. As of this checkout, 23 read validated end to end, a band of partials and most honestly marked not supported — a distribution the site quotes rather than hides, because it is the honest shape of a young framework.

The statuses are load-bearing, not decorative. A machine-readable index is generated from the matrix, and a test holds the two in step and asserts that every test file a row names as evidence still exists on disk — so a status is checkable rather than asserted (C-20 describes the gate that runs it all on every push). Positioning tracks the matrix too: this site holds back service-desk language because the relevant rows read partially supported, and a page may not describe a support product while they do.

What a matrix row is not

A status is a self-assessment with evidence, not a comparative measurement. Validated end to end means this repository's own suite completes the job against this repository's own fixtures — it does not mean the job was measured against another product, and no row implies a ranking. The one instrument that would produce a comparative number, the build benchmark, is published as a protocol and has not been run (L-03).

A matrix also preserves each partial job's remaining gap. The marketing rows await coverage promotion; the optional MK1 package provides supplied funnel observations and local proposal approval, with no campaign execution (L-11). Import, duplicate detection and merge read partially supported: the implemented slices are bounded JSON input, deterministic matching on import, and human-governed logical canonical links. CSV parsing, duplicate detection on manual entry and physical merge remain absent; export is not supported (L-06). The matrix records evidenced coverage of the checkout, not a promise to complete the roadmap.

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-20 The verification gate runs on every push — source checks and then the whole test suite — covering happy paths and the policy boundaries that matter: hostile input, transaction rollback, idempotency, concurrency and immutability among them.

    LimitA test count measures effort, not correctness — read the adversarial-review categories in docs/QUALITY_GATES.md to see what is actually attacked. Real-browser tests are run manually and are not in CI.

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-03 The build benchmark has not been run. The protocol is designed and published; no Successful Agent Build Rate exists yet. Any number you see quoted for this project is not ours.
  • 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-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