The discovery call: ask before you pitch

A first call that opens with a pitch talks about the seller: hundreds of tutors, an AI practice partner, flexible schedules, reports for HR. The buyer has nothing of their own to react to, so the easiest polite exit is "send me something to read". It sounds friendly; it usually means goodbye.

The rehearsal with Pavlo showed it. After a minute of features, the seller knew nothing about Veloria: not the problem, not who pays, not the timing. Pavlo knew a lot about Klasna and had no reason to continue.

More features or an early price make the same mistake louder. What's missing isn't information about Klasna; it's information about Veloria.

So the first call is not a presentation. It's a conversation in which the buyer talks most of the time, about their own work, and the seller earns the right to propose something later.

A discovery call is mostly asking and listening, and how you ask decides what you learn. The habit from the Customer Development course applies here too: ask about real past events, not opinions about the future, and don't hint at the answer you hope for.

"Would your team like better English?" gets a yes from everyone and tells you nothing. It's hypothetical (it costs nothing to say yes), and it's leading (the polite answer is obvious).

Compare: "Tell me about the last time an English call went wrong." It asks for a fact. The answer shows whether the problem exists, how it shows up and who it touches, and it opens follow-ups about cost and frequency.

Other weak forms to avoid: "Wouldn't our program have prevented that?" (leading), "Is English a big problem for you?" (opinion), and any question that already contains your pitch.

The goal of a discovery call is to learn whether there's a real deal. Use the four questions you use to qualify any deal, plus one about the buying process:

1. Is there a problem worth paying to solve? Ask for a recent incident, then its cost in money or time.
2. Who pays? "If you decided to do this, whose budget would it come from?"
3. By when? Look for a date from the buyer's own calendar, such as a budget deadline.
4. What happens next? What the buyer will do after the call.
5. How does the company buy? "Before a decision, who else would want to see it?" maps the committee and the steps.

Each question targets one unknown, so you can tell after the call what you know and what you still need. At Veloria, one call found the problem, the approver, the budget date and two more people in the process; the cost in money became a question for the next step.

When a buyer describes a real incident, the temptation is to jump in: "Our program would fix that!" Resist it. The first story is the start of understanding, not the end.

Pavlo described a dispatcher who misunderstood a Polish carrier about a delivery window: the truck waited at the border for hours, Veloria paid a penalty, and the client complained to Stepan. Good follow-ups stay on facts:

• What happened next? How did the team handle the next call with that carrier?
• How often does something like this happen? ("A couple of times a month," says Stepan.)
• Who knows what it costs? (Yaryna, the finance director.)

Each answer shows how the team copes today, which is what any solution must beat, and who else cares. Leading questions ("Wouldn't our program have prevented that?"), opinion questions and an early price list all cut the story short just when it gets useful.

Timing in a B2B deal should come from the buyer's own process, not from the seller.

Pavlo mentioned that Veloria's 2027 budgets close in mid-December. That's a real date: if the program isn't in the budget by then, it likely waits a year. It shapes every next step, from the sample lesson to the proposal.

Other real dates: a current supplier's contract end and its notice period, a planned start of a new team, the date of a board meeting that approves spending.

An invented deadline ("this price is valid until Friday") is different. It pressures the buyer with something they can see through, and a finance director who notices it starts doubting everything else you say.

So listen for dates and write them down, ask about them directly ("When do budgets for next year close?"), and plan backwards from them.

Halfway through a discovery call, take stock: what has the call established, and what is still a guess? Writing it down keeps you from assuming the deal is further along than it is.

At Veloria, the call established:

• a real problem: a carrier misunderstanding led to a penalty and a client complaint, a couple of times a month;
• the approver: a program this size needs Yaryna's approval; small courses come from Pavlo's budget;
• a real date: 2027 budgets close in mid-December;
• the process: Stepan (shifts) and IT security (any new app) will want to see it.

Not established: the cost of the problem in money. Pavlo pointed to Yaryna for that, so it becomes a question for the next step. And nobody has agreed to buy anything.

Mixing the two lists is how pipelines start to lie: a friendly call gets marked as "almost won" when only half the facts are in.

Calls often end with "This was useful. Send me a proposal and I'll pass it around." It feels like progress, but a proposal now would be priced before you know what the problem costs, and passed around without you.

A real next step moves the decision and has three parts:

• a date;
• names: who will be there;
• an action on the buyer's side, not only yours.

At Veloria: "Could we show a sample lesson built on a carrier call to you and Stepan in the first week of December, and ask IT for their questionnaire now? Then the proposal can reflect what you need before budgets close." Pavlo agreed to check Stepan's week and forward IT's contact the same day.

If a buyer won't commit to any step with a date and their own action, that's information too: the deal may not be real yet.

A discovery call has a simple shape that keeps it from turning into a pitch:

1. Agree the purpose and the time: "We have thirty minutes; I'd like to understand your situation first."
2. A recent real example of the problem.
3. Its cost and frequency.
4. Money, timing and people: who pays, by when, who else is involved.
5. Sum up what you heard, so misunderstandings surface now.
6. Agree a dated next step that both sides own.

Each step builds on the one before: cost only makes sense once there's a concrete incident, and the money question lands better once the cost is on the table. The summary is the step people skip, and it's the one that catches "I thought you said Stepan approves".

How it fits together: ask instead of pitching, about past facts, find the problem, payer, date and process, then a dated next step. Next lesson: the demo for Pavlo and Stepan, and a shared plan from a sample lesson to a signature.