How to Scope an AI Pilot in 3–4 Weeks – A Practical Template

Key takeaways

• A 3–4 week AI pilot can show whether AI can do one defined task on your real data well enough to justify more investment. It cannot prove production readiness, scale or adoption across a whole company.
• The success metric needs a measured baseline and a test set frozen before building starts. Otherwise the result is an opinion, not a measurement.
• Acceptance criteria should separate delivery (the agreed scope was built and handed over) from outcome (the metric was reached), because the contract may treat them differently.
• What happens if the metric is missed should be settled in the contract before kickoff, not negotiated in week four.
• As of October 2026, our published price for an AI Pilot is USD 3,000–15,000 fixed fee for 3–4 weeks; other providers price differently.

What a 3–4 week AI pilot can and cannot prove

Three terms are often mixed up. A proof of concept (PoC) checks whether something is technically possible, often on sample data. A pilot usually tests one defined use case on your real data (or a de-identified copy of it), sometimes with real users, and measures it against a target. An MVP (minimum viable product) is the smallest version you would actually ship and support.

Four weeks is often enough for a pilot when the scope is one task, one user group and one data source, and access, data quality and approvals are sorted before kickoff. Examples include drafting replies to one category of support emails, extracting fields from one type of document, or answering staff questions from one set of manuals using RAG (retrieval-augmented generation, where the model answers from your own documents).

It is not enough to prove security sign-off, behaviour under heavy load, several integrations, or whether a whole department will change how it works. Those belong in the next phase, and the pilot report should tell you what that phase needs.

How to scope an AI pilot – the template

Copy this into your own document. The example column uses one illustrative case, an accounts-payable team keying supplier invoices into an ERP. The numbers in it are made up to show the level of detail, not results from a project.

Two sections deserve extra care. Section 3 is the one most likely to slip: if data access is not ready in week one, a 3–4 week timeline is unlikely to hold. Section 6 is the one that is easy to skip. Items on the out-of-scope list are often the features someone asks for in week three; writing them down now, together with an agreed change process, is what keeps a fixed price meaningful.

If you are not sure which use case to put in Section 1, our free AI readiness assessment asks five questions and returns four readiness scores with a suggested next step.

How to set a success metric you can measure in four weeks

A pilot metric must be measurable on data you already have, within the pilot. A few rules make it hold up:

1. Measure the baseline first. Time a few people doing the task, or score the current process on the same test set. "It feels slow" is not a baseline.
2. Freeze a held-out test set before building. Set aside real examples that the engineers do not use while tuning prompts or code (a few hundred is a common starting point; the right number depends on the task), and have your domain expert label the correct answers before development starts. Scores on examples the system was tuned on are usually higher than you will see in production.
3. Define "correct" exactly. For extraction: do "Jan 5, 2026" and "2026-01-05" count as the same date? For answers: is a correct answer without a source citation a pass?
4. Know what your sample can show. If each of 100 test items is scored simply right or wrong, one item moves the score by one percentage point, so a 2-point difference between two versions may be noise.
5. Track two secondary numbers. Cost per task (many model providers bill per token, a small chunk of text) and response time. Agree in advance whether a cost ceiling is part of acceptance or only an input to the go/no-go decision.

A published example shows what a time-based metric looks like. For a growing US tech company, we built a Slack AI operations agent using the Claude API, RAG and Notion. The published case study reports 70% less time spent on status reporting. That was a 6-week full build at USD 25,000, above the pilot range, but the metric is the same kind: time spent on a task, compared with the time it took before.

Week-by-week plan for a 4-week pilot

A 3-week pilot compresses weeks 2 and 3. Keep the evaluation and the decision meeting either way.

Our AI Pilot follows this shape. As published in October 2026, it takes one use case to a working pilot on your real data over 3–4 weeks, subject to the agreed scope and data readiness, for a fixed fee of USD 3,000–15,000. You own the code delivered, and nothing larger is committed until the pilot proves its value. Payment terms and other options are on our pricing page. For scoping a full fixed-price project after the pilot, see our fixed-scope AI development guide, and for budget limits, what an AI app under $10,000 can include.

If the metric is missed – questions to agree in the contract

A pilot is an experiment, so missing the target is a possible result. Whether a miss has any contractual consequence depends entirely on the terms you sign, which is why it is worth deciding in advance what a miss means. Agree answers to these questions in writing before kickoff:

• What are you paying for? Is the fee for delivering the agreed scope and evaluation, or is any part tied to reaching the metric? Both models exist; the contract should say which one applies.
• Who measures, and how? Which test set, which scoring rule, and who signs off the result? The answer should match Sections 4 and 5 of the template.
• What counts as a miss? Is 93% against a 95% target a miss, a partial pass, or a reason to adjust?
• Is there an adjustment window? If results are close, is there an agreed extra iteration, how long is it, and who pays for it?
• What if the cause is the data? If the miss comes from data quality or access problems found during the pilot, how is that recorded and handled?
• What do you keep? Do you receive the code, prompts, test set and evaluation report whatever the result, and can you take them to another vendor?
• Can you stop cleanly? Is there any obligation to buy a next phase, and are any licences, cloud accounts or API keys in your name so nothing is stranded?

As of October 2026, our published terms for pilots and projects under USD 15,000 are 50% at signing and 50% on acceptance, with full code ownership. Ask any provider to show you their equivalent in the contract itself, not only in a sales call. This is general information, not legal advice; have your own counsel review the contract.

Frequently asked questions

How long should an AI pilot take? For one use case on one data source, 3–4 weeks is often enough to build a working version and measure it against a frozen test set. Several integrations, multiple user groups or compliance review usually push it beyond that. If data access is not ready at kickoff, the timeline moves with it.

What should be included in an AI pilot scope document? A one-sentence problem statement, users and workflow, the data needed and when it is available, one success metric with a baseline, acceptance criteria, an out-of-scope list, a weekly timeline, risks, and what happens if the metric is missed. It should also list what you own at the end: code, prompts, test set and the evaluation report.

What happens if an AI pilot doesn't hit its success metric? That depends on what the contract says, which is why it should be agreed before kickoff. Settle whether the fee covers the work or the outcome, who measures the result, whether there is an adjustment window, and what you keep. A missed metric with a clear error analysis is still useful if it stops you funding the wrong full build.