Client Intake Form Template
A client intake form template covers what almost any agency or freelancer needs before starting a project — who the client is, what they're trying to achieve, what they already have, what you need from them, and when it's due. The fields below work as a copy-paste checklist on their own, and as a downloadable PDF you can print or send as-is.
Why one template, not one per project type
Most intake templates online are built for a single niche — a web design questionnaire, a branding brief, a marketing intake — and duplicate most of their fields across each other. Underneath the surface differences, every client-facing project needs the same six kinds of information: who to contact, what the project is, what it should achieve, what materials already exist, what access it needs, and when it's due. This page covers that shared core. If you're specifically building a website, the web design version below adds the few web-specific fields (pages needed, opening hours, analytics) on top of it; for a pure logo or brand identity project, see the logo and brand design brief checklist.
Five kinds of field cover nearly everything on an intake form, and mixing them up is where most homemade forms go wrong:
- Text — a short, structured answer: a name, an email, a URL.
- File — an asset the client already has: a logo, a PDF, a set of photos.
- Choice — a fixed set of options, so you get back a value you can act on instead of a sentence you have to interpret.
- Credential — a login or a password. Not a text field — see why below.
- Structured — a small set of related facts with a fixed shape, like an address or opening hours, where you want the same fields back every time.
The form, section by section
1. Contact
| Field | Type | Why ask |
|---|---|---|
| Client or business name | Text | Needed to personalize everything else — a proposal, an invoice, the project name itself. |
| Primary contact name and role | Text | Who you reach when something's unclear; a title tells you whether they can make final calls. |
| Email address | Text | Where the finished brief, reminders, and the eventual deliverable all go. |
| Phone number (optional) | Text | For anything too time-sensitive to wait on an email reply. |
2. Project basics
| Field | Type | Why ask |
|---|---|---|
| Project type | Choice | Website, brand identity, marketing campaign, app, other — routes which later sections actually apply. |
| Do you have an existing site or brand? | Choice (yes/no) | Distinguishes a from-scratch project from one with existing constraints to work within. |
| Link to existing site or brand materials | Text (URL) | Only relevant if the answer above is yes; saves a round trip asking for it separately. |
| What's driving this project now? | Text | A rebrand, a broken old site, a new launch — the reason shapes what "done" looks like more than any brief does. |
3. Goals
| Field | Type | Why ask |
|---|---|---|
| What should this achieve in the first few months? | Text (long) | Turns "make it look professional" into something you can actually check against later. |
| Who is this for? | Text (long) | The target audience is the basis for almost every content and design decision downstream. |
| What would make this a failure, even if it looks great? | Text (long) | Surfaces the one hidden requirement — a legal disclosure, a stakeholder's pet feature — before it's a week-five surprise. |
4. Content and materials
| Field | Type | Why ask |
|---|---|---|
| Logo | File | The actual file, not a screenshot of it — ask for SVG or a large PNG. |
| Brand colors | Choice (color list) | Hex codes if they exist; a phone photo of something branded to sample from if they don't. |
| Key copy or messaging | Text (long) | A headline, an about paragraph, anything legally sensitive (pricing, disclaimers) that should come from the client, not be invented. |
| Photos or other assets | File (multiple) | State a minimum count and resolution up front, not after a 400px photo arrives. |
5. Access
| Field | Type | Why ask |
|---|---|---|
| Existing site or hosting login | Credential | Never a plain text field — see the section below on why. |
| Domain registrar access | Credential | Finding out two days before launch that the client doesn't have this is a common, avoidable delay. |
| Third-party accounts (analytics, email, social) | Credential or Text | Whatever the new work needs to connect to; ask which ones apply rather than assuming. |
6. Timeline and budget
| Field | Type | Why ask |
|---|---|---|
| Hard deadline, if any | Text | A launch date, an event, or a campaign start — distinguishes a real constraint from an aspirational one. |
| Budget range | Choice | Offering three tiers gets an honest answer faster than asking a client to name a figure cold. |
| Who has final sign-off | Text | Confirm this once at the start, especially the moment there's more than one stakeholder. |
Web design version
A website project needs everything above, plus a handful of fields specific to the medium. Add these on top of the six sections when "project type" is a website — the questionnaire framing and the section titles stay the same, only these rows are new:
| Field | Type | Why ask |
|---|---|---|
| Which pages does the site need? | Choice (multiple) | Home, About, Services, Contact, Blog, and so on, picked from a fixed list rather than free text, so the answer maps straight onto a sitemap. |
| Typography preference, if any | Choice | Most clients are fine with your recommendation; ask so the ones who care can say so before a design round gets built on the wrong font. |
| Opening hours | Structured | Monday–Friday, Saturday, Sunday as three fixed fields rather than a paragraph to parse — only relevant for a business with set hours. |
| Analytics tracking ID | Text | Nice to wire in from day one, but a site can launch and collect a data gap of a few days without lasting damage — not worth delaying launch over. |
Nothing else changes: the admin login for an existing site, domain registrar access, and the exact address and contact details for the footer are already covered above under Access and Content and materials, the same as for any other client-facing project.
Why credentials get their own field
A password typed into the same box as the project brief gets stored, copied, and backed up exactly like the brief — in plaintext, in whatever tool held the form, indefinitely. Nothing about a form makes a credential safer just because the rest of the form is harmless. The fix is a field built for a one-time handoff: encrypted the moment it's submitted, shown once to the person who asked for it, then gone. How to get client logins securely covers the reasoning in more detail; the secrets vault is BriefGate's implementation of it — encrypted on the server the moment it arrives, never in the client's browser, and never a "zero-knowledge" claim we can't back up.
Download the template
The client intake form template PDF has every field above, grouped into the same six sections, ready to print or fill in on screen — one page, no tracking, no signup. It's a starting point to adapt, not a fixed form: drop what a given project doesn't need, and add anything specific to your own process.
Common mistakes
One long field for "brand stuff" or "assets." A client can't picture "assets" — only a logo file and a set of photos. Break every bundled request into the individual files or facts it contains. No minimum resolution stated on photo or logo fields. "High resolution please" produces a phone screenshot about half the time; "at least 512px wide" produces a usable file. Credentials collected the same way as everything else — worth repeating, because it's the mistake with the worst downside. No deadline attached to the form. A request with no due date competes with everything else in a client's inbox that does have one, and loses. Sending the form once and never following up — most stalled intakes aren't refusals, they're a moment that passed unnoticed; see why clients don't send materials for the reminder cadence that fixes it.
Sending this same template through BriefGate
Everything above works as a plain PDF or a shared document — that's the point of publishing it as one. Where it tends to fall short past the first few projects is the same place any static form does: nothing tracks who's answered what, nothing reminds a client who's gone quiet, and a credential typed into a form field sits exactly as exposed as it would in an email.
An AI coding agent — or you, from the dashboard — can turn this exact list into a live client portal with one call to define_intake. Each row above maps to a real item type: the text fields stay text / longtext, the logo and photos become image and file_list with format and size constraints, brand colors become color_list, project type and budget range become select, the web design version's pages-needed field becomes multiselect and opening hours becomes structured, and every credential becomes a secret item — sealed on BriefGate's server the moment it's submitted and released to your agent exactly once. The client gets one branded link with nothing to sign up for (see the client portal), BriefGate chases them on a schedule until every required item is in (see the chase engine), and your agent reads the finished intake back with one call to get_intake_results — typed data, not a PDF to re-key by hand. The full type reference is in item types.
Sending this list once, to one client, works on every plan including Free. If you run the same kind of project repeatedly and want to save this exact field set as a reusable template — so a new project starts pre-filled instead of rebuilt from scratch — that's a paid feature starting on the Solo plan; see templates for how saved templates work and what's included on each plan.
Frequently asked questions
Is a PDF client intake form enough, or do I need a portal?
For a single project, a PDF or a shared document works fine — print it, email it, or drop it in a shared drive. A portal starts earning its keep once you're running more than a couple of projects at once and can't reliably remember who still owes what, or once a form field would have to hold a password.
What's the difference between this and a web design intake form?
There isn't a separate one — the web-specific fields (pages needed, opening hours, analytics ID) are folded into the web design version section above, so this one template covers both a website project and anything else client-facing.
Can I just put a password field in the PDF or a generic form?
You can, but it's not a safe place for one — a filled-in PDF or a form's stored answers sit around indefinitely, readable by anyone with access to the file or the account behind the form. Collect credentials separately, through something built for a one-time reveal, rather than folding them into the same document as everything else.