The AI Use-Case Intake Form That Stops Pet Projects at the Door

A weak intake form does not reduce bureaucracy. It relocates bureaucracy into the meeting where expensive people are now discovering basic facts out loud. That is the opposite of speed.

The scale of the gap is already measurable. Zapier's August 17, 2026 governance survey found 91% of executive leaders say their organizations have AI governance policies, yet nearly four in five say employees work around those same processes to deploy or modify AI workflows faster. The paperwork exists. The operating system does not.

The same pattern shows up in accountability. KPMG's June 24, 2026 Global AI Pulse found only 24% of leaders say the CEO is accountable for AI-driven business outcomes. The organizations with clear top-level accountability report meaningful value at 57%, against 21% for everyone else. Ownership is not a governance side note. It is the difference between AI spend that compounds and AI spend that drifts.

And the requests keep coming. Salesforce's February 5, 2026 Connectivity Report says organizations already use an average of 12 AI agents, while 83% say most or all teams have adopted them and 50% of agents operate in isolated silos. By the time your roadmap committee meets, the company is not debating one future use case. It is trying to regain control of a live system.

The form should force seven answers. Each one earns a real decision.

First, what business problem are we solving. Not "an AI assistant for support." That is a tool category. The answer must name the broken work, the baseline, and the cost of leaving it alone.

Second, who owns the outcome. Not the person excited about AI. The owner is the person who can tell the team to change the workflow on Monday morning and who will still own the result when the novelty has worn off. If there is no such person, reject the request. A committee is not an owner.

Third, what exact workflow is in scope. One workflow, one user group, one output. Gartner's July 31, 2026 roadmap guidance is blunt about the need to invest in foundations around value management, organization, governance, engineering, and data rather than treating AI as a tools exercise. Intake is where that discipline starts.

Fourth, what data will the system touch. That means systems, permissions, sample access, refresh rate, and the system of record. If the team cannot reach representative data inside ten working days, they are not asking for an AI build yet. They are asking for a data cleanup or integration project.

Fifth, what evidence threshold would make this worth funding next. State the measure, target, review window, and stop rule in writing. KPMG's June 24, 2026 Global AI Pulse found organizations with strong cost visibility are five times more likely to report established ROI, 15% versus 3%. You do not get cost visibility after the fact. You design for it during intake.

Sixth, what happens when the output is wrong. The requester should say how the mistake is caught, who handles escalation, what action is reversible, and when a human must approve. If the only answer is "we'll monitor it," the request is still a sketch.

Seventh, what next decision are we asking for right now. Reject, return for evidence, park, fund discovery, or approve a bounded pilot. One request, one decision. Otherwise the form becomes an idea dump and the roadmap inherits the sorting job.

You do not need fancy software to start. A form in Notion, Airtable, Google Forms, or your ticketing system is enough if it forces the right fields.

# AI use-case intake form

## Request summary
- Request title:
- Department:
- Submitted by:
- Date:

## 1. Business problem
- What business problem are you trying to solve?
- What is the current workflow today, without AI?
- What baseline number proves the problem is real right now?
- Why does this matter this quarter?

## 2. Accountable owner
- Who owns the business outcome?
- Who can change the workflow on Monday morning?
- Who signs off if the use case moves forward?

## 3. Workflow boundary
- What exact workflow is in scope?
- What input starts the workflow?
- What output should the system produce?
- What exceptions or edge cases are already known?
- What human step must remain?

## 4. Data and systems
- Which systems hold the required data?
- What data classes are involved?
- Who owns the data?
- Can representative sample data be accessed within 10 working days?
- What is the system of record?

## 5. Evidence threshold
- What measure will be used to judge success?
- What baseline was captured?
- What target must be met?
- Over what review window?
- What stop rule kills the pilot?

## 6. Risk and controls
- What is the impact if the output is wrong?
- What downstream system or person consumes the output?
- What approval step is required before any irreversible action?
- What fallback path exists if the system is paused?

## 7. Next decision requested
- Reject
- Return for evidence
- Park for later sequencing
- Fund discovery
- Approve a bounded pilot

## Notes from reviewer
- Duplicate of existing tool or workflow?
- Missing fields to return to requester:
- Decision date:
- Review date:

The important part is not the field order. It is the refusal to let the request through with blanks in the fields that decide funding.

Triage is where most teams get polite and lose control. They invent six middle states because rejecting work feels political. That is how pet projects survive.

Use four states only. Reject means the use case should not move forward as written. No owner. No measurable business problem. Duplicate of a capability the company already has. Or the requested action should not be automated at all.

Return for evidence means the idea may be real, but the requester has not done the homework. Missing baseline. Missing sample data. Missing acceptance threshold. Missing risk owner. This is not a punishment state. It is a way of keeping governance review from becoming free consulting.

Park means the request is valid, but another request gets to evidence faster or depends on less cleanup. Parking is where a visible queue matters. The requester should leave with the one condition that would move the item up, not a vague promise to revisit it later.

Advance means approve only the smallest next funded step. That might be discovery, evaluation design, or a bounded pilot. Do not approve "the whole solution" from intake. Gartner's June 25, 2025 warning that over 40% of agentic AI projects will be canceled by the end of 2027 due to escalating costs, unclear business value, or inadequate risk controls is what happens when organizations fund enthusiasm instead of the next test.

Some requests should die fast. Not because AI is a bad idea. Because the proposal has not earned the cost of one more meeting.

Reject when the use case is really a feature shopping request for a tool the company already owns. Reject when nobody can name the workflow owner. Reject when the problem statement is just a category noun like "knowledge assistant" or "AI agent for finance" with no before number attached. Reject when the proposed action is irreversible and the requester cannot name the human approval step that must sit in front of it.

Reject, too, when the cheaper fix is obviously not AI. This matters more than people admit. A real intake owner has to be willing to say that a report, an integration, a cleaner export, or a simple process change beats a fresh model call. That is exactly where the free audit earns its keep for companies without internal AI leadership, because the count and the workflow map usually expose a simpler fix before the build conversation starts.

And reject when the requester is asking the roadmap to solve a governance problem it has already created. Zylo's 2026 SaaS Management Index says business units now control 81% of SaaS spend while IT directly manages 15%. If the request begins with "we already bought this tool and now need the roadmap to integrate it," the right answer may be no. The roadmap is not an absolution service for procurement by expense report.

This is the part a fractional AI officer is actually there to own. Not the form itself. The queue, the decision rights, and the discipline that keeps the form from turning into admin theater.

The protection works because one person holds one visible list. That person can reject a request, send it back for evidence, park it, or advance it to the next funded step. They are not doing all the work alone. They are making sure the work arrives in a shape the company can decide.

That role matters most when demand spikes across departments. Salesforce says organizations already average 12 AI agents, and Gartner says only 13% think they have the right governance in place while the average global Fortune 500 enterprise could exceed 150,000 agents by 2028. The backlog will not get smaller by waiting for perfect maturity. It gets safer when somebody owns the gate and keeps the rules public.

The trick is refusing to become the person everyone waits on for free thinking. A part-time AI leader protects the roadmap by sending incomplete requests back with specific missing facts, by keeping the queue visible to every department, and by separating prioritization from solution design. Once a request clears intake, the next move may be a bounded pilot with an evaluation set, a workflow discovery sprint, or a custom build for one workflow. But the roadmap stays clean because those downstream motions start only after the intake packet is real.

That is also why the role needs delivery proximity. A part-time AI leader who can only advise eventually becomes another checkpoint people work around. The reason our fractional CAIO engagement pairs roadmap ownership with real delivery capacity is simple: somebody has to defend what comes first and then get the first thing shipped.

Day one, the requester submits the form. Day two or three, the intake owner checks for duplicates, blank fields, missing owners, and no-go risk patterns. By day five, the requester has a written state: reject, return for evidence, park, or advance.

That short cycle matters. Long intake cycles train people to work around you, which is already what Zapier's survey shows happens when governance feels slower than experimentation. A five-day rhythm keeps the gate real without teaching the company to treat it as theater.

One last rule is worth writing down. The intake form should not ask the requester to pick the model, tool, or architecture. That comes later. The useful packet answers what the system is allowed to do, who owns outcome and data, and what evidence proves it is ready for the next gate. The vendor decision is downstream of that, not upstream of it.

If your form starts with model choice, you are not doing intake. You are letting the requester smuggle solution bias into the room before the business case has survived first contact.