A project intake form is a short, standard form that every new project request fills in before anyone commits money or people to it. Its whole job is to capture the same core facts from every idea, the problem, the sponsor, the rough cost, the expected benefit, so that ten requests arriving in ten different formats become ten comparable records a PMO can actually rank. Without one, the loudest requester wins and the important work waits. This guide gives the fields the form needs, a filled example you can copy, and the steps to build one in Excel, Word, or a form tool.
Key takeaways
- A project intake form standardizes what every new request must state up front, so requests can be compared on the same basis instead of on who asked most persistently.
- The essentials are the requester and sponsor, the problem and desired outcome, the strategic objective, rough cost and effort, the expected benefit, key risks, and any hard deadline or dependency.
- Keep it short. A form a busy manager will fill in honestly beats a thorough form nobody completes. If a field will not change a decision, cut it.
- The form is the artifact; the intake process is the workflow around it (who reviews, how it gets scored, where it goes next). The two are covered separately and linked below.
What is a project intake form?
A project intake form is a structured request form that collects a consistent set of information from anyone proposing a new project, so the request can be logged, screened, and scored the same way as every other request. It is the front door to the portfolio: the point where a vague idea in someone's inbox becomes a defined candidate with a sponsor, a rough size, and a stated benefit. The form does not approve anything. It makes the request complete enough to decide on.
The form is one piece of a larger workflow. The steps around it, who receives requests, who reviews them, how they get scored and routed, are the project intake process. This page covers the form itself: what goes in each field and how to build it.
What should a project intake form include?
A project intake form should include the requester and sponsor, a plain description of the problem and the desired outcome, the strategic objective it supports, a rough estimate of cost and effort, the expected benefit, the key risks, and any hard deadline or dependency. Everything else is optional. The table below is a complete field set you can lift straight into a template; trim the rows that will not change a decision in your organization.
| Field | What goes in it | Why it matters |
|---|---|---|
| Request title and date | A short name for the request and the date submitted | Gives every request an identity and a place in the queue |
| Requester and department | Who is asking and which team they sit in | Shows where demand is coming from across the organization |
| Sponsor | The senior person willing to fund and defend the request | A request with no sponsor is a wish, not a candidate |
| Problem or opportunity | The business problem to solve, stated as a problem not a solution | Forces clarity on the actual need before a solution is locked in |
| Proposed outcome | What "done" looks like and who benefits | Sets the scope and the success test up front |
| Strategic objective | The company goal or driver this request supports | Lets you screen out work that fits nothing on the strategy |
| Expected benefit | The value expected: revenue, cost saved, risk reduced, compliance met | The basis for ranking one request against another |
| Estimated cost and effort | A rough order-of-magnitude budget and the roles or hours needed | A request with no size cannot be weighed against capacity |
| Timeline or deadline | Requested start, target date, and whether the deadline is hard | Separates genuine time pressure from wishful urgency |
| Dependencies | Other projects, systems, or teams this relies on | Surfaces conflicts before they derail delivery |
| Risks and constraints | Known risks, compliance drivers, or fixed constraints | Flags requests that carry more than their size suggests |
Swipe to see more →
Two fields do most of the work. The problem statement is where requests fall apart: people describe the solution they want ("we need a new CRM") instead of the problem ("sales cannot see account history, so deals stall"). Push for the problem. The expected benefit is what makes the request scorable later, so it should be as concrete as the requester can honestly make it, even if it is only a rough range.
A sample project intake form
Here is the same field set filled in for a realistic request. A completed example is worth more than an empty template, because it shows the level of detail the form is actually asking for.
| Field | Example entry |
|---|---|
| Request title and date | Customer portal self-service, submitted March 4 |
| Requester and department | D. Okafor, Customer Support |
| Sponsor | VP of Customer Experience |
| Problem or opportunity | Support handles 4,000 password and billing tickets a month that customers could resolve themselves; agents cannot reach higher-value cases. |
| Proposed outcome | A self-service portal for password resets, billing history, and plan changes, cutting routine tickets. |
| Strategic objective | Improve customer experience and reduce cost to serve. |
| Expected benefit | Deflect roughly 30 percent of routine tickets; free about 1.5 agent full-time equivalents for complex work. |
| Estimated cost and effort | Rough order of magnitude 120,000 dollars; two developers and a designer for about four months. |
| Timeline or deadline | Preferred start Q3; no hard external deadline. |
| Dependencies | Needs the identity system upgrade already in flight. |
| Risks and constraints | Portal must meet accessibility standards; benefit depends on customer adoption. |
Swipe to see more →
Notice what the completed form makes possible. A reviewer can see the size, the benefit, the strategic fit, and the dependency on another project, everything needed to score it against the other requests in the queue, without a single meeting. That is the point of the form.
How do you create a project intake form?
You can build a workable intake form in under an hour. The tool matters less than the discipline of using one form for everything.
- Pick where requests will land. A shared online form (Google Forms, Microsoft Forms, or a form in your work-management tool) beats a document, because it drops each submission into a single list automatically. A Word or Excel template works too if you keep every completed form in one folder or sheet.
- Add the fields above as questions. Use short-answer boxes for names and titles, longer text for the problem and outcome, and dropdowns for strategic objective and benefit type so entries stay consistent and sortable.
- Make the few decision-critical fields required. Sponsor, problem, expected benefit, and rough cost should be mandatory. Leave the rest optional so the form stays fast to complete.
- Send every submission to one intake log. A single spreadsheet or list where each row is a request is what turns the forms into a queue you can screen and rank. Mature teams go further and automatically route each new request to the right reviewer instead of triaging the inbox by hand.
- Review and score on a schedule. The form feeds a regular intake review where requests are scored and either advanced, held, or declined. How that scoring works is covered in project prioritization criteria.
Should you use one intake form or several?
Use two, occasionally three, sized to what the request will cost. A single form for every request is the most common reason intake dies: it is either so short that large proposals arrive unassessable, or so thorough that a manager with a two week idea gives up and goes around it. Match the effort of asking to the size of the ask.
| Request size | Form | Fields | Decision path | Response time |
|---|---|---|---|---|
| Small, under roughly 20 days of effort | Fast lane | Requester, sponsor, problem, rough effort, deadline. Five fields. | Team or delivery lead decides. Logged, not scored. | 5 working days |
| Standard, a few weeks to a few months | Full intake form | The complete field set above. | Screened, scored, ranked against the current queue. | 15 working days, or the next intake cycle |
| Large or strategic | Full form plus a business case | The form triggers a case, it does not replace one. | Portfolio board, usually at a gate. | Next board meeting, stated on submission |
Swipe to see more →
Set the boundary in whatever unit your organization argues about, days of effort or dollars, and publish it. The number matters far less than the fact that it is written down, because an unpublished boundary gets negotiated on every request by whoever is most senior in the room.
The fast lane is what protects the rest of the system. Without a legitimate route for small work, small work does not disappear; it gets done informally by people who were assigned to something else, and it shows up later as unexplained variance in your capacity numbers. Logging it, even without scoring it, is what makes that shadow demand visible.
Which fields should be dropdowns rather than free text?
Anything you will later sort, filter, count, or score must be a dropdown. Free text is fine for the problem statement and the outcome, and nowhere else. This one design choice is the difference between an intake log you can rank in an afternoon and a folder of documents somebody has to read and re-key.
| Field | Control | Options to offer | Why |
|---|---|---|---|
| Strategic objective | Dropdown, single select | Your actual published objectives, plus "none of these" | The most important dropdown on the form. Free text here means every request claims to be strategic in its own words, and none of them can be counted. Keep "none of these" as a real option; it is how you find work that is worth doing but is not strategy. |
| Benefit type | Dropdown | Revenue, cost reduction, risk reduction, compliance, capability | Different types are scored on different scales. Mixing them in one text box makes fair comparison impossible. |
| Estimated cost | Dropdown of bands | Under 25k, 25k to 100k, 100k to 500k, over 500k | Bands get answered honestly. An exact figure at intake is invented, and then it gets quoted back as a commitment for the next two years. |
| Estimated effort | Dropdown of bands | Under 20 days, 20 to 100, 100 to 500, over 500 | Also routes the request to the right form tier automatically. |
| Deadline type | Dropdown | No fixed date, preferred date, hard external date | Separates real constraints from preference. "Hard external date" should require a follow-up field naming the regulation, contract, or event. |
| Requesting department | Dropdown | Your org list | Lets you see demand by area, which is usually the first genuinely surprising chart intake produces. |
| Problem or opportunity | Free text, with a character limit | A limit of around 500 characters | The limit is the feature. It forces a requester to state the problem rather than attach a deck. |
| Proposed outcome | Free text, limited | Around 300 characters | Same reason. Short answers are easier to compare and harder to hide in. |
Swipe to see more →
One warning on the objective dropdown. If your published objectives are broad enough that every request can honestly pick one, the field has told you nothing and everything will screen through. That is a strategy problem surfacing in a form, and it is better to find it here than three quarters into the year. It is also the field to revisit whenever the strategy changes, because a stale option list quietly keeps routing new work against last year's priorities.
What makes an intake submission incomplete?
A submission is incomplete if it is missing a named sponsor, a problem statement, a benefit, or a size band. Those four make a request comparable; the rest can be filled in later. Return incomplete requests to the requester rather than completing them yourself, and log the return so the queue reflects reality.
The temptation to fill in the gaps on someone's behalf is strong, especially when the PMO can guess the answer. Resist it. A sponsor the PMO nominated has not agreed to anything, and a benefit the PMO estimated becomes the number the project is measured against for years.
| What arrives | Outcome | What you send back |
|---|---|---|
| Missing sponsor | Return | Ask who will fund and defend this. If no name comes back within two weeks, close it. Most do not come back, and that is the form working. |
| Solution stated as the problem | Return with one question | "What happens today that this would stop happening?" Usually produces a better request, and sometimes a smaller one. |
| No benefit, or benefit stated as "efficiency" | Return | Ask for a direction and a rough size: which number moves, and roughly how much. |
| No size band | Return | Offer the bands again. Nobody needs an estimate, only a bracket. |
| Duplicate of an existing request or live project | Merge, do not reject | Link the two and tell both requesters. Rejecting a duplicate makes people submit it again under a different title. |
| Complete but fits no strategic objective | Accept and score it anyway | Not every worthwhile request is strategic. Route it to the fast lane if it is small, and let the ranking handle it. |
Swipe to see more →
Track your return rate. A rate above roughly a third usually means the form is asking for something people cannot reasonably know at submission, and the fix is to the form rather than to the requesters. A return rate near zero usually means requests are being tidied up on the way in, which feels helpful and hollows out the comparison the form exists to make possible.
What is the difference between a project intake form and an intake process?
The form is the document that captures a single request; the intake process is the end-to-end workflow that receives, reviews, scores, and routes every request. The form is a noun, the process is a verb. You need both: a great form with no process behind it collects requests nobody acts on, and a process with no standard form drowns in requests that cannot be compared. The full workflow, including who owns it and how requests connect to prioritization, is in the project intake process guide.
Who fills out a project intake form?
The person requesting the work fills out the intake form, usually a manager or team lead who has spotted a problem or opportunity, often with help from the sponsor who will fund it. In practice the PMO or a business analyst frequently helps the requester complete the harder fields, especially the expected benefit and rough cost, because those are the fields requesters tend to leave vague. The named sponsor is what separates a real candidate from an idea, so a form without one usually goes back before it enters the queue.
What happens after a project intake form is submitted?
After submission the form enters the intake log and waits for the next intake review, where it is screened for completeness, scored against the portfolio's criteria, and then advanced to business-case development, put on hold, or declined with a reason. A well-run intake never leaves requests in silence: every requester gets a decision and a rationale, which is what keeps people using the front door instead of lobbying for their projects through side channels. Requests that advance usually move next into a fuller project business case, and the wider funnel of managing all this incoming demand is covered in demand management. The staged flow that carries an approved request from here through to delivery is the project pipeline.
Turning good intake into a ranked portfolio
An intake form is only as valuable as what happens to the data it collects. Captured consistently, those fields feed straight into a scoring model that ranks candidates on benefit, strategic fit, and effort, which is how a queue of requests becomes a funded, prioritized portfolio. See the project scoring model for the scoring math and how to prioritize a project portfolio for the decision that follows.