Martech maturity model for small teams

Last updated: 13 October 2026.

Assess one business process before scoring the company

Start with something specific: getting a qualified enquiry to the right person, helping a new account reach activation, or keeping a cancelled customer out of an upgrade campaign.

Write down the customer, trigger, required outcome, systems involved and person accountable. A company can handle inbound leads well while running renewal reminders from an unreliable spreadsheet. Calling the whole company “advanced” conceals that difference.

If the process itself is unclear, use the customer journey identification guide first. If the systems and handoffs are unclear, make a martech stack map. Maturity assessment comes after you can explain what the operation is supposed to do.

The five levels and six assessment areas below are our practical framework. They are not an industry certification, a validated company benchmark or a formula that predicts revenue. Use them to agree on evidence and priorities.

Five levels, with a reason to move between them

The levels describe increasing control over a defined operation. Higher levels include the relevant evidence from earlier ones. Buying software does not move the assessment up a level.

Level 1: Ad hoc

The process depends on memory, improvised fixes or one person's private knowledge. You cannot reliably explain what happened to a particular customer.

Evidence might include contradictory field definitions, an unowned integration or different answers when two people describe the same handoff.

The next useful improvement is usually small: agree on the outcome, assign responsibility and document how the work actually happens. Do that before adding another automation.

Level 2: Repeatable

Someone can follow an agreed process and produce the intended result. The team knows the main inputs, definitions and exceptions. Another person can carry out the routine work.

A checklist and a reviewed CSV import can qualify. Automatic execution is not required.

The limitation is visibility across boundaries. Each individual step may work while customers still disappear between the form, CRM and sales queue. Move further when those handoffs matter enough to verify systematically.

Level 3: Connected and controlled

The relevant steps work together, whether through software or a deliberate manual handoff. You can trace a customer across them. Matching rules, ownership and exception handling are explicit.

Evidence includes a tested transfer, a known response to a rejected record and a way to stop the process when an input becomes unsafe to use.

A connector marked “connected” is insufficient. Show that the right record arrived, retained its meaning and triggered the right next step.

Level 4: Measured in operation

You observe the process over a stated period and compare it with agreed requirements. Failures, delays and exclusions are visible to someone who can act.

The distinction from Level 3 is sustained operational evidence. A successful setup test establishes a path; it does not establish its ongoing reliability.

Measure the outcome that matters. A campaign reporting successful sends can still fail if it contacts accounts that already completed onboarding. Include whether the right customers were eligible.

Level 5: Adaptable

The team can change the process, evaluate the consequences and recover safely when the change fails. People understand the dependencies well enough to update them together.

Evidence includes a recent controlled change, checks of its effects, an exercised recovery procedure and updated operating instructions. AI is optional. A modest system with reliable change control can reach this level.

Level 5 is worthwhile where change is frequent or mistakes are expensive. It is unnecessary overhead for a low-volume process that works, rarely changes and has a cheap, safe fallback.

Apply those levels across six areas

Assess each area separately for the process you selected. These are evidence prompts, not a requirement to produce 30 documents. One well-kept operational record may support several findings.

1. Business purpose and ownership

Can the team explain why the process exists and who makes decisions about it?

• Level 1: Different people describe different outcomes, or nobody owns the result.
• Level 2: The outcome, accountable owner and routine responsibilities are agreed.
• Level 3: Teams agree who owns each handoff and resolves conflicts between systems.
• Level 4: The owner reviews outcome and failure evidence and changes priorities accordingly.
• Level 5: A proposed change includes its dependencies, expected benefit, review point and reversal criteria.

An owner needs authority and time. Naming the founder against every process without reserving operating capacity leaves the work unowned in practice.

2. Customer data and identity

Can you identify the right person or account and trust the fields the process uses?

• Level 1: Identity and field meaning depend on guesswork or inconsistent spreadsheets.
• Level 2: The team defines the essential fields, their sources and the customer entity being counted.
• Level 3: Matching rules and missing or conflicting values have explicit handling across systems.
• Level 4: Relevant quality checks run on a stated cadence, with failures and affected records reviewed.
• Level 5: Changes to identity or field definitions are assessed against downstream uses before release.

Choose checks around the job. A nightly aggregate report and a cancellation suppression check have different freshness needs.

The UK Government Data Quality Framework defines quality around fitness for the intended use and recognises tradeoffs between dimensions. Completeness alone does not establish accuracy. A fully populated CRM can still contain incorrect account links.

For implementation detail, the single customer view guide explains why joining records requires explicit entity and conflict rules.

3. Integration and execution

Does an input reach the right destination and cause the intended action?

• Level 1: Records are moved or actions triggered without a dependable process.
• Level 2: The transfer is documented and someone checks its routine completion.
• Level 3: The end-to-end handoff is verified, with handling for rejection, repetition and missing data.
• Level 4: Coverage, delay and incorrect actions are monitored against agreed requirements.
• Level 5: Integration changes are tested with representative cases and can be reversed or contained.

Count an approved exclusion separately from a missing record. Otherwise, an intentionally suppressed customer can look like an integration failure, while a duplicate send disappears inside a healthy delivery total.

4. Measurement and decisions

Can a result be reproduced and used for the decision it is meant to support?

• Level 1: Reports disagree without an explanation, or success has no stable definition.
• Level 2: The metric has an agreed population, event, time window and calculation.
• Level 3: Reports can be reconciled to their inputs, with known exclusions documented.
• Level 4: The team records decisions made from the evidence and checks the relevant outcomes.
• Level 5: Definition changes and new analyses are reviewed for comparability, uncertainty and decision value.

This area does not require attributing every pound of revenue to a channel. Knowing that a report cannot answer a causal question is useful evidence of judgement.

Do not award a higher level because the dashboard refreshes faster. Ask whether the refresh changes a decision and whether the underlying data supports it.

5. Reliability, access and customer preferences

Can the team prevent inappropriate actions, detect trouble and respond?

• Level 1: Access, preferences or recovery depend on informal assumptions.
• Level 2: Access and preference handling are documented, with an owner and a basic stop procedure.
• Level 3: Required controls are checked across the complete flow, including relevant failure cases.
• Level 4: Exceptions and incidents are reviewed, and the team checks whether controls keep working.
• Level 5: Recovery and change procedures are exercised, with lessons applied to the live process.

Privacy and security requirements are obligations to establish for the actual use, not benefits unlocked at a higher maturity level. An acceptable maturity rating cannot excuse a missing required control.

A customer preference may change after an audience is generated. Assess where the final eligibility check happens and what occurs if that check is unavailable.

6. People and operating capacity

Can the team use, maintain and change the process without relying on one person?

• Level 1: One person carries the knowledge, or nobody consistently uses the process.
• Level 2: Routine instructions exist and a second person can follow them.
• Level 3: Handoffs, escalation and support responsibilities work across the people involved.
• Level 4: The team reviews operating effort, recurring mistakes and training gaps.
• Level 5: People can cover absences and introduce changes without losing essential controls.

A manual process may be well understood but too expensive at next quarter's volume. That is a capacity constraint to solve. An automated process that nobody can diagnose may have the opposite problem.

Record evidence without manufacturing a company score

Use the highest level supported by evidence for each area, including the relevant earlier requirements. If evidence supports only part of a level, record the lower level and name the gap.

Use “unassessed” when you have not checked. It does not mean Level 1. Conversely, a confident stakeholder opinion is not evidence that the process works.

Do not average the six levels into “3.7 out of 5.” These are ordered categories, not equal units of business value. A high measurement rating cannot compensate for broken suppression or unknown ownership.

Keep a separate record of critical gaps. Decide whether each gap blocks operation, limits scope or can be addressed within an agreed period. Make that decision with the person responsible for the affected risk.

Useful evidence includes a traceable sample, an observed exception, a run log, a completed handover or a recent change record. Record dates and coverage. Ten successful examples from one signup route say little about a second route you never inspected.

The government's data quality action-planning guidance recommends identifying critical data, defining relevant rules, establishing a baseline and recording repeated assessments. Apply that discipline to the chosen workflow; do not spend weeks measuring fields nobody uses.

Here is a fictional assessment record for an onboarding reminder. The target timing is an assumption for this example, not a universal benchmark:

workflow: trial_onboarding_reminder
area: integration_and_execution
assessment_status: assessed
observed_level: 2
desired_level: 3
required_outcome: no reminder after recorded activation
timing_requirement: activation visible to eligibility check within 15 minutes
evidence:
  - type: staging_trace
    coverage: standard signup with one workspace
    result: routine transfer completed
missing_evidence:
  - repeated activation event
  - customer in more than one workspace
  - unavailable activation status
  - preference change before send
next_action: verify these cases with sending disabled
owner_role: marketing_ops
stop_condition: eligibility cannot be established
review_trigger: tests completed and corrective changes checked

A staging trace supports a claim about staging. Do not turn it into a claim about production reliability. Production review needs appropriate permissions, safe checks and evidence from the actual running process.

What should a 20-person company aim for?

Headcount is a poor target setter. A 20-person team sending large automated audiences may need stronger controls than a 50-person business handling a small number of enquiries manually.

As a starting recommendation, aim for Level 2 across the routine work you rely on, Level 3 across consequential handoffs and Level 4 where continuing failure would be costly or hard to notice. These are planning defaults, not industry benchmarks.

Consider a fictional 20-person SaaS team. It has agreed activation definitions, integrated product events and a dashboard reviewed every week. Its reminder process sometimes sees yesterday's activation state. Nobody has checked what happens when the data sync stops.

The next investment should establish current eligibility and failure handling. A new AI campaign generator would not resolve either gap.

The team might keep its monthly reporting process at Level 2 while improving reminder reliability to Level 4. Different targets are sensible when they reflect different consequences.

Use this sequence:

Open full diagram

A review trigger could be a new acquisition channel, a second product, a major increase in volume, a system migration or a recurring incident. Reassess when the assumptions change.

Make the next improvement small enough to verify

A maturity assessment should end with one concrete commitment: the gap, its consequence, the change, the owner and the evidence that will show whether it worked.

“Improve data maturity” cannot be completed. “Make activation status available before reminder eligibility is evaluated, and handle unavailable status without sending” can be checked.

DORA's software delivery guidance recommends assessing a specific application or service, identifying its constraint, making an improvement and checking progress. That research concerns software delivery; it does not validate this martech model. The useful borrowing is a bounded improvement cycle.

For a small team, reserve operating time as well as setup time. A check that creates an alert nobody investigates adds work without establishing control.

Before funding the next level, ask:

If you cannot explain why the extra capability matters now, keep the current target and revisit it at a defined trigger. Maintenance is a valid decision.

Where AI belongs in the assessment

Assess the job an AI system performs using the same six areas. A summariser drafting internal notes and an agent changing customer records need different evidence and controls.

Check inputs, allowed actions, review responsibility, failure handling and whether the output improves the task. Do not award maturity points for connecting a model to more tools.

NIST's AI Risk Management Framework 1.0 core organises risk management around govern, map, measure and manage. It describes continuing, context-dependent work rather than a prescribed sequence.

That is useful guidance for an AI use case, not proof that deploying AI is the final stage of martech development. Sometimes the better decision is a documented rule or a human review.

Turn the findings into work

Bring the process owner, an operator and someone who understands the systems together. Inspect the workflow, record the evidence and agree on the most consequential gap.

Keep the assessment alongside the operating instructions. Revisit the affected areas after a material change or incident. There is no need to rebuild a company-wide scorecard every month.

If the gap is an unreliable handoff between product, CRM, billing or messaging, martech integration support can help turn the finding into a scoped implementation. The starting deliverable should be a defined outcome and verification plan. A larger stack is not a success criterion.