01 / UNDERSTAND
What is a stakeholder map?
A stakeholder map shows the people, groups and organisations connected to a service or decision. It makes their roles and relationships visible so a team can see who shapes the outcome and who experiences its consequences.
Unlike an organisation chart, it can include residents, suppliers, informal supporters and others outside the delivery organisation. This guide uses a relationship map. An influence and interest matrix can answer a different question about engagement, but it should not replace an account of how actors depend on one another.
Why map stakeholders?
A project can have agreement inside the team and still fail at a boundary. Someone approves the budget, another person controls access to a site, and a third receives the complaints. An actor list alone does not show those dependencies.
Mapping helps turn “we should involve stakeholders” into a concrete plan: who needs to contribute, to which decision, and why. It also exposes relationships the team has assumed rather than checked.
When to use a stakeholder map
USE IT WHEN
At the start of a service project with several organisations or delivery teams.
Before changing responsibilities, handoffs or participation in a decision.
When the same decision repeatedly stalls because a dependency is unclear.
When to choose another method
Use Service Blueprint when the main question is how delivery works across a sequence of interactions.
Use Customer Journey Map when you need to understand one person’s experience over time.
Use User Interviews to investigate a missing perspective rather than guessing it on the map.
What you’ll need
State the service boundary and the decision ahead. Gather existing process descriptions, contracts where relevant, and accounts from people doing or receiving the work. Start with roles rather than personal names. Keep a source or an explicit assumption beside each important connection. Invite people with different views of the service; the project sponsor’s account is only one perspective.
What belongs on the map?
Keep the elements that help answer your question and support a decision.
The service boundary and the question the map should support.
People, groups and organisations, including those outside the delivery team.
What each actor needs, contributes or stands to lose.
Directed exchanges, dependencies and decision rights between actors.
Where each important claim came from, and what is disputed or missing.
Who must contribute to the decision, in what way and with what support.
02 / PUT IT INTO PRACTICE
How to create a stakeholder map
Keep evidence and assumptions distinct. Revisit your work when new information changes your understanding.
01
Set the boundary
Name the service and the decision; avoid mapping an entire organisation by default.
Focus on changes to repair appointments and how those changes reach the right people.
02
Identify the actors
List those delivering, receiving, enabling and being affected by the service.
Include tenants, scheduling, the contact centre and the contractor.
03
Describe their stake
Record each actor’s role, needs, constraints and relevant authority.
The contractor assigns visits; the tenant must be able to arrange access.
04
Connect the roles
Draw labelled arrows showing what passes between actors.
Distinguish an appointment instruction from a change of availability.
05
Check the missing links
Validate disputed connections and ask who is absent from the discussion.
Trace a changed appointment with the people who receive and forward it.
06
Plan participation
Choose the next decision and record the participants, contribution and owner.
Bring operational staff and affected tenants into a review of the change process.
Example: improving a housing repairs service
Illustrative scenario: all actors and connections are hypothetical. A housing provider wants to reduce missed repair appointments. The initial discussion includes the repairs team, a booking service and a maintenance contractor.
The map adds tenants, the contact centre and a tenant representative group. Booking sends an appointment to the contractor, but a tenant’s changed availability reaches the contact centre. The team suspects that this update does not always reach the person attending. That is a relationship to verify, not an established finding.
The map changes the next meeting: include someone who receives updates, someone who schedules work and tenants with different access needs. Ask how a change travels through the service. Only then decide whether to change the process, the booking interface or the contractor agreement.
03 / BELOW THE SURFACE
Below the surface: influence is not exposure
The actor who can approve a change is not necessarily the person who bears its cost. In the repairs example, a contractor may control a schedule while a tenant loses time waiting at home. Ranking people only by organisational influence can make that consequence disappear.
01 / AUTHORITY
Who can decide?
Name the relevant decision right rather than relying on seniority.
02 / CONSEQUENCE
Who bears the cost?
Whose time, access or working conditions change with this choice?
03 / PARTICIPATION
Who is still absent?
What would enable them to contribute before the decision is made?
Separate decision authority from exposure to consequences. Record both without collapsing them into a single importance score. A tenant may lack formal approval power while holding essential knowledge about whether an appointment arrangement is workable.
For each planned decision, ask whose agreement is required, whose experience is needed and who will live with the result. A representative group may help reach people, but it cannot automatically speak for every circumstance. Check who remains absent and how they could participate. This is an editorial check on the map’s usefulness, not a validated scoring framework.
Stakeholder Map template
The two page working canvas captures actors, their stake, authority, dependencies and evidence. The second page records directed connections and turns them into a participation plan, unresolved questions and named actions. Use the relationship register to sketch nodes and labelled arrows on a shared board when a visual overview helps.
The PDF has 39 editable fields. Open it in a PDF reader that supports forms and save a copy. Add another sheet when necessary; the number of rows is a workspace limit, not a limit on who matters.
Practical tips
Label connections with concrete exchanges, such as an approval, update or payment.
Separate a role from the person currently holding it.
Ask each actor which other role they depend on.
Record disagreements instead of forcing a single version too early.
Common mistakes
Mapping only senior people or internal departments.
Treating a line between two actors as evidence of a working relationship.
Assuming low influence means little need to participate.
Producing a polished diagram without assigning a next action.
What you’ll get
A bounded view of actors and relationships, with a clear account of what remains uncertain. Use it to choose who to involve in the next decision, what contribution is needed and who will follow up. Revisit the map when responsibilities, agreements or the service itself change.