QUICK ANSWER
What should a project intake form template include?
A project intake form template should capture the requester, current situation, problem signal, desired outcome, affected groups, high-level scope signals, constraints, dependencies, safe evidence references, minimum-data boundary, human reviewer, clarification state, disposition, proposed handoff, and revision history. It should state clearly that intake does not authorize, prioritize, schedule, fund, scope, staff, or approve the project.
A useful project intake form captures one proposed whole project before anyone authorizes, prioritizes, schedules, funds, scopes, staffs, or promises it. It gives a human intake owner enough bounded context to request clarification, hold, decline, or propose the next accountable handoff without pretending the intake record is a charter, requirements document, or plan.
This original pack includes an editable Markdown form, a completed fictional JSON example, a human-triage CSV, a closed Draft 2020-12 schema, a dependency-free validator, 60 mutation and drift tests, and a deterministic ZIP. It deliberately excludes automatic scoring, approval, detailed requirements, live-form behavior, and sensitive uploads.
Build intake around one pre-authorization decision
Collect the minimum whole-project context needed for accountable human triage, then route the proposal to the correct downstream owner. Keep evaluation, authority, and delivery records separate.
Confirm that the request is a whole-project proposal
Use this owner when someone proposes a project-sized initiative and an intake owner needs a consistent first record. Smartsheet describes intake as the first stage for assessing whether an IT project should be implemented and lists sponsor, goals, dates, costs, impact, scope, and dependencies as common signals. This pack keeps those signals high level and does not convert them into approved scope or a business case.
Sources: [smartsheet-intake], [intake-pack]
Standardize context without turning the page into a live form product
Atlassian describes an intake form as a standardized document used at the start of a project, request, service, or client relationship. Asana similarly separates the form that captures requests from the later prioritization and action process. The downloadable form owns the record shape only; authentication, persistence, notifications, workflow automation, and public submission behavior belong to a separately designed product.
Sources: [atlassian-intake], [asana-intake], [intake-pack]
Record high-level signals and preserve uncertainty
Ask for the current situation, observable problem signal, desired outcome, affected groups, inclusions, exclusions, constraints, dependencies, and safe evidence references. Keep uncertainty visible as reported, confirmed, unknown, or conflicted. Do not ask the requester to manufacture certainty, priority, value, budget precision, detailed requirements, or a delivery date.
Sources: [smartsheet-intake], [intake-pack]
Keep scoring, prioritization, and approval outside the form
Asana presents scoring, prioritization, scheduling, approvals, automation, and predefined delivery steps as parts of a broader intake process. Those can be useful in an accountable operating model, but they are not neutral facts inside one request. This pack records human criteria, evidence, rationale, and a bounded disposition without computing a score or making an automatic decision.
Sources: [asana-intake], [intake-pack]
Route authorization to a separate project charter
PMI defines the project charter as the sponsor-issued record that formally authorizes a project and gives the project manager authority to apply organizational resources. That authority is why this intake locks authorized, prioritized, scheduled, and requirements-complete to false. A triage disposition may propose a charter-owner review, but it cannot create the charter or authorize work.
Sources: [pmi-charter], [intake-pack]
Minimize input and exclude uploads from the public template
OWASP recommends allowlisting structured input and enforcing server-side validation. Its file-upload guidance requires layered controls across extension, type, signature, filename, size, authorization, storage, scanning, and request protection. Because this resource does not design that system, the example expects no sensitive data, disables uploads, and uses safe references at reserved domains.
Sources: [owasp-input], [owasp-upload], [intake-pack]
Validate a closed record graph, then review the real proposal
JSON Schema Draft 2020-12 supplies the schema vocabulary used by the pack. The dependency-free validator adds cross-record rules for roles, evidence, human triage, follow-ups, handoffs, revision continuity, no-upload boundaries, safe fiction, and source parity. Structural validation catches drift; accountable people still decide purpose, authority, feasibility, capacity, risk, sensitivity, retention, and the next owner.
Sources: [json-schema], [owasp-input], [intake-pack]
What this project intake owner covers
Use the template for one pre-authorization whole-project request and its human triage state. Keep adjacent records and product behavior with their accountable owners.
Included
- Requester and intake-owner roles, current situation, problem signal, desired outcome, and affected groups
- High-level included and excluded scope signals, deliverable hints, constraints, dependencies, and safe evidence references
- Minimum-data and no-upload boundary, human review criteria, disposition, rationale, follow-ups, proposed handoffs, and revision history
- Original Markdown, JSON, CSV, closed Draft 2020-12 schema, validator, 60 tests, and deterministic exact-allowlist ZIP
Not included
- Single-feature discovery, evidence, candidate status, and product handoff owned by the feature request template
- Public or authenticated form UI, field rendering, submissions, storage, notifications, permissions, and automation owned by a live-form product
- Website-specific client discovery owned by the website design questionnaire
- Sponsor authorization and project-manager authority owned by the project charter
- Detailed business or product requirements, acceptance criteria, and traceability owned by a BRD or PRD
- Delivery sequence, tasks, assignments, resources, schedule, baseline, monitoring, and recovery owned by the project plan
- Portfolio comparison, automatic scoring, prioritization, funding, approval, or staffing decisions
- Sensitive free text, credentials, government IDs, payment data, health data, legal files, employee records, private customer records, or uploads
DOWNLOADABLE RESOURCE
Download the deterministic project intake pack
Use the Markdown form for editable human review, JSON for the closed record graph, and CSV for triage inspection. The completed service-request routing pilot is fictional, uses reserved `.test` identities, contains no upload, and remains unauthorized.
Project intake form template pack
An original provider-neutral whole-project intake record with high-level context, human triage, bounded dispositions, proposed handoffs, and explicit pre-authorization flags.
Format: Markdown form, fictional JSON example, human-triage CSV, closed Draft 2020-12 schema, dependency-free validator, tests, and package scripts in one ZIP
Locally reproduced August 1, 2026. SHA-256: be123edf1e559757315d65944fb4e6cf9e1c6e89c3feaf18c9f2c646701b9bab
Included
- Editable Markdown project intake form and completed fictional JSON example at reserved domains
- Review-friendly CSV kept in exact parity with the four human triage criteria
- Closed Draft 2020-12 schema and dependency-free validator with 60 positive, mutation, and drift tests
- Exact eight-file deterministic ZIP with fixed timestamps, safe fictional identities, no uploads, and no automatic scoring or approval
Verification boundary
After extraction, run npm run check. It validates the fictional record plus schema, Markdown, and triage-table parity. Rebuilding the repository source pack under different time zones must reproduce the locked SHA-256. The result is structural evidence only.
Three bounded project intake patterns
Each pattern gathers only high-level whole-project signals for human triage. Replace the fictional details after the requester, intake owner, sensitivity owner, and downstream decision owner review the local process.
Internal operations improvement request
Use when: A team reports a repeated operating problem that may justify a cross-functional improvement project.
Record the current operating situation, observable problem signal, affected groups, desired outcome, high-level inclusions and exclusions, reported timing constraint, dependencies, and safe evidence references. Let a human intake owner request clarification or propose a charter-owner review without estimating delivery or claiming authority.
Structure
- Requester and intake-owner roles, coarse operating context, desired outcome, scope signals, constraints, dependencies, and evidence limitations
- Human criteria, unknowns, rationale, clarification owner, proposed charter handoff, no-upload declaration, and pre-authorization flags
Watch for: Do not use the intake record as a process map, approved scope, requirements baseline, priority ranking, project charter, or delivery plan.
Sources: [smartsheet-intake], [asana-intake], [intake-pack]
Client-service initiative request
Use when: A service team needs one internal project proposal record before deciding whether discovery or authorization should begin.
Capture the requesting function, service context, desired outcome, coarse audience, exclusions, constraints, dependencies, and safe evidence references. Standardize the document, then route website-specific questions to a website questionnaire and commercial or legal details to their controlled owners.
Structure
- Internal requester role, non-sensitive service context, high-level outcome, affected group, scope signals, and evidence limitations
- Human triage state, clarification question, proposed downstream owner, explicit no-upload rule, and revision record
Watch for: Do not collect private client records, contracts, legal files, credentials, payment information, or detailed website requirements in this public intake template.
Sources: [atlassian-intake], [owasp-upload], [intake-pack]
IT modernization request
Use when: An internal team proposes replacing or improving a system and the portfolio intake owner needs a first reviewable record.
Describe the current system situation at a coarse level, the observed problem, desired outcome, affected groups, environment boundary, constraints, dependencies, and evidence locations. Preserve technical uncertainty and route any accepted proposal to separate charter, requirements, security, architecture, and planning owners.
Structure
- Whole-project request, high-level system context, included and excluded signals, data boundary, constraints, dependencies, and safe evidence references
- Human triage rationale, unresolved authority criterion, bounded disposition, proposed charter handoff, and contiguous revision history
Watch for: Do not paste network details, credentials, production configuration, private logs, personal data, target architecture, detailed requirements, estimates, or implementation tasks into a public template.
Sources: [smartsheet-intake], [owasp-input], [json-schema], [intake-pack]
Choose the record owner before collecting more detail
The deciding question is what is being requested and which accountable decision comes next. Similar-looking forms can own very different commitments.
Someone proposes one whole project and a human intake owner needs enough high-level context to clarify, hold, decline, or propose the next owner.
Choose: Use this project intake form template.
Tradeoff: The record stays intentionally pre-authorization and cannot substitute for portfolio comparison, charter, requirements, planning, or delivery evidence.
Someone reports one product capability or user problem and the team needs discovery evidence before commitment.
Choose: Use the feature request template.
Tradeoff: A feature request can feed product discovery and portfolio review, but it does not own a whole-project proposal or authorize implementation.
A sponsor is ready to formally authorize a project and assign project-manager authority.
Choose: Use the project charter template.
Tradeoff: A charter creates a materially stronger authority record and requires sponsor review that a triage disposition cannot provide.
The initiative has advanced enough to define detailed business behavior, product requirements, acceptance criteria, or traceability.
Choose: Use a BRD or PRD with its requirements owner.
Tradeoff: Detailed requirements improve downstream precision, but collecting them during first intake creates friction and can imply commitment before the proposal is accepted.
An authorized initiative needs tasks, resources, dependencies, schedule, baseline, monitoring, and delivery ownership.
Choose: Use the project plan template.
Tradeoff: Planning turns selected scope into an execution model; it should not be smuggled into a pre-authorization request.
People need to submit requests through a public or authenticated interface with storage, notifications, permissions, routing, or uploads.
Choose: Design and build a live-form product.
Tradeoff: A live product needs reviewed UX, authentication, validation, access, retention, deletion, abuse, observability, and failure handling beyond this downloadable document.
START WITH ONE REVIEWABLE REQUEST
Keep project intake useful without turning it into approval
Download the editable pack, replace the fictional values, name the human intake owner, and preserve the charter, requirements, planning, sensitivity, and portfolio boundaries.
Download the project intake packThe pack is informational and provider-neutral. Structural validation does not authorize or approve an adapted request.
What the template and validator cannot decide
A consistent intake record reduces ambiguity, but structure does not turn a proposal into an authorized or valuable project.
- The completed example is fictional and uses reserved `.test` identities. It contains no real requester, sponsor, evidence system, client, vendor, environment, or project.
- The validator checks a bounded set of obvious secret, personal-data, host, brand, formula, upload, reference, state, and revision patterns. It is not a complete privacy, security, malware, fraud, or content scanner.
- A supported criterion means only that the cited fictional evidence addresses that criterion. It does not prove strategic value, feasibility, return, urgency, risk, capacity, or priority.
- A human disposition can request clarification, hold, decline as out of scope, or propose a handoff. It cannot approve, fund, prioritize, staff, schedule, scope, charter, specify, or plan the project.
- The no-upload profile avoids an unreviewed file path; it does not establish retention, access, deletion, confidentiality, compliance, or incident-response policy for an adapted system.
- Official guidance and local governance change. Recheck sources, request categories, field purpose, owners, sensitivity, access, retention, escalation, authority, and downstream records before material reuse.
Official sources and ownership boundaries
These current official and first-party sources were checked on August 1, 2026. They informed the original field model and boundary analysis; their copy and downloadable templates were not reused.
[intake-pack] Playcode:Same-release project intake form example
Checked August 1, 2026. Supports: The exact fictional field model, human triage state, proposed charter handoff, pre-authorization flags, safe reserved identities, validator rules, tests, and deterministic archive described here.
[smartsheet-intake] Smartsheet:Free Project Intake Forms and Templates
Checked August 1, 2026. Supports: Project intake as an early assessment record and common high-level signals such as sponsor, description, goals, target dates, costs, impact, scope, resources, and dependencies.
[asana-intake] Asana:Project intake process: How to capture, score and start
Checked August 1, 2026. Supports: The distinction between the request-capture form and the broader process for review, prioritization, scheduling, approvals, automation, ownership, and next steps.
[atlassian-intake] Atlassian:Free Intake Form Template
Checked August 1, 2026. Supports: An intake form as a standardized document for collecting important information at the start of a project, request, service, or client relationship.
[pmi-charter] Project Management Institute:PMI Lexicon of Project Management Terms
Checked August 1, 2026. Supports: The project-charter authority boundary: the initiator or sponsor formally authorizes the project and gives the project manager authority to apply organizational resources.
[owasp-input] OWASP Cheat Sheet Series:Input Validation Cheat Sheet
Checked August 1, 2026. Supports: Allowlist-oriented syntactic and semantic input validation, exact options for fixed fields, and server-side enforcement for a future live intake product.
[owasp-upload] OWASP Cheat Sheet Series:File Upload Cheat Sheet
Checked August 1, 2026. Supports: The layered extension, type, signature, filename, size, authorization, storage, scanning, and request controls that an actual upload feature requires.
[json-schema] JSON Schema:JSON Schema Draft 2020-12
Checked August 1, 2026. Supports: The schema draft and validation vocabulary used to express the closed machine-readable record shape in the downloadable pack.
Project intake form template FAQ
Is a project request form template the same thing as a project intake form?
For this article, yes. Project request form template and project intake form template describe the same pre-authorization owner: one consistent record for a proposed whole project and its human triage. If your organization uses both names, define one canonical record and avoid copying the same request into competing queues.
What is the difference between a project intake form and a feature request?
A project intake form owns one whole-project proposal, its high-level context, constraints, dependencies, and human routing state. A feature request owns one product capability or user problem and its discovery evidence before implementation commitment. Route product-feature demand to the feature request owner instead of widening this project record.
Does a project intake form authorize the project?
No. This template locks authorization, priority, schedule, and requirements completeness to false. PMI assigns formal project authorization and project-manager authority to the project charter. Human triage may propose a charter-owner review, but a proposed handoff does not authorize, fund, staff, scope, schedule, or begin the work.
What information belongs in first-stage project intake?
Collect the requester and intake owner, current situation, problem signal, desired outcome, affected groups, high-level inclusions and exclusions, constraints, dependencies, safe evidence references, data boundary, human criteria, clarification state, disposition, next owner, and revision history. Ask only for information needed to make that first routing decision.
Should a project intake form score or prioritize requests automatically?
Not in this neutral request record. A broader portfolio process may compare proposals, but it should expose its inputs, uncertainty, ownership, capacity, and decision rights. This pack preserves criterion state, evidence, rationale, and a human disposition without calculating a priority score or making an automatic approval decision.
Should a project intake form accept file uploads?
Only after a separate live product defines why uploads are necessary and reviews file types, signatures, names, size, authorization, storage, scanning, access, retention, deletion, abuse, and incident handling. This public template disables uploads and uses safe evidence references because it does not implement those controls.
When should intake become a charter, BRD, PRD, or project plan?
Create a charter when a sponsor is ready to authorize the project. Create a BRD or PRD when an accepted opportunity needs detailed requirements and traceability. Create a project plan when authorized scope needs tasks, resources, schedule, baseline, monitoring, and delivery ownership. Keep links between records instead of turning intake into all four.
Can I turn this document into an online project intake form?
Yes, but treat that as a separate product build. Preserve the field purpose and boundary, then design authentication, access, server-side validation, persistence, synchronization, notifications, routing, retention, deletion, observability, error recovery, accessibility, and abuse controls. The downloadable pack validates a fictional record, not a deployed form service.
BUILD THE REVIEWED INTAKE EXPERIENCE
Turn the bounded record into an internal project intake tool
Describe the requester, intake owner, fields, permissions, states, clarification loop, evidence references, handoff boundaries, retention rules, and failure recovery you need.
Build the project intake toolThis informational article does not grant signup AI credits. The linked product page follows its own current eligibility rules.