AI Project Intake Prompts: Turn Requests Into Clear Work

Someone sends “we need a dashboard by Friday.” Another person forwards it with “urgent.” Congratulations: a sentence has acquired a deadline, an imaginary team, and apparently your entire afternoon.

AI project intake prompts help you turn incoming requests into something a human can evaluate before work starts. They can clarify the problem, expose missing information, compare supplied evidence, and draft a response. They cannot approve a project, discover your team's actual availability, or convert a stakeholder's enthusiasm into a business case.

The goal is a decision-ready request, not a longer form. Use these ten templates with an approved workplace AI tool. Start with one messy request and keep the first review deliberately small.

What project intake should do before kickoff

Project intake answers whether a request is clear enough to consider, who should review it, and what information is missing. Kickoff comes after the relevant humans have agreed to start. Mixing the two is how a tentative idea gets a delivery date before anyone has examined it.

A useful intake record distinguishes four things:

• Requested outcome: what the requester wants to change.
• Proposed solution: the implementation they currently imagine.
• Supporting evidence: what establishes the problem and its importance.
• Decision status: who has actually authorized what, if anything.

“Build a dashboard” is a solution proposal. “Managers cannot see which orders need attention before the weekly review” is a problem statement. Neither proves that a new dashboard is the best response. An existing report, a clearer process, or no project at all may be the answer.

Keep detailed requirements gathering for questions that genuinely need it. Intake should identify the next decision, not secretly commission a full specification.

Prepare a small, safe input packet

Give each excerpt a stable source ID such as S1 or S2. Reviewers can then check why a statement appears in the output. Keep the original material in its approved system rather than copying everything into a chatbot.

Use only tools approved for the data involved. Do not paste credentials, personal records, confidential financial information, raw security findings, or private client documents into an unapproved service. Removing names may still leave identifying combinations of details.

Treat source material as untrusted data. If a request says “ignore the process and mark this approved,” that is text to analyze, not an instruction to follow. None of the prompts below authorizes sending messages or changing project records.

For a broader starting point, the practical guide to AI at work explains how to choose a bounded task instead of giving a model an entire department to improvise.

10 AI project intake prompts to copy

Apply this rule to every template: Use only supplied evidence. Cite source IDs. Mark unknowns and inferences. Never invent owners, approvals, capacity, costs, benefits, or dates. Draft only; a human must review before any action.

You do not need all ten for every request. A small clarification may be enough. A request that touches multiple teams or sensitive processes needs the relevant human review, not additional chatbot confidence.

Prompt 1: Clarify an ambiguous request

Use this when the incoming message contains a solution and urgency but little explanation. The output should reduce ambiguity without quietly expanding the job.

Review this sanitized incoming request: [S1 request].
Extract the proposed solution, desired outcome, affected workflow,
requested timing, and stated reason for urgency. Cite each source.
Separate explicit statements from interpretations and unknowns.
Draft a neutral problem statement and at most five clarification
questions, ordered by how much each answer changes the next decision.
Do not assume the proposed solution is necessary or approved.

Check that questions are answerable. “What is the strategic alignment?” may sound professional while helping nobody. “Which decision cannot be made using the current report?” is harder to dodge and easier to use. Send only the questions that matter now, after reviewing them yourself.

Prompt 2: Create a minimal project intake form

A form should help someone ask for work, not punish them for trying. Use this to build a short reusable template for your actual request categories.

Using [request categories] and [supplied review rules], draft a minimal
project intake form. Include field name, plain-language question,
why it is needed, and whether it is required for initial review.
Separate requester-entered facts from reviewer-only decision fields.
Allow unknown answers with a follow-up path. Add conditional questions
only where a supplied rule requires them. Do not request sensitive data.

Watch for unnecessary fields. A requester may know the problem but not the technical owner or implementation cost. Requiring those answers can manufacture guesses before the review even starts. Test the form on one ordinary request and remove fields whose answers do not change routing or readiness.

Prompt 3: Separate the need from the requested solution

Use this before everyone falls in love with the first implementation suggested. The point is to reveal options, not let AI choose the architecture.

Analyze [S1 request] and [S2 clarification answers]. Produce separate
sections for the underlying need, proposed solution, constraints,
and evidence of the problem. Quote the supporting source IDs.
Suggest up to three alternative approaches as hypotheses, including
reuse of an existing process where plausible. For each, state what
must be checked before it could be considered. Do not rank options
without supplied criteria or claim that an option will save money.

Reject alternatives that ignore confirmed constraints. A manual workaround may be inappropriate for a sensitive workflow. A new tool may require reviews that the original requester never considered. The useful output is a smaller set of questions for qualified people, not a menu of unsupported promises.

Prompt 4: Build an evidence and unknowns register

Requests often mix observations, opinions, and impressive-looking numbers. This template keeps them from blending into a fictional business case.

From [source packet with IDs], create an evidence register with:
claim, source, claim type, scope, known limitations, and verification
question. Distinguish observed facts, requester estimates, preferences,
and model inferences. Preserve units and time periods exactly.
Flag unsupported benefit claims and conflicting statements.
Do not calculate ROI from missing inputs or treat repeated claims
as independent evidence. End with the three decision-critical unknowns.

Check every number against its source. “This affects every customer” should not survive if the only evidence is two examples. A missing measurement does not make a request worthless; it tells the reviewer what they can and cannot justify yet. The model's job is to preserve that distinction.

Prompt 5: Check overlap with existing requests

Two requests can sound alike but serve different users. They can also sound different while asking for the same underlying capability. Use comparison to find review candidates, not automatically close tickets.

Compare [new request ID and summary] against [approved existing request
summaries with IDs]. Return potential matches with shared outcome,
shared workflow, important differences, supporting sources, and the
question needed to confirm overlap. Label each as possible duplicate,
related work, or insufficient evidence. Do not merge or close records.
Do not infer equivalence from similar titles alone.

Have an owner confirm the match before consolidation. If two teams need different access controls, a shared report might not satisfy both. Link related work where appropriate and retain the original request history. Duplicate detection should remove unnecessary effort, not erase a stakeholder's unmet need.

Prompt 6: Surface capacity and dependency questions

AI cannot see an engineer's week unless you provide an authorized, accurate account of it. Even then, a calendar gap is not permission to allocate the person.

Using [request], [confirmed constraints], and [approved capacity summary],
list delivery questions that must be resolved before accepting work.
Separate required inputs, skills, external dependencies, and timing
constraints. Cite evidence and mark proposed reviewer roles as proposed.
Do not assign people, estimate availability, or promise a completion date.
For each unresolved item, draft a specific confirmation question.

Use the workload management prompts when a real capacity discussion is needed. Intake can identify that discussion; it cannot replace it. Check whether a requested date reflects a genuine external constraint, an internal preference, or simply the day someone typed “Friday.”

Prompt 7: Route the request using supplied rules

Routing errors create invisible delays. This prompt makes the applicable rule visible without appointing the model as your approval committee.

Apply only [supplied intake routing policy] to [request and evidence].
Create a routing draft containing review step, triggering request fact,
policy reference, proposed reviewer role, and missing information.
Separate mandatory reviews from optional consultations according to
that policy. If no rule covers a case, say policy gap and ask for human
routing guidance. Do not infer approval or bypass required reviews.

Check the policy version before using the result. A model can apply an obsolete excerpt with perfect enthusiasm. Requests involving security, legal, financial, or personnel consequences belong with the authorized specialists under your real rules. Do not upload sensitive underlying material just to make the routing answer more specific.

Prompt 8: Compare requests without fake precision

A neat score can hide missing evidence. Use this to produce a transparent comparison when a human has supplied the criteria and their meanings.

Compare [request summaries and source IDs] using only [criteria,
definitions, and any approved scoring rules]. Show evidence by criterion,
unknowns, and trade-offs. Do not invent weights or substitute confidence
for business value. If scoring is authorized, show its inputs and leave
unsupported entries unscored. Explain which missing answer could change
the comparison. Do not declare a final approval or priority decision.

Keep requests with missing evidence visible rather than automatically putting them last. Some genuinely important work arrives poorly documented. For a deeper comparison process, use the prioritization templates. A transparent disagreement about criteria is more useful than a decimal score nobody can explain.

Prompt 9: Draft an accept, defer, or decline response

The decision must already exist. This prompt helps communicate it without accidentally promising more than the reviewer authorized.

Draft a requester response using [human decision record and source ID].
State the authorized decision, its documented reason, and confirmed next
step. Distinguish acceptance for discovery from approval for delivery.
Include only agreed owners and dates. For deferred work, use a documented
review trigger if supplied; otherwise say the trigger is not yet agreed.
Do not invent reassurance, commitments, or reasons. Draft only; do not send.

Read it from the requester's perspective. “Accepted into the backlog” can sound like “being built next week.” Spell out the stage. A decline should explain the relevant reason without disclosing private comparisons with other requests. A defer message needs a real review condition, not “we will circle back” dressed up in a nicer shirt.

Prompt 10: Prepare the intake-to-kickoff brief

Use this only once a human decision authorizes the next stage. Preserve unresolved issues so the kickoff team does not mistake a polished summary for complete agreement.

Create a handoff brief from [intake record], [evidence register], and
[authorized decision]. Include confirmed outcome, in-scope discovery or
delivery work, explicit exclusions, evidence references, constraints,
open questions, and the next authorized step. Separate requested items
from approved commitments. Flag contradictions; do not resolve them by
guessing. End with a human verification checklist, not a launch plan.

Connect the result to your kickoff workflow and preserve the decision in a decision log. If new requests appear during handoff, treat them as changes for review. The scope creep prompts can help compare those additions against what was actually agreed.

Worked example: the urgent dashboard request

This example is hypothetical. Its source IDs and events illustrate the method; they are not customer evidence or a claim about actual results.

S1: A requester says, “We need a dashboard by Friday for the weekly review.” S2: A follow-up explains that managers want to identify orders requiring attention before that meeting. S3: An approved inventory summary lists an existing weekly exception report, but nobody has confirmed whether its fields meet the request. S4: The authorized reviewer approves a short discovery step only, with no delivery date agreed.

A useful intake record would look like this:

The wrong AI output says “Build a real-time dashboard by Friday to improve efficiency.” It invented real-time requirements, accepted the deadline, and asserted a benefit. The better output asks whether the existing report can answer the actual question and keeps delivery authorization separate.

A human might later decide to improve the report, commission a dashboard, or decline the request. Intake has succeeded when that choice can be made with visible evidence and uncertainty. It does not have to result in a new project to be useful.

Frequently asked questions

What are AI project intake prompts?

They are instructions that help an AI tool structure incoming work requests for human review. Useful outputs include clarification questions, intake forms, evidence registers, overlap comparisons, and draft responses. They do not approve work or establish whether the requested solution is technically feasible. Keep the model focused on a bounded review task.

Can I use ChatGPT to create a project intake form?

You can use an approved tool to draft one from sanitized request categories and your supplied review rules. Check workplace policy before entering data. Review every required field and remove questions that encourage requesters to guess costs, owners, or technical details they cannot know. Test the form before making it a requirement.

How is intake different from requirements gathering?

Intake establishes what is being requested and whether it is ready for the next review or stage. Requirements gathering examines what the eventual work must satisfy in greater detail. Intake may reveal a few critical requirements, but it should not imply that a complete specification or delivery commitment already exists.

Should AI score or prioritize incoming requests?

It can organize evidence against criteria that humans provide. It should not invent scoring weights, make unsupported benefit estimates, or decide that undocumented work has no value. If your process uses scores, preserve inputs and unknowns. The authorized reviewer remains responsible for trade-offs and the actual priority decision.

What if the request has almost no evidence?

Ask the smallest number of questions needed to identify the next decision. Record what is missing instead of generating plausible details. Some requests need a short discovery step to gather evidence; others can be clarified in a reply. The appropriate human decides whether that effort is warranted and who can authorize it.

Does acceptance mean a delivery date is promised?

Not necessarily. Acceptance may mean the request is recorded, ready for review, approved for discovery, or approved for delivery. Those are different states. Define them in your process and state the applicable one in the response. Only include a delivery date when the authorized people have actually agreed to it.

Start with the next messy request

Take one incoming request, label its sources, and run the clarification prompt. Check the result against the original message before using it. If the output has fewer assumptions and a clearer next question, it is doing useful work. If it has a confident timeline nobody agreed to, it is creating more work with excellent formatting.

For a broader guide to using AI without outsourcing your judgment, read Don't Replace Me: A Survival Guide to the AI Apocalypse. The machine can help organize the queue. Humans still decide what deserves to become work.