How to Run a Discovery Call for an AI Project

AI projects almost never fail on the model. They fail six weeks in, when the data that was described on the call as in the system turns out to be four spreadsheets, an inbox and one person's memory of how exceptions get handled.

A discovery call has one job: find that out before you quote. Everything else on the agenda below exists to get you to the five data questions with enough context that the answers mean something.

The 30 minute shape

Resist demonstrating anything. A demo in the first call moves the conversation to what the tool does and away from what they have, and what they have is the thing that decides whether this project is viable.

The five data questions

1. Where does this data live right now, and can you show me a screenshot of it? The screenshot is the question. In the system covers a database, a shared drive of PDFs and an email folder equally well, and those are three different projects.

2. How far back does it go, and did anything change about how it was recorded? A format change eighteen months ago means your usable history starts eighteen months ago.

3. Who decides what a correct answer looks like, and do two of them agree? If two experienced people label the same twenty cases differently, no model will resolve that, and the disagreement is the real project.

4. What happens today when the process hits something unusual? The exceptions are where the value is and where the effort is. A process that is 95% routine and 5% judgement is usually a 5% project by cost.

5. Who else has tried this, and what happened? A previous failed attempt is useful rather than disqualifying, as long as you find out about it now rather than in month two.

Ask for the screenshot on the call. People are consistently more optimistic about their data in conversation than in their own file explorer, and the gap between the two is the single most useful thing you will learn.

The answers that should worry you

• We can export it. Possibly true, and it means nobody has done it, so the shape and quality of that export are unknown to everyone including them.

• It is all in there, we just need to get it out. Usually describes unstructured text where the required fields exist as prose rather than as fields.

• We want it to be about 95% accurate. A number arrived at by feel. Ask what happens on the other 5% and whether anyone checks, and see whether an answer exists.

• Our situation is quite unique. Sometimes true. More often it means the exceptions have never been written down and live entirely with one person, who is usually not on the call.

• Legal will be fine with it. Verify separately, especially for anything touching personal data, hiring or money.

Qualifying the buyer, briefly

Three questions, and you can fold them into the last five minutes without it feeling like an interrogation: who else needs to say yes, what budget range this sits in, and what happens if they do nothing. The third is the informative one. If nothing bad happens when they do nothing, there is no deadline, and the project will drift regardless of how well it is scoped.

If the person on the call cannot approve spending, your goal for the call changes: you are now writing something they can forward, and writing the proposal afterwards has to survive being read without you in the room.

Closing the call

End with a specific next step and a date on it. Not I will send some thoughts. Something like: I will send a one page summary of what I heard by Thursday, including the two things I think are risky, and if that reads right we can talk about a scoped first phase.

The one page summary is worth more than it costs. It surfaces the misunderstanding while it is still free, and clients routinely correct something material in it. A scoped first phase is usually the right next step rather than a full build, which is what turning it into a paid pilot is for.

What to write down while they talk

Four things, in their words rather than yours. Paraphrasing during the call is how a scope disagreement gets built in on day one.

1. The sentence they use for the problem. It goes in the proposal verbatim, and it is what they will recognise as their own project when someone else reads it.

2. Every number they say out loud. Volumes, durations, headcount, error rates. Half will turn out to be estimates, and knowing which half is worth asking about later.

3. The exceptions, as a list. This becomes your scope boundary and the thing you point at when the fifth exception arrives in week three, which is the mechanism behind handling scope creep.

4. Anything they said they would check. These are the open risks, and following up on them is the cheapest credibility you will ever buy.

Pricing comes after, not during

If a number is asked for on the call, give a range with an explicit condition attached: projects of this shape usually land between X and Y, and which end depends on what the data turns out to look like. Then move on. A precise figure given before you have seen the data is a figure you will have to defend or retract.

The exception is a budget qualification, which runs the other way. Asking whether they are thinking in thousands or tens of thousands is not pricing, it is finding out whether the conversation has a future, and it is better asked in minute twenty-five than in week two. What to charge for the work covers the actual number once you have the facts.

One caveat worth raising on the call rather than in a contract: if the project touches personal data, hiring decisions or anything that affects individuals, the compliance work is part of the project rather than an afterthought. The ICO guidance on AI and data protection is a reasonable starting point for what that involves, and mentioning it early marks you out as someone who has done this before.

When to say no

Two answers should end it, politely, on the call. First, the data does not exist and building it is a bigger project than the one being discussed, unless you are willing to sell that project instead and they are willing to buy it. Second, nobody can define a correct answer. That is not a modelling problem and no amount of engineering fixes it.

Saying so early costs you one opportunity and buys a reputation for being straight, which is worth more over a year than one badly scoped engagement. Telling a client their idea will not work covers how to phrase it without losing the relationship.

Frequently asked questions

Should a discovery call be free?

The first 30 minutes, yes, for most independent practitioners. Anything that requires you to look at their actual data or produce a written assessment is paid work, and framing it that way early also filters out people who were never going to buy.

What if they arrive having already chosen the technology?

Take it as information rather than a constraint, and run the same agenda. If the data answers rule out their chosen approach, you have something concrete to point at, which is a much easier conversation than disagreeing about tools in the abstract.

How do I keep a discovery call from becoming free consulting?

Answer questions about the shape of a solution, not the specifics of theirs. What usually goes wrong with this kind of project is generous and costs nothing. Here is how I would structure your pipeline is the deliverable. The boundary matters later too, as handling scope creep sets out.

Can I send the questions in advance?

Send two or three, not all five. Advance notice on the data questions produces better answers because someone actually looks. Sending everything tends to produce a prepared written response that skips the hesitation, and the hesitation is a lot of the signal.