Updated September 2026: this 2019 post described starting an opportunity with a delivery contact I had not worked with before, beginning with the questionnaire to send to the client, which he reviewed and added to. I have rewritten it into a guide to writing a good client questionnaire at the start of a proposal.
The first step on every opportunity was a questionnaire to the client, and I had a ready-made set. I shared the first draft with the new delivery contact, who was happy with it and added a couple of questions. He was calm, in control and supportive when needed, which made the start easy.
Why does the questionnaire matter so much?
Because the answers set the scope, assumptions and price of everything that follows. Questions not asked become assumptions, and assumptions become disputes later. A good questionnaire is the cheapest risk reduction in the whole proposal.
What should a client questionnaire cover?
- Scope: processes, locations, users and systems in scope, and what is explicitly out.
- Current state: existing systems, versions, integrations and known pain points.
- Volumes: transactions, records, users and growth expectations.
- Constraints: timelines, budgets, compliance and technology preferences.
- Decision process: who evaluates, the criteria and the dates.
How do you keep it manageable for the client?
Prioritise. Clients answer twenty sharp questions far better than eighty generic ones. Group questions by topic, number them, and explain briefly why the less obvious ones matter. Remove anything already answered in the RFP.
How should you use a standard questionnaire?
As a starting point. Tailor it to the client's industry and the RFP, and let the delivery team add questions from their experience, as my new colleague did. A reused questionnaire that has not been tailored tells the client you did not read their document.
When should the questionnaire go out?
As early as the RFP rules allow. Many RFPs set a deadline for clarification questions, sometimes within the first week. Missing it means working on assumptions for the whole response, so put the question deadline in the plan on day one.
What if answers do not come back in time?
Document the assumptions you will make for each unanswered question and include them in the proposal. It protects both sides and often prompts the client to answer the questions that matter.