Should I pay everything before the pilot starts?
Paying a reasonable amount before work starts is not automatically a warning sign. Discovery, preparation and reserved delivery time are real work. The concern is paying the whole implementation fee before the supplier has demonstrated anything you can assess. Separate the commercial commitment from the technical promise: what exactly does each payment buy, and what evidence shows that stage is complete?
For a defined pilot, ask for a short schedule covering discovery, working demonstration, evaluation and handover. These are suggested stages, not a mandatory industry payment model. Some suppliers combine them; others charge for time rather than deliverables. Either can work if you understand your exposure and the stopping points. Avoid assuming that a lower deposit means lower total risk. A cheap start followed by an open-ended support commitment can be worse than a clearly scoped paid discovery.
Do not demand that a consultant guarantee a business outcome they cannot control. Staff availability, source information and your approval process affect delivery. Instead, agree what the supplier is responsible for producing and what you must provide. If your team misses an agreed data deadline, the contract should explain the effect on dates and charges. If the supplier misses a milestone, it should explain the available remedies. Neither side should have to discover those terms during a disagreement.
What evidence should unlock a milestone payment?
Tie a milestone to something inspectable, rather than a phrase such as "AI integration complete". For an internal document assistant, that could mean a working connection to an agreed document set, an evaluation report against agreed questions, and a demonstrated refusal to retrieve material outside the test user's permissions. A slide presentation showing the architecture is not the same deliverable as a working system.
Write down who assesses the evidence, how long they have to review it and how defects are reported. Distinguish a blocking defect from a minor improvement request. A tool that exposes another customer's information should not be treated like a cosmetic typo. Equally, the buyer should not withhold an otherwise agreed payment because they have thought of an unrelated feature. A change-control process protects both parties from quietly expanding the original promise.
The UK government's AI procurement guidelines, published in 2020, recommend defining the business problem rather than prescribing a particular solution. They also encourage assessing data before procurement. Those are public-sector guidelines, not a compulsory payment schedule for small businesses, but the purchasing lesson is useful: you cannot agree a meaningful acceptance test without knowing the intended task and the information available. Ask for an example of the evidence pack before signing, so you know whether you are buying measurable delivery or an impressive demonstration.
How can we test success without inventing a guarantee?
Start with representative work and keep some examples out of the supplier's development process. A supplier who has practised on every test question can demonstrate familiarity rather than general usefulness. Include ordinary cases, awkward exceptions, missing information and requests the system should refuse. Use fictional or appropriately authorised information where possible, and agree data handling before sharing real customer material.
Measure the whole task. If AI produces a draft in seconds but someone spends longer correcting it than the old process took, speed of generation is a misleading success measure. Record review time, important errors, successful completions and any work shifted to other staff. Set your thresholds before the evaluation, with tighter controls where mistakes could harm customers or staff. There is no universal accuracy percentage that makes every workflow safe.
The government's AI Playbook for the UK Government includes principles on meaningful human control and using the right tool for the job. It says products should be tested before deployment and checked during live use. This does not mean a small company must copy a government assurance programme. It does support separating a successful sales demonstration from evidence that a tool works in its intended setting. Agree in advance whether a failed test leads to correction, a smaller scope, another paid experiment or a stop decision. The answer affects the real price of the pilot.
Source: AI Playbook for the UK Government.
What costs should sit outside the quoted pilot fee?
Ask the supplier to separate their delivery fee from third-party subscriptions, model usage, hosting, licences and ongoing support. A milestone payment does not necessarily include those items. Establish who owns each account, who receives the bill, what usage assumptions were made and whether there is a spending cap. Ask what happens when a trial credit expires. None of these questions requires the supplier to predict every future invoice; they require clear boundaries.
Here is hypothetical arithmetic, not a market price or a Precise Impact AI offer. Suppose a pilot is quoted at £6,000 excluding VAT, split into three agreed £2,000 stages. If discovery ends at the first stopping point, your fee exposure should follow the contract, not an assumption that every later stage is automatically payable. External costs and cancellation commitments may still apply. Ask the supplier to state those explicitly, including any reserved time that remains chargeable.
Compare that with a time-and-materials proposal containing a weekly limit and a written stop instruction. It may be a better fit when the technical uncertainty is high. A fixed fee is not inherently safer if its exclusions make every useful discovery an additional charge. Compare proposals on the same task, evidence requirements and handover obligations. Microsoft Copilot or another existing business tool may be sufficient for the problem; a custom pilot should earn its extra delivery and maintenance burden.
What should happen if the pilot does not pass?
Agree a review and correction route before anyone starts work. The contract should distinguish failure to deliver the agreed implementation from an honest experiment showing that AI is not suitable for the task. Discovery that your source records are unreliable can be valuable, but it should not be relabelled as a successful production rollout. A useful pilot may end with a recommendation not to proceed.
Specify what you receive at each stopping point: findings, test results, documentation, configurations and access to accounts where relevant. Ownership and licensing need explicit terms. Paying for development does not by itself tell you which components you own or whether another supplier can maintain them. If reusable supplier software remains licensed, ask how that affects future support and exit costs. Check the written agreement rather than relying on an informal promise that everything will be handed over.
Do not assume that a failed evaluation creates an automatic refund right. Refunds, credits, termination rights and rework allowances depend on the contract and applicable law. Get appropriate advice on material commitments. Operationally, the important question is whether you can stop safely: retain the old workflow, prevent unapproved actions and preserve the evidence needed to understand the outcome. An unresolved invoice should not be the first time you discover that your business cannot access its own project accounts.
When is milestone-based buying not the right choice?
Milestones suit bounded delivery where both sides can describe the next useful result. They are less useful when you are purchasing a standard subscription with published terms, a short training session or a clearly defined advisory workshop. Forcing those purchases into a complex acceptance process can cost more administrative time than it saves. Proportion matters: a low-risk internal trial and an agent with permission to change customer records do not need identical contracts.
If you cannot yet describe the workflow or provide representative examples, start with a small discovery engagement rather than pretending a full implementation can be fixed precisely. Agree the discovery outputs and a budget limit. If the supplier's role is ongoing experimentation, a capped time-based arrangement with regular reviews may be more honest than artificial milestones that everyone expects to rewrite.
Before signing, ask one practical question: "If we decide not to continue after this stage, what have we paid, what do we receive and what obligations remain?" A clear answer is more useful than a promise of transformation. If you want help comparing a proposal with the work your business actually needs, a conversation can help identify the missing acceptance criteria before you commit. Keep the decision focused on demonstrable usefulness, manageable exposure and a safe way to stop.
Is This Right for You?
This guide is for UK businesses comparing paid custom AI pilot proposals. It is not a suggested price list or a substitute for reviewing the actual contract.