Reusable template
What questions should a client intake form ask?
A reusable client-intake question bank for identity, goals, scope, constraints, timing, ownership and the next decision—without asking for data nobody will use.
A client intake form should ask only what the team needs to identify the requester, understand the desired outcome, scope the work, recognize constraints, assign an owner and choose the next step. Start with seven core questions, then reveal service-specific questions conditionally. Remove any field that does not change preparation, routing, qualification or delivery.
A publication-authored 28-question bank with purpose, field type, required-state and downstream-use rules, informed by current intake and workflow templates and the publication's CRM data-model methodology.
Key findings
- Seven core questions cover most early client decisions: identity, contact route, request type, desired outcome, current context, timing and next-step preference.
- Budget, file uploads and detailed scope questions should be conditional when they are not relevant to every service.
- The best deletion rule is operational: if an answer does not change preparation, routing, qualification or delivery, do not ask for it yet.
Seven core intake questions
Start with the smallest set that can change the next action. For a general business-service intake, these seven questions usually create enough structure for triage without turning the first interaction into a full discovery workshop.
| Question | Recommended field | Decision it supports |
|---|---|---|
| Who should we contact? | Name plus work email | Identity and reply route |
| Which organization or project is this for? | Short text | Account or project context |
| What kind of help do you need? | Controlled single select | Service route and relevant follow-up questions |
| What outcome are you trying to achieve? | Long text | Preparation and success definition |
| What is happening now? | Long text or controlled stage | Baseline, urgency and known constraints |
| When does this need to happen? | Date or timeframe range | Feasibility and priority |
| What should happen next? | Call, written reply, estimate or other option | Handoff and expectation |
Keep the first route simple. Use the request type to reveal only the fields that apply to that service instead of making every client scan every possible question.
Reusable 28-question bank
This bank is a menu, not a recommendation to publish 28 required fields. Select questions only when the downstream user can explain how the answer changes their work.
| Group | Questions to choose from | Typical downstream use |
|---|---|---|
| Identity | Contact name; work email; phone; organization | Deduplication, account matching and response route |
| Request | Service type; project name; short request summary; desired deliverable | Queue, specialist and scope preparation |
| Outcome | Primary goal; success measure; priority outcome; consequence of delay | Discovery agenda and trade-off decisions |
| Current state | Current approach; known problem; previous attempts; existing provider or system | Baseline and migration context |
| Scope | Audience; channels; volume; geography | Effort, capability and ownership |
| Constraints | Target date; budget range; fixed requirement; dependency | Feasibility, timing and routing |
| Handoff | Decision maker; collaborators; preferred channel; next-step preference | Follow-up owner and meeting preparation |
For each selected question, write the decision it controls beside the field definition. That note is evidence that the question belongs.
Required, optional or conditional
| State | Use it when | Example |
|---|---|---|
| Required | The record cannot be identified, routed or safely acted on without it | Contact route and request type |
| Optional | The answer improves preparation but an honest 'not sure' is acceptable | Budget range or supporting link |
| Conditional | The question applies only after a prior answer | E-commerce platform after 'online store' is selected |
| Deferred | The information matters later but not for the first decision | Detailed asset inventory before kickoff |
File uploads deserve special caution. Ask for a file only when someone will review it before the next interaction, define accepted formats and size, and avoid collecting sensitive material through a general business intake.
Stable field names and answer types
Human-readable labels can change without breaking a workflow if the underlying field names remain stable. Use names that describe the concept, not the current copy.
| Label | Stable field name | Type | Allowed values or rule |
|---|---|---|---|
| What kind of help do you need? | request_type | Enumeration | strategy | design | implementation | support | other |
| When do you need to start? | target_start_band | Enumeration | asap | 30_days | 90_days | later | unsure |
| What outcome matters most? | primary_outcome | Long text | 500 characters; no HTML |
| Who will make the decision? | decision_role | Enumeration | self | executive | committee | unknown |
| What should happen next? | next_step_preference | Enumeration | call | written_reply | estimate | unsure |
Controlled values are easier to route and measure than free text. Keep the original submission as evidence, then map the current client state into the broader CRM-ready data model.
The intake-question deletion test
For every question, finish this sentence: If the client answers X instead of Y, we will… Keep the question only if the ending describes a real preparation, routing, qualification or delivery change.
- Preparation: does the answer change what the team reviews before contact?
- Routing: does it select a queue, owner or specialist?
- Qualification: does it establish fit, readiness or a hard constraint?
- Delivery: does it change scope, timing or the service itself?
If none applies, delete or defer the field. Then connect the form to the post-submission workflow and verify that each retained answer reaches the person or system that needs it.
Evidence and limitations
A publication-authored 28-question bank with purpose, field type, required-state and downstream-use rules, informed by current intake and workflow templates and the publication's CRM data-model methodology.
- The question bank is for general business services and intentionally excludes medical, legal, financial and other regulated intake.
- Each organization must adapt terminology, required fields, retention and access to its own process and data policy.
Sources and verification
Current product and plan claims use the primary sources below. Internal methodology links describe the publication's own frameworks and should not be read as vendor documentation.
- Atlassian Jira intake form template and workflow
- HubSpot, Create and edit CRM properties
- CRM-ready form data model
- The Form Review testing methodology
Last materially verified .