Show Who Must Agree at Each Step of a Complex Sale

Most stakeholder maps are org charts with a sales problem. They list names, titles, and how warmly each person received you. Then the deal stalls and the map explains nothing, because it was never built to explain anything. It recorded who exists.

A map that earns its keep records something else: what the customer's decision depends on. Not who might sign, but what has to be true before the next step can responsibly happen, who can answer for each of those conditions, and what evidence the customer actually asked for. GOV.UK's stakeholder research guidance is a decent model for the inquiry itself — it treats stakeholder work as finding out about responsibilities and context rather than assigning influence scores — but it describes a public-service research practice, not a sales methodology. The distinction matters when you carry its habits of inquiry into a commercial conversation.

Let me show you what that looks like on a deal, because the method is easier to argue with once it has a body.

The account, as far as anyone knows

This is an invented case, and its limits are the point. No customer was interviewed, no trial was run, no buying intention observed. Every "confirmed" fact below is confirmed within the fiction — the kind of thing a seller might have heard in one call and written down. The unanswered items are the ones that would actually drive the next meeting.

The product is a shared scheduling tool. The prospect is a mid-sized architecture firm, forty-odd people, multiple studios that book the same meeting rooms and site-visit vans. The seller has had one call, with a studio manager named Priya, and a follow-up email from her.

The contact list after that call looks impressive enough:

• Priya — Studio Manager. Ran the call. Said "we keep double-booking the vans, it's embarrassing."
• Daniel — Operations Director. Copied on Priya's follow-up email. Never spoken to.
• Marcus — Partner, one of four. Mentioned by Priya as "the one who cares about this stuff."
• IT vendor — unnamed, "they handle our systems." Priya was vague.

It is a bad map. It has four rows and zero decisions. Daniel was copied on an email, which is a fact about an email and nothing else — not authority, not interest, not involvement in the decision. Marcus "cares about this stuff" according to one person's summary. The IT vendor is a job description with no name. If the seller builds a deck from this list, the deck will be aimed at Priya's enthusiasm and Daniel's imagined seniority.

Start with the decision that's actually live

Before adding anyone to the map, name the decision currently in front of the customer. Not "they might buy scheduling software." Something with edges: whether to run a two-week trial in two studios before the end of the quarter. That's a decision a specific person can say yes or no to, and its shape tells you what evidence is needed.

Priya raised the double-booking problem herself. That makes the problem real to her. A problem being real to one person is not the same as a purchase being on the table — those are different states, and collapsing them is how sellers end up presenting to a room that hasn't decided to decide.

So write the live decision down, then write down what would have to be resolved before the next one could follow. Which brings us to dependencies.

Draw dependencies, not stages

A standard procurement sequence — demo, trial, proposal, legal, signature — is a story sellers tell each other. Real decisions move unevenly and sometimes backward. What you can trace is dependency: this agreement can't happen until that question is answered.

From the one call and the email, here is what the invented seller could defensibly write. Confirmed means Priya said it, in those words or close. Uncertain means it's the seller's inference, written as a question.

Two rows there deserve a second look. "Bad enough to fund" is not implied by "embarrassing" — plenty of embarrassing problems go unfunded for years, and treating Priya's word choice as a budget signal is exactly the kind of inference that produces confident, wrong decks. And the implementation row is the seller's own concern, not the customer's stated one. That's legitimate to hold as a hypothesis. It is not legitimate to present it back to Priya as if she raised it.

Now arrange the dependencies as a sequence, with arrows only where the conversation supports them:

[Problem real to Priya] ──confirmed──▶ (?)
                                        │
              ┌─────────────────────────┼──────────────────────────┐
              ▼                         ▼                          ▼
   (Fit: could a tool           (Resources: does anyone      (Implementation:
    change our workflow         with budget want this        can it be adopted
    without breaking it?)       solved?)                     without disruption?)
              │                         │                          │
              └───────────┬─────────────┴──────────────┬───────────┘
                          ▼                            ▼
              (Trial as next step:             [No confirmed
               acceptable to whom?)             path to purchase]

The dashed quality is the honest part. Three questions sit in parallel, none confirmed, and there is no confirmed arrow from any of them to a purchase. That's not a failure of the map. That's the map doing its job.

Give each question an owner and a piece of evidence

A name beside a stage is decoration. What makes the map operational is the pairing: this question needs this person's answer, and here is the material that could answer it.

The "requested by customer" column is the one sellers skip, and it's often the most instructive. Right now the invented answer is no across the board: whatever the seller brings to the next call, none of it has been asked for yet, and the seller still doesn't know which evidence the customer wants. That's a planning gap, and it's cheaper to see it in a table than to discover it in a meeting.

Notice, too, how the evidence changes shape with the question. "Is it funded?" can't be answered by a deck. "Would it disrupt workflows?" might be, but only if the walkthrough uses the customer's actual scenario — the vans, the rooms, the studios. Generic demo data would answer a question nobody has.

Don't read authority off a job title

Daniel is the Operations Director and was copied on an email. It is tempting to write "decision-maker" next to his name. Resist it. Being copied on a message establishes that a message was copied. It doesn't establish that Daniel has budget authority, that he's interested, that he's involved in this decision, or that Priya wanted him informed rather than merely visible. Any of those might be true. None is known.

Marcus is worse. "The one who cares about this stuff" is one person's summary of another person's attitude, relayed secondhand. Using it to decide Marcus is the economic buyer is a chain of three inferences presented as a fact.

The honest entries are the boring ones:

This is a thin map, and thin is correct. Ask Priya to correct it — not as a formality, but because a direct question ("who else would need to weigh in before a trial could start, and what would they need to see?") resolves more than a month of inference. Her answer, whatever it is, becomes another confirmed arrow on the map.

The correction that changes the next meeting

Here's where the method pays. Suppose, in a second call, Priya mentions that any new tool has to clear the firm's IT vendor before it touches studio systems — and that the vendor's review takes about three weeks and has blocked a previous purchase. She says this casually, as context.

The map has to change. Implementation readiness was a seller's hypothesis; now it's a confirmed dependency with an identified gatekeeper and a known lead time. That single correction does several things at once:

• It moves the IT review from "probably fine" to a real step with a real duration, which changes any timeline the seller might have sketched.
• It makes the vendor — previously a blank row — into someone whose approval conditions need to be learned.
• It gives the trial question a sequence: a two-week trial can't start before a three-week review finishes, unless the trial runs outside studio systems, which is now a specific question rather than a vague one.

None of this was knowable from the contact list. All of it was knowable from one sentence, because the map was built to receive it. And notice what the correction didn't do: it didn't reveal who holds budget authority, and it didn't confirm that a purchase will follow a trial. A corrected dependency is not a completed decision. It's one fewer question.

This is where the next meeting's purpose comes from. If the implementation gate is now known, and funding is still unknown, then the most useful next conversation is not the full demo — it's the one that finds out whether the problem is funded and who would carry the admin work. A polished trial-proposal deck would answer the wrong question on the wrong day: it addresses a step the customer hasn't agreed to seek, and it leaves the funding question, which nothing on the map yet answers, untouched.

Keep the map honest and keep it moving

Two habits keep this from decaying into an org chart again. First, mark every entry with its source: heard from Priya, inferred by the seller, requested by the customer, unknown. An inference that isn't labeled will, within a week, be remembered as a fact. Second, treat the document as a working account of one decision, not a truth about the firm. When Priya clarifies something, the map changes and so does the next meeting's purpose. When she contradicts the seller's hypothesis, the hypothesis goes, not the correction.

The result is not a prediction of a sale. It's a better-founded next conversation: here is the agreement currently blocking movement, here is the evidence that would resolve it, and here is the one person whose role still needs confirming before you prepare anything.

For the invented firm, that's funding — not fit, not the demo, not Daniel's title. Whether anyone with budget authority wants the double-booking problem solved is the resource question nothing on the map yet answers, and Priya may not be the person who can answer it, though the implementation gate the second call revealed now has an identified gatekeeper and a lead time. The evidence is a direct conversation, not a deck. The role still unconfirmed is Daniel's, and he was added to the map because someone copied him on an email, which was never enough.

Frequently asked questions

What should a stakeholder map record instead of names, titles, and warmth?

It should record what the customer's decision depends on: what has to be true before the next step can responsibly happen, who can answer for each condition, and what evidence the customer actually asked for. A map that lists only who exists explains nothing when the deal stalls. Asking what decision is live and what would resolve it is more useful than assigning influence scores.

How do you start mapping a complex sale?

Name the decision currently in front of the customer with edges—for example, whether to run a two-week trial in two studios before the end of the quarter. Then trace dependencies rather than procurement stages. Distinguish confirmed facts from inferences: in the invented case, the double-booking problem is confirmed by Priya, but whether it is bad enough to fund, whether a tool can be adopted without disruption, whether anyone with budget authority wants it solved, and whether a trial is acceptable all remain unresolved.

Why is Daniel not the decision-maker just because he was copied on an email?

Being copied on a message establishes that a message was copied. It does not establish budget authority, interest, involvement in the decision, or that Priya wanted him informed rather than merely visible. Marcus is even weaker: “the one who cares about this stuff” is one person's secondhand summary of another person's attitude. Reading authority off a title or an email chain produces confident, wrong plans.

What changed when Priya mentioned the IT vendor's review?

Implementation readiness moved from a seller's hypothesis to a confirmed dependency with an identified gatekeeper and a known lead time—about three weeks—and the vendor's approval conditions now need to be learned. A two-week trial cannot start before a three-week review unless it runs outside studio systems, which becomes a specific question. The correction does not reveal who holds budget authority or confirm that a purchase follows a trial.

What keeps the map honest and useful over time?

Mark every entry with its source: heard from Priya, inferred by the seller, requested by the customer, or unknown. An unlabeled inference will soon be remembered as a fact. Treat the document as a working account of one decision, not a truth about the firm. When Priya corrects something, the map changes and so does the next meeting's purpose; when she contradicts a hypothesis, the hypothesis goes, not the correction. Guidance such as GOV.UK's stakeholder research is a model for finding out about responsibilities and context, but it is public-service research practice, not a sales methodology.

Further reading

• Show the Work a Customer Must Do to Adopt the Product — If the map shows an implementation dependency with no owner, this splits the transition into supplier and customer work and names who must decide access, information, and exceptions.
• Make a Sales Deck Travel Beyond Its Internal Champion — Before you prepare anything for readers who were not on the call, this separates forwarding, evaluating, and authorizing so the deck carries the context each reader needs.