Project Intake Form Template: Stop Bad Work Before It Reaches the Queue

Project Intake Form Template: Stop Bad Work Before It Reaches the Queue

A project intake form captures the decision-making facts before work is approved: the business outcome, requester, owner, urgency, scope, affected teams, effort, risks and success measure. Use it to reject incomplete requests, compare worthwhile projects fairly and route approved work without turning your project queue into a collection of untested opinions.

Updated August 24, 2026

TL;DR: A project intake form is a decision tool, not administrative paperwork. Require every requester to state the problem, desired result, evidence, deadline, owner, dependencies and success measure. Then score the request for business value, urgency, effort, risk and readiness. Return incomplete forms instead of letting project managers investigate vague ideas. Approve only work that has an accountable sponsor and a measurable outcome. Route approved requests into one visible queue, tell rejected requesters why, and review the intake process monthly. The template and scoring method below work in a document, form or spreadsheet. If requests are already scattered across email, chat and meetings, book a free project-intake workflow consultation with Wavicle.

What is a project intake form?

A project intake form is a standard set of questions used to collect and evaluate a new project request before people, time or budget are committed. It gives the decision-maker enough information to approve, reject, defer or investigate the request without a week of meetings.

The form should answer six basic questions:

• What problem or opportunity are we addressing?
• What business result should change?
• Who owns the result and who requested the work?
• Why does the work matter now?
• What people, systems and teams will be affected?
• How will we know the project worked?

An intake form is not the same as a project plan. Intake happens before approval. It decides whether the work deserves a place in the queue. A project plan comes later and explains how approved work will be delivered.

It is also not a suggestion box. Suggestions can be broad and exploratory. Intake creates a decision record. The requester must make the case, the reviewer must apply consistent criteria, and the outcome must be visible.

Current search results confirm that people looking for a project intake form template expect something usable. The live results reviewed on August 24, 2026 were dominated by templates from Smartsheet, ProjectManager, Atlassian, Tally, Bonsai and Workamajig. Their common promise is simple: collect objectives, scope, budget, timing and ownership before work starts. The template below adds the missing management layer: evidence, scoring, decision rules and routing after submission.

Why do teams need project intake before work starts?

Without intake, the loudest request often wins. Work arrives through an executive message, a sales complaint, a meeting comment or a customer escalation. Somebody says it is urgent. A project manager begins investigating. Three meetings later, nobody can state the expected result or who will own it after delivery.

That pattern wastes capacity in four ways.

First, project managers become human search engines. They chase context, locate stakeholders, translate vague requests and discover dependencies that the requester should have identified.

Second, teams compare work using inconsistent facts. One request includes a detailed business case; another has only executive enthusiasm. Both appear in the same queue as if they were equally understood.

Third, approval becomes invisible. People start small pieces of work while waiting for a formal decision, creating hidden commitments and confusing priorities.

Fourth, rejected work never receives a clear explanation. The requester resubmits the same idea through a different channel, and the cycle begins again.

The cost is not merely administrative. PMI's requirements-management research says nearly 47% of unsuccessful projects fail to meet their goals because of inaccurate requirements management. Source: Project Management Institute, Requirements Management: Core Competency for Project and Program Success, accessed August 24, 2026. Intake will not solve every requirements problem, but it can stop projects with an undefined outcome, missing sponsor or untested deadline from entering delivery as if those questions were settled.

PMI's 2024 Pulse of the Profession research surveyed 2,246 project professionals and 342 senior leaders across multiple regions. The study found that work location itself did not meaningfully change project performance; teams with suitable ways of working, capability and organizational support performed comparably across office, hybrid and remote settings. Source: Project Management Institute, The Future of Project Work, published 2024 and accessed August 24, 2026. The practical lesson for intake is that the form must create shared clarity regardless of where the request begins.

Asana's 2023 Anatomy of Work Global Index surveyed 9,615 knowledge workers across six countries. Its research summary reported that 79% of workers at collaborative organizations felt well prepared to respond to challenges, four times the share at less collaborative organizations. Source: Asana, Anatomy of Work Global Index 2023 research announcement, published February 7, 2023 and accessed August 24, 2026. A good intake process supports that readiness by putting the same facts, criteria and decision in front of everyone.

These figures do not prove that one form will improve your project success rate. They show why disciplined requirements, shared context and consistent collaboration matter before a team commits to delivery.

Which fields should a project intake form include?

Use the smallest form that still supports a real decision. A 40-question form will encourage copy-paste answers or drive requesters back to private messages. A five-question form may leave reviewers doing all the investigation.

The following template works for marketing campaigns, operational improvements, internal software, customer-experience changes, reporting projects and automation requests.

Keep optional details outside the main form. Attach financial models, research or diagrams when they exist, but do not require every small request to produce a board-level document.

How can you copy and use this project intake form template?

Copy the following structure into a document, online form or spreadsheet. Use one paragraph or a few bullets per answer.

Project request title:

Requester:

Business sponsor and decision owner:

Date submitted:

Problem or opportunity:

Who experiences the problem, and how often?

Evidence available today:

Desired business outcome:

Baseline and success measure:

Why now? What happens if we wait?

Requested decision date and delivery date:

What is included?

What is excluded?

Teams, customers or partners affected:

Known dependencies and owners:

Known risks and required reviews:

Likely effort, budget or capacity required:

Preferred solution, if any, and why:

Alternatives already considered:

After submission, add reviewer-only fields:

Completeness check:

Business-value score:

Urgency score:

Readiness score:

Effort score:

Risk score:

Decision: approve, investigate, defer, reject or return incomplete

Decision reason:

Next owner and due date:

Do not make a preferred solution mandatory. A requester may understand the pain but not the best fix. If the form asks “Which tool should we buy?” before it asks “What result should change?”, it has already biased the decision.

Use conditional questions when possible. A request involving personal information should reveal questions about access, retention and approval. A customer-facing change should ask about communication and support. An automation request should ask which actions require a person to review them. The form stays short for normal requests and becomes deeper only when the risk demands it.

How should you score project requests fairly?

Scoring does not remove judgment. It makes judgment visible. The aim is to stop priority from changing according to who is in the room.

Use five criteria, each scored from one to five:

• Business value: How strongly could the project improve revenue, cost, capacity, customer experience or risk?
• Urgency: Is there a dated event or accumulating cost, or is the deadline merely preferred?
• Readiness: Are the owner, evidence, decisions, data and affected teams available?
• Effort: How much time, money and organizational change are likely required?
• Risk: What is the potential harm if the change is wrong, late or poorly adopted?

Value, urgency and readiness increase priority. Effort and risk reduce it. A simple priority score is:

Priority score = business value + urgency + readiness − effort − risk

The formula is less important than the written reason behind each score. A “five” for value should name the expected outcome and evidence. A “five” for urgency should name the deadline and consequence. A “one” for readiness should name the missing sponsor, data or decision.

Do not automatically approve the highest number. Use hard gates:

• Return the request if required fields are incomplete.
• Do not approve work without a named sponsor.
• Send regulated, security-sensitive or high-consequence requests for qualified review.
• Do not schedule a request whose critical dependency has no owner.
• Separate investigation from delivery when the evidence is weak.

An investigation is a legitimate decision. If a revenue complaint appears serious but the data is incomplete, approve a short diagnostic with a clear question and deadline. Do not disguise uncertainty as a full project.

Calibrate scores monthly. Compare what reviewers predicted with what happened. If “small” requests repeatedly consume large effort, improve the effort questions. If high-value projects stall because adoption was ignored, strengthen the readiness score.

What decisions should happen after a request is submitted?

Every submission should receive one of five outcomes within a stated response window.

Approve means the request meets the gates, has sufficient priority and can enter planning. Approval should name the next owner, not merely change a status field.

Investigate means the opportunity may be valuable, but one or more facts must be tested before approval. State the question, evidence needed, owner and deadline.

Defer means the request is valid but loses to more important work or depends on a future event. Give it a review date. A deferred queue with no dates is a polite graveyard.

Reject means the project should not proceed under current conditions. Explain whether the reason is low value, duplication, risk, lack of fit or a better alternative.

Return incomplete means the reviewer cannot make a decision because required facts are missing. Name the missing fields and send the request back without starting a discovery project on the requester's behalf.

Publish the reason beside the decision. Transparency teaches requesters what a strong submission looks like and reduces political rework. It also lets leaders audit whether the organization is consistently funding the outcomes it claims to value.

Set a service expectation. For example, acknowledge requests immediately, check completeness within two working days and make a priority decision at the weekly portfolio review. The exact timing depends on volume, but silence should never be the process.

How should approved requests enter the project queue?

Approval is a handoff, not the finish line. The intake record should create the next work item with the context intact.

Carry forward:

• The approved problem and outcome.
• The sponsor and delivery owner.
• The baseline and success measure.
• The scope boundaries.
• The decision date and reason.
• The known dependencies and risks.
• The first planning action and its owner.

Do not make the project manager retype or reinterpret the approved request. The intake form should remain linked to the project record so later scope arguments can return to the original decision.

Keep intake status separate from delivery status. “Approved” means the organization has agreed the work deserves planning. It does not necessarily mean a team starts tomorrow. Capacity planning still decides when work begins.

Limit work in progress. If ten projects are approved and the team can responsibly deliver three, pretending all ten have started creates delay and fragmented attention. Show the difference between approved, scheduled and active work.

At kickoff, confirm that the intake facts are still true. A deadline may have moved, a sponsor may have changed or a dependency may no longer exist. Update the record rather than allowing the team to execute an expired decision.

Which parts of project intake should be automated?

Automate the repetitive movement of information, not the management judgment that gives the process value.

Useful automation can:

• Acknowledge the request and provide a tracking link.
• Check whether required fields are present.
• Return incomplete requests with the missing items listed.
• Route requests by department, risk type or expected value.
• Detect a likely duplicate and show the related request to a reviewer.
• Calculate a draft score from the reviewer's answers.
• Create the approved work item and copy the decision context.
• Notify the requester when status or ownership changes.
• Remind reviewers when the response window is close to expiring.
• Produce a monthly view of volume, approval rate, decision time and common rejection reasons.

Keep people accountable for approval, prioritization, risk acceptance and tradeoffs between teams. A formula can compare stated inputs. It cannot decide whether the evidence is trustworthy or whether a strategically important request deserves an exception.

Start with a simple form and one queue. If intake is inconsistent, adding a complicated platform will make inconsistency faster. Run the manual decision process for several cycles, observe the real exceptions, then automate stable steps.

An AI assistant may help summarize long submissions, suggest missing questions or group similar requests. Treat those outputs as recommendations. A reviewer should verify the source record and own the decision, especially when jobs, customers, money, sensitive information or contractual commitments are affected.

What project intake metrics should leaders review?

Measure whether intake improves decisions and flow, not merely how many forms were submitted.

Track:

• Requests submitted per week or month.
• Percentage returned incomplete.
• Median time from submission to decision.
• Approval, investigation, defer and rejection rates.
• Percentage of requests with a sponsor and measurable outcome.
• Duplicate-request rate.
• Approved work waiting for capacity.
• Requests started outside the process.
• Difference between estimated and actual effort.
• Percentage of completed projects that achieved the intake success measure.

Segment the numbers by team and request type. A high incomplete rate from one department may indicate unclear guidance. A low rejection rate may indicate disciplined requesters, or it may reveal that reviewers approve everything. A long decision time may come from the review meeting, missing evidence or an absent sponsor. The metric points to the question; it does not provide the diagnosis.

Review the rejected and deferred work, not only approved projects. Repeated requests for the same outcome may reveal a real unmet need. Repeated requests for the same tool may reveal that employees are trying to solve a process problem without a clear owner.

Close the loop after delivery. Compare the promised outcome with the observed result. Over time, this teaches the organization which request signals predict value and which confident claims do not.

What mistakes make a project intake form fail?

Avoid these common failures:

• The form is long enough to feel like a project plan.
• The requester must choose a solution before describing the problem.
• “Urgent” is accepted without a dated consequence.
• Reviewers score requests but never explain the score.
• Executives bypass the process while everyone else follows it.
• Incomplete requests enter discovery because reviewers are trying to be helpful.
• Approved work disappears into a queue with no owner or start rule.
• Rejected work receives no reason and returns through another channel.
• The form captures risks but nobody performs the required review.
• The process is automated before the decision rules are stable.
• Intake data is never compared with delivery results.

The most dangerous version is ceremonial intake: every request fills the form, every request is approved, and leaders continue changing priority privately. That process adds paperwork without creating a decision system.

Give the intake owner authority to return weak requests, including requests from senior people. If exceptions are allowed, record the exception, decision-maker and reason. Hidden exceptions destroy trust; visible exceptions can be governed.

How can Wavicle improve a project intake workflow?

Wavicle helps non-technical founders, operations leaders, general managers and project teams turn scattered requests into one measurable operating workflow.

The work begins with the current path: where requests arrive, what reviewers chase, how priority is decided, where approvals stall and which fields actually matter after delivery starts. The aim is not to impose a giant project-management system. It is to find the smallest process that produces consistent decisions.

Wavicle can help define the intake questions, scoring method, decision gates, response windows, ownership and management view. It can then connect the form to the tools the team already uses, route incomplete or risky requests, create approved work with the decision context attached and report where capacity is being consumed.

The result should be observable: fewer incomplete requests, faster decisions, less duplicate work, clearer ownership and a higher share of completed projects tied to a measurable business outcome.

If your team is managing project demand through inboxes, chat messages and recurring meetings, book a free consultation at wavicle.tech/contact. Bring a few recent requests, including one that went well and one that became a mess. That is enough to identify whether the bottleneck is the form, the decision rules, the handoff or the underlying portfolio discipline.

What are the frequently asked questions about project intake forms?

What is the difference between a project intake form and a project brief?

A project intake form collects enough information to decide whether work should proceed. A project brief is usually created after approval and gives the delivery team more detail about objectives, audience, scope, approach and constraints. Small organizations may combine them, but the approval decision should remain explicit.

Who should complete the project intake form?

The person requesting the work should complete the business problem, outcome, urgency and evidence. The sponsor should confirm ownership and priority. Reviewers should complete scoring, risk checks, the decision and the next owner. Project managers should not be expected to invent the requester's business case.

How long should a project intake form be?

Aim for a form that a prepared requester can complete in 10 to 20 minutes. Use roughly 10 to 15 core questions and reveal extra questions only for relevant risk or project types. If reviewers still require several meetings for basic context, improve the questions rather than simply adding more fields.

Should every request use the same project intake template?

Use the same core decision fields so work can be compared fairly. Add conditional sections for customer-facing changes, sensitive data, automation, procurement or regulated work. A single giant form for every situation will either overwhelm small requests or underserve risky ones.

What should happen to an incomplete project request?

Return it with the missing information listed and keep its status visible. Do not let a reviewer quietly fill the gaps through meetings and messages. That trains requesters to submit weak forms and transfers the cost of thinking to the project team.

Can project intake be managed in a spreadsheet?

Yes. A spreadsheet can work when request volume is modest and one owner maintains the process. Use one row per request, controlled status values, decision dates and links to the full submission. Move to a dedicated system only when routing, permissions, volume or reporting genuinely require it.

How often should project requests be reviewed?

Check completeness continuously or within a stated response window, then make priority decisions on a predictable cadence such as weekly. Urgent exceptions should have defined criteria. A daily emergency path for ordinary work means the priority system is broken.

What is the best first automation for project intake?

Automate acknowledgment, completeness checks, routing and creation of approved work items. Keep priority, risk acceptance and final approval with named people. These steps remove administrative delay without giving a system authority over business tradeoffs.