Your kickoff questions decide what you're really building

“Can customers book online?” sounds like one feature. It could mean a link to an existing booking service, a request that someone confirms by email, or a checkout that reserves a place immediately. A website discovery questionnaire should expose those differences before you estimate or design the site.

Start with decisions. You need to know what the website must accomplish, who it’s for, what happens after a visitor acts, and which constraints shape the work. A list of preferred colors won’t answer any of that.

What is a website discovery questionnaire?

It’s a set of questions you use to define the project before building it. The output is an agreed direction: the visitor you prioritize, the action you support, the pages and functions you need, and the responsibilities on each side.

Use it during early scoping, then confirm unresolved answers at kickoff. If you’ve already signed a proposal, discovery should make its assumptions explicit; a newly requested function needs a scope discussion before it enters the build.

Discovery and content collection have different jobs. Discovery asks whether workshop booking belongs on the site. Content collection asks for the workshop descriptions, dates, photos, and policies once that decision is settled. Send the website content questionnaire after you’ve agreed what those answers will support.

Copy this website discovery questionnaire

Treat the following as a question bank for a small business website. Remove irrelevant questions and prefill confirmed answers from your sales conversation. You can paste the selected sections into an email, shared document, or form.

Put this introduction above them:

These questions help us agree what your website needs to do before we design it. Short answers are enough. For a feature, describe what you expect a visitor to do and what should happen afterward. Mark anything undecided so we can discuss it at kickoff. We’re establishing the project direction here; we’ll request page text and images separately.

Name the person completing it and the date you need their answers. Keep the first pass focused on choices the client can make without consulting every colleague. Use the meeting for the answers that need discussion.

Business goals and success

1. What changed in your business that makes this website project necessary now?
2. What is the most important outcome the new site should support?
3. What should a visitor do to produce that outcome: inquire, book, buy, visit, apply, or something else?
4. How do you handle that action today, and where does it break down?
5. What evidence would tell you the new site is helping? Do you have a current baseline?

Ask for a priority. “More sales, better hiring, and a stronger brand” names three ambitions without telling you which should shape the homepage. Follow up with: “If we could improve only one of these at launch, which would you choose?”

For measurement, distinguish an observed starting point from a target. A client can want more bookings without knowing how many the current site generates. Record the missing baseline and who will establish it; don’t turn a guess into a promised result.

Audience and visitor decisions

1. Who is the primary visitor you want this site to serve?
2. What situation brings that person to you?
3. What must they understand before taking the main action?
4. What usually stops them from taking it?
5. Are there other visitor groups that need a different route through the site?

Replace demographic shorthand with a task. “Adults aged 25 to 55” doesn’t tell you whether the visitor wants a first pottery lesson or a private workshop for their colleagues. Those visitors need different details and may need different booking routes.

Ask the client where this knowledge comes from: customer conversations, inquiry emails, sales records, or an assumption. The answer tells you what you can design around now and what still needs checking.

Offers, pages, and launch scope

1. Which offers must the website support at launch, in priority order?
2. Which pages or sections do you expect, and what should each help a visitor decide?
3. Which offers, audiences, or locations are outside this project’s scope?
4. What existing content should stay, change, or disappear?
5. What could wait until a later phase without preventing the main visitor action?

Don’t treat the requested sitemap as settled merely because it arrived in a spreadsheet. Ask why each page exists. A separate page may be justified by a distinct offer or audience; another may duplicate information already available elsewhere.

For a redesign, have the client point to important existing pages and links that people still use. Record migration needs before replacing the site. You don’t need a full content inventory in this questionnaire, but you do need to know whether preserving material is part of the work.

Features and what happens after a click

1. Which actions need more than a standard page or contact form?
2. For each action, what does the visitor submit, choose, receive, or pay for?
3. What should happen immediately afterward, and what does your team do manually?
4. Which existing systems must the website connect to? Who manages them?
5. What happens when the preferred action isn’t available, such as a full workshop or an unanswered inquiry?

Use this small worksheet for every feature that affects the estimate:

Feature	Visitor action	Immediate result	Staff responsibility	Existing system
[Feature name]	[What the person does]	[What they see or receive]	[Who handles the next step]	[System name or undecided]

“Booking” is a label. The filled row is a requirement you can investigate. If the client already uses a booking service, inspect the actual account and available connection before promising an integration. A link, an embedded flow, and a custom connection are different amounts of work.

Ask for the system name and account owner here. Arrange access through the appropriate invitation process rather than requesting passwords in the questionnaire.

Design direction and brand constraints

1. What should a visitor understand or feel about the business after viewing the site?
2. Which existing brand elements must stay, and which can change?
3. Share up to two reference websites. For each, name a specific element you like and why it would help your visitors.
4. What should the design avoid?
5. Are there audience needs or accessibility requirements we should account for from the start?

A reference needs a reason. “I like this site” could refer to its photography, short navigation, or expensive animation. Ask which part matters before treating the entire site as a direction.

Keep preferences tied to the job. A calm visual style may suit a beginner choosing a class, while a complicated animated introduction may delay the timetable they came to find. Discovery gives you a basis for discussing that tradeoff before presenting designs.

Content, ownership, and ongoing updates

1. What usable material already exists, and where is it kept?
2. Who supplies business facts, who writes the page copy, and who approves it?
3. Are new photos, translations, or other content services needed?
4. Who will update the website after launch, and what will they change most often?
5. Who owns the domain, hosting, and connected accounts today?

Establish responsibilities here. Don’t ask for every service description or staff biography yet. Once the sitemap is confirmed, the page-by-page website content template turns those responsibilities into specific collection requests.

The update question can change the implementation. A studio that changes class dates every week needs a different handoff from a business that updates its address once a year. Describe the client’s editing tasks before deciding what controls to provide.

Budget, timing, and approval

1. What budget or approved range is available for this project? Does it include content work and ongoing service costs?
2. Is there a required launch date? What event makes it fixed?
3. Which client-side decisions or deliveries could affect that date?
4. Who can approve scope, design, and launch? Name the decision-maker for each.
5. Who gathers feedback, and when can the approvers review work?

A date without a dependency is only a preference. An advertised class opening may create a real deadline, but you still need time for content, approval, and testing before it.

If budget and required scope don’t fit, reduce the launch scope or revisit the budget before design. A questionnaire can’t resolve that tradeoff on its own. It can expose it while you still have choices.

How do answers become a usable project brief?

Imagine a fictional ceramics studio asking for “a modern website with online booking.” Its owner wants weekend classes to fill and assumes private group bookings should use the same flow. This is a worked example, not a client case study.

Your follow-up reveals that public classes have 8 places and fixed dates. Private groups require the owner to check instructor availability before quoting. One flow would either make public classes unnecessarily manual or promise private bookings the studio can’t yet confirm.

Write down the resulting decisions:

Discovery answer	Decision to confirm
Public classes have fixed dates and limited places.	Provide a route to reserve a dated class through the studio’s existing booking service, subject to checking that service.
Private events need availability checks and a quote.	Use a separate inquiry route with no immediate reservation promise.
The owner changes class dates weekly.	Confirm which timetable information lives in the booking service and who updates the website.
The client mentions a future ceramics shop.	Exclude product sales from this launch; revisit them as a separate phase.

Send this interpretation back. The raw questionnaire is useful input, but the confirmed brief is what your team can estimate and build against. Include the goal, priority audience, launch scope, exclusions, dependencies, and owners.

For an undecided item, record a next action rather than silently choosing an answer. “Owner to confirm the booking account’s capabilities before the estimate is finalized” is actionable. “Booking TBD” doesn’t identify who moves it forward.

Should clients fill it out alone or answer on a call?

Send the factual parts ahead of time: existing website, systems, reference links, budget range, and decision-makers. Discuss competing priorities and ambiguous features together. Reading the form aloud from beginning to end uses meeting time without resolving much.

This matches the emphasis in Three Seven’s discovery question bank: the conversation behind an answer matters alongside the answer itself. Use the form to find where that conversation is needed.

At the end of kickoff, read back the consequential choices. Can a visitor reserve a place immediately? Is the shop excluded? Who approves the first design? Then request written confirmation of the brief and any unresolved dependencies.

You’re ready to begin when those answers describe the same project to both sides. Only then should you start the content collection process that fills it.