Start with an observable outcome
Describe who performs the task, what starts it and when it is truly complete. Add the current problem: waiting, manual copying, errors, unassigned handoffs or information that is hard to find. If reliable measurements are unavailable, say so and include baseline measurement in the project.
Avoid objectives such as “automate the whole department”. A bounded request supports a verifiable proposal: prepare replies about existing orders, show the source of the status and route requests without a valid reference to a person. State exclusions such as complaints, commercial changes and new orders. This gives suppliers a shared boundary before they discuss technology.
Information that makes proposals comparable
Scroll the table to compare all columns.
| Section | Content | Why it changes the proposal |
|---|---|---|
| Process and volume | Input, outcome, frequency, peaks and people | Defines scope and required capacity |
| Examples | Ordinary cases and exceptions with expected outcomes | Makes quality testable |
| Systems and data | Sources, available access and required operations | Exposes dependencies and integration work |
| Controls | Approvals, exclusions and prohibited actions | Defines the autonomy boundary |
| Handover | Accounts, documentation, tests, training and operations | Prevents the project ending with a demonstration alone |
Illustrative example of a bounded request
“The team receives status enquiries about existing orders. We want to identify the reference, read status from the business system and prepare a draft in the shared inbox. The system must show its source and must not promise an unavailable date. An operator approves sending. Requests without a reference go to a dedicated queue.”
Attach examples with unnecessary data removed, a system list and open questions: is API access available, is delivery status reliable, and who owns the queue? This allows the supplier to distinguish verified facts from assumptions and explain what preliminary investigation is needed before committing to an outcome.
Request evidence, exclusions and acceptance criteria
An acceptance criterion should describe the process. “Working chatbot” does not define supported questions or behaviour when no answer exists. Include quality, review effort, integration and failure handling in the same assessment. Also state who checks the evidence and how unresolved defects affect handover.
- Request tests on agreed cases and a failure report, not only successful examples.
- Separate included work, dependencies you own and future options.
- Ask which costs are fixed, recurring or volume-dependent, with their assumptions.
- Define approval of scope changes and who decides when to stop the pilot.
- Specify materials and access needed to operate the system or change supplier.
Compare responses without hiding uncertainty
Use columns for “demonstrated”, “assumed” and “unverified”. A proposal that acknowledges an unknown can be more useful than a broad promise. Give each investigation a concrete output: confirmed access, an analysed sample or a demonstrated operation.
UK AI procurement guidance is a methodological reference for defining needs before solutions, not a statement of obligations for private European businesses. Our operational suggestion is to bring a brief, a few cases and a process owner to the first discussion. That is enough to make the conversation concrete without deciding every technical detail in advance.
A template to work from.
AI vendor scorecard
An evidence-based comparison with explicit conditions and gaps to clarify before a decision.
Download the Markdown templateBusiness process inventory
A verifiable process map with a beginning, an end, an accountable owner and a baseline. Attach it to your project brief.
Download the Markdown templateAutomation handover worksheet
A handover record with accessible materials, accepted responsibilities, an operating exercise and assigned outstanding work.
Download the Markdown templatePractical questions
Must we already know which model to use?
No. Describe the task, data, controls and constraints. The supplier should justify the technical choice and explain how it will be tested on your cases.
What if current time and volume are unknown?
Declare the uncertainty and request a measurement phase with a defined output. Keep unverified estimates separate from measured inputs, especially when projecting benefits.
Can we request a proposal without sharing sensitive data?
For an initial discussion, describe the process and provide clearly labelled synthetic examples. Later validation may need authorised samples limited to the necessary data.
References and method
Methodological reference on clarifying needs, engaging suppliers and documenting responsibilities and deliverables; originally written for UK public-sector procurement.