An agency intake form should collect information needed for the next delivery decision, with a named owner and clear handling for missing answers. Organize it around client goals, contacts, scope, assets and dependencies. Request account access through a separate controlled process, and keep optional background questions separate from inputs that block kickoff.
- Client submitsCollect the inputs needed for the next delivery decision.
- Owner reviewsCheck missing answers, contradictions and changes in scope.
- Resolve open itemsAssign each clarification and identify what blocks kickoff.
- Prepare the next stepUse confirmed inputs; keep the original submission available.
Request account access separately. A completed form is ready for review, rather than automatic acceptance.
Start with the decisions the form supports
Before adding a field, ask who will use the answer and what they will decide from it. If nobody can explain that connection, the question may belong in a conversation or may not be necessary.
- Proposed fieldState the information being requested.
- Named userIdentify who will use the answer.
- Delivery decisionState what that person decides from it.
- No clear useMove it to conversation or remove it.
Do not make clients restate scope already agreed in the proposal.
A form for a discovery engagement might need the client’s current process and the problem they want to resolve. A campaign intake might need audience information, existing assets and approval contacts. The same long form rarely serves both well.
Separate information already agreed in the proposal from information you still need. Requiring clients to restate settled scope can create conflicting records. Show the agreed scope for confirmation when useful, and route disagreements to a person.
Group fields by use
| Group | Useful information | Operational purpose |
|---|---|---|
| Goals | Desired outcome and current problem | Align discovery and delivery |
| Contacts | Working contact and approval owner | Route questions and decisions |
| Assets | Existing files and approved source locations | Prepare delivery inputs |
| Dependencies | Dates, other suppliers and blocked inputs | Plan sequencing |
| Communication | Agreed channel and meeting participants | Avoid scattered requests |
Keep the form clear about whether an answer is required, optional or can be discussed later. “Unknown” can be more useful than an invented answer supplied to get through a required field.
- GoalsAlign discovery and delivery.
- ContactsRoute questions and decisions.
- AssetsIdentify approved source locations.
- DependenciesPlan dates, suppliers and blocked inputs.
Mark whether each answer is required, optional or discussable later.
Use questions clients can answer
Ask for a concrete description instead of an internal label the client may not understand. “Who approves the final deliverable?” is clearer than “approval hierarchy.” “What must happen before we can begin?” is more useful than an unexplained dependency field.
Include short context where the question needs it. Explain how a requested asset will be used and where to provide it. Avoid asking the same thing several times with slightly different wording.
For example, a client may know which team handles the website but not which individual can grant access. Let them identify that team and mark the person as unresolved. The onboarding owner can follow up with a specific request.
A client onboarding questionnaire you can adapt
Use these prompts as a starting template. Keep questions that support your engagement, remove information already agreed, and mark which answers are required for the next step. A discovery project and an ongoing campaign can need different inputs.
| Group | Question to ask | Why the answer matters |
|---|---|---|
| Outcome | What should this engagement help your business accomplish? | Gives delivery a clear intended result |
| Current situation | What is happening today, and where does the work get stuck? | Defines the starting problem |
| Success | What observable change would help you judge progress? | Sets a useful review conversation |
| Scope | Does the agreed scope match your understanding of the work? | Surfaces a discrepancy before delivery |
| Audience | Who will use or receive the deliverable? | Helps the team make relevant choices |
| Working contact | Who should receive day-to-day questions? | Identifies a practical response owner |
| Approval | Who can approve the deliverable or request a change? | Separates feedback from an authorized decision |
| Other participants | Which colleagues or suppliers need to be involved? | Reveals dependencies and review participants |
| Assets | Where are the current approved files and reference materials? | Points the team to the appropriate source |
| Version | Are any supplied files being revised elsewhere? | Reduces conflicting versions |
| Platforms | Which accounts may be relevant, and who manages them? | Prepares a separate access request |
| Dependencies | What must happen before the next stage can begin? | Makes a blocker visible |
| Dates | Are there fixed dates we should discuss, and why are they fixed? | Reveals constraints without promising a deadline |
| Communication | Which agreed channel should carry questions and decisions? | Reduces scattered instructions |
| Unknowns | Which answers are still unknown, and who can help resolve them? | Creates an honest clarification path |
For each required answer, name the agency reviewer and the action they will take. A response such as “we need to check internally” can be useful if the team records who will check and when the next decision can happen.
Do not ask for passwords, banking credentials or unnecessary sensitive information in this questionnaire. Identify relevant systems here, then use the approved invitation or sharing method in the access request checklist.
Use the questionnaire inside the onboarding process
Send the questions with a short explanation of the next stage and the person who can help. Review the answers against the current agreement. If a response proposes extra work, route it through scope change review before it changes the project.
The questionnaire supplies information. The onboarding checklist records whether the information is usable and whether the engagement can proceed. Keep those jobs separate so a submitted form does not silently approve kickoff.
Keep access requests separate
Do not turn the intake form into a collection of account passwords. Identify which platforms may be relevant and who manages them. Then use a controlled access request with a named recipient and the level of access needed for the work.
- Intake formIdentify relevant platforms and managing contacts.
- Controlled requestName recipient and required access level.
- Access checklistTrack request, grant and review status.
- No usable accessKeep platform mention separate from readiness.
Do not collect passwords in a broad intake record.
Link to the client access checklist so the project can track what is requested, what was granted and what still needs review. A platform name in the intake form does not mean usable access exists.
Review the submission before creating work
A submitted form can trigger a review task. The reviewer should check missing required inputs, contradictory answers and changes from the agreed scope. Automatic task creation is useful when the information is predictable; it is less useful when every unusual answer produces a poorly defined task.
Keep the original submission and a dated clarification record. Do not silently replace the client’s answer with your interpretation. If the interpretation changes a delivery decision, confirm it through the responsible contact.
Improve the form from actual friction
Watch which questions clients leave blank, answer incorrectly or repeatedly ask you to explain. Ask delivery which answers it actually uses. Remove fields that add effort without improving a decision.
Your success measure is not the number of completed fields. It is whether the project reaches its next step with accurate information and fewer clarifications. Review the form after a small set of engagements, then make a controlled change rather than expanding it indefinitely.
Questions and answers
How many questions should an agency intake form contain?
Use the fewest questions that support the next delivery decisions. There is no universal number. Identify required kickoff inputs, optional background and questions better handled in a meeting, then remove fields with no clear user or purpose.
Should a client intake form ask for passwords?
Use the form to identify platforms and access contacts. Handle access separately with a named owner and an appropriate sharing or invitation method. Avoid collecting account credentials in a broad intake record that many team members may see.
What happens when a client leaves a required answer blank?
Create a specific clarification task and identify whether the missing answer blocks kickoff. Let the client state that information is unknown when appropriate. A forced guess can create more delivery work than an openly unresolved input.