Briefly: a capability map lists what the business does, not how it does it or which system does it. “Manage customer credit” is a capability; “run the credit check flow in Salesforce” is not. It earns its place on a Salesforce programme by giving stakeholders a way to argue about scope and priority without arguing about technology, which is usually the argument they were actually having.
What makes something a capability
Three tests, all of which must pass:
- It is a noun phrase describing an ability, not a process or a step. “Order fulfilment”, not “pick and pack the order”.
- It would still exist if you changed every system. Capabilities outlive technology. If replacing Salesforce removes it from the list, it was a feature.
- It is stable over years. Processes change annually. Capabilities rarely do.
| Capability | Not a capability |
|---|---|
| Customer onboarding | Send the welcome email |
| Quote and pricing | CPQ implementation |
| Case resolution | Omni-Channel routing |
| Revenue recognition | The finance integration |
| Partner management | Experience Cloud portal |
The right-hand column is what most first attempts produce, because people describe what they are building rather than what it is for.
Structure
Two levels is usually right, three at most. Level one is the handful of things the business does — perhaps eight to twelve. Level two decomposes each into four to eight. A third level exists only where a specific area is the subject of the programme.
Going deeper is the most common way these become useless. A four-level map with two hundred boxes is an org chart in disguise and nobody reads it twice.
What you use it for
Scoping. Colour the capabilities in scope for this phase. The conversation immediately becomes “why is credit management not in phase one” rather than “should we build that object”, which is a much better conversation to be having with a steering committee.
Finding duplication. Map which system supports each capability. Three systems supporting “customer master” is a finding you can put in front of people who do not care about data models but do care about the same customer having three addresses.
Prioritising. Rate each capability on how well it is currently served and how much it matters. The gap (high importance, poorly served) is your roadmap, and it is derived rather than asserted, which makes it much harder to argue with.
Keeping the argument off technology. This is the real value on a Salesforce programme. Stakeholders arguing about whether to use Sales Cloud or a custom object are usually disagreeing about what the business needs to be able to do. The map moves the disagreement to where it belongs.
Building one
- Start from an industry reference model if one exists for your sector. Starting from a blank page produces a map shaped like your current org chart.
- Interview across functions, not just the sponsor. Capabilities missed are always the ones belonging to a team nobody invited.
- Write level one first and stop. Get agreement on eight to twelve before decomposing anything. Decomposing before the top level is agreed means redoing it.
- Test each entry against the three rules. Delete or rewrite anything that fails.
- Map systems to capabilities last, once the map is agreed. Doing it earlier biases the map toward what the systems happen to do.
Step three is where most of the discipline is needed and where most programmes skip ahead.
Where it goes wrong
It becomes the org chart. If level one matches your departments exactly, you have mapped the organisation rather than what it does. Capabilities frequently span departments, and the ones that do are usually the interesting ones.
It becomes a systems inventory. Boxes named after products mean the exercise inverted. Systems are an overlay on the map, never the map.
It is built and never used. A map produced in a workshop and filed is a cost with no return. If it is not on the wall during scope discussions, do not build it.
It is too detailed to show anyone. The audience is a steering committee. If it does not fit on a page they can read while you talk, it will not do its job.
Honest limits
A capability map does not tell you what to build, how hard anything is, or in what order to sequence delivery. It is a framing device — it makes scope conversations tractable and it makes duplication visible.
On a small programme with one clear sponsor and an agreed scope, it is overhead. The value appears when several stakeholders disagree about priority and have no shared vocabulary for the disagreement, which is the situation on most large Salesforce programmes and very few small ones.
Frequently asked
How long does it take to build?
A first usable version is days, not weeks, if you start from a reference model and interview efficiently. Perfecting it has diminishing returns quickly.
Who owns it?
The business, with architecture facilitating. A map owned by IT gets treated as an IT artefact and loses the authority that makes it useful.
How often should it change?
Rarely. If it changes every quarter, it is describing processes rather than capabilities and the level of abstraction is wrong.
Does it replace a process map?
No, and they are frequently confused. Capabilities are what. Processes are how. Both have uses and they answer different questions.
Do I need one for a single-cloud implementation?
Usually not. The cost is not repaid unless there are competing stakeholders or a multi-phase roadmap to sequence.
Reference: Salesforce Well-Architected and Salesforce Architect enterprise architecture resources, Salesforce; general business architecture practice.
