Why Should Every Discovery Call End With a Written Recap?

Why should every discovery call end with a written recap?

Because a discovery call only becomes useful once both sides agree on what was said. A short written recap confirms the problem, the goals, the constraints, and the next step. It catches misunderstandings while they are cheap to fix, and it gives the client something to forward to the people who were not on the call.

I have delivered more than 100 projects for over 25 clients across more than six years. If I had to pick one habit I would tell any consultant or founder to adopt before their next sales conversation, it would be this one. It takes a short while after each call, and it is the cheapest insurance against a project starting on the wrong foot.

This is not a sales trick. It is the simplest way I know to make sure I am solving the problem the client actually has, not the one I assumed they had.

What is a discovery call recap?

A discovery call recap is a short email or document sent after the first serious conversation with a potential client. It restates their problem in my words, lists what they want to achieve, notes any limits like budget or timing, and proposes a clear next step. The client then confirms or corrects it.

It is not meeting minutes. Minutes record everything. A recap records what matters for the decision. If something came up that does not affect the project, it does not go in.

It is also not a proposal. A proposal comes later, after the recap is confirmed. Sending a proposal before the problem is agreed is how scope arguments start.

What should a discovery call recap include?

A good recap covers five things in plain language: the problem as I understood it, what success looks like for them, the constraints I heard, the open questions I still have, and the next step with a date. Keep it short enough to read on a phone in under two minutes.

The problem statement is the most important part. Write it the way you would explain it to someone who was not there. If you cannot write it in two or three sentences, you probably did not understand it well enough, so say that in the open questions.

Success is the second most important. Try to write it as something both sides could check later. "More demo requests from the right companies" is better than "a better website." It is also the line that anchors everything you scope afterward.

Why not just rely on call notes or a recording?

Notes and recordings capture what was said, but they do not confirm that both sides understood it the same way. A recap is an active step. It asks the client to agree. That confirmation is the whole point, and a recording sitting in a folder never asks for it.

Recordings are useful when clients agree to them. But nobody rewatches a forty-minute call to check a detail. A one-page recap is something people actually read.

There is also a difference between hearing and understanding. A client might say "we need a new site," when what they mean is "our leads go nowhere after the form." The recap is where I write down which one I think they meant, and give them a chance to correct me.

How does a recap help the client?

It gives the client a clear summary they can share internally. Most buying decisions involve someone who was not on the call, such as a cofounder, a manager, or finance. A good recap lets my contact explain the project to them without having to translate my thinking from memory.

This matters more than people expect. My contact is often my champion. If they struggle to explain what was discussed, the project stalls. A recap does part of their job for them.

It also shows them how I work. A clear, honest recap is a small preview of how I will keep them informed during the project. Clients notice when the first thing they receive is careful and specific.

How does it help me decide whether to take the project?

Writing the recap forces me to look honestly at fit. If the problem is outside what I do well, or the constraints make a good result unlikely, that becomes obvious once I write it down. Sometimes the right next step in a recap is to say the project is not a fit.

I have written about how I decide whether to take a project outside my stack. The recap is often where that decision becomes clear. A vague problem stays vague in my head. On the page, the gaps show.

Saying no in a recap is kinder than saying no after a proposal. The client has spent less time, and I can often point them to a better option while the conversation is still fresh.

How does the recap shape scope and pricing?

The confirmed recap becomes the foundation for the proposal. My pricing is fixed-fee, with most projects between $1,000 and $10,000, so scope has to be clear before I quote. The recap is where scope starts. If something is not in the confirmed recap, it is not in the quote by default.

Fixed-fee pricing only works when both sides agree on what is included. The recap creates that agreement early, in plain language, before any numbers appear. That makes the proposal conversation about price and timing, not about what the project even is.

It also protects the client. If they later want something new, both sides can look back at the recap and decide whether it is a change. That is a calmer conversation than arguing over what someone remembers saying on a call weeks ago.

What mistakes make a recap useless?

The common mistakes are writing too much, sending it days later, using jargon the client did not use, and skipping the next step. A recap that is long, late, or vague does not get read or confirmed. Then it is just another email, not an agreement.

Speed matters most. Send the recap the same day if you can. The call is fresh for both sides, and the client is more likely to reply with corrections while they still remember the details.

Language matters too. If the client called it "the lead problem," call it that, not "inbound conversion optimization." Using their words shows I listened, and makes it easier for them to share.

Should a recap be long or short?

Short and precise beats long and thorough. The temptation is to prove you listened by writing everything down. A better way to prove it is to write less, but more exactly. A client who can confirm a recap in two minutes will confirm it. One who has to read three pages will put it off.

Keep the confirmed recap somewhere you can find it later, alongside the project. A written record of project decisions matters for the same reason, which I described in why I keep a written record of every project decision. The recap is simply the first entry in that record.

The reason never changes. A project goes well when both sides start from the same understanding, and a short written recap is the cheapest way to get there.

What should you do next?

After your next discovery call, send a short recap the same day. Cover the problem in plain words, what success looks like, the constraints, your open questions, and one clear next step with a date. Ask the client to confirm or correct it, and keep the confirmed version with the project.

Try it on your next three calls. You will probably catch at least one misunderstanding you would have missed.

If you are planning a website or automation project and want to start with a clear, written understanding of the problem, reach out. A clear recap of your problem is where I would want to start. Let's chat.