My first AI automation pilots start from £1,750 as a fixed fee for a defined workflow, with delivery over four to eight weeks. The public Governed Agentic Pilot offer states 50 percent to book and 50 percent on working handover. The scope, acceptance criteria and responsibilities are agreed before work begins.
That is my starting offer, not a survey of UK market rates or a quote for every automation project. The final scope matters more than the label “AI pilot”. Connecting one stable data source to a reviewable draft is a different piece of work from replacing a process across several teams.
What does the pilot fee cover?
The offer covers one working workflow, implementation and evaluation, acceptance tests, documentation and a usable handover. We define the outcome, data boundaries, ownership and approval points before building. Human approval is required before anything is sent or published.
A proposal should turn that description into specifics. Name the source systems, output, people involved and the cases the workflow must handle. State what happens when an input is missing, a provider is unavailable or a reviewer rejects the draft. List the excluded tasks with the same care as the included ones.
Four to eight weeks is the stated delivery period for the scoped offer. Access, sponsor availability and review time need to be planned within it. A discovery call is not a substitute for checking those dependencies before agreeing delivery.
Which costs should you compare alongside the build?
| Cost | What to establish |
|---|---|
| Pilot build | The fixed scope, payment points and acceptance criteria |
| Software and usage | Existing subscriptions, model calls, hosting and usage limits |
| Internal time | Source preparation, access, review, training and decisions |
| Ongoing operation | Monitoring, exception handling and named support ownership |
| Future changes | How additions and provider changes are scoped and approved |
Do not assume recurring subscriptions or maintenance are included indefinitely in a build fee. Equally, do not assume a particular support charge without a written scope. Ask who pays each provider, who can inspect usage and what stops unexpected consumption. This guide introduces no additional rate card.
What can make a pilot more involved?
Data preparation often changes the work. A reliable export with agreed fields is easier to use than inconsistent documents across several systems. Permissions, duplicate records and unclear source ownership can matter more than the model choice.
Integration is another variable. A supported API may allow a bounded connection; a process dependent on a fragile manual interface can need a different approach. Check the available route before treating a demonstration as a production plan.
Exceptions and consequences also shape the scope. Preparing an internal summary has a different review burden from drafting something that could create a customer commitment. More reviewers, more output formats and more departments increase the operating work as well as the implementation.
How would you budget an illustrative reporting pilot?
Illustrative scenario, not a quote or client result: a team wants a weekly report prepared from two approved sources for one manager. The initial scope could include importing the figures, checking dates, preparing a source-linked summary and presenting it for review. Sending the report or changing source records would remain outside that preparation step.
The team would identify any service subscriptions, estimate usage from representative runs and allocate the manager's review time. It would agree how missing data and failed runs are reported and who maintains the connection after handover. A request to add customer emails later would be a new scope decision, not an assumed feature of the first report.
This example is deliberately specific about responsibilities and deliberately does not invent a project price. A usable estimate needs the actual sources, access and exceptions.
How do you assess whether the cost is worthwhile?
Start with the current complete process: preparation, checking, corrections and handovers. Compare it with the proposed process, including ongoing review and running costs. Keep observed measurements separate from assumptions about future adoption or volume.
A simple planning calculation is current handling cost minus the proposed handling and service costs. It is a scenario, not an automatic saving: freed time only has commercial value when the business can use it. Do not count every generated draft as a lead or attach a revenue claim to a readiness score.
My website intelligence dashboard case study makes that separation visible: organising evidence and prioritising work do not, by themselves, establish improved rankings or revenue. The same discipline belongs in a pilot business case.
What should happen after the pilot?
Agree who operates the workflow, holds the accounts, reviews exceptions and can pause it. Handover should include the source and configuration appropriate to the scope, operating instructions, acceptance evidence and a practical explanation for the next owner.
Set a review point to decide whether to continue, revise or stop. Expansion should follow evidence from the agreed workflow. If the process itself still needs diagnosing, discuss an AI readiness assessment separately from the implementation offer. Buying a larger build before clarifying the work can leave both the budget and the responsibility uncertain.