A practical COM-B checklist for service leaders

Most service failures are not caused by bad intent, poor strategy or lack of effort. They fail because the service assumes people will behave differently without changing the conditions that shape behaviour.

For example, a service may ask patients to attend regular follow-up appointments, while appointment times are inflexible, travel is difficult and reminders are unclear, making the expected behaviour hard to sustain in practice.

COM-B is a simple model for understanding behaviour change, based on the idea that behaviour only happens when people have the capability, opportunity and motivation to act. It was developed by Susan Michie and colleagues at University College London as part of the Behaviour Change Wheel, to help policymakers and practitioners design interventions grounded in real-world evidence rather than assumptions.

The COM-B model is useful precisely because it is simple. It helps leaders ask better questions early - before money is spent, technology is built, or delivery momentum makes change hard.

This article is deliberately practical. No theory. Just a checklist you can use in meetings, gateways and design reviews.

What COM-B is for (in plain terms)

Behaviour only changes when:

  • people can do the thing (capability)
  • their environment allows it (opportunity)
  • they want or feel able to do it (motivation)

If any one of these is weak, behaviour change is fragile or fails completely.


The COM-B checklist

Use this as a diagnostic, not a compliance exercise. You are looking for risk signals, not perfect answers.

C = Capability

Do people have the ability to do what the service expects?

Ask:

  • Do users clearly understand what is being asked of them?
  • Are there hidden skills required that we are taking for granted?
  • Are we relying on confidence, judgement or interpretation rather than clear steps?
  • Does this assume digital, health, language or system literacy?
  • Would a stressed, tired or anxious person still manage this?

Early risk signals:

  • “We’ll explain it in training”
  • “They’ll learn over time”
  • Heavy reliance on written guidance
  • Frequent user errors blamed on carelessness

Common misstep:

  • Treating capability gaps as training problems, rather than design problems.

O = Opportunity

Does the real-world context make the behaviour possible?

Ask:

  • When and where does this behaviour need to happen?
  • What else is competing for attention at that moment?
  • Do systems, processes or policies actively get in the way?

  • Is the digital and physical environment aligned?
  • Who controls access, permissions or timing?

Early risk signals:

  • Workarounds becoming normal
  • Staff or users creating parallel systems
  • “In theory this works, but in practice…”
  • Dependence on goodwill or heroics

Common misstep:

  • Designing for an idealised process rather than lived reality.

M = Motivation

Do people actually want to behave this way, in this context?

Ask:

  • What problem does this solve for the user, not the organisation?
  • What feels risky, effortful or emotionally loaded about this behaviour?
  • Are we relying on willpower rather than ease?
  • What past experiences shape trust or scepticism here?
  • What happens if people do not comply?

Early risk signals:

  • Over-reliance on comms, nudges or incentives
  • Language about “engagement” without evidence of uptake
  • Blame framed as resistance or culture
  • Drop-off after initial adoption

Common misstep:

  • Assuming motivation is about attitude, rather than experience.

How leaders can spot risk early

You don’t need a full research programme to use COM-B well.

Use it:

  • at the start of discovery, before solutions are defined
  • in design reviews, to stress-test assumptions
  • at gateways, to identify delivery risk
  • when adoption stalls and the instinct is to push harder

A simple rule of thumb:

  • if a solution relies on training, comms or enforcement, revisit COM-B
  • if success depends on “people just doing the right thing”, revisit COM-B
  • if failure is blamed on users, revisit COM-B

A practical COM-B checklist for service leaders

Most service failures are not caused by bad intent, poor strategy or lack of effort. They fail because the service assumes people will behave differently without changing the conditions that shape behaviour.

For example, a service may ask patients to attend regular follow-up appointments, while appointment times are inflexible, travel is difficult and reminders are unclear, making the expected behaviour hard to sustain in practice.

COM-B is a simple model for understanding behaviour change, based on the idea that behaviour only happens when people have the capability, opportunity and motivation to act. It was developed by Susan Michie and colleagues at University College London as part of the Behaviour Change Wheel, to help policymakers and practitioners design interventions grounded in real-world evidence rather than assumptions.

The COM-B model is useful precisely because it is simple. It helps leaders ask better questions early - before money is spent, technology is built, or delivery momentum makes change hard.

This article is deliberately practical. No theory. Just a checklist you can use in meetings, gateways and design reviews.

What COM-B is for (in plain terms)

Behaviour only changes when:

  • people can do the thing (capability)
  • their environment allows it (opportunity)
  • they want or feel able to do it (motivation)

If any one of these is weak, behaviour change is fragile or fails completely.


The COM-B checklist

Use this as a diagnostic, not a compliance exercise. You are looking for risk signals, not perfect answers.

C = Capability

Do people have the ability to do what the service expects?

Ask:

  • Do users clearly understand what is being asked of them?
  • Are there hidden skills required that we are taking for granted?
  • Are we relying on confidence, judgement or interpretation rather than clear steps?
  • Does this assume digital, health, language or system literacy?
  • Would a stressed, tired or anxious person still manage this?

Early risk signals:

  • “We’ll explain it in training”
  • “They’ll learn over time”
  • Heavy reliance on written guidance
  • Frequent user errors blamed on carelessness

Common misstep:

  • Treating capability gaps as training problems, rather than design problems.

O = Opportunity

Does the real-world context make the behaviour possible?

Ask:

  • When and where does this behaviour need to happen?
  • What else is competing for attention at that moment?
  • Do systems, processes or policies actively get in the way?

  • Is the digital and physical environment aligned?
  • Who controls access, permissions or timing?

Early risk signals:

  • Workarounds becoming normal
  • Staff or users creating parallel systems
  • “In theory this works, but in practice…”
  • Dependence on goodwill or heroics

Common misstep:

  • Designing for an idealised process rather than lived reality.

M = Motivation

Do people actually want to behave this way, in this context?

Ask:

  • What problem does this solve for the user, not the organisation?
  • What feels risky, effortful or emotionally loaded about this behaviour?
  • Are we relying on willpower rather than ease?
  • What past experiences shape trust or scepticism here?
  • What happens if people do not comply?

Early risk signals:

  • Over-reliance on comms, nudges or incentives
  • Language about “engagement” without evidence of uptake
  • Blame framed as resistance or culture
  • Drop-off after initial adoption

Common misstep:

  • Assuming motivation is about attitude, rather than experience.

How leaders can spot risk early

You don’t need a full research programme to use COM-B well.

Use it:

  • at the start of discovery, before solutions are defined
  • in design reviews, to stress-test assumptions
  • at gateways, to identify delivery risk
  • when adoption stalls and the instinct is to push harder

A simple rule of thumb:

  • if a solution relies on training, comms or enforcement, revisit COM-B
  • if success depends on “people just doing the right thing”, revisit COM-B
  • if failure is blamed on users, revisit COM-B

Synopsis

Reading time
minutes

Author