The Supplier Case Has More Than One Owner
PathPatron Use-Case Canvas — 2 of 7
On Friday morning, Maya looks again at the supplier case that filled her Thursday afternoon. She has a useful first pass: a supplier is late, the procurement coordinator has chased status three times, a contract clause is still missing and Finance has stopped vendor creation because bank data has not cleared its check.
It would be easy to call that a procurement problem. Procurement is the voice Maya heard first. It is also the team with the most visible frustration.
But the supplier cannot start because several people are carrying different parts of the same consequence. Legal is protecting the company from an incomplete agreement. Finance is protecting it from a bad payment setup. The business owner is protecting a delivery date. The supplier-facing coordinator is trying to turn a contradictory set of requests into one clear next action. And Maya is the person who will have to explain the delay if nobody can name an owner.
The first article gave Maya a way to start with one real case instead of a shiny AI request. This article helps her answer the next question: whose outcome must the team understand before it decides what deserves attention?
At this point, Maya does not need a complete organisation chart and she does not need a stakeholder workshop with thirty people. She needs a small, defensible map of the people who make a difference to this case.
The person who asks loudest is not always the person whose problem leads
The request on Maya’s screen reads: “Can we use AI to speed up supplier onboarding?” The procurement manager who sent it is not wrong. She has spent the week chasing updates and re-explaining a delay. But “speed it up” is a request for an intervention, not yet a shared description of the problem.
Maya returns to the actual case. She asks the coordinator to show her the last supplier message, the missing contract item, the failed bank-data validation and the project milestone that makes the delay matter. Then she asks a more useful question: who would be affected if we made this route faster in the wrong way?
That question changes the room.
If an assistant sends a better reminder but the supplier still receives conflicting requests, it has not solved the coordinator’s problem. If a workflow clears a case faster but makes incomplete evidence look complete to Legal, it has created a worse problem. If the business owner receives a confident date that Finance cannot honour, the new speed is only a better-looking escalation.
Maya writes the coordinator into the Persona space, because she is closest to the consequential moment. She does not mistake that for a verdict on whose pain matters most. It is simply the most concrete place to begin.
Maya makes a first map, then asks people to correct it
Maya’s solo first pass from Article 1 has already given her a short list of roles visible in the evidence trail. She turns it into invitations, not conclusions:
- the procurement coordinator, who is doing the chasing;
- Legal, which can accept or reject the contract evidence;
- Finance, which controls vendor creation after the data check;
- the business owner, who experiences the delivery consequence;
- the supplier-facing coordinator, who can show what the supplier was actually asked to do; and
- the process or control owner, if the case still cannot show who owns an exception.
She invites only the people who can supply critical evidence, carry the impact, approve an exception, own the outcome or make a workaround permanent. Everyone else can be consulted later. The point is not representation for its own sake. The point is to make a decision the real workflow can survive.
In the invitation, Maya is precise: We are not selecting a tool. We are checking one recent supplier case, the outcomes each of us is protecting and the evidence we need before we propose a change.
That wording matters. It gives Legal and Finance permission to arrive as sources of operational knowledge rather than as people who have been asked to bless an idea after the fact.
The stakeholder map is a working conversation, not a roster
Maya puts the activity board beside the Canvas. For each material participant, the group writes five short notes: their role in this case, the outcome they are protecting, one fact that supports the note, the authority they hold and the change that would be unacceptable.
This works in either setting. Online, Maya creates the board in Mural, Miro or the organisation’s approved whiteboard, then gives each participant a small, named area to add evidence before discussion starts. In a meeting room, she prints the same five prompts as cards, puts them on a wall beside the Canvas and hands out sticky notes. The medium changes; the discipline does not: one note should make one claim that someone can point back to in the case.
The group starts with silence. For five minutes, each person adds only what they know from this case. That prevents the first confident storyteller from turning a familiar policy into a substitute for evidence.
Then Maya works down the board.
| Participant | What they are protecting | Evidence from this case | Authority or boundary |
|---|---|---|---|
| Procurement coordinator | A reliable status and fewer chaser emails | Three status requests; no named next owner | Can coordinate; cannot waive checks |
| Legal reviewer | Complete contractual evidence before risk is accepted | A required clause was absent from the packet | Can accept or reject contractual evidence |
| Finance Operations | Validated bank and tax data before a vendor exists | Bank validation failed before creation | Can block creation; does not own every upstream request |
| Business owner | A dependable supplier start date | The project milestone is now exposed | Can sponsor priority; cannot override controls alone |
| Supplier-facing coordinator | One coherent request and a clear next action | The supplier received overlapping requests | Can clarify communication; cannot decide an exception |
The table is not a scorecard of who is right. It makes a practical distinction visible: people can want a case resolved quickly and still be protecting different things. Maya calls those differences targets, not obstacles.
Use the Compass roles already in the room
One of Maya’s early notes says “Procurement owns onboarding.” The discussion proves that sentence is too loose to guide a change. Rather than inventing new role labels, Maya uses the Compass terminology the team can already navigate.
The procurement coordinator may be the daily User of the work. The business sponsor may act as a Buyer when a change needs investment or commitment. Finance Operations may be the Decider at the vendor-creation boundary. Legal, procurement or a business lead may be an Influencer where their evidence or position shapes the outcome. A Transformer is the person or team that will execute the transformation itself: moving the painful current process to a pain-free future state by redesigning, implementing, introducing and carrying the change through adoption.
These are not extra boxes to fill or permanent job titles. One person can carry more than one role in a case, and the team should record only the role that changes the decision. A procurement-team member who will simply operate the resulting process is a User; they are also a Transformer only if they will actively deliver the transformation. This prevents a familiar failure: a pilot helps the visible user, then the team discovers too late that it has not involved the Decider, the relevant Influencer or the people who must deliver the change.
Maya asks two linked questions: Which User will work in the future process, and which Transformer will deliver the change from the painful process to that future state? She then asks which Buyer, Decider and Influencer must support or shape the move. If the team cannot answer, she labels it Information gap. She does not turn a job title into an answer.
A fast first session can still be honest
The first group session does not need to become a multi-week discovery programme. Maya can run a responsible 45-minute version once she has prepared the case trail.
| Time | What Maya asks the group to do | What becomes clearer |
|---|---|---|
| 0–5 min | Read the case evidence and add facts silently | What happened, without a solution debate |
| 5–15 min | Name the material people around this one case | Who supplies information, receives impact or holds a boundary |
| 15–25 min | Write each person’s outcome to protect | Why apparently sensible changes may conflict |
| 25–35 min | Add authority, ownership and unacceptable change | Who can block, override or carry the result |
| 35–45 min | Mark evidence gaps and agree the next conversations | What needs validation before the team defines a use case |
The output is deliberately incomplete. Maya leaves with a better account of whom to involve and what to verify—not with permission to automate anything.
If the people cannot meet yet, she can ask an approved AI assistant to prepare the same board from anonymised case material. It may organise a first draft; it cannot infer somebody’s authority, motivation or tolerance for risk.
Prompt template: prepare a first stakeholder board
Using only the anonymised case material below, prepare a stakeholder board for a Use-Case Canvas session. For every note, label it Evidence, Hypothesis or Information gap. For every Evidence note, quote or identify the source material it comes from. Map people only to these Compass roles where supported: User, Buyer, Decider, Influencer and Transformer. Treat a Transformer as someone who will execute the transformation from the painful current process to the pain-free future state; do not label a person a Transformer merely because they will operate the future process. State which named role must validate every Hypothesis or Information gap. Do not infer authority, motivation, risk tolerance, policy or ownership from a job title. Return: (1) a concise board grouped by role, (2) open questions for the session and (3) a suggested 45-minute agenda. Case material: [paste approved, anonymised material here].
Use AI to make the session easier to work with
AI can make the meeting more useful without replacing the people who need to make the judgment. Before an online session, Maya can use an approved assistant to turn the case trail into a neutral agenda, a first list of questions and a board skeleton. Before an in-room session, it can produce the same five printed prompt cards and a one-page case summary.
During an online session, the group can use its approved meeting transcription and whiteboard tools to capture contributions, cluster duplicate notes and flag statements that have no cited evidence. During an in-room session, Maya can photograph the wall at agreed checkpoints and, with the group’s consent, make an approved recording or written notes. An assistant can then transcribe the cards and organise them into the same board structure. Do not upload personal, confidential or supplier-sensitive material to a tool that has not been approved for it.
After either format, AI can prepare a concise read-out: the evidence captured, hypotheses still to test, information gaps, unresolved tensions, and the next conversation each Compass role needs. Maya checks that read-out against the board before sharing it. The record is a meeting aid, not a decision made by the assistant.
Put the shared version on the Canvas
Only after the conversation does Maya update the Canvas. It is still mostly open. She fills the areas that now have a shared basis:
- Persona: the procurement coordinator, her consequential moment and the evidence that makes it real;
- Stakeholders: Legal, Finance Operations, the business owner, the supplier-facing coordinator and any named process/control owner;
- Pain Point / Opportunity: not “automate onboarding,” but the observable situation: a supplier cannot be activated because multiple teams need evidence and no one can see the coherent next action; and
- Decision boundary: the provisional tension—speed versus control—and the authority that must be confirmed.
The filled notes are not a finished diagnosis. They are a shared promise not to treat the coordinator’s loud request as the whole problem. Maya has enough to decide whether this case deserves deeper work: it is real, consequential, evidence-rich enough to investigate and supported by the people whose constraints would shape any credible change.
Choosing where to spend attention first
When Maya has more than one candidate case, she uses the same map as a lightweight priority check. A case moves forward when four things are true:
- The consequence is material. Someone can show what delay, rework, risk or missed value changes.
- The case is concrete. There is a recent example and people can bring evidence, not just opinions.
- The outcome has an owner. The team can name who would sponsor discovery and who would live with the result.
- The boundaries are visible. The team knows enough to avoid a change that weakens a necessary control.
A loud request with no evidence, no affected owner or no accessible source of truth does not become the priority simply because it is urgent. It may need discovery, a clearer policy or a named owner before it needs technology.
Next: make the tensions explicit
Maya can now see the people around the supplier case. The next article does a different job: it tests where their interests, influence and authority collide. It turns the first stakeholder notes into evidence about power, pain and the boundary a future change must not cross.
Where you are in the Use-Case Canvas series
You are here: Article 2 — The Supplier Case Has More Than One Owner. Start with Article 1 — The Monday-Morning Supplier Problem, which frames the real case. This article maps the people and Compass roles around it. Next, Article 3 will make the tensions between power, interest and pain explicit.
PathPatron principle: start with the person closest to the work, then widen the frame until the team can see who is affected, who decides and what a responsible change must preserve.