A client onboarding questionnaire is the structured intake document that captures project scope, business context, decision authority, and success metrics before work begins. Done right, it reduces scope creep, aligns expectations, and gives your team everything needed to start without a dozen clarifying emails.
Start with questions that position the project inside the client's broader reality. Ask what they do, who they serve, and what prompted this project now rather than six months ago. The timing question matters because urgency shapes scope. A rebrand ahead of a trade show has different constraints than one driven by a gradual market shift.
Include a question about their main competitors and how they currently differentiate. Clients rarely volunteer this unprompted, but it surfaces whether they see themselves as premium, volume-focused, or niche. Ask about internal stakeholders who will weigh in. A three-person startup answers to founders; a municipal agency might involve elected officials, department heads, and procurement. Knowing the approval chain early prevents bottlenecks when you need sign-off on creative direction or technical architecture.
Finish this section by asking what success looks like in plain language, separate from formal KPIs. The qualitative answer often reveals priorities that metrics alone miss—like executive confidence in presenting the new site to the board, or internal team buy-in on a content calendar.
This section exists to draw hard lines. List the deliverables you anticipate based on the intake call, then ask the client to confirm, add, or remove items. Be explicit about format and ownership: are they getting layered design files, or exported PNGs? Do they expect staging environment access, or just the final migration?
Ask what they already have that you will use or integrate with. Existing brand guidelines, a content library, analytics historical data, or a CRM integration all affect scope. If they mention assets you will inherit, ask about format and access. A logo provided as a low-resolution JPG embedded in a Word doc is not the same as a vector file.
Include a question about what is explicitly out of scope. Clients often assume ongoing support, minor updates, or training are included when your proposal covers build only. Naming exclusions in the questionnaire lets you reference this shared understanding if scope discussions arise later. For agencies working across Canada, clarify whether bilingual execution is in scope or monolingual with translation as a separate phase.
Ask who has final approval authority on creative, technical, and budget decisions. In many organizations, these are three different people. The marketing director might approve messaging, IT approves hosting and integrations, and finance approves any budget changes. Map this early.
Find out how long their internal review cycles typically take. A corporate client with legal and compliance review might need two weeks for a single round of feedback. A founder-led company might turn around revisions in 24 hours. Build this into your timeline assumptions rather than discovering it when the first milestone stalls.
Ask if there are blackout periods when key stakeholders are unavailable—fiscal year-end, annual conferences, holiday shutdowns. For government or education clients, budget cycles and academic calendars create hard deadlines. Knowing these upfront prevents scheduling a major deliverable review during a period when nobody can respond. If the client is subject to procurement rules or requires formal change-order processes, surface that here so your contract structure accommodates it.
Ask what metrics they currently track and what the baseline numbers are. If the goal is to increase organic traffic, knowing they get 1,200 visits per month versus 45,000 changes the strategy and the definition of a meaningful lift. If they do not track anything yet, that is useful information—it means you need to establish measurement infrastructure as part of the project.
Include a question about how they will measure ROI internally. Some clients need hard revenue attribution; others care about lead volume, brand awareness, or operational efficiency. Understanding their internal reporting requirements helps you structure dashboards and milestone reporting in a format their executive team actually uses.
Ask about timeline drivers beyond preference. Is there a product launch, a regulatory deadline, a lease expiration, or a funding round that creates a hard constraint? Distinguish between preferred timelines and immovable dates. A client who wants to launch in Q2 but has no external forcing function can flex if discovery uncovers complexity. A client presenting to investors in eight weeks cannot. If they express budget flexibility contingent on timeline, capture that tradeoff explicitly so you can reference it when scoping phases.
Ask what platforms, tools, and systems the final deliverable needs to connect with. A website might need to integrate with their CRM, email platform, payment processor, or inventory system. Each integration adds scope and introduces dependencies on third-party APIs and access permissions.
Find out about their current hosting environment and whether they have technical staff in-house. A client on managed WordPress hosting with no developer has different support needs than one running a custom stack with a full IT department. If they expect you to handle hosting, clarify whether they want you to manage it ongoing or hand off credentials post-launch.
For Canadian clients, ask about data residency requirements. Some organizations, especially in healthcare, finance, or government sectors, require Canadian data hosting to comply with provincial privacy laws. Others need bilingual admin interfaces if staff in Quebec will manage content. Clarifying these requirements in the questionnaire prevents expensive rework when technical constraints surface during build.
Once the client submits the questionnaire, compile their answers into a summary document and send it back for confirmation. Frame it as a mutual understanding check, not a formality. This step catches misalignments before you write a proposal. If your summary describes a five-page site and they expect twelve, better to resolve that now.
Use the questionnaire output to structure your proposal sections. Their stated goals become your objectives section. Their success metrics inform your reporting plan. Their approval workflow shapes your milestone structure and timeline buffers. The questionnaire is not a separate artifact—it is the foundation your entire project plan builds on.
Reference specific questionnaire answers in kickoff meetings and milestone reviews. When scope questions arise, point back to the documented understanding. If the client requests something outside the agreed deliverables, the questionnaire provides a neutral reference point for discussing change orders. Treat it as a living document that evolves with the project, not a form you file away after intake. Update it if major assumptions change, and use the revised version to keep everyone aligned as the project progresses.
Length depends on project complexity, but most effective questionnaires land between 15 and 30 questions. A simple website refresh might need fewer; a full rebrand with technical integrations needs more. Prioritize open-ended questions over yes-no checkboxes—they surface assumptions and context you would not think to ask for. If the questionnaire feels too long, break it into phases: send business and scope questions first, then technical and timeline details after initial alignment.
Send it after the initial call but before you write a proposal. The call gives you enough context to customize which questions matter for this client. The questionnaire captures details in writing that are easy to misremember from conversation. It also signals to the client that you run a structured process, which builds confidence. If they are hesitant to invest time before seeing a proposal, offer a shorter intake version and expand it once they commit.
Follow up directly on skipped or unclear responses before proceeding. Vague answers often indicate the client has not thought through that aspect yet, which is valuable information. You can offer to workshop those areas together, or flag them as decision points that need resolution before certain milestones. Do not assume or fill in blanks yourself—ambiguity in the questionnaire becomes scope conflict later. If they consistently avoid detail, it may signal readiness issues worth addressing before engagement.
Treat conflicts as clarification opportunities, not gotchas. Bring the discrepancy to the client neutrally and ask which reflects their current thinking. People often revise priorities between conversations and written responses as they think things through. Use the conflict to confirm which version is accurate, then update all documentation to match. This habit prevents misalignment from compounding as the project progresses and creates a clear record if expectations shift mid-project.
Add questions about bilingual requirements, provincial compliance context, and data residency if the client operates in regulated sectors or serves Quebec markets. Ask about preferred currency for invoicing and whether they need HST or GST details structured a certain way for their accounting. For government or institutional clients, include questions about procurement processes, accessibility standards like WCAG compliance, and any mandated Canadian content or supplier preferences that might affect vendor selection or hosting decisions.
Review it after every few projects to identify questions that consistently need follow-up or ones clients always skip. Add questions when you encounter a new scope issue that better intake would have prevented. Remove or reword questions that generate answers you never reference. A questionnaire is a diagnostic tool—it should evolve as you learn which information actually predicts project success and which questions just add friction without value. Quarterly review cycles work well for most agencies.