The questions we ask on every discovery call

A discovery call that just asks "tell me about your project" produces a proposal built on whatever the client happened to think to mention. We run a consistent set of specific questions on every call instead, each one designed to surface something that would otherwise only come up mid-project, when it's more expensive to address.

This question, more than any other, reveals the actual business pressure behind a project. A client who says nothing changes if the site doesn't get rebuilt has a very different urgency and risk profile than one who's actively losing deals to a competitor with a better site. The proposal, timeline, and even the launch strategy should differ accordingly.

This surfaces stakeholder structure early, before it becomes a mid-project surprise when someone senior sees the work for the first time in week six and has strong opinions nobody else on the project team anticipated. We ask this directly rather than assuming the person on the call has full authority.

Past failures are often more informative than stated preferences, since they reveal specific things a client is trying to avoid repeating, not just abstract goals. We ask this even for clients who've never worked with an agency before, since "what we tried in-house and abandoned" carries the same kind of signal.

A vague goal like "a better website" can't be measured against later. A specific number, a lead volume, a conversion rate, a booking count, gives both sides something concrete to actually evaluate the engagement against once it's live, rather than a subjective, after-the-fact judgment about whether it "feels" successful.

Beyond the single named decision-maker, we ask specifically whether legal, IT, or another department needs to approve anything, domain access, a data processing agreement, a security review, before work can actually begin. Surfacing this dependency in week one is far cheaper than discovering it the week we're meant to launch.

Every one of these questions is designed to surface something that would otherwise only come up as a mid-project surprise. Answering them upfront costs an extra fifteen minutes on the discovery call and reliably saves far more time than that later in the engagement.

A deadline tied to a genuine external event, a trade show, a funding announcement, a contractual obligation, is a real constraint we plan around seriously. A deadline that's really just "we'd like it soon" with no specific driver behind it has more flexibility than the client initially presents, and knowing the difference changes how we sequence and staff the work.

We've had more than one client initially present a deadline as immovable, only to reveal under a slightly more specific question that the actual hard constraint was several weeks later than the date first mentioned. Understanding the real driver behind a stated deadline, not just accepting the date at face value, often opens up scheduling flexibility that benefits the quality of the final work.

A project that needs to integrate with an existing CRM, an internal tool, or a legacy system the client didn't think to mention upfront can materially change scope once discovered mid-project. We ask this directly and specifically, listing common integration categories out loud, rather than leaving it as an open-ended question a client might not think to answer completely on their own.

Every answer from this call feeds directly into a specific section of the proposal that follows, not into generic boilerplate, so a client reading our proposal can see their own words and constraints reflected back in the plan we're recommending. That connection between what was said on the call and what appears in the proposal is itself part of what builds trust before any contract is signed.

We could collect most of these answers through a written intake form before the call, and for some questions we do, but the more revealing answers tend to come out through a live conversation where a follow-up question can pursue an interesting or ambiguous response in real time. A form gets you the stated answer; a conversation often gets you the reasoning behind it, which is usually the more useful part.

Every question on our current discovery list traces back to a specific past project where its absence caused a real problem later, and we keep adding to the list as new gaps surface rather than treating it as a finished, permanent set. This process of continuously refining the list based on real misses is, in a small way, the same discipline we recommend clients apply to their own onboarding and intake processes.

A client who's been through a thorough, specific discovery call with us often comments afterward that it was more useful than the conversations they'd had with other agencies bidding on the same project, and that impression, formed before any proposal even arrives, does real work in establishing the kind of thoroughness we bring to the actual project that follows.

Getting an honest answer about internal team dynamics, who actually disagrees with this project internally, whose support is genuine versus polite, remains the hardest thing to surface reliably in a first call, and we're still experimenting with how to ask it in a way that invites a genuinely candid answer rather than the diplomatic one most people default to with someone they've just met.