Project Intake Form: Fields, Routing and Triage Rules

Ask for what you need to make a decision, and nothing else. A workable core set is:

• Requester and team, filled in automatically where your tool allows.
• Request title in a sentence, and what problem it solves.
• Who benefits, and what happens if it doesn't get done.
• Desired date, and whether the date is fixed by something external.
• Rough size: small (a day or two), medium (a few weeks) or large (more than a month).
• Links to anything relevant, such as a brief, ticket or customer thread.
• Budget owner, if the work costs money.

Make the problem statement required and the solution optional. Requesters who write "build a dashboard" have already jumped to a solution. "We can't see which customers are waiting on onboarding" tells you what to solve.

Not every request needs every question. A conditional form shows extra fields only when relevant: if the requester picks "needs a vendor", ask for vendor name and contract date; if "affects customers", ask which customers and whether they've been told. This keeps the form short for simple requests and complete for complex ones.

Test the form with three real recent requests. If you can't decide what to do with any of them using only the form's answers, add the missing question. If a field went unused in all three, remove it. Project tools such as Asana and Monday.com both support forms that create tasks or board items directly, so answers land where the work happens without re-typing.

Set a short, visible routine so requesters know what happens next:

1. Every submission lands in one queue with one named triager, and a backup for absences.
2. The triager reviews the queue on a fixed schedule, such as twice a week, rather than continuously.
3. Each request gets one of four outcomes: accept and schedule, ask a clarifying question, defer with a review date, or decline with a reason.
4. The requester gets an automatic acknowledgment at submission and a human reply after triage.
5. Accepted requests get an owner, a start window and a place in the plan.

The reply matters as much as the decision. A "no" with a reason and a suggested alternative keeps people using the form. Silence teaches them to go around it with a direct message.

Score requests on three questions: how many people or customers it affects, how costly the delay is, and how much effort it takes. A simple 1 to 3 scale for each is enough to sort a queue. High reach, high delay cost and low effort come first. Low reach, low cost and high effort come last.

Watch capacity while you triage. If the team already has more accepted work than hours, accepting another request means delaying something. Make that tradeoff explicit: "We can take this if we move X to next month." Before accepting, count what's available in billable hours for the people who'd do the work. The operations KPI dashboard can track queue size and time to triage.

Look for these patterns in a form that people avoid:

• Too many required fields, so people skip the form and message someone directly.
• No visible response time, so requesters can't tell whether anyone read the submission.
• Several forms for the same team, which makes the queue impossible to prioritize.
• Triage by whoever is loudest, instead of by the criteria above.
• Requests that never get closed, leaving a queue full of items nobody will do.

Every quarter, close anything older than 90 days with a message asking the requester to resubmit if it still matters. Pair the form with a weekly status report, such as the weekly project status report, so accepted work stays visible to requesters.