How to Brief an AI PoC: A One-Page Template
An AI PoC needs a question your team can answer at the end. “Can reviewers use this draft extraction on our documents?” is a workable starting point. “Explore what AI could do for us” needs a narrower workflow first.
Bring a short brief to the scoping conversation. It does not need every answer. It needs to distinguish what is known, what is assumed and what someone must confirm before work starts.
A one-page brief you can reuse
1. The workflow and its owner
Task: We need [role] to turn [input] into [output].
Current process: Today this happens in [steps and systems], about [volume] times per [period].
Problem: The difficult part is [delay, repeated work or error], based on [observation or measurement].
Reviewer: [Person or role] can judge whether an output is useful and explain mistakes.
2. Samples and access
Examples available: [Formats, languages and representative cases], including [messy or unsuccessful cases].
Reference answers: [Who can label or review expected outputs].
Sharing constraints: [Approved location, fields to remove, permitted uses and retention requirements].
Systems: [Names and required access], with status [available, awaiting approval or unknown] and an owner for each dependency.
Agree how samples will be handled before sharing them. Do not attach credentials or customer records to an initial enquiry. If safe representative samples are unavailable, write that down; the next step may be discovery rather than implementation.
3. Evaluation and boundaries
Current baseline: [How the work performs now], or [how we will measure it].
Proposed acceptance check: [Input set, expected behaviour, proposed threshold and reviewer].
Guardrails: [Actions that require review, failures to expose and access restrictions].
Out of scope: [Other workflows, integrations, languages or production requirements].
4. The decision and practical limits
Decision after the PoC: [Proceed to a pilot, revise the approach or stop], made by [owner].
Constraints: [Budget range, timing and hosting or procurement requirements].
Open questions: [Unknown], owned by [person], to be resolved by [date or milestone].
Make the evaluation meaningful
A target such as “80% correct” is incomplete until you define the examples, what counts as correct and how serious each error is. Use it as a proposed threshold for discussion, not a result the PoC has already achieved.
Keep some representative examples out of prompt tuning and development so the final check tests more than the demonstration cases. Agree how many examples and repeated runs the decision needs; a small sample gives limited evidence. Report errors and reviewer effort alongside the headline metric.
Plan measurement at the start. This is also the approach in the GOV.UK Service Manual's guidance on performance data.
What a useful proposal should return
Look for a named workflow, concrete deliverables, prerequisites, exclusions, a price and schedule tied to those assumptions, and written acceptance criteria. It should explain what happens if access is delayed, the evaluation fails or the scope changes.
Separate the experiment's deliverables from the business hypothesis. A completed evaluation can show that the AI approach is unsuitable. That can still support a useful decision, provided this outcome and the delivery obligations were agreed in advance.
Bring the brief to the right starting point
If you are still choosing the workflow, read what to build first. If you have a task, sample plan and reviewer, send a PoC enquiry with the brief's non-sensitive outline. We can use it to discuss the scope and missing inputs.
Compare all packages if a workflow review or an implementation sprint fits your stage better.