Case: map Veloria's buying committee

When a prospect asks for a proposal, the person asking is rarely the only one who decides. Pavlo asked, and in the same breath named three more people who can stop the deal: Yaryna, the finance director, who will want numbers; Stepan, the operations director, whose dispatchers are already stretched; and IT security, which checks any app first. Add the forty employees who would actually take the lessons.

Before writing anything, give each person four lines: role, fear, what they need to see, what you don't know. Start from fear, because in a company purchase saying no rarely gets anyone in trouble. Pavlo fears backing a program people drop after a month; Yaryna, a running cost with no visible result; Stepan, dispatchers pulled off shifts at busy hours; IT security, employee data in an unapproved tool; the learners, being tested and exposed in front of colleagues.

Each fear follows from the person's job. Treat the map as hypotheses to check in the meeting, not as facts.

On a committee map, a guess written down soon starts to look like a fact, and then nobody asks the question any more. Yaryna wants numbers, so it's tempting to write her in as the economic buyer. But at Veloria, training money might sit with HR, with operations, or need Yaryna's sign-off above some amount. Wanting numbers shows she has a say; it doesn't show the budget is hers.

So write "budget owner: unknown" and find out. The way to find out, as with any committee question, is to ask about a past purchase rather than about authority: "When Veloria last bought team training, how was it approved, and who was involved?" A past purchase is easier to describe and more accurate than a hypothetical, and it doesn't make Pavlo feel tested.

A map with honest question marks shows exactly what the first meeting has to achieve. A map that guesses everything looks confident and is wrong somewhere you can't see.

The questions for a first meeting should come straight from the blanks on your map. Good ones ask about the past and the present, because people describe what happened more accurately than what they would do.

For Veloria, each unknown has its question:

• Budget owner: "When Veloria last bought training for a team, how was it approved, and who was involved?"
• Yaryna's numbers: "What happens today when a dispatcher can't handle a call with a foreign carrier?" The answer is the cost of the problem.
• Success: "What would Yaryna need to see to call a first stage a success?"
• Stepan's shifts: "Which shifts and times could the 40 people realistically spare for lessons?"

Three kinds of question waste the meeting. Asking Pavlo whether he signs or needs his boss puts him on the spot. A leading question ("Would you agree our program would save money?") gets a polite yes that means nothing. A deadline ("Sign by Friday and lock in this year's price") is pressure, not information, and tells you nothing about who decides.

The IT security check is one of the checks that most often stalls a deal late, because it usually starts after everyone else has agreed. At Veloria, Pavlo said any app needs a security check first, so it belongs on the map from day one.

Two moves help. Ask for the security questionnaire early, ideally right after the first meeting, so it runs alongside the other conversations instead of after them. And answer plainly: what employee data Klasna keeps, where it's stored, for how long, and who can see it. A short, factual answer is easier for an IT lead to approve than a long, reassuring one.

The tempting shortcut is to say "we're fully secure" so the check won't slow things down. It does the opposite: an IT lead hears a claim nobody can verify, and the first precise question exposes it. Never promise what you can't show. Being exact about the limits, such as what Klasna doesn't store, builds more trust than a blanket guarantee.

The most common first-meeting mistake is pitching to the one person who already wants to buy. A plan built around Pavlo alone brings proof nobody asked for, skips the budget question and pushes the things that stall deals to the end.

Look at a typical draft: thank Pavlo, show twelve slides on tutors, reviews and the AI practice partner, send the full price for all forty people and ask for a signature this month, leave the IT check until after the contract. It has nothing for Yaryna's numbers, Stepan's shifts or IT's data questions, and no question about who decides.

Proof must fit a fear on the map: Yaryna needs a success measure agreed up front, Stepan a schedule around shifts, IT security plain facts about data. Be honest about what you can't prove yet: Klasna's Teams clients are smaller offices, none in logistics. That is what a pilot is for: one group, a few weeks, measures agreed with Pavlo and Yaryna in advance and a joint decision date. It lowers the buyer's risk without a big bet.

Pavlo is the champion: he will argue for Klasna in rooms you never enter. That makes him your most valuable contact, and the easiest one to lose. The rule is simple: make his job easier and never go around him.

In practice: ask Pavlo whom to invite to the meeting rather than deciding yourself. Don't email Yaryna or Stepan from contacts found elsewhere; reaching other people at Veloria is his call. If he says only he will come, that's fine for a first meeting. Leave him a one-page summary he can forward, with a line for each of the others: the success measure for Yaryna, the schedule question for Stepan, the data answer for IT security.

Pushing him to bring his boss can cost you the champion. It tells him you see him as an obstacle on the way to the "real" buyer, and it may embarrass him inside his company. A forwardable page does the opposite: it lets him carry the case and look well prepared doing it.

Preparing for a first meeting with a company runs in a fixed order, because each step needs the one before it:

1. List everyone the contact mentioned and their role in the decision.
2. For each person, write their fear, what they need to see and what you don't know.
3. Pick proof that answers each fear, and note what you can't prove yet.
4. Sketch a small, time-boxed pilot to test what the proof can't show.
5. Write the questions that close the biggest unknowns, starting with how such a purchase gets approved.
6. Send the contact a short agenda and ask whom they'd like to invite.

Proof chosen before the fears are written down ends up answering nobody's worry. A pilot designed before you know what proof is missing tests the wrong thing. Questions written before the map is drafted miss the real blanks. And the agenda goes out last, built from everything above, with the guest list left to the champion. For Veloria, this order turns Pavlo's single request into a plan for five people.

Price matters in every B2B deal, but timing changes what it means. Klasna's list price is 800 UAH a lesson. Attached to a first note, before anyone has agreed what the program covers or what success looks like, it invites Yaryna's no before she knows what the money buys. A number with no scope is easy to reject and hard to defend.

That's not a reason to hide it. If Pavlo asks for a figure, give it plainly, with what it covers. Being open about price is honest; leading with it is just early. The first note to Pavlo has a different job: make his work easier and ask one thing you truly need to know, such as how the last training purchase was approved.

How it fits together: in this module you learned that a company buys as a committee, that the situation sets what it compares you with, and that proof and pilots lower each person's risk; this case put all three on one page. The next module asks which companies are worth that effort at all.