Project intake form template: Gate fields vs brief fields

A project intake form template should hold two forms in one file: A short gate that lets you answer yes, no or not yet, and a longer brief that nobody fills in until the answer is yes. Most downloadable templates give you one long form instead, and that shows up in two ways — requests that arrive half-finished, and answers nobody downstream ever reads.

What follows is the split itself: Seven gate fields, fifteen brief fields, a conditional set that depends on the request type, and two tests you can run on your existing form this week to decide what stays.

The two jobs one form is asked to do

Decision fields answer whether the work should happen and when. Brief fields answer what exactly gets built. They have different readers, different deadlines, and different consequences when left blank.

Blending them creates a form that is simultaneously too long for the requester with a real, funded project and too detailed for the requester who is still thinking out loud. The sequencing is also wrong. Someone who does not yet know whether the budget exists cannot sensibly tell you which fonts are licensed or who owns the DNS records — so they guess, and you inherit the guess as if it were a fact.

Two stages fix the sequencing without adding a single field. Stage one is submitted by anyone. Stage two is sent only to requests that cleared the gate.

The gate: Seven fields that decide

Field 7 does more work than the other six combined. "We lose the retail campaign window" and "it would be nice to have" are the same request until someone writes the consequence down.

Keep the gate to a single screen. If it needs scrolling on a phone, something in it belongs in stage two.

The brief: Fifteen fields, opened after a yes

Send these once the gate decision is made, so the requester spends effort on work that is actually scheduled.

Scope (3)

• 1. Deliverables, counted — "6 pages, 2 reusable templates", not "a website"
• 2. Explicitly out of scope
• 3. Must-have functions, listed separately from nice-to-have

Technical (4)

• 4. Current platform and plan
• 5. Who holds domain and hosting access, by name
• 6. Third-party tools that must connect
• 7. Tracking or analytics requirement

Content (3)

• 8. Who writes the copy, and by which date
• 9. Who supplies photography or video
• 10. Languages, and whether translation is in scope

Brand (3)

• 11. Logo files, with the formats you need named in the question
• 12. Fonts, plus who holds the licence
• 13. Two references they like and one they dislike, each with a one-line reason

Process (2)

• 14. Number of review rounds expected, with reviewer names
• 15. Blackout dates — holidays, code freezes, competing launches

Field 13 is worth phrasing exactly that way. "Send inspiration" produces a folder of screenshots; "one you dislike and why" produces the constraint you would otherwise discover in round two. The same principle drives the longer field list in our web design template for client intake, where the mandatory core is deliberately smaller than the full set.

The blank test: How to cut a field

Every field in your template has to survive one question: Who reads it, and what changes if it arrives empty?

If nobody can say what changes when a field is blank, the field is decoration. Cut it, and give the seconds back to the person filling in the form.

Run this once against the template you already use. In most intake forms that have been edited by more than two people over a couple of years, several fields fail immediately — usually the ones added after a single awkward project that never recurred.

The first-question log: Finding the field you are missing

Cutting is easier than knowing what to add. Here is a measurement instead of a guess.

For your next ten submissions, write down the first clarifying question you had to ask after reading the form. Just the first one, in the requester's words if possible. Then apply a threshold:

• A question that appears in 3 or more of 10 submissions becomes a required field.
• A question that appears once or twice stays a conversation.

The threshold matters because every new field is paid for by every future requester, including the ones who would never have triggered that question. Adding a field to serve one edge case in ten is a bad trade; adding one that removes a round trip in a third of your intake is not.

Ten submissions is small, so treat the result as a shortlist rather than a verdict. Two consecutive rounds of ten pointing at the same missing field is a strong signal.

What a round trip actually costs

The 3-in-10 threshold is easier to hold once the cost of the alternative is on paper.

Assume a studio taking 40 briefs a quarter. A missing field produces one clarifying email, and the requester answers in a median of 1.5 business days.

The 21 days are the number worth sitting with. They do not appear on anyone's timesheet, and they are the reason a brief that could have started on Tuesday starts the following Monday.

Now the other direction, which is why the threshold is 3 and not 1: a field that helps 1 in 10 costs the other nine about 20 seconds each. Over 40 briefs that is 36 × 20 s = 12 minutes a quarter to save 4 round trips — still worth it. A field that helps 1 in 40 costs 39 × 20 s = 13 minutes to save one. That is where it stops paying, and it is roughly where the threshold sits.

Conditional fields, by request type

One template, several tails. Ask the request type in the gate, then show only the matching extras in stage two.

This is where a single flat PDF starts to lose. Conditional logic needs a form that can hide and show sections, which is also the point at which routing rules become worth more than the form itself — that trade-off is the subject of our piece on project intake software for agencies.

Fillable PDF, spreadsheet or web form

The failure mode of the PDF route is re-keying. Answers come back inside a document, so somebody retypes them into wherever the work is actually tracked, and the uploaded logo arrives in a different message than the brief that explains what it is for. That gap is exactly what a portal closes: Brief, files and approval sit on the same record, and — in cluein.me's case — export together as a structured package rather than as a folder someone has to reassemble.

Making a fillable PDF, if that is the right call

• Lay the form out in a document editor first, with the gate on page one and the brief starting on page two.
• Export to PDF, then add form fields in a PDF editor that supports them.
• Name each field exactly like the column or property it will end up in. Future-you pasting data will notice.
• Fill it in on a phone, save, close, reopen. Some mobile readers handle annotations differently from desktop viewers, so verify that your entries survive the round trip before you send it to a client.
• Send the empty copy to one colleague and ask them to return it. Test the return path, not just the form.

What a free template can and cannot give you

A free project intake form template is worth downloading for one thing: Section order. Someone has already thought about the sequence — requester, outcome, constraints, scope, sign-off — and that saves you an hour of staring at a blank page.

What it cannot know is your approval threshold, your platform, your review cycle or who in your organisation is allowed to say yes. Those are the fields that determine whether the form produces a decision or just a record. So keep the skeleton and replace every field where you cannot name a reader.

Judge any template you download by counting how many of its fields would survive the blank test above. If most of them are demographic or descriptive, you have a filing form, not an intake form.

Intake data goes stale faster than the form does

Three fields expire: Budget band, target date and the sign-off name. Staffing changes, quarters roll over, the person who was going to approve moves teams.

A workable rule: If a submission is more than 30 days old when work is about to start, reconfirm those three before kickoff. One message, three questions. To make that possible, show the submission date on the record itself — forms that store only the answers, and not when they were given, quietly turn old assumptions into current facts.

Where intake forms quietly fail

The form becomes an inbox. Requests arrive, nobody owns the queue, and after a fortnight of silence requesters go back to messaging you directly — which is where they started, except now there is also an unmaintained form.

The countermeasure is a published response time for the gate decision, printed on the form itself: Something like "you will get a yes, no or not-yet within two working days." Then staff it. If nobody can commit to that window, the honest move is to not launch the form yet, because an unanswered form teaches people that the form does not work.

The second failure is subtler. Someone adds a field after every difficult project, nobody removes any, and within two years the form is 40 fields long and the completion rate falls off. Schedule the cut: Once a quarter, run the blank test and delete what fails. Our briefing template for designers uses the same discipline — a full set for complex work, a short set for everything else.

Start with ten requests, not a redesign

Do not rewrite the template first. Take your next ten incoming requests, log the first question you had to ask on each, and mark which existing fields nobody read. You will have the two lists that matter — what to add, what to cut — before you have changed a single line of the form.

The open question is what happens to requests that fail the gate. Most teams have no answer beyond silence, and a "not yet, revisit in Q4" queue that someone actually reviews is the part of intake nobody builds.