Web design client intake form template
A copy-pasteable client intake form for web design projects, with the exact field type each item needs, ready to send as-is or adapt before kickoff.
Why a template instead of a blank page
Most web designers rebuild the same list of questions for every new project, from memory, which means the list is a little different each time and something always gets skipped. A fixed template fixes both problems: nothing depends on remembering what you asked last time, and every client gets asked for the same things in the same order, which makes the answers easier to compare and easier to plug into a project plan. The list below is deliberately close to the website project intake checklist — the difference is that this page gives you the actual field list ready to send, not just the reasoning behind each item.
Five kinds of question show up in a web design intake, and mixing them up is where most homemade forms go wrong:
- Text — short, structured answers: a business name, a tracking ID, a URL.
- File — an asset the client already has: a logo, a menu PDF, a set of photos.
- Choice — a fixed set of options, so you get back a value you can branch logic on instead of a sentence you have to interpret.
- Credential — a login or a password. This is not a text field. Treating it like one is the single most common mistake on this list.
- Structured — a small set of related facts with a fixed shape, like opening hours or an address block, where you want the same keys back every time rather than a paragraph.
The form, section by section
1. Business basics
| Field | Type | Notes |
|---|---|---|
| Business name, exactly as it should appear | Text | Do not assume last year's version or the domain name is still correct. |
| Primary contact name and role | Text | Who you email when something is unclear. |
| Do you have an existing website? | Choice (yes/no) | Branches the rest of the intake — see below. |
| Existing website address | Text (URL) | Only asked if the answer above is yes. |
2. Brand identity
| Field | Type | Notes |
|---|---|---|
| Logo file | File (image) | Ask for SVG or a large PNG, not a screenshot or a resized export. |
| Brand colors | Choice (color list) | Hex codes if they have them; otherwise a phone photo of something branded to sample from. |
| Typography preference, if any | Choice | Most clients are fine with your recommendation — ask so the ones who care can say so. |
3. Content
| Field | Type | Notes |
|---|---|---|
| Homepage headline and intro copy | Text (long) | The item most likely to hold up launch, because it is hardest for the client to write. |
| About / services page copy | Text (long) | Can start as a placeholder and be swapped in once it exists. |
| Photos (minimum count and resolution stated) | File (multiple) | State the minimum width up front instead of discovering a 400px photo after upload. |
| Which pages does the site need? | Choice (multiple) | Home, About, Services, Contact, Blog, and so on — pick from a fixed list rather than free text. |
4. Technical access
| Field | Type | Notes |
|---|---|---|
| Current CMS or hosting admin login | Credential | Never a text field — see the section below on why. |
| Domain registrar access, if separate from hosting | Credential | Finding out two days before launch that the client doesn't have this is a common, avoidable delay. |
| Analytics tracking ID | Text | Nice to wire in from day one; not worth delaying launch over. |
5. Business facts and sign-off
| Field | Type | Notes |
|---|---|---|
| Opening hours | Structured | Monday–Friday, Saturday, Sunday as three fixed fields, not a paragraph you have to parse. |
| Address and contact details, exactly as they should appear | Text | Small inconsistencies between the site and the Google listing hurt local search. |
| Who has final sign-off on the site | Text | Confirm this once at the start, especially with more than one stakeholder. |
Why credentials need their own field
A login typed into the same text box as the homepage headline ends up stored, copied, and backed up exactly like the headline — in plaintext, in whatever tool held the form, indefinitely. A password does not become safer because the form that collected it happens to also collect copy. The one-line fix is to give it a field designed for a one-time handoff: encrypted the moment it is submitted, released once to the person who asked, and gone from the system after that. How to ask clients for logins and passwords securely covers this in more detail if you're building the request from scratch rather than from a template.
Common mistakes
- One long free-text field for "brand stuff." A client cannot 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 on photo or logo requests. "High resolution please" produces a screenshot half the time; "at least 512px wide" produces a usable file.
- Credentials in the same channel as everything else. Covered above, and worth repeating — it's the mistake with the worst downside.
- Asking for everything before kickoff. Some items block the start (logo, homepage copy, existing site access); some only block the finish (analytics ID, final photo round). One deadline for all of it makes the request heavier than it needs to be.
- A single request with no follow-up. Clients intend to reply and then the moment passes. The list above only does half the job if nothing chases the missing half a few days later.
Running this form through BriefGate
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: text and long text fields stay text / longtext, the logo and photos become image and file_list with format and size constraints, brand colors become color_list, the yes/no and page-selection questions become boolean and multiselect, opening hours becomes a structured item with a small JSON Schema, and every credential becomes a secret item — sent over HTTPS and sealed on BriefGate's server before it is ever stored and revealed to your agent exactly once. The full type reference, including every constraint field, is in item types.
{
"project_name": "Bella Napoli — Website",
"client": { "email": "[email protected]", "name": "Marco Esposito" },
"items": [
{ "key": "business_name", "label": "Business name", "type": "text", "required": true },
{ "key": "has_existing_site", "label": "Do you have an existing website?", "type": "boolean", "required": true },
{ "key": "logo", "label": "Logo", "type": "image", "required": true,
"constraints": { "formats": ["svg", "png"], "min_width": 512 } },
{ "key": "brand_colors", "label": "Brand colors", "type": "color_list", "required": true },
{ "key": "hero_copy", "label": "Homepage headline and intro", "type": "longtext", "required": true },
{ "key": "photos", "label": "Photos", "type": "file_list", "required": true,
"constraints": { "formats": ["jpg", "png"], "min_count": 5 } },
{ "key": "pages_needed", "label": "Which pages does the site need?", "type": "multiselect", "required": true,
"options": [
{ "value": "home", "label": "Home" },
{ "value": "about", "label": "About" },
{ "value": "services", "label": "Services" },
{ "value": "contact", "label": "Contact" }
] },
{ "key": "cms_login", "label": "Current CMS admin login", "type": "secret", "required": false },
{ "key": "opening_hours", "label": "Opening hours", "type": "structured", "required": false,
"schema": { "type": "object", "required": ["mon_fri", "sat", "sun"],
"properties": { "mon_fri": { "type": "string" }, "sat": { "type": "string" }, "sun": { "type": "string" } } } }
],
"chase_schedule": "default"
}BriefGate emails the client a single branded portal link, validates every field as they fill it in, and chases them on the schedule you set until everything required is in. Your agent reads the finished project back with one call to get_intake_results — typed data, not a folder of attachments and a spreadsheet row to parse. The quickstart walks through connecting an agent and sending the first intake end to end.