Stakeholder map for deal strategy

Use this workflow before a material customer meeting, forecast review, or proposal decision. It gives account executives and deal leaders one shared view of who matters, what evidence supports that view, and where to spend the team’s time next.

The aim is not a fuller account summary. It is a decision: which relationships need attention before the next meeting, and who owns each action.

1. Set the decision and the review date

Start with the opportunity, not the account. Write these fields at the top of a working document:

• Opportunity: name, CRM link or identifier, current stage and target decision date.
• Decision sought: what the customer must approve, fund, sign, or change.
• Next meeting: date, attendees and purpose.
• Deal-team decision: the specific choice you will make after mapping stakeholders. For example, whether to pursue executive sponsorship, repair a relationship with security, or pause proposal work.

Set a review date, usually the next meaningful customer interaction. A stakeholder map without a date becomes a historical contact list.

2. Gather evidence in one input pack

Collect information from four places. Do not ask the model to infer missing facts from a vague CRM summary.

1. Export or copy the relevant CRM notes: opportunity history, contacts, stage changes, risks, next steps and closed-lost history if relevant.
2. Add meeting records from the current opportunity: attendee lists, call notes, recordings or transcripts, action items and objections. Label each meeting with its date.
3. Add public account information that is relevant to the opportunity: company priorities, leadership changes, reporting lines, announcements, job postings or published strategy. Include the source and date beside each item.
4. Add the current deal position: your proposed outcome, commercial shape, known alternatives, agreed success measures and open questions.

Remove unrelated personal data and internal commentary that the deal team does not need. Keep the source with each claim. A statement such as “Operations is under pressure to reduce manual work” is useful only if the map can point to a meeting note, public statement, or named owner.

If you are uploading files or using connected data, check the current handling and product options in the xAI documentation overview. These can be version-dependent.

3. Build the first stakeholder table

Ask the model you are using to extract people and claims into a table. Give it the input pack and this instruction:

Create a stakeholder map for this opportunity. Use only the supplied material. For each person, separate evidence from inference. Do not invent reporting lines, budget authority, support level, or meeting attendance. Flag conflicts between sources and list missing information.

Use these columns in the output. Keep one row per person, not one row per meeting.

Field	What to record
Person and role	Name, job title, function and organisation
Deal role	Economic buyer, champion, blocker, evaluator, user, legal or procurement contact, executive sponsor, or unknown
Evidence	Dated source, short supporting detail and confidence: high, medium or low
Position	Supportive, neutral, opposed, unknown, or mixed
Influence	What they can approve, prevent, shape or introduce
Relationship	Direct, team relationship, executive relationship, or no known route
Next action	Owner, contact method, purpose and due date

Use unknown freely. It is more useful than a confident but unsupported label.

A champion is not merely a friendly contact. Look for evidence that they spend political capital, share internal process detail, introduce you to decision-makers, or help move a customer action forward. An economic buyer is the person who can make or secure the spending decision, not simply the most senior attendee.

4. Find gaps that can change the deal

Review the table with the deal team. Focus on missing relationships that could delay, block, or redirect the decision. Ask these questions in order:

1. Who can release or protect the budget, and have you tested that assumption?
2. Who gains from the proposed change, and have they taken an observable action to support it?
3. Which function can block progress, such as security, finance, procurement, legal, operations or a technical owner?
4. Whose evaluation criteria are still unknown?
5. Are all customer relationships held by one seller or one contact? If so, where is the relationship risk?
6. Which stakeholder must be involved before the next meeting can produce a decision?

Do not solve every gap with another introductory call. Match the action to the missing evidence. You may need a champion to explain the approval path, a technical peer meeting to test feasibility, or an executive message that asks for the right sponsor.

If you see this	Treat it as	Next contact action
No confirmed budget owner	Economic buyer gap	Ask the champion who owns the business case and what approval is required
Supportive user, no senior route	Champion limit	Ask for an introduction tied to a customer outcome, not a generic executive meeting
Security raised late	Blocker risk	Arrange a scoped technical discussion before proposal commitments
Several contradictory notes	Evidence conflict	Ask the account owner to verify the fact in the next customer conversation

5. Turn the map into a pre-meeting plan

End the review by selecting no more than three actions before the next meeting. Each action needs one owner and one testable outcome.

Write them in this format:

• Owner: person on your deal team.
• Contact: named customer stakeholder or role.
• Action: the message, request or meeting to arrange.
• Purpose: the evidence you need to obtain or the risk you need to reduce.
• Done when: an observable result, such as a confirmed approver, an accepted technical session, or a stated evaluation criterion.

For example: Owner: AE. Contact: Operations director. Action: ask the champion for an introduction before Thursday. Purpose: confirm who owns the operational business case. Done when: the director confirms whether they sponsor the initiative and names the approval route.

Then make the deal-team decision in one sentence: Spend time on executive sponsorship before drafting the proposal, because budget ownership is unconfirmed and the current champion cannot verify the approval path.

6. Check where the map is wrong

A map is wrong when it presents assumptions as facts, misses a person with veto power, or assigns actions that do not answer the biggest uncertainty. Check it before acting.

Look for these warning signs:

• The same person is labelled economic buyer, champion and technical evaluator with no separate evidence.
• Every influential contact is described as supportive, but meeting notes contain objections or delays.
• The only evidence is old CRM text, with nothing from recent conversations.
• Contact actions say “follow up” rather than naming the person, question and intended result.
• The next meeting includes users but not the person who owns the decision or evaluation process.

Ask a deal-team colleague to challenge the three most important labels: economic buyer, champion and blocker. They should ask, “What did this person do or say that proves the role?” Update the map after each customer interaction, especially when attendance, timing, budget, success criteria or process changes.

When the workflow does not work

If the output is vague, reduce the input pack to the current opportunity and ask for a table with dated evidence only. If roles are still uncertain, do not ask for stronger predictions. Make “confirm role and approval path” the next customer action.

If the team cannot agree on the map, record the disagreement as an evidence conflict, assign one owner to test it, and avoid committing more proposal or executive time until the result is known. The useful outcome is not certainty. It is a clear, shared choice about the next best use of deal-team effort.