Turn a Signed Scope Into a Workable Client Kickoff

A signed agreement records what was sold.
A client onboarding questionnaire closes that gap. It collects and confirms the inputs that affect scope, priorities, ownership, timing, approvals, access, measurement, dependencies, and risk. It should not repeat the entire sales process, replace discussion, or invite a new list of deliverables. Its job is narrower: turn an agreed engagement into a workable plan.
The strongest questionnaire is selective. Prefill what sales already captured, ask the client to confirm delivery-critical assumptions, and remove questions whose answers will not change the work. Start with a concise core, then add only the service-specific modules relevant to the engagement.
What a client onboarding questionnaire is—and where it belongs
A client onboarding questionnaire is a structured intake sent to a new client to collect the business context, goals, expectations, preferences, stakeholders, and project information needed before substantive work begins. Typical topics include desired outcomes, decision-makers, dates, communication, assets, access, measurement, and foreseeable obstacles. This broadly matches Typeform’s description of an onboarding questionnaire template for gathering goals, expectations, communication preferences, and project details before work starts.
A common sequence is:
- Agreement signed or engagement confirmed.
- Welcome message sent and sales handoff completed.
- Known information transferred into the onboarding record.
- Questionnaire sent to the appropriate client stakeholders.
- Submission reviewed internally.
- Missing or contradictory answers clarified.
- Kickoff held to confirm consequential decisions.
- Tasks, access requests, milestones, reporting, and project workspaces created.
That sequence is a starting point, not a universal rule. A small consulting engagement might combine the questionnaire with kickoff. A complex implementation might use separate forms for operational, technical, finance, and legal stakeholders. A recurring service might maintain a shared onboarding document that continues to evolve.
The questionnaire should not be the first unexplained file a client receives after signing. Introduce it in a welcome message that explains what happens next, why the information is needed, who should respond, when it is due, and how to get help. Practitioner guidance on onboarding as a broader client-support system likewise places intake alongside a welcome message, process explanation, expectation setting, and access to personal support.
Onboarding is not the same as pre-sale discovery
A discovery or qualification form helps determine whether and how to sell the work. It may explore:
- The prospect’s problem and desired result
- Fit between the need and the provider’s expertise
- Budget or commercial viability
- Buying authority
- Possible solutions
- The scope and price to propose
An onboarding questionnaire supports a different decision: how to deliver work that has already been agreed. It confirms stakeholders, dates, review procedures, source materials, access needs, metrics, and other operating details.
A client discovery questionnaire, for example, is framed around understanding a prospective client’s business, goals, current situation, fit, budget, and service-scoping needs. Some topics overlap with onboarding, but the decision being made is different.
Terminology varies. One business may use “intake” for lead qualification, while another uses it for post-sale administration. Some providers collect delivery details during sales because implementation is highly standardized. The practical test is not the label:
Is this answer being used to decide whether and what to sell, or to organize work that has already been sold?
Do not make the client repeat the sales process
Avoid asking a new client to re-enter its legal name, website, contracted services, agreed fee, or known contacts simply because a blank template includes those fields. Transfer reliable information from the CRM, proposal, statement of work, sales notes, and relevant correspondence.
Avoiding duplication does not mean treating every sales note as final. Details may be incomplete, outdated, or understood differently by sales and delivery. Prefill consequential information and ask the client to confirm or correct it:
- “We have listed Priya Shah as the final approver. Please confirm or update.”
- “The signed scope identifies the UK launch as the priority. Is that still correct?”
- “The proposal lists 15 September as the preferred launch date. Is that fixed or flexible?”
- “We understand that your team will supply product photography. Please confirm.”
Treat the completed questionnaire as a documented source of planning inputs—not a guarantee of project success. As an internal project-control policy, route any answer that appears to change fees, deadlines, rights, or deliverables through the change procedure defined for the engagement. Contract interpretation depends on the applicable agreement and circumstances; Larping Agency’s terms notice similarly advises readers to review contracts and consult a professional about rights-related terms.
Design the questionnaire around decisions, not curiosity
Every field should pass a question-to-decision test:
What will the delivery team do differently based on this answer?
Keep a question if the answer affects at least one of these areas:
- Scope or priorities
- Scheduling or milestones
- Ownership or stakeholder involvement
- Review and approval
- Measurement or reporting
- Asset collection
- Account or platform access
- Dependencies
- Risk handling
If no one can identify the decision, task, or project artifact affected by the answer, remove the field. “Interesting to know” is not enough when the client must spend time supplying it.
Audit what you already know
Before drafting the questionnaire, compare possible fields with the CRM, proposal, contract, statement of work, sales notes, and recent emails. Label each field:
| Label | Use |
|---|---|
| Prefilled | The answer is known and reliable; display it instead of asking again. |
| Reconfirmed | An answer exists, but it is important enough to verify. |
| Newly requested | Sales did not collect it, and delivery needs it. |
| Conditional | It matters only for a selected service, platform, stakeholder, or risk. |
| Removed | It duplicates reliable information or will not influence delivery. |
This audit can also expose internal handoff problems. If sales repeatedly collects information that delivery cannot find, the answer may be a better handoff process rather than a longer client form.
Choose respondents by knowledge and authority
Send the questionnaire to someone who can provide reliable answers or coordinate the people who can. The contract signer is not always the person who understands daily operations, analytics, technical access, brand standards, or approval procedures.
For a complex client, route sections separately:
- Operational lead: workflow, responsibilities, and dependencies
- Marketing lead: audiences, channels, positioning, and performance
- Technical lead: systems, integrations, environments, and access
- Finance or procurement: purchase orders, expenses, and invoicing
- Legal or compliance contact: required review and escalation
- Executive sponsor: desired outcome and final priorities
Name one client-side person responsible for approving the consolidated response. Without that role, several individually reasonable submissions can become a conflicting set of instructions.
Make “required” mean required
Make a field mandatory only when its absence blocks planning or delivery. A primary contact may be required; a list of admired brands usually is not. A hard launch date may be essential for event work, while a long company history can remain optional.
Use conditional logic to preserve detail without showing every question to every client. If the client selects paid social, reveal media-account and spend-control fields. If it selects website migration, reveal hosting, domain, staging, and redirect questions. If legal review is a dependency, ask who owns it and how much lead time to reserve.
Recommendations to use approximately 10 to 15 core questions are practitioner heuristics rather than evidence-based limits. Rock, for example, recommends a compact core with targeted additions in its questionnaire guide, but relevance, complexity, and answer effort matter more than raw field count.
A practical structure is:
- A concise universal core
- Relevant conditional service modules
- An optional final comment
- A separately defined process for sensitive access or documents
Copy-ready client onboarding questionnaire: 15 core questions
This is an adaptable template, not a universal checklist. Prefill known information and remove any question that will not affect the engagement.
Copy-only version
- Who is the day-to-day contact for this engagement, and what is the best way to reach them?
- Who has final approval authority, and who else should be consulted or kept informed?
- Which subject-matter, technical, finance, legal, or compliance contacts may need to contribute?
- In two or three sentences, what does your organization provide, to whom, and why do customers choose it?
- Which audiences, products, services, markets, or offers are in scope for this engagement?
- What must be true at the end of this engagement for you to consider it successful?
- Which measures will indicate progress, where does the source data live, and who owns it?
- Which agreed deliverables or outcomes are essential, and which are secondary?
- Are there fixed launch dates, events, review periods, blackout dates, or dependencies we need to plan around?
- How will work be reviewed, who will consolidate feedback, and how much time should we allow for approval?
- Which channel and update cadence should we use, and what response time should each side plan for?
- Which existing brand files, research, documentation, examples, or prior work should we use, and where are they stored?
- Which platforms, accounts, tools, or environments will the team need to use, and who can grant access?
- What has or has not worked in similar work before, and are there requirements, claims, terminology, or boundaries we should know?
- What could delay, complicate, or derail the work?
Optional: Is there anything important that these questions did not cover?
Contacts and ownership
1. “Who is the day-to-day contact for this engagement, and what is the best way to reach them?”
Decision informed: Establishes who coordinates routine questions, meetings, files, and follow-ups. Ask for the person’s role as well as their name, and use structured choices for the preferred contact channel.
2. “Who has final approval authority, and who else should be consulted or kept informed?”
Decision informed: Maps decision rights and prevents feedback from being mistaken for final approval. Separate people who approve, contribute, and receive updates.
3. “Which subject-matter, technical, finance, legal, or compliance contacts may need to contribute?”
Decision informed: Identifies specialist dependencies before the team reaches a blocked review or implementation step. Reveal contact fields only for the stakeholder types selected.
Business context
4. “In two or three sentences, what does your organization provide, to whom, and why do customers choose it?”
Decision informed: Gives the team a concise, client-approved description of the business and audience. Prefill it from sales materials when possible and ask the client to confirm or correct it.
5. “Which audiences, products, services, markets, or offers are in scope for this engagement?”
Decision informed: Connects business context to the contracted work. This matters when the organization has multiple divisions, regions, offers, or customer groups but the engagement covers only some of them.
Outcomes and measurement
6. “What must be true at the end of this engagement for you to consider it successful?”
Decision informed: Establishes the outcome the client expects the work to support. Ask for something observable rather than only an aspiration such as “grow awareness” or “improve the website.”
Useful follow-ups include:
- What would be visibly different?
- Who would notice the change?
- Which business decision would this work enable?
- What is essential, and what would merely be desirable?
7. “Which measures will indicate progress, where does the source data live, and who owns it?”
Decision informed: Connects the desired outcome to a measurement plan, data source, and accountable owner. Include “not yet defined” as a valid response. An unresolved measure should become a kickoff topic rather than forcing the client to invent one.
Scope and priorities
8. “Which agreed deliverables or outcomes are essential, and which are secondary?”
Decision informed: Helps sequence work and resolve tradeoffs within the signed scope. Display the agreed deliverables so the client is prioritizing existing commitments rather than drafting a new wish list.
Add a project-control note:
Your response will help us plan the agreed work. Requests outside the recorded scope will be reviewed separately rather than added automatically.
Timing
9. “Are there fixed launch dates, events, review periods, blackout dates, or dependencies we need to plan around?”
Decision informed: Distinguishes genuine constraints from preferred dates. Ask the respondent to label each date as fixed, externally dependent, or flexible.
“We would like this in June” requires different planning from “This must launch before an external filing on 12 June” or “Our approver is unavailable for the last two weeks of June.”
Approvals
10. “How will work be reviewed, who will consolidate feedback, and how much time should we allow for approval?”
Decision informed: Defines the review workflow. The response should identify where work is submitted, who gathers comments, who resolves conflicts, who approves, and how much time the schedule should reserve.
“Everyone will comment in the document” is not a complete approval process. Ask who decides when comments disagree.
Communication
11. “Which channel and update cadence should we use, and what response time should each side plan for?”
Decision informed: Establishes a practical communication pattern. Offer realistic channel and cadence choices, then ask whether urgent issues need a different route.
Treat response time as an expectation-setting prompt, not an unconditional guarantee. Confirm the final arrangement against the agreement and each side’s stated availability.
Assets
12. “Which existing brand files, research, documentation, examples, or prior work should we use, and where are they stored?”
Decision informed: Creates the initial asset checklist and reveals what is available, missing, outdated, or awaiting approval. Allow approved uploads or links, and ask the client to label each folder or file rather than sending an unexplained archive.
Access
13. “Which platforms, accounts, tools, or environments will the team need to use, and who can grant access?”
Decision informed: Produces an access-request list with an accountable client-side owner. Ask for the platform, required role, access owner, and date needed.
Adopt and display a clear operating policy:
Do not place passwords, recovery codes, or other sensitive credentials in this questionnaire. Record only the platform, required permission, access owner, and due date. The project team will confirm the separately approved access method.
This is a workflow rule for the engagement, not a claim that one transfer method is suitable for every organization or data type.
Experience and constraints
14. “What has or has not worked in similar work before, and are there requirements, claims, terminology, or boundaries we should know?”
Decision informed: Surfaces relevant history and non-negotiable constraints. The response may identify approval sensitivities, brand-language rules, technical limitations, or approaches the client does not want repeated.
Do not assume a previous approach was objectively good or bad. Ask what happened, why the client interpreted it that way, and which part matters now.
Risks
15. “What could delay, complicate, or derail the work?”
Decision informed: Seeds the dependency list and risk register. Prompt for:
- Unavailable stakeholders
- Unresolved internal decisions
- Technical dependencies
- Legal or compliance review
- Missing assets
- Access delays
- Procurement requirements
- Anticipated staffing or organizational changes
- Conflicting launch priorities
The client will not know every risk. The purpose is to surface known concerns that should influence planning.
Optional final field
“Is there anything important that these questions did not cover?”
Keep this optional. It gives the client room to identify an omission without turning a vague closing prompt into a mandatory essay.
Treat budget as conditional after the sale
Budget belongs in pre-sale discovery when it affects fit, scope, and pricing. Once the price and scope are agreed, do not ask whether the client can afford the contracted work.
Use a post-sale budget field only when delivery needs details such as:
- Approved media or production spend
- Expense limits
- Travel or purchasing procedures
- Purchase-order requirements
- Authority for incidental costs
- A proposed change that may affect price
As a project-control policy, do not convert an onboarding answer into a change to the fee, usage rights, exclusivity, deadline, or scope. Route the issue through the review process specified for the engagement.
Add only the service-specific questions the project needs
The core questions establish how the relationship and project will operate. Service modules collect specialist information that changes the delivery method.
Use one deletion rule:
If the answer will not change delivery, leave the module out.
Marketing and content module
Ask about:
- Priority audience segments
- Current channels and campaigns
- Common customer objections
- Competitors or comparable brands
- Existing performance information
- Brand voice and terminology
- Required and prohibited claims
- The content or campaign’s role in the broader plan
- Existing research, creative, and reporting conventions
Do not ask clients to reproduce an entire marketing strategy unless creating that strategy is outside your scope. If audience research is a deliverable, ask what the client currently believes and what evidence exists—not for a fully resolved persona that the engagement is intended to develop.
UGC and creator-campaign module
Ask:
- What does the product do?
- Who is it for?
- Which features or use cases should creators understand?
- What may creators claim, and what should they avoid claiming?
- Which deliverables, durations, aspect ratios, and file formats are required?
- Where will the content be published?
- Who reviews concepts, scripts, rough cuts, and final files?
- Which products, samples, locations, or props are supplied?
- What is the review and reshoot procedure?
- What usage, whitelisting, and exclusivity boundaries were recorded for the engagement?
Larping Agency’s TikTok Shop Affiliate guide recommends that a seller’s creator brief explain what the product does, who it is for, and which claims creators should avoid. Those are useful operating inputs, but the onboarding questionnaire should record—not invent—commercial rights.
Transfer fees, usage duration, territories, paid-media rights, whitelisting, exclusivity, renewal, and ownership terms from the relevant agreement. Escalate contradictions for appropriate review.
Social media module
Ask:
- Which accounts and regions are in scope?
- What is the current objective for each account?
- Who creates, reviews, approves, schedules, and publishes?
- Who responds to comments and direct messages?
- What community-management activity is outside scope?
- Which issues require escalation, and to whom?
- Which tools and account roles are needed?
- Are any topics or dates restricted?
- How should errors, complaints, or sensitive messages be handled internally?
Separate publishing access from content approval. A client may approve content but retain publishing responsibility, or authorize publishing while reserving particular posts for executive review.
Design and brand module
Ask about:
- Current logos, typefaces, color references, templates, and guidelines
- Required file formats and dimensions
- Print, packaging, digital, environmental, or presentation applications
- Accessibility and production constraints
- Printers, developers, fabricators, or other downstream users
- Decision-makers and review stages
- Reference material
- Mandatory brand standards
- Subjective preferences
Distinguish preferences from requirements. “We like minimal layouts” permits interpretation; a mandatory production or accessibility rule is a constraint that must be planned around.
Web, SEO, and technical module
Ask about:
- Current content-management system and technical stack
- Development, staging, testing, and production environments
- Analytics and reporting setup
- Domain, DNS, hosting, and repository ownership
- Technical contacts
- Migration limitations
- Required integrations
- Release and rollback procedures
- Approval environments
- Known security, privacy, procurement, or compliance reviews
- Existing SEO research, redirect requirements, and measurement baselines
Do not require a marketing contact to guess technical details. Route the module to the appropriate owner and allow “unknown—technical contact to confirm.”
Consulting and recurring-service module
Ask:
- What process or operating model exists today?
- Who owns implementation on the client side?
- Which decisions must the engagement produce?
- Who attends recurring meetings?
- What reporting does each stakeholder need?
- Which recommendations can the provider implement directly?
- Which require client approval or internal resources?
- When should assumptions and goals be reviewed?
- What would trigger a change in priorities?
For recurring services, schedule a review point. Answers that were accurate at onboarding can become outdated as personnel, budgets, products, and priorities change.
Accounting and other specialized services
Generic accounting and bookkeeping templates may request business, transaction, employee, and document information. One Financial Cents questionnaire template describes those categories and advises firms to customize the requests.
Specialized or regulated providers should not assume that a general agency form fits their work. Define the fields, permissions, storage, transfer process, review steps, and retention practices according to the organization’s own professional and compliance requirements. Obtain qualified guidance where necessary.
Choose response formats that make answers usable
Question wording determines what the client understands. Response format determines what the team can do with the answer.
Use short text for identifiers
Short fields work well for:
- Names
- Roles
- Email addresses
- URLs
- Account handles
- Workspace names
- Project codes
Do not use a large text box when the expected answer is a name or link.
Use dates and structured choices for operational data
Use date fields or structured selections for:
- Fixed deadlines
- Preferred dates
- Update cadence
- Communication channels
- Approval roles
- Regions
- Service selections
- Project phases
- Readiness status
Structured answers are easier to sort, assign, transfer, and automate. Include “other,” “unknown,” or “not yet decided” when appropriate.
Use multiple select when several answers can apply
Checkboxes or multiple-select fields suit:
- Audiences
- Channels
- Stakeholder groups
- Deliverables
- Platforms
- Asset types
- Constraints
- Risks
Do not force one answer when several legitimately apply.
Use open text where the client’s language matters
Open text is appropriate for:
- Business context
- Definitions of success
- Prior experience
- Concerns
- Constraints
- Risks
- Unusual dependencies
Use it selectively. A questionnaire made almost entirely of large text boxes creates avoidable effort and produces responses that are difficult to compare or route. HoneyBook’s guide to client onboarding questionnaire design likewise recommends concise questions, context, suitable response types, clear due dates, and convenient file or link submission.
Use uploads and shared links deliberately
Allow approved uploads or shared links for brand assets, research, specifications, prior work, and project documents. Ask respondents to describe what they supplied:
- “Current brand guidelines—approved March version”
- “Product photography—web use approved”
- “Analytics export—January to June”
- “Draft policy—awaiting legal approval”
Descriptions help the team detect missing, duplicate, outdated, or unapproved material.
Use conditional logic for relevant follow-ups
Reveal a follow-up only after the client selects a relevant:
- Service
- Platform
- Deadline
- Risk
- Stakeholder type
- Deliverable
- Access requirement
- Review procedure
Conditional logic should simplify the client’s path, not conceal a confusing maze. Test each branch before publishing the form.
Give context without leading the answer
A difficult prompt may need an explanation or examples. Keep them neutral.
Instead of:
Which of our recommended weekly meeting times works for you?
Ask:
How often should routine progress meetings occur? Examples: weekly, fortnightly, monthly, milestone-based, or only when a decision is required.
The second version does not imply that weekly meetings are preferred.
Review checklist
Before publishing, verify that the questionnaire has:
- A clear purpose
- A logical order
- Short, neutral language
- Defined technical terms
- No double-barreled questions
- No fields the team will ignore
- No required answer the named respondent cannot provide
- Appropriate optional and conditional sections
- A usable experience on respondents’ likely devices
- A clear way to request help
Send it with a deadline, context, and a human fallback
Send the questionnaire soon after the engagement is confirmed and the welcome message has explained the onboarding sequence. Allow enough time for the client to consult colleagues and for the delivery team to review the submission before kickoff.
Advice such as sending it “within 48 hours” is a practitioner workflow heuristic, not a universal standard; Rock is one source that recommends that timing in its onboarding guidance. The correct interval depends on what must be known, how many people need to contribute, and when kickoff will occur.
Tell the client:
- Why the information is needed
- Who should complete or approve it
- Which sections may require colleagues
- The expected level of effort
- The exact due date
- What happens after submission
- How to get help
Send script
Welcome to the project. This questionnaire collects the information our delivery team needs before kickoff. We have prefilled what we already know. Please confirm or complete the highlighted fields by [date]. If another stakeholder should answer a section, you can forward or assign it to them.
If the form requires research, do not call it “quick.” Give a realistic effort estimate and identify the sections likely to require other people.
Reminder script
To keep the planned kickoff useful, we still need the highlighted answers by [date]. If completing the form is inconvenient, we can work through the blocking questions together on a short call.
Do not automatically cancel kickoff because the form is late. Identify which missing answers genuinely block useful work, contact the accountable person, explain the consequence, and agree on a recovery path.
An assisted-completion call may be appropriate when:
- The respondent cannot use the form comfortably
- Important questions are unclear
- Several departments must coordinate
- Written answers remain too vague
- Only a few blocking fields remain
Neutral clarification prompts
For vague outcomes:
What would that outcome look like in observable terms?
For unclear priorities:
If these items compete for time, which should take precedence?
For ambiguous timing:
Which date is fixed, and which is a preference?
For conflicting feedback:
Who is responsible for consolidating these views into one approved direction?
For missing measurement ownership:
Who can confirm the data source and whether the team can access it?
For an apparent scope expansion:
This request appears broader than the recorded scope. Should we continue within the current plan, or review a formal change?
Turn the responses into a kickoff agenda and project plan
Submission is not the end of the process. It is the start of internal interpretation.
Assign one person to review the response. Do not simply forward raw answers to the delivery team and expect everyone to notice the same gaps.
Run a blocker check
Look for:
- Missing day-to-day contact or final approver
- Uncertain scope boundaries
- Contradictory priorities
- Unconfirmed fixed dates
- Undefined review steps
- Missing or unapproved assets
- Unresolved access
- Metrics without a source or owner
- Dependencies without responsible people
- Risks without a response plan
A form can be complete at the field level while remaining operationally incomplete. “The marketing team will approve” fills a box but does not identify who gives final approval.
Compare answers with signed and sales records
Review the submission against the:
- Contract
- Statement of work
- Proposal
- Sales notes
- Confirmed commercial correspondence
Separate harmless updates from material contradictions. A new phone number is an update. A different target market may change the work. A preferred date becoming fixed may affect feasibility. An additional campaign, region, or deliverable may require review.
Create a clarification log
For each unresolved item, record:
| Field | Purpose |
|---|---|
| Original answer | Preserves what the client submitted. |
| Issue | Explains why it is incomplete, conflicting, or consequential. |
| Owner | Names the person responsible for resolving it. |
| Resolution deadline | Prevents the question from remaining open indefinitely. |
| Final decision | Records the approved answer. |
| Source | Identifies where the decision was confirmed. |
This prevents clarification from dissolving into scattered messages.
Convert approved answers into project artifacts
The approved answers should produce:
- Kickoff agenda
- Stakeholder and approval map
- Task list
- Responsibility assignments
- Milestones
- Asset checklist
- Access requests
- Communication plan
- Measurement plan
- Dependency list
- Risk register
A broader client-onboarding process outline similarly connects sales handoff, stakeholder and requirement gathering, kickoff, planning, delivery, and later handoff stages. The questionnaire is useful when it feeds those operating steps rather than remaining an isolated form.
Confirm, do not reread, at kickoff
Do not spend kickoff reading every response aloud. Confirm the decisions with the greatest effect on delivery:
- Desired outcome
- Immediate priority
- Scope boundary
- Final approver
- Hard dates
- Feedback process
- Metrics and data ownership
- Dependencies
- Major risks
- Open clarification items
Use the remaining time to resolve ambiguity, explain the plan, and agree on next actions.
Maintain one approved source of truth
Choose one location for final onboarding answers: the CRM, project workspace, shared onboarding document, or approved form record.
Preserve the original submission, but record later decisions in the designated source of truth. Do not let conflicting versions circulate indefinitely across forms, email, chat, and meeting notes.
Revisit goals, assumptions, risks, and stakeholder details at an early review point or after a material change. A sponsor may leave, a launch may move, or a planned metric may prove unavailable.
Use a simple readiness status rather than an unsupported predictive score:
- Ready: No known blocking items.
- Ready with open items: Work can begin, but named items remain unresolved.
- Blocked: One or more specific missing decisions or inputs prevent the planned work.
Always list unresolved items beside the status.
Select a tool—and collect only what you can handle responsibly
Dedicated onboarding software is optional. Choose the simplest method that supports the engagement.
Four delivery options
Basic form: Suitable for structured, one-time intake when answers should be standardized or exported.
Shared document: Useful when several people must collaborate, answers will evolve, or respondents need visible context.
CRM form: Appropriate when responses should update existing company, contact, deal, or project records.
Dedicated onboarding workspace: Useful for multi-owner workflows, assignments, recurring requests, status visibility, and ongoing collaboration.
Evaluate tools against practical requirements:
- Autosave
- Save-and-return support
- Reminders
- Conditional logic
- File or link submission
- Permissions
- Mobile usability
- Accessible form design
- Exports
- Integrations
- Version history
- Assignment to several stakeholders
Verify current pricing, features, integrations, security documentation, and regional availability directly with providers before choosing. Product details and commercial terms can change.
Keep sensitive access out of the ordinary questionnaire
Create an explicit organizational rule that passwords, recovery codes, payment details, and other designated sensitive credentials are not collected through the general onboarding form.
The questionnaire can record:
- Platform name
- Required permission or role
- Access owner
- Date access is needed
- Status of the request
Your organization should separately define which access or document-transfer methods it approves for each context. That determination may depend on the systems involved, the information being handled, contractual requirements, and qualified security or compliance review.
Apply data minimization
Collect only what the team needs to deliver the engagement. Limit internal access according to assigned responsibilities, and avoid creating unnecessary copies of the same files.
This approach is consistent with Larping Agency’s stated minimal-data policy, which describes limited website and newsletter collection. That policy does not establish that Larping Agency operates a client questionnaire or provides onboarding services; it illustrates an editorial preference for collecting less data rather than more.
The sources used here do not establish which legal, privacy, security, or regulatory rules apply to a particular provider. Organizations handling personal, financial, health, regulated, or confidential records should obtain guidance appropriate to their circumstances.
Maintain the questionnaire as an operational document
Assign an internal owner and record the current version. After several uses, ask:
- Which answers were repeatedly missing?
- Which questions produced unusable responses?
- Which fields were never consulted?
- Which clarifications delayed kickoff?
- Which sales information should transfer automatically?
- Which modules need to be split or shortened?
Useful internal diagnostic measures include:
- Completion time
- Abandonment or noncompletion
- Missing blocking information
- Number of clarification requests
- Kickoff delays attributable to missing inputs
- Answers corrected after kickoff
These are process measures, not universal benchmarks. Use them to improve your own workflow.
Client onboarding questionnaire FAQs
How long should a client onboarding questionnaire be?
It should be long enough to collect the information that affects delivery and no longer. Recommendations of approximately 10 to 15 core questions are practitioner heuristics, not universal limits, as reflected in Typeform’s questionnaire guidance.
Evaluate answer effort rather than field count. Fifteen essay prompts may be burdensome, while a longer form containing prefilled confirmations, short selections, and conditional fields may be straightforward.
Should the questionnaire be sent before or after the kickoff call?
Usually before kickoff, with enough time for the delivery team to review the answers. That allows kickoff to confirm decisions and resolve gaps instead of collecting every basic fact.
Exceptions are reasonable. A short engagement may combine the questionnaire with kickoff, an assisted call may replace the form, and a complex implementation may collect the universal core before kickoff and technical modules afterward.
What is the difference between a client intake form, a discovery questionnaire, and an onboarding questionnaire?
A discovery questionnaire generally supports pre-sale decisions about the prospect’s problem, fit, possible solution, budget, scope, and commercial approach.
A client onboarding questionnaire supports post-sale delivery by confirming goals, stakeholders, dates, approvals, assets, access, metrics, dependencies, and risks.
A client intake form is an inconsistent label. Some providers use it for qualification; others use it for post-sale onboarding or administrative registration. Look at the decision the form supports rather than relying on its title.
Who should complete the onboarding questionnaire when the client has several stakeholders?
Choose a primary respondent with enough knowledge and authority to coordinate the response. Route specialist sections to the operational, marketing, technical, finance, legal, compliance, or executive contacts best able to answer them.
Name one person responsible for approving the consolidated response. Record unresolved disagreements rather than allowing several stakeholder versions to circulate as equally final instructions.
Should clients submit account passwords or sensitive documents through the form?
Set a clear project policy that account passwords and other designated sensitive credentials are not entered in the ordinary onboarding questionnaire. Use the form to identify the platform, required role, access owner, and deadline; handle the actual access request through the separate method approved by your organization.
Before requesting a sensitive document, confirm that it is necessary. Then apply the collection, access, retention, privacy, compliance, and security procedures defined for that information and engagement.
Begin with the 15-question core. Remove fields whose answers will not influence delivery, prefill information captured during sales, and add only the modules the engagement requires. Send the questionnaire as part of a clear welcome sequence, review it before kickoff, reconcile contradictions with the recorded scope, and turn approved answers into owners, dates, approvals, access requests, metrics, dependencies, and risks.
The useful questionnaire is not the longest one. It is the one whose answers the team actually uses.