AI project requirements: an editable template and worked example

A useful AI specification answers three questions: which work will the system handle, where must it stop, and what evidence will you accept at delivery? Write these answers before comparing tools. “Prepare a record from an email, then wait for the assistant's approval” already defines a clearer project than “automate our administration”.

The PDF decision pack follows one case from request to pilot selection. The editable Word template brings together your requirement, acceptance criteria and expected supplier response. Start with these two documents; the kit retains the supporting worksheets. No form is required to download them.

Check whether the task needs AI

First identify what makes the task difficult. If a form already supplies a reliable customer identifier, site and date, a connection between tools may suffice. Adding a model does not remove the need to check permissions, duplicates and transfer failures.

AI is worth testing when the input needs interpretation: differently phrased emails, mixed information or a description to extract. But two indistinguishable customer records do not suddenly provide evidence allowing a model to choose.

Ask which parts can work without AI. Compare cost and recoverability against the same service delivered rather than the number of advertised features.

Put the requirement on one page

Consider a fictional maintenance company preparing service records from a dedicated mailbox. The pilot should produce a proposal the assistant can review; it must not schedule a technician or promise a price.

For your business, attach an authorised or anonymised example and its expected output. Name who confirms each rule. An educational example does not replace checking your own sharing permissions.

The guided text template remains available without Word. Mark answers “confirmed”, “assumption” or “open”. Give each open question an owner instead of hiding it in vague language.

Follow a request through approval

M-001 says: “For site Rouen-02, the door remains stuck. Could you attend on 30 September 2026?” The fictional reference maps the sender to C-017 and authorises Rouen-02. These facts come from the reference, not model inference.

The assistant approves P-001 v1. If someone changes the date to produce v2, v1 approval must not authorise v2. Without an available approver, the request waits: silence is not consent.

This sequence makes a requirement testable. Ask for the proposed version, supplied approval and actual recorded state. A response saying “record created” does not by itself establish creation.

The worked example also retains unresolved questions: production tool, volume, hosting and substitute approver. It supports scoping; it does not yet justify an assumption-free implementation fixed price.

Replace promises with observable tests

“95% reliable AI” does not tell you whether an unauthorised write belongs to the remaining 5%. Define failures that prevent the intended use first. A formatting error and a record created against the wrong customer have different consequences.

The acceptance matrix maps seven requirements to tests. The detailed cases specify inputs, initial state, expected outcomes and evidence: complete input, ambiguous identity, missing date, absent or stale approval, recovery, forbidden access and export.

For recovery, create a record and deliberately lose the response in the test environment. Blindly retrying may create a duplicate. Ask how the operation is found and how simultaneous retries are handled. A search followed by creation does not alone demonstrate that protection.

For permissions, an answer omitting forbidden content is only one indication. Check what was retrieved and submitted to the model. Without the required traces, record “not verified”.

Here is an invented observation to illustrate a decision, not an executed trial: T04 approves v1, changes the date in v2, then creates v2 using the old approval. Decide “correct and retest” even if the other six tests pass. After correction, repeat T04 and related write/recovery tests. Preserve the initial failure in the record.

Compare proposals for the same project

Send the same versioned requirement and attachments. Request “included”, “excluded” or “to clarify”, with evidence or an expected deliverable. The comparison worksheet retains an exact reference for each response.

Two fictional offers differ: A includes approval before creation; B creates automatically and reviews the next day. B does not meet R04. Price cannot compensate: request a compliant variant before ranking offers. A's promise also remains subject to testing.

The PDF carries the example through pricing: A quotes €4,200 setup and €180 per month; B quotes €2,900 and €320 per month. Over twelve service months, supplier subtotals are €6,360 and €6,740 excluding tax. These invented amounts are not market prices. They exclude internal time and are not complete costs. They illustrate why setup price alone is insufficient.

Clarify included usage, overages, maintenance, training, export and work outside the package. An unknown remains unknown. Specify work expected from your team and dependencies that can move the schedule: missing access, data repairs or unavailable approval.

Measure remaining work before claiming savings

This calculation is an independent simulation, not the fictional company's measured volume: 1,000 cases at six minutes equal 100 monthly hours. Two review minutes per case, five correction hours and five operations hours leave about 43.3 hours, theoretically freeing 56.7 hours of capacity.

At four review minutes, remaining work rises to 76.7 hours, freeing just 23.3 hours. Under these assumptions, the time benefit disappears at 5.4 review minutes per case. That boundary identifies what to measure during the pilot, rather than relying on one favourable estimate.

Use the assumptions worksheet and calculator to replace these values. Compare equal scope, retain corrections and refusals, and check quality alongside time. Add design, training and service costs separately when evaluating profitability. Available hours become cash savings only when actual spending falls.

Decide whether to proceed correct or stop

Break the project into decisions. Scoping establishes inputs, outputs and permissions. The prototype demonstrates the workflow. Acceptance checks agreed cases. The pilot examines supervised real work; operational release adds ownership and handover.

Keep dossiers out of tuning. If every case has been used to fix the solution, prepare new ones before assessing behaviour on unseen inputs. The kit's seven cases teach the method; they do not measure general reliability.

The decision record should identify passing mandatory criteria, unknown observations, who accepts reservations and who takes over operation. The milestone worksheet helps name decision-makers.

Continue the pilot when required evidence is available and accepted. Correct and retest a repairable defect. Reduce or stop a scope whose mandatory constraint cannot be met. Finally, ask the backup operator to find a request, explain its state and prepare recovery without the system's author beside them.

Prepare the supplier request

We want to prepare a service record from an email request.
Attached are a versioned requirement, an example and acceptance cases.
Please distinguish included, excluded and unresolved items.
Describe the minimum solution, including what can work without AI.
Separate scoping, setup, recurring costs and our team's work.
For each mandatory requirement, propose a test and its evidence.
List access dependencies, assumptions and recovery arrangements.
No write or distribution is authorised before agreed approval.

You can request scoping while the target tool or volume remains unknown. Say so: you are buying resolution of those unknowns before an implementation commitment. The preparation workflow lists the attachments.

References support the method, not client results: France Num addresses work organisation; the 2020 UK procurement guidelines inform need/data preparation without transferring their legal framework; Anthropic distinguishes a claimed outcome from actual system state. This guide's documents are original.

Your decision: do 56.7 hours represent a saving?

Fictional case: the monthly calculation falls from 100 hours to 43.3 hours of remaining work. No design or training cost has been added. Can you announce demonstrated return on investment?

• A. Yes: 56.7 freed hours prove cash savings.
• B. No: this is theoretical capacity to measure and compare with complete costs.
• C. Yes, if the hours are multiplied by any hourly rate.

Adapt this: which actual work will use freed time, and what data will verify that?

Try your assumptions in the calculator. Calculations stay on your device; no data is sent.

The Initial IA scoping workshop can turn these inputs into a pilot scope. Bring a representative example and an expected outcome; unresolved areas are part of the scoping work.

Written by Initial IA, 26 September 2026. Expanded on 27 September 2026. Source, template and calculations reviewed on 5 October 2026. Fictional company and editable template; acceptance-coverage check, not validation of a customer project.