An intake form template with two required fields
· 5 min read · by Tan Gravam
The short answer
Here is the whole template. Field one: What needs to change? — free text, required. Field two: Who is affected, or what happens if nothing changes? — free text, required. Field three: Is there a date this is tied to? — optional, because most requests honestly have none. That is the form. Every field beyond these is paid for by the requester at the moment their patience is shortest, and answers a question that belongs to a later stage — category, priority and size are the team's work, not the door's. What makes the template function is not the fields; it is that a request which clears them visibly moves, and one that does not gets its question back the same day.
Anyone searching for an intake form template is usually holding a longer form than they need. Here is the entire template, followed by the reasoning, and then the part that matters more than the fields: what has to happen after submission for any form to keep working.
The template
| Field | Type | Required |
|---|---|---|
| What needs to change? | Free text | Yes |
| Who is affected — or what happens if nothing changes? | Free text | Yes |
| Is there a date this is tied to? | Date + one line of context | No |
That is the form. The third field is optional because most requests honestly have no date, and a required date field teaches people to invent one — after which every request is "urgent" and the field means nothing.
Why these two questions
The first question forces a request to contain a need — something that should be different. This is the question that catches topics: "reporting", "the mobile app", "tech debt" are subjects wearing the grammar of a request, and they fail "what needs to change?" in a way everyone can see. A topic cannot be routed, sized or decided on — accepting one into a queue just moves the work of understanding it to someone with less context than the requester had.
The second question forces stakes: either a person or group the change serves, or a consequence of inaction. One of the two is enough. Requiring both would be bureaucratic; requiring neither admits requests that read fine and mean nothing. Note what the pair deliberately is not: it is not "any two of three". A request with impact and urgency but no stated need is the most dangerous shape in the queue — pressure attached to a void — and a bar that admits it will commit someone to building it.
The fields that are missing on purpose
Category — taxonomy serves the report, not the decision; whoever needs the report can tag later, in bulk, with context. Priority — the requester's priority is always "high"; actual priority is decided against capacity, later, by the people accountable for it. Size or effort — the delivering team sizes work at shaping, and a number typed at the door by the requester is a wish that will be quoted back as an estimate. Requirements detail — a request is not a specification; asking for one at the door gets you fiction in a confident voice, and assumptions dressed as facts are exactly what shaping exists to unpick.
Every one of these fields is paid for by the requester at the moment their patience is shortest. The bill arrives later, as the hallway request that bypassed the form entirely.
The part no template can contain
A form works for exactly as long as submissions visibly move. Two service levels keep the door alive, and both are cheap:
- Below the bar: same-day handback. A request missing its need or its stakes goes back with the one question that clears it — while the requester still has the context in their head.
- Above the bar: a decision within the week. Not delivery — a decision. Plan it, send it to a time-boxed discovery, park it with a review date, or decline it with a reason the requester can read.
A beautiful form in front of a black box trains people to stop using the form. The door argument is its own essay: the form is the cheapest place in the whole delivery process to intervene, and the least attended.
If you use DeliverySheet
This template is the product's Capture step, enforced rather than suggested. The two questions are the deterministic floor — a demand cannot enter the lifecycle without a stated need plus an impact or a trigger, and there is no "capture anyway" override. Paste the raw Slack message or email as it arrived: the AI drafts the structured fields from it and flags which of the two signals it can and cannot find, so the handback question is asked at the door instead of three weeks later. What happens after the door — the four recorded exits — is the rest of the intake process.
I'm Tan Gravam. I build DeliverySheet — it takes a vague work request to a clear delivery decision, so the shape, owner, capacity, dependencies and open questions are on the table before anyone commits people or a date.
$189/month per workspace, unlimited members, 7-day free trial. I answer the support email myself.
More on turning a request into a decision
Read the overview: Turning a request into something you can decide on →
- The engineering intake process, end to end
One door, two questions, four recorded exits. The whole intake process for an engineering team — without a triage committee or a twelve-field form.
- Triage is deciding what happens next, not sorting by size
Request triage fails when it produces an ordering instead of decisions. The four exits, who sits in the room, and the fifteen-minute version.
- The side channel is rational
Requests arrive as DMs because the door leads to silence. Policing Slack fixes nothing; making the door the fastest path to an answer does.