Project Intake Form: Turn New Requests Into Clear Decisions
Download a project intake form with a complete example, a practical triage process, and reply scripts that separate receipt, approval, and scheduling.
A project intake form collects the information needed to decide whether proposed work should proceed. It should describe the problem, desired outcome, audience, deadline reason, scope, dependencies, and requester. Keep submission, approval, and scheduling separate: receiving a complete form does not mean the team has promised to do the work.
The form should clarify a decision, not transfer an unclear email into an unclear tracker.
What should the form ask?
Ask for information that changes the decision: why the work matters, what result is needed, what constrains timing, and who can clarify or approve it. Avoid demanding a fully engineered solution from someone who is asking for help defining the problem.
Download the project intake form. The plain text file includes requester prompts, a reviewer section, a completed fictional request, and three reply scripts. It is free to use without registration.
| Requester field | Helpful prompt |
|---|---|
| Problem | What is happening now that needs to change? |
| Outcome and audience | Who benefits, and what should they be able to do? |
| Proposed deliverable | What are you asking the team to produce? |
| Deadline and reason | What date matters, and what happens if it changes? |
| Scope and exclusions | What belongs in this request, and what does not? |
| Dependencies | Which people, inputs, or approvals are required? |
| Requester and approver | Who can answer questions and accept the result? |
| Existing material | What can the team reuse or inspect? |
Keep the reviewer fields separate: fit, missing information, capacity, decision, owner, and next update. The requester can explain urgency; the team must still assess it against other commitments.
The University of Delaware's project intake service captures items including the business driver, proposed dates, problem, staffing needs, and funding status. Its institutional process is larger than many small-team needs, but it demonstrates why a request needs context beyond a title and due date.
Follow required procurement, security, and funding processes. This form does not authorize bypassing those decisions.
What does a completed request look like?
A completed request explains the need without pretending the proposed solution is already approved. This fictional example concerns an operations team receiving a request for an onboarding FAQ; the dates and scope are illustrative.
Request title: make expense instructions easier for new starters to find.
Problem: the welcome message links to several documents, and new starters ask their team lead which expense instructions are current.
Outcome and audience: new employees should be able to locate the approved submission steps and the right help contact from their welcome message.
Proposed deliverable: a short FAQ and one updated welcome-message link. The requester is open to a simpler change if it solves the same problem.
Deadline and reason: requested before the next cohort's welcome message is sent. The requester must confirm the actual send date; “as soon as possible” is not enough to reserve a delivery slot.
Scope: answer the agreed recurring questions using existing policy. Exclude changing reimbursement rules or choosing a new expense platform.
Dependencies: the policy owner must identify the authoritative source and review any wording that interprets the rules.
People: Jordan is the requester and can supply recurring questions. Avery is the policy owner. The delivery owner has not yet been assigned.
Existing material: the welcome-message draft and the current policy documents are available in the approved shared folder.
Reviewer decision: needs information. Confirm the send date and review availability before evaluating delivery capacity.
The request is understandable, but the team cannot promise a date yet.
Asana's intake guidance separates stages such as new, triage, review, acceptance, and scheduling. You do not need its software to preserve that distinction in your own workflow.
After acceptance, use a project brief to record the agreed scope and delivery commitment.
How do you triage requests?
Review fit, completeness, consequence, and capacity before assigning a delivery slot. A polished request can still be the wrong work, and an important request can still need a different team or a later date.
Use this sequence:
- Fit: does this work belong to the team, and can it support the intended outcome?
- Completeness: is there enough information to estimate or decide? Ask only for the missing information that matters.
- Timing: is the date an external constraint, a preference, or an assumption?
- Dependencies: are inputs and approvers available when needed?
- Capacity: what existing commitment would this work displace?
- Decision: accept, request clarification, defer, decline, or route elsewhere, with a reason and next step.
The approaching cohort matters, but it neither eliminates policy review nor automatically outranks existing commitments.
Use the weekly focus capacity calculator to examine available time, then compare the request with the work already planned. A capacity check should include ongoing responsibilities and review time, not just an empty-looking calendar.
Avoid a scoring formula unless the criteria improve the decision. “Impact: five” is not evidence. “The current welcome link points to an outdated policy” is an observable condition that a reviewer can verify.
Delaware's intake process explicitly includes staffing and funding information. For a small team, the equivalent question may be simpler: who will do this, and what must move to make room?
Record who can authorize the tradeoff; receiving a request does not confer authority over other commitments.
How do you reply without overpromising?
State the request's current status and the next decision. Use different language for acknowledgment, acceptance, and scheduling so the requester cannot reasonably mistake “received” for “will deliver Friday.”
These are original scripts you can adapt:
Receipt: “I have received the FAQ request. Before we assess timing, please confirm when the welcome message will be sent and who can review the policy wording. I will update you after those two points are clear.”
Accepted, not scheduled: “The FAQ fits our team's scope. We still need to agree on capacity and a review window before promising a delivery date. I will bring the scheduling choice to the next planning discussion.”
Scheduled: “We have agreed to produce the FAQ and update the welcome link. Robin owns delivery, and Avery has confirmed the review window. The agreed date applies to that scope; additional requests will need a separate timing check.”
Asana's process separates accepted from scheduled work. Keep the same distinction visible in the language you send, even if your entire intake system is a shared document.
When the request cannot fit, explain the tradeoff rather than offering an ungrounded apology: “We can bring this forward if the current guide revision moves. Otherwise, the next available slot is after that delivery.” Use a clear boundary conversation when someone must choose between competing promises.
Silence is not approval. Record any missing decision and keep the request in the appropriate stage.
How do you keep the process lightweight?
Remove questions nobody uses and add clarity where requests repeatedly stall. A useful form earns its place by reducing follow-up work, not by making requesters prove they can complete an elaborate administrative exercise.
Inspect recent requests. Identify missing answers that delayed decisions and fields nobody used; revise the form accordingly.
Offer help when a requester knows the problem but cannot name the deliverable. A short conversation may be faster than returning the form repeatedly. Capture the result afterward so the same uncertainty does not reappear during delivery.
Keep one visible queue and one current decision record. Link to approved shared material instead of duplicating sensitive documents in a broadly accessible form.
Move accepted work into the weekly plan. Do Only 3 Things a Day addresses the personal commitment that follows: deciding what can receive focused attention today. Intake makes demand visible; it does not create unlimited time to satisfy it.
Frequently asked questions
Is an intake form the same as a project brief?
No. Intake captures proposed work for evaluation. A brief records the agreed work and boundaries after clarification. Some fields overlap, so reuse confirmed information instead of asking the requester to type it twice.
Should every request receive a numerical score?
Only if the criteria help the decision and can be applied consistently. A score should summarize evidence, not replace it. For a small queue, a documented tradeoff may be clearer than a weighted formula.
Can we use email instead of a form tool?
Yes. Use consistent prompts and transfer the request into a shared decision record. Make ownership and status visible so the process does not depend on one person's inbox or memory.
What about emergency work?
Use the organization's established urgent-response route. Capture the essential facts without delaying necessary action, then record the commitment and displaced work afterward. The routine form should not become a barrier to handling an actual emergency.