Discovery Call Checklist

When to use this

• You have a discovery call coming up and want a calm, repeatable structure.
• You want discovery calls to produce clear scope and next steps (not endless talking).

How to use this checklist

A discovery call is a decision-making call. The goal is not to impress the client with ideas. The goal is to leave with enough clarity to do one of these things confidently:

• write a scoped proposal/SOW,
• propose a smaller paid first step, or
• say no (briefly, professionally) and move on.

Use the interactive checklist in the preview as a repeatable operating procedure. Check items off as you go. Your progress is stored locally in your browser, so you can refresh the page and come back later. When you want to reuse it in your own docs, use "Copy as Markdown".

It focuses on the handful of answers that decide everything downstream: what the client actually wants, what constraints shape the work, and what the next step is.

Quick start (how to use the preview)

Use the interactive preview like a cockpit checklist. Check items off live, and treat missing answers as risk.

1. Open the interactive preview and keep it visible during the call. Your progress will be saved locally in your browser.
2. Use the checklist to pace the call. If the conversation drifts into brainstorming, bring it back to constraints and decision-making.
3. Write down clean answers, not your interpretation. Specific notes today become safe scope tomorrow.

After the call, use "Copy as Markdown" to paste your checked items into your notes, tracker/CRM, or follow-up draft.

Before the call (prep)

Prep is not about a perfect plan. It is about keeping the call calm and avoiding free consulting: confirm who is involved, set a clear timebox, request inputs you need, and decide how deep you will go on solutions.

1) Confirm attendees and who the decision-maker is (or will be)

You cannot close a discovery call without a decision-maker, a decision process, or a path to one. If the buyer is not on the call, surface that early.

Useful questions (email or calendar reply):

• Who will be on the call, and what role does each person play in the decision?
• If the decision-maker cannot attend, what is the plan to get their input and approval?

2) Send a short agenda, timebox, and what "done" means

If you want a ready-to-use notes structure, pair this checklist with the Discovery Call Agenda. Paste that agenda into your notes doc before you join.

What "done" means for a discovery call:

• you understand the trigger (why now) and stakes,
• you define success in 30/60/90 days (outcomes),
• you capture constraints you can price (timeline, access, approvals),
• you agree on next step, owner, and decision date.

When you send the agenda, include one sentence that protects the end of the call: "We'll close by agreeing on the next step and decision timeline."

3) Request any materials you need

Discovery is faster when you can look at real artifacts. Request only what is relevant to the work:

• links, docs, or existing drafts
• an access list (what systems you might need access to)

4) Prep 3 core questions: trigger, success (30/60/90), constraints

These are the minimum inputs you need to scope safely.

• Trigger (why now): What prompted this conversation? What changed? What is at stake?
• Success (30/60/90): What outcomes do they want, and what changes if you succeed?
• Constraints: What limits the work (timeline, budget range, stakeholders, approvals, access, compliance)?

You can ask dozens of questions, but if these three are fuzzy, your scope will be fuzzy.

5) Decide your boundary: diagnose clearly, don't design the solution for free

The boundary is the line between "helpful" and "unpaid work". You can be generous with clarity without producing deliverables. Your job on discovery is diagnosis: map the situation, name constraints, and propose a safe next step.

If you tend to over-deliver in calls, decide your depth ahead of time. For example: you can outline options and tradeoffs, but you will not draft the full plan, write implementation details, or produce a spec live.

6) Open a notes doc and paste your agenda template

Clean notes let you write scope that matches what was said. Use a consistent structure every time.

If you do not already have one, start with the Discovery Call Agenda (notes template). Your notes doc becomes your source of truth when you write a proposal or a Statement of Work.

On the call (questions + notes)

The goal on the call is clarity: what is happening, what matters, what is constrained, and what the next step should be.

1) Start with a frame

A frame sets agenda, timebox, permission to interrupt, and what happens next.

2) Ask what prompted this now (the trigger and stakes)

The trigger tells you why this is happening now.

Questions that fit this checklist item:

• What prompted this conversation now?
• What happens if you do nothing for the next 90 days?

Notes to capture: the trigger in plain language, who is feeling it, and what cost of delay looks like for them.

3) Define success in 30/60/90 days (outcomes, not tasks)

Success defines the shape of phase 1. If the client can only describe tasks ("we need a redesign"), help them translate it into an outcome ("we need X to be true after the redesign").

Questions that get to outcomes:

• What does success look like in 30/60/90 days?
• What is different when this is working?

Notes to capture: outcomes, non-goals, and what "done" means for phase 1 versus a longer-term vision.

4) Map the current state

The current state is where you stop guessing. You want the concrete version of the story: what happens today, where it breaks, and what the team does to work around it.

Questions that make answers concrete:

• What happens today? Walk me through it step by step.
• What is the current workaround, and why does it fail?

Notes to capture: the real workflow (not the ideal one), systems/tools involved, owners, and the failure points that will drive scope.

5) Capture constraints: timeline, budget range, stakeholders, approvals, access, compliance

Constraints decide the project more than ideas do. If you skip them, you will quote a "thing" and discover the real work after you start.

Capture constraints in these buckets:

• Timeline: deadlines and what drives them.
• Budget range: a range is enough for alignment.
• Stakeholders: who is involved and who approves.
• Approvals: what needs approval and when.
• Access: what you can access today vs later.
• Compliance: requirements that shape tools and review.

Notes to capture: the constraints themselves and the "waiting risks" (access and approvals) that can stall delivery if you do not plan for them.

6) Confirm phase 1 scope and boundaries (what's in, what's out, and what's a change request)

You do not need perfect scope on the call. You do need enough clarity to name what is included, what is excluded, and what becomes a change request.

If you want a repeatable way to handle "just one more thing," keep these tools nearby:

• Scope Change Checklist (process the request without awkwardness)
• Change Request Addendum Pack (price scope changes in writing)

7) Agree on the next step (proposal/SOW vs paid phase 1), plus decision timeline and owner

Do not end a discovery call with "I'll send something over." That is how deals stall. End with a decision about what happens next, who owns it, and when the decision will be made.

The clean next steps are usually one of these:

• Proposal/SOW: you have enough clarity to scope and price the work.
• Paid phase 1: uncertainty is still high, so you propose a smaller paid step (audit, roadmap, prototype) to de-risk the larger project.
• No: there is a mismatch you cannot price or do not want to accept.

Notes to capture: which path you agreed to, who is responsible for the decision, and the date you will follow up.

After the call (recap + next step)

The follow-up is where discovery turns into work. Send a clean recap, confirm constraints, and propose the next step you can stand behind.

1) Send a recap the same day

Send a recap while the conversation is still fresh. Keep it short and decision-oriented.

A simple recap structure:

• Goal: success in 30/60/90 days.
• Current state: what breaks today.
• Constraints: timeline, access/approvals, compliance, budget range (if shared).
• Next step: proposal/SOW or paid phase 1.
• Decision: owner and decision date.

If you used the interactive preview, "Copy as Markdown" is a fast way to reuse your checked items as the skeleton of this recap.

2) Log notes and schedule the follow-up date immediately

Capture notes in your tracker/CRM and schedule the follow-up while you still have momentum.

3) Pick the pricing model based on uncertainty

Pick the pricing model based on uncertainty. If the scope is still unclear, propose a paid phase 1 instead of pricing the whole unknown.

This is where the Rate Calculator becomes useful: it gives you floor math and anchors so you are not guessing under pressure.

If you want the deeper explanation behind risk pricing in discovery, read how to set freelance rates.

4) Draft the SOW/proposal, send it, and set a calendar reminder to follow up

When you have enough clarity to scope, write it down while your notes are fresh. If you do not have enough clarity, propose a paid phase 1 instead of pricing the whole unknown.

To turn discovery notes into scope boundaries, use the Quote to SOW Checklist and then draft your doc from the Statement of Work (SOW) Template.

Set a calendar reminder for follow-up even if you think you will remember. Follow-up is part of the work.

What this checklist prevents

• Free consulting: you solve the problem live, but the client doesn't buy.
• Vague scope: you quote a "thing," then discover the real constraints after you start.
• Stalled deals: the call ends without a next step, decision timeline, or owner.

The checklist prevents these by forcing coverage: ask the hard questions (constraints), keep boundaries (no free design), and close the loop (next step + decision date).

Decision rules

• If uncertainty is high, propose a paid first phase (audit, roadmap, prototype) instead of guessing.
• If there is no clear decision-maker, treat it as a risk and price it (or decline).
• If the client won't discuss constraints (timeline, access, approvals), you don't have enough to scope safely.

If you want a clause-by-clause view of how scope boundaries, review windows, and payment terms protect you, read freelance contracts: the clauses that matter.

FAQ

What if the client wants solutions on the call?

Be helpful without doing unpaid delivery. Share high-level options and tradeoffs, but keep coming back to constraints and next steps. A clean line is: "I can outline approaches today, then I'll propose the right first phase once we confirm constraints."

What if they cannot share budget?

Treat it as a constraint and decide what you can still do safely. You can often proceed with ranges, a phased plan, or a smaller paid first step. The goal is alignment, not getting them to say a number.

What if the decision-maker is not on the call?

Do not ignore it. Ask what the approval path is and what the timeline looks like. If the path is unclear, treat it as risk: propose a smaller paid phase 1 or decline until the decision-maker can engage.

How do I turn this into a scoped SOW?

Use your notes to write outcome, deliverables, constraints, and scope boundaries. Then run the Quote to SOW Checklist and draft from the Statement of Work (SOW) Template.

Want the full system?

This checklist is the operational layer. For the maintained explanation behind it, read how to set freelance rates (discovery as risk pricing) and find clients without a huge audience.

For scope docs and change control, pair this with the Statement of Work (SOW) Template and Scope Change Checklist.

How to customize

1. Add 3-5 questions specific to your service and risk profile.
2. Define your boundary for depth (diagnose + outline, not build the full solution live).
3. Add a red flags section based on your past bad projects.

Related Codex pages