A promising contact may understand the problem and like your work, yet still be unable to approve a project. Another person owns the budget, a team must accept the solution, and procurement may need to review the terms. If you discover this after sending a detailed proposal, you can spend weeks revising a document for people you have never met.

A buyer decision map is a short working note about who is involved and what must happen next. It is not an organizational chart and it should never be used to pressure your contact. Its purpose is to decide how much pursuit effort is justified and what information would help the client make a sound choice.

Key takeaways

• Identify the people who experience the problem, sponsor the work, approve spend, and review risk.

• Ask what each person needs to see before a decision can be made.

• Confirm the decision event and timeline instead of inferring them from enthusiasm.

• Choose a conversation or scoped diagnostic when a full proposal would rest on missing information.

• Update the map as you learn; do not treat a first contact’s account as complete.

Start with the decision, not the org chart

Ask your contact what decision the organization is trying to make. Is it choosing whether to fund a project, selecting between approaches, comparing providers, or approving a specific statement of work? Those are different stages. A client may be ready to discuss the problem but not yet ready to buy an implementation.

Then ask what would make the decision possible. The buyer may need a business case, a technical review, a small proof of concept, an internal priority shift, or clarity about timing. Your next step should produce that missing evidence. A polished proposal is useful only when it addresses the current decision.

Identify the roles around the work

The problem owner feels the cost of the current situation and can describe what a good outcome would change. The users will live with the result and may know practical constraints the sponsor cannot see. The sponsor is willing to advocate for the work internally. The budget approver can commit money or authorize the purchasing route. A reviewer may assess security, legal terms, technical fit, or procurement requirements.

One person can hold several roles, especially in a small organization. In a larger one, the roles may be spread across teams. Do not assume a job title tells you who actually decides. Ask how this type of purchase is normally approved and who would need to be comfortable with the result.

Keep the map lightweight. A private note with roles, names if known, decision criteria, open questions, and the next interaction is enough. Avoid collecting personal details that do not help the work. If you are introduced through a recruiter or agency, be clear about who represents whom and what direct access is permitted.

Ask questions that respect your contact

You can learn the process without asking, “Are you the decision-maker?” That question can sound dismissive of a useful champion. Try: “Who else will use or approve the result?” “What concerns are likely to come up when this is reviewed?” “How have similar projects been approved?” “Would it help to include the team that will own the handoff?”

These questions give your contact a way to help. They also reveal whether the opportunity is funded, exploratory, or blocked. If the contact cannot answer yet, record the uncertainty instead of interpreting it as disinterest. A legitimate project can have a messy decision path; what matters is whether there is a plausible way to resolve it.

Match your evidence to the audience

Different participants may need different proof. A problem owner may want a clear approach and evidence that you understand the operational pain. Users may need confidence that the work fits their workflow. A technical reviewer may need boundaries around systems and data. A budget approver may need options, cost, timing, and consequences of delay.

You do not need a separate pitch deck for each person. A concise proposal can explain the problem, method, deliverables, dependencies, fee, and decision requested. But you may need to gather input from several roles before that proposal is accurate. Our guide to qualifying an inbound lead can help with the earlier fit conversation.

Find the decision event

Ask what will happen after you send the next piece of information. Is there a committee meeting, budget review, vendor comparison, or sponsor conversation? Who will present the proposal, and will you be available for questions? What would count as a yes, a no, or a request for revision?

If there is no decision event, propose a smaller next step. For example: “Before I draft the full implementation plan, could we meet with the reporting owner and the person approving the budget? I can then send a scope that reflects both the need and the purchasing path.” If that meeting is not possible, you can send a short concept note or an indicative range, clearly marked as preliminary.

Decide how much to invest

Your map should inform your own pursuit decision. Strong problem fit and a responsive sponsor may justify a focused exploratory call. A funded project with access to the right people may justify a detailed proposal. A vague request with no owner, no timetable, and no route to approval may belong in a follow-up list rather than your immediate proposal queue.

Avoid turning the map into a rigid score. A small company can decide quickly but still have unclear scope. A large organization can have several reviewers yet be ready to act. Use the roles and decision event to choose the next useful action, then update the map from what actually happens.

Before you invest in another meeting, write a one-sentence next-step test: “If the sponsor can introduce the budget approver and confirm the project window, I will prepare a scoped proposal.” Share the test with your contact in more natural language and agree on when to revisit it. This creates a fair checkpoint for both sides. If the introduction or timing cannot be confirmed, you can keep the relationship warm without reserving delivery capacity for work that has not been authorized. If the test is met, you know exactly what the proposal needs to address.

SmartBid can help you review opportunities and track pursuit decisions across sources. Add the buyer’s decision path to that judgment: the right project is one you can deliver well and one the client can actually authorize.