7 Questions to Ask Clients Before Starting a Project (That Most Kickoffs Miss)

The kickoff call felt great. The client laughed at your jokes, said "exactly" four times, and you hung up with three pages of notes and a signed proposal. Two weeks into the build, an email arrives from a name you have never seen. Subject line: "Some thoughts from our side." It turns out the person you have been talking to was never the one who decides.

Nobody messed up that call. You asked about goals, audience, timeline, budget. All the things every kickoff checklist tells you to ask. The trouble is that those questions cover the project as the client describes it, and projects rarely die from the part the client describes. They die from the parts nobody thought to mention: the second decision-maker, the CRM everything must feed into, the copy that will not be written until October.

This is a list of seven questions to ask clients before starting a project, built from projects that went sideways in very specific ways. For each one: why it matters, and what it costs when it gets skipped.

One distinction before we start. These are not the brief questions about audience and deliverables; the brief itself, and how to get a client to actually complete one, is covered in how to write a project brief clients actually fill out. The seven below sit underneath that document. They are about the conditions around the project, and they are the ones a form never surfaces on its own.

Why the standard kickoff list lets you down

Budget, audience, deadline, goals. Ask those four and you will get answers, the answers will be fine, and you will still get blindsided. Not because clients hide things. Because clients answer what you ask and almost nothing else.

A client knows their marketing manager just resigned and the replacement starts in week three of your build. They know the last agency quit halfway. They know the founder has strong opinions about photography. None of that feels like "project information" to them, so none of it comes up on the call. It comes up later, at the worst possible price.

The seven questions

In rough order of when they fit into a conversation. Phrase them in your own voice, but ask all seven.

1. 1"Why this project, and why now?" Every project has a trigger, and the trigger is the real brief. A "dated" website that suddenly needs replacing usually means something specific happened: a competitor relaunched, an investor asked awkward questions, a trade fair is coming in September. Skip this and you polish the wrong thing. I have watched a team spend two weeks refining a design system for a site whose actual job was to look credible to a handful of distributors at one event. The trigger also tells you which deadlines are real and which are preferences.
2. 2"Who else will have an opinion on this?" Not "who is the decision-maker". You already have a contact; this question is about everyone else. The head of sales who wants his product line on the homepage. The board member who forwards award-site links. The founder's brother who "does websites". Ask now and you can plan for those opinions. Skip it and they arrive in week nine, attached to a redesign request, carrying more authority than your contact ever mentioned.
3. 3"Who gives final sign-off, and what do they care about?" A different question from the last one. Opinions slow projects down; a veto kills them. Find out whether the person who approves the final invoice has seen anything yet: the proposal, the budget, a single screen. If the answer is "I'll show them when it's ready", stop and fix that before you start. The most expensive feedback in this business is a managing director seeing the work for the first time in the final week.
4. 4"What does this need to connect to?" Every business runs on a tangle of existing tools: a CRM, a booking system, a newsletter platform, a warehouse spreadsheet that is secretly the real database. Whatever you build has to live inside that tangle. Asked up front, an integration is an architecture input. Discovered in week six ("oh, and it needs to sync with HubSpot"), it reopens decisions you thought were closed, and the rework usually lands on your side of the invoice.
5. 5"What have you already tried, and what happened?" Almost no project is the first attempt. There was a previous agency, an internal redesign that stalled, a template someone bought and abandoned. The history tells you two things: what failure looks like to this client, and what baggage you are inheriting. A client whose last agency went quiet and then disappeared will read your first slow week as the beginning of the end. Better to know that before your first slow week.
6. 6"What does done look like to you?" If the answer is a feeling ("when it feels right", "when we're happy"), you do not have a finish line, you have a mood. Push gently for something observable: order enquiries arriving through the form, reception answering fewer calls, the sales team actually sending the new deck. Skip this and revision rounds never converge, because the project ends when the client's mood does. That can take a while.
7. 7"Who is producing the content, and by when?" The least glamorous question on the list and the best predictor of whether you ship on time. Copy, photography, product data, translations, legal pages: someone has to make all of it, and that someone is usually a client employee with a full-time job. Finished builds routinely sit for months waiting on an "About us" page. Get a name and a date for every asset, and treat a missing answer as the project risk it actually is.

You will notice budget is not on the list. Ask about it, obviously. It just does not belong with these seven, because clients expect the budget question and answer it readily. The seven above are the ones they never see coming.

Several of them are also scope questions wearing a disguise. The integration question and the done question in particular are where most scope gets silently set. If runaway scope is the problem that brought you here, the longer treatment is in how to prevent scope creep before the project starts.

The phrasing does half the work

A blunt question gets a polite, useless answer. The stakeholder question is the clearest example. Ask it the way most checklists phrase it and the client says no, because in their own mind they genuinely are the decision-maker.

Same information, different mechanics. The first asks the client to assess their own org chart on the spot, which nobody can do. The second runs a small simulation, and names fall out of it. Most of the seven benefit from the same trick: ask about a concrete future moment instead of an abstract category.

For sign-off: "Walk me through what happens between us delivering and the invoice being approved." For history: "Tell me about the last time you hired someone for work like this." Scenarios over categories, every time.

Where the answers end up

The answers only protect you if they get written down somewhere both sides can see. In a structured brief, each of these questions has a home. Here is a slice of one, filled in after exactly this kind of conversation with a fictional but very recognizable wine importer:

Notice how the answers landed. The why-now question became the goal. The sign-off question became a named person, a known preference, and a scheduled review. The content question became two open questions with owners and dates attached, instead of a surprise in week seven. If you want to see the full shape rather than a slice, there are three complete, filled-out project brief examples you can copy, covering a bakery site, a booking platform, and an internal tool.

Asking all seven, every time

Knowing the questions is the easy part. Asking all of them, on every project, while also building rapport, taking notes, and steering a client who wants to talk about fonts, is the hard part. On a good call you will cover five. On a rushed one, two.

This is the gap ReqBrief was built to close. Instead of relying on whoever runs the kickoff call to remember everything, you send the client a link and an AI interviews them one question at a time, before the project starts. It asks the unglamorous questions every single time, follows up on vague answers, and turns the conversation into a structured brief with the stakeholders, integrations, and success criteria already filled in. Your kickoff call then starts from the answers instead of hunting for them.

However you run it, the principle stands. The questions that save a project are the ones about everything around it. Ask them before you start, write the answers down, and the email from the name you have never seen becomes a paragraph in the brief instead of a surprise in week two.

Frequently asked questions