AI Use Case Intake Form
The AI use case intake form has ten fields. If a requester cannot complete them, the request is not ready, and the conversation should start there rather than in delivery. The first fields ask what decision or process changes, who owns that decision today by name, and how the current process performs.
The intake form does most of the filtering that a governance committee would otherwise do slowly. A request that cannot name the decision it changes or the person who owns it is not a use case yet.
The template
Ten fields. If a requester cannot complete these, the request is not ready and the conversation should start there.
- What decision or process does this change?
- Who owns that decision today, by name?
- What does the current process cost, in time, money, or error rate?
- What does good look like, expressed as a number?
- What data exists, who owns it, and have you seen it?
- Who accepts the output and acts on it?
- What happens when the system is wrong?
- Is the effect reversible?
- Who has funded implementation, as distinct from the pilot?
- What is the deadline and what drives it?
How to use it
- Require all ten fields before the request enters any queue.
- Treat an incomplete form as the start of a conversation rather than a rejection: the missing fields are usually the real problem.
- Insist on a named decision owner. "The department" is not an answer.
- Capture current process performance, because without a baseline no later claim of improvement can be tested.
Where this goes wrong
The failure modes below are the ones worth checking for first. Each describes a way this artefact stops doing its job while still appearing to be in use.
- The form collects the proposed solution instead of the problem. An intake that opens with "we want a chatbot" has already foreclosed the analysis. Capture the decision being made, who makes it today, and what it costs to get it wrong.
- There is no field for the option of not building anything. Intake processes that only accept proposals generate proposals, and a register full of approved low-value systems is harder to unwind than an empty one.
- Data availability is asserted rather than checked. A use case that depends on a dataset nobody has confirmed exists, in a form nobody has confirmed is usable, will fail late and expensively.
- Submissions are scored by the team that submitted them. Self-scored intake converges on everything being high value and low risk. Scoring belongs with someone who carries no delivery incentive.
Common questions
What should an AI use case intake form ask?
Ten fields, beginning with what decision or process the system changes, who owns that decision today by name, and how the current process performs so that improvement can later be measured. If a requester cannot complete the form, the request is not ready, and the missing fields are usually the real problem rather than an administrative gap.