A small-business AI brief should be short enough for a supplier and the people who will use the tool to understand, but detailed enough to prevent a persuasive demonstration from becoming an uncontrolled deployment. The brief is not a wish list for every impressive feature. It states the job to improve, the evidence required, the people affected, the permitted information, the decisions that remain human and the point at which the company will accept or reject a pilot. Writing it before choosing a vendor makes the business's needs visible and gives staff a shared basis for testing claims.
Begin with a business outcome rather than a product category
Write a sentence identifying a real task: for example, reducing the time required to route incoming service enquiries without losing complaints or incorrectly confirming appointments. Name the employees involved, the information they use, the existing case system and what an authorised completed result looks like. A request to 'install an AI assistant' cannot be fairly evaluated because assistants can search documents, draft messages, classify enquiries or change connected records, each with a different consequence. The initial purpose should be sufficiently narrow that ordinary and difficult cases can be inspected.
Observe several real examples and identify which part creates friction. Some delays are caused by slow writing, but others result from missing customer details, outdated policy information, weak routing or nobody owning an unresolved case. If a better form or shared queue addresses the problem, the brief should acknowledge that alternative. A proposed model must demonstrate additional value rather than benefit from being compared with an unnecessarily broken existing process.
Describe the current workflow and the desired change
Show what happens from receipt to verified completion today. Identify the contact channel, the source of truth, staff approvals, records modified and customer messages issued. Include exception paths, because a routine enquiry can become a dispute, confidential account question or request requiring specialist judgement. A simple flow diagram or short list of stages is sufficient if it records responsibility and the actual system result.
Specify where the proposed AI step will enter that process. It may propose an enquiry category, retrieve an approved paragraph or prepare a draft for an employee. Distinguish these advisory operations from writing to a CRM, changing a booking or sending an external commitment. The latter require technical permissions, identity controls and testable transaction evidence beyond natural-sounding chat output. State what happens if the tool cannot confidently determine the answer or if a connected application is unavailable.
Document users, decision owners and affected customers
Identify who will interact with the product: a receptionist, manager, service specialist or customer. Describe which employees check model output and which person can approve a new use or stop an unsafe capability. A project without an accountable business owner can become an orphaned subscription, especially when the supplier configured everything and left no internal knowledge-maintenance process. Assign people to approve sources, observe results and receive escalated cases.
Include accessibility and language needs relevant to the actual audience. If the product is embedded on the website, customers should understand when they are speaking to an automated service and how to reach a person. If staff use it internally, their interface must expose the source evidence and uncertainty needed to exercise judgement. Do not assume the same design suits a mobile customer and an employee reviewing a confidential case.
State the information the tool may use
List current policies, service descriptions, forms and authoritative records relevant to the task. For each, identify the owner and whether the information is public, internal or customer-specific. A pilot that answers standard opening-hours questions rarely needs private account history. Avoid importing an entire mailbox or file repository simply because the supplier offers a quick connector. If historic material contains contradictions, resolve the source problem or design the system to flag uncertainty.
Where personal data is involved, define purpose, necessary fields, access, retention, possible processors and a route for correction. The UK ICO's guidance on AI and data protection is an appropriate starting point for understanding those considerations, but the exact legal analysis depends on what the business is doing. Where sensitive or high-impact information is proposed, require suitable review before any live upload. Synthetic or appropriately protected examples may be enough for the first functionality test.
Specify output, quality and review requirements
For each input, explain what the output should contain. An enquiry summary might need the customer's objective, verified facts, missing details, original-message reference and next owner. A draft reply may need an accurate acknowledgment, approved answer and realistic next step. Avoid asking for a generic professional tone without specifying what the company must not promise. A correctly escalated request can be a successful outcome when the assistant is not authorised to decide.
Define how reviewers verify material statements and what evidence they receive. If the tool claims that an appointment was confirmed, test the calendar record. If it extracts an amount from a document, compare it with the source. A polished summary that omits an unusual requirement should fail even if the rest is fluent. Ask the supplier to show how staff can reject a recommendation, repair a case and communicate an important correction to somebody who already received inaccurate information.
Write permission and security constraints explicitly
Differentiate reading information, preparing suggested actions and executing live changes. Restrict access to the minimum operations necessary for the agreed pilot. Request records of permissions, connected accounts, administrative roles and how credentials will be revoked. A prompt that instructs the assistant to ask permission is useful but cannot replace technical enforcement when tools can send messages, modify records or trigger payments.
Test an attempted unauthorised action, a malicious instruction embedded in customer-provided material, a missing system response and duplicate calls. The NCSC's secure AI development guidance recommends considering secure design, deployment, monitoring and maintenance throughout the lifecycle. Applying these principles requires assessing the actual product and integrations rather than assuming a supplier's marketing claim establishes security.
Define a pilot that can genuinely be evaluated
Select representative cases before configuring the product. Include easy routine questions, incomplete requests, contradictory documents, out-of-scope demands, an unavailable connection and an escalation requiring a person. Write expected outcomes independently so a demonstration cannot redefine success after an unexpected result. Record the actual source-system state as well as the generated language. If the task has no dependable test reference, first improve the baseline process or data.
Choose task-specific measures such as correct routing, useful first response, verified completed requests, number of staff corrections and repeat contacts. Define the denominator and evaluation period. Comparing a quiet trial week against a seasonal busy period without adjustment is misleading. Do not automatically count all model replies as resolved cases or all hypothetical minutes as financial savings. Staff should judge whether the output helps complete real work, not merely whether it looks sophisticated.
Include budget, ownership and exit expectations
Set an authorised trial ceiling and identify what it covers: licences, usage, configuration, integrations, employee training, checking effort and ongoing maintenance. Determine who may approve an extension and what results justify it. Ask vendors whether advertised budget alerts actually enforce spending limits. Check support arrangements, relevant subcontractors, product changes and what happens to company data when the contract ends.
Specify how to export essential records and return to manual service. A demonstration environment is not a safe production dependency if nobody knows how to recover pending enquiries during a provider outage. Include the people responsible for taking over when the normal project owner is absent. A short, tested fallback procedure protects the business more than an optimistic claim that the technology will always be available.
Request comparable answers from shortlisted suppliers
Give vendors the same task and test cases. Ask which capabilities exist in the proposed subscription tier, which integrations require separate products and what implementation work belongs to the buyer. Require a clear account of what remains a model judgement rather than a deterministic guarantee. Compare support, permissions, correction workflow, access to logs, data handling and departure costs alongside any visible features.
Technical descriptions from Microsoft, Google or other suppliers can explain what their products are capable of, but they are not controlled studies proving the best fit for this firm. Treat a polished demonstration as an invitation to test, not evidence of production readiness. Where a supplier cannot demonstrate a critical denial, uncertainty or recovery scenario, keep the corresponding capability out of scope until it can be assessed safely.
End the brief with a decision and review cycle
Write acceptance criteria that an owner can apply: which tasks may go live, what evidence must pass, what error triggers suspension, who approves the release and when a further review occurs. Record the decision and any restricted features. Material changes in model, knowledge, customer population, data flow or action permissions should reopen the relevant assessment. The brief becomes a living reference for both procurement and operation.
A good AI brief protects the business from scope creep and gives a supplier enough detail to build the correct service. It makes uncertainty explicit and preserves human accountability. The most useful output of the exercise may be a decision to use a simpler tool, a limited AI drafting pilot or a more carefully governed integration, depending on what the evidence actually supports.
A feature wish list versus a testable AI project brief
Both can be used to start a supplier conversation, but only one describes what the business will accept as a safe and useful result.
| Check | Product feature wish list | Task-specific implementation brief |
|---|---|---|
| Objective | Ask for a chatbot, automation or advanced agent. | Identify the customer task and verifiable completion. |
| Inputs | Assume the vendor can connect all documents. | Identify approved sources, owners and necessary data. |
| Authority | Describe capabilities without permission boundaries. | Specify allowed actions, human approvals and rejected operations. |
| Testing | Judge fluent output from a prepared demonstration. | Use representative cases, expected results and source-system checks. |
| Decision | Choose from visible features and introductory fee. | Evaluate real outcomes, total cost, incidents and exit arrangements. |
Practical decision: agree the business task, data, permission boundaries and acceptance test before a supplier implements an integrated assistant. The comparison is a planning framework, not empirical proof that one procurement document will save a fixed amount of money.
Source A — assessing trustworthiness: UK Government, Introduction to AI assurance, UK guidance explaining assurance principles and evidence (accessed 27 October 2026).
Source B — security through the lifecycle: NCSC, Guidelines for secure AI system development, international secure-design and operating recommendations (accessed 27 October 2026). These offer complementary perspectives, not competing measured product results.
Frequently Asked Questions
How long should a small-business AI brief be?
It should be concise enough to use, but contain the task, owner, sources, boundaries, acceptance cases, costs and fallback. Completeness matters more than a fixed page count.
Should we choose a supplier before writing the brief?
Define the business problem and expected results first, then ask shortlisted suppliers to demonstrate comparable cases and controls.
What is the most important acceptance test?
Verify that the tool achieves the actual authorised task and responds safely when information is missing, permissions are insufficient or an integration fails.
Do we need to include privacy in an early trial?
Yes. Identify any personal data, intended purpose, access, providers and retention before using live records; appropriately protected examples may suffice initially.
When should the brief be revised?
Review after major scope, source, model, permission or supplier changes, and whenever trial evidence reveals a consequential mismatch.