Process7 min read
The discovery call I run before every project
A good first conversation is not a sales call with questions in it. Here is the structure I use, the questions that consistently earn their place, and the answers that tell me to walk away.
Most bad web projects were already bad before anyone opened a design tool. The brief was a list of pages, the budget was a number nobody had tested against the scope, and the actual business problem was never stated out loud. Almost all of that is preventable in a single well-run hour.
I run the same structure every time. It takes about sixty minutes, I take notes rather than slides, and I do not show any work until the end, if at all.
Start with the business, not the website
The first twenty minutes never mention the site. I want to know how the business actually makes money, where enquiries come from today, which of those are worth having, and what happens to one after it arrives. A surprising number of website problems turn out to be follow-up problems, and it is better for everyone if that surfaces now.
- Who is the customer you would happily take ten more of this year?
- Where did the last five good enquiries come from, honestly?
- What do people ask you before they commit, every single time?
- What do you lose work to, and is it price, trust, or being harder to deal with than the alternative?
Then the site, framed as a cost
Only once the business is clear do I ask about the existing site, and I ask about it as a liability rather than an aesthetic. What is it currently failing to do? Which page do people leave from? What do you find yourself explaining on the phone that the site should have explained already? Nobody redesigns a site because it is old. They redesign it because it is costing them something they can name.
If a client cannot describe what the current site costs them, the new one has no target to hit and no way to be judged a success.
Constraints, out loud, early
Then the unromantic part: budget range, deadline and why that deadline exists, who has to approve the work, who will write the copy, and who will maintain the site in a year. That last question decides more of the technical approach than any other, and it is the one most likely to have never been considered.
I say my number in the call. Not a proposal to be sent later, a range said out loud while we are both still in the conversation. If it is wrong for them, we find that out in minute forty rather than after I have spent two days writing a document.
The answers that end the call politely
Some answers tell me to decline, and declining early is a favour to both parties. A client who cannot name a decision maker will not be able to approve anything. A client whose deadline is fixed but whose content has not been started is describing a delay that will later be characterised as my fault. And a client who wants the site to look like a specific competitor, exactly, is not buying design work, they are buying a copy, and I am the wrong person for it.
Everything else is workable. Small budgets are workable if the scope shrinks to match. Tight deadlines are workable if the decisions are fast. Vague ideas are extremely workable, because that is the part of the job I am supposed to be good at.
Written by Philipp Roth
Owner of KOMUNIQUE — Web Design Agency