Client Communication: Discovery Call Framework

A structured discovery call uncovers what clients actually need, surfaces scope risk early, and sets every web project up for an on-time delivery.

Published 7 min read
Fredy RodriguezFredy Rodriguez
Two ceramic coffee cups and a blank notepad with a pen on a clean meeting table — evoking a structured client discovery conversation before a web project begins
Table of Contents

A web project that goes sideways rarely falls apart during design or development. It falls apart in the first conversation, when both sides walked away with different pictures of what was being built.

The web design discovery call is where those pictures either align or diverge. Run it well and you have a shared foundation for everything that follows. Run it loosely and you are managing misaligned expectations from week one.

Why a web design discovery call makes or breaks projects

Most project overruns trace back to a gap in understanding, not a gap in execution. A client assumed the site would include a booking system. The agency assumed it was a five-page brochure. Neither assumption got spoken out loud until work was already underway.

A structured discovery call closes those gaps before they cost anyone time or money. It is the highest-value hour a web team invests in the entire project cycle.

Clients who feel genuinely heard in the first conversation are more patient through revisions and more trusting of recommendations when the project gets complicated.

What a discovery call is (and what it is not)

A discovery call is a diagnostic session. Its goal is to understand the client’s business well enough to propose the right solution, not to pitch.

It is not a sales call. The difference is intent: a sales call is built around persuasion; a discovery call is built around listening. If you are talking more than you are listening, you are running a sales call.

It is also not the project kickoff. Discovery happens before a proposal is written. The kickoff happens after the proposal is signed. Conflating the two produces proposals built on incomplete information.

Before the call: prepare so the time counts

Research the client’s existing site and market

Spend 15 minutes reviewing the client’s current site, their Google Business Profile, and two or three competitors before the call. That preparation saves the conversation from covering ground you could have handled on your own.

In Houston, a contractor in the Energy Corridor operates in a different context than a restaurant in Montrose. Pre-call research lets you ask sharper questions and signal that you understand the client’s world.

Send a short pre-call questionnaire

A four to six question form, sent 24 hours in advance, gives clients time to think rather than improvise. Cover the essentials: primary goal for the new site, what is frustrating about the current one, the timeline, and who approves the final design.

You also catch early scope signals this way. A client who lists seven “primary goals” and a six-week timeline needs a realistic conversation before the call even starts.

The questions that surface real requirements

Business goals and how you will measure success

“What do you want the site to do?” is too broad. Ask instead: “In 90 days, what would have to be true for you to call this project a success?” That framing produces a specific, measurable answer rather than a vague aspiration.

Follow with: “How are you currently tracking that?” Clients who have never thought about measurement cannot evaluate the project’s success, which makes scope creep more likely.

Problems with the existing site or setup

“What is frustrating you about the current site?” surfaces the real pain. The follow-up, “Walk me through what happens when a new visitor lands on your site today,” often reveals problems clients did not know how to describe.

This is also where you learn what has been tried before. If a client rebuilt the site 18 months ago and is already unhappy, understanding why tells you more than any brief.

Technical integrations and constraints

Ask: “What third-party tools does your business rely on, and which ones need to connect to the new site?” Booking systems, CRMs, payment processors, and marketing automation tools all have integration implications. Discovering a required integration after a proposal is signed is one of the most common scope-creep triggers on web projects.

At Desque, this question regularly surfaces connections the client assumed were obvious (a niche scheduling tool, a custom inventory feed) that would have been missed without asking directly.

Budget range and timeline reality

Clients often deflect on budget, but getting a range early protects both sides. Try: “We work across a range of investments. Can you share a ballpark so I can make sure what we propose is realistic?” Most clients will give a range even if they resist naming a number.

Timeline should be anchored to a real event. “When do you need this live, and why that date?” A deadline tied to a trade show is very different from a client who “wants it soon.”

Decision-maker map

Ask who else needs to approve the final design and whether anyone’s feedback could change the direction significantly. Finding out on week three that a co-founder has strong opinions about the logo is avoidable. Map the approvers before the proposal is written.

Listening for what is not said

The most important discovery signals are not always direct answers. They are how clients respond.

A client who hedges every budget question (“we’ll figure it out as we go”) is signaling either genuine uncertainty or reluctance to commit. Both require a follow-up conversation before a proposal is written.

A client who mentions a previous agency relationship that “did not work out” without specifics may have expectations that differ from yours. Ask: “What would you have done differently?” That answer tells you more about how they will engage throughout the project than any formal brief.

When requirements conflict (a complex custom build, a four-week timeline, a budget that suggests a template), name the tension directly in the call. Resolving it there is far less costly than during revisions.

The motion-giraffx project shows why this matters: a thorough discovery conversation revealed operational constraints not in the original brief that shaped the entire build. The Costa Custom Pools project is another example, where discovery surfaced the client’s lead-generation workflow and informed the site’s page structure and contact flow.

After the call: document and confirm shared understanding

Within 24 hours, send the client a written summary: their goals, the problems they want solved, the constraints you noted, and any open questions. Ask them to confirm it is accurate.

Four to six bullets is enough. The goal is confirmation, not a comprehensive brief. This step catches misalignment before it becomes a proposal built on wrong assumptions, and it creates a record both sides can reference when scope questions come up later.

What comes next

Discovery findings feed directly into the project proposal: scope, deliverables, timeline, and investment. A proposal written without discovery is a guess. A proposal written after it is grounded in what the client actually needs.

Up next in this series: how to turn discovery findings into a proposal that protects both sides.

Our web design service page explains how we structure the first conversation and what follows. For more on why the trust built in these early conversations shapes the entire engagement, this post on trust and web design is worth reading first. The discipline of listening before proposing also connects to UX research methods, where the same approach applies before designing.

Ready to run your own discovery call? Start with ours.


Frequently asked questions

What is a discovery call for web design?

A discovery call is a structured conversation between a web design agency and a prospective client that happens before any proposal is written. Its purpose is to understand the client’s business goals, uncover problems with their current setup, map technical constraints, and confirm that both sides have a realistic shared understanding of scope, budget, and timeline.

What questions should I ask during a web design discovery call?

Focus on four areas: business goals (what does success look like in 90 days?), existing site problems (what is frustrating you right now?), technical constraints (what third-party tools must connect to the new site?), and project logistics (who has final sign-off, and what is the realistic timeline?). These four categories surface what you need to write an accurate proposal.

How long should a web design discovery call last?

For most small to mid-size projects, 30 to 45 minutes is sufficient. Complex projects with multiple stakeholders or integrations may run to 60 minutes. Anything longer usually signals insufficient preparation on one side or both.

What happens after a web design discovery call?

The agency sends a written summary of key findings, asks the client to confirm it is accurate, then uses that summary to build a project proposal covering scope, deliverables, timeline, and investment. Part 2 of this series explains how to turn those findings into a proposal that protects both sides.

Share this postTwitter / XLinkedInBluesky
Fredy Rodriguez
Fredy Rodriguez

Technical Director & Co-Founder

Runs the data-and-code side of Desque: SEO, GEO, AEO, PPC, copywriting, and the engineering behind every site we ship. Builds in Go and TypeScript.

Continue in series: Client Communication