A good discovery call ends with a page of notes that the person building your site can still trust three weeks later. A bad one ends with a recording nobody replays and a vague feeling that everyone agreed. If you want discovery call notes for a website project that survive the build, write them as decisions, not as a transcript.
This is for owners and managers who sit on the client side of the table, and for anyone running the call. The format works the same either way.
What should discovery call notes for a website actually contain?
Six things: the goal, the audience, the constraints, what is out of scope, who decides, and what is still open. Anything else is color. If a note does not change what gets built, what gets left out or who signs off, cut it.
Write the goal as one sentence with a verb in it. “Get more people to request a quote from the Denver service area” is a goal. “Modernize our online presence” is a mood. The sentence is what you will hold up in week four when someone suggests a photo carousel that does not serve it.
The audience line is just as short. Name the one or two kinds of visitor who matter most and what each one needs to do on the site. A homeowner who wants to know if you cover their zip code needs a different first screen than a facilities manager comparing three vendors.
How do you capture constraints before they turn into surprises?
Ask about the boring things on purpose. Budget range, launch date, who has to approve copy, which tools the site must connect to. Then ask what already exists: the domain, the hosting account, the old site, the logo files, the photos. People rarely volunteer these because they do not seem like design questions, and they cause most of the delays.
Write each constraint with its source. “Launch before the March trade show (owner)” is more useful than “tight timeline”, because when the date slips, you know whom to ask. If the budget is a ceiling and not a target, say that in the notes. Our piece on how a website budget takes shape covers how to set that range before the call.
One habit pays off every time: capture the unpleasant facts while everyone is still polite. The old developer who has not returned your emails, the plugin license nobody can find, the legal text that must stay word for word. Those belong in the notes, with a name next to each one.
Why does the out-of-scope list matter more than the wish list?
Because the wish list grows by itself and the out-of-scope list never does unless somebody writes it. Scope creep rarely arrives as a big demand. It shows up as “while you’re in there, could we also add a members area?” in the middle of a sprint.
Keep a short list titled “Not in this project” and read it back at the end of the call. Typical entries: blog migration, e-commerce, multilingual pages, a booking system, rewriting every service description. Anything on that list can still happen later, as its own piece of work with its own estimate. The point is that nobody discovers it was excluded after the invoice arrives.
Next to it, keep an “open questions” list with an owner and a date for each item. If the answer is “client to confirm which email handles form submissions by Friday,” the build can proceed around it. If the question has no owner, it will still be open at launch.
What does the format look like, and who gets the copy?
Half a page is enough. Use the same headings every time so a second person can find things: Goal, Audience, Constraints, Not in this project, Decisions, Open questions, Access needed. Under Decisions, write what was decided, who decided it and the date. Under Access, list the logins and accounts you need. That way the end of the project does not turn into a hunt. The handoff checklist for DNS, CMS and analytics is a good starting point for that last section.
Send the notes within a day, while the call is fresh, and ask for corrections by a stated time. Silence counts as agreement only if you said so in the email. Then pin the notes where the whole team can find them. Whoever builds the site should open them first when a question comes up mid-build. You can see where that fits in how a project runs from first call to launch.
What to do next
- Write the goal as one sentence with a verb.
- List constraints with the person who set each one.
- Read the “Not in this project” list aloud before hanging up.
- Give every open question an owner and a date.
- Send the notes the same day and ask for corrections.
If your last project drifted and nobody can say when, start with the notes from that call. Whatever is missing from them is where the drift began.