What does an AI proof of concept cost us?

Start with what isn't on the bill: no fee, no software to buy or install, and no login to grant, so nobody creates an account or approves a connection. The desk keeps working as it does today, because the test reads copies of work your team has already finished.

What the test does use is your people's time, in places you can name before it starts:

• The first call. Thirty minutes with Rob to name the job and roughly how many of those documents arrive in a month.
• The NDA. Read by whoever signs agreements for the company, with your counsel if you use one, before any document moves.
• The reviewer and the criteria. The owner names the person who knows this work best, and the two agree in writing what a good draft must get right.
• The documents. Copies of 20 to 30 documents your team already finished, each with the record of what was done with it.
• The scoring and the decision. Your reviewer marks every draft against the finished work, and the owner hears the call.

Most of what the test asks lands on one person: your reviewer, the person on your team who knows this job best. Before the test, they help write the success criteria and choose the documents. During it, they score each draft against the finished work, field by field. After it, they walk the owner through the call and the misses that mattered.

How long that takes depends on the job: a one-page certificate request scores faster than a long order, and clean files faster than faded scans. Ask your reviewer to estimate it from a few documents they would pick, then block the time and name who covers their live work meanwhile. That cover is the true cost of the test, and the line an owner should agree before saying yes.

If your documents can't leave the building, their share grows. We build look-alikes with you, and because no finished work exists for an invented document, the right answer for each one has to be written down first.

Budget for it anyway. The federal Digital Services Playbook's checklist expects a project's budget to include research, discovery and prototyping, and a test on old documents is that step, paid for in staff time.

The second cost is clerical, and it often falls to someone on the desk rather than the reviewer. For each document, someone finds the original as it arrived, exports or prints the record your team made from it, copies both, and takes out anything the job doesn't read before the set goes.

The effort depends on where the work lives. Documents that came by email and records that export from your system to a file are quick to gather. Paper in a cabinet, or records that only show on a screen, take longer: a scan here, a screen print there.

The pull teaches something on its own. If finding the finished version of a document means searching several places or asking the person who handled it, a live job will face the same question every day, so note it.

A pilot on live work runs inside your business. It needs access to the system the work lands in, so someone in IT or at your software reseller sets up accounts and permissions. Every draft is checked before it counts, so your desk does its normal day with the checking on top, and a wrong value that slips past can reach a customer or a ledger. A pilot in your systems also needs an agreement first, so the commitment comes before you know whether the job suits AI.

A test on old documents skips all of that. The right answers are already on file, nothing your team does today waits on a draft, and nothing connects, so there is no access to grant and none to take back.

Public buyers test before they commit where they can. The Federal Acquisition Regulation lets a federal agency evaluate supplies under comparable in-use conditions before award, and use the results to rate a proposal or judge whether it is technically acceptable. For information technology it favors modular contracting: buying in successive increments, each delivered and tested as a workable piece that doesn't depend on the next, under contracts structured so the government is never required to buy the next increment.

Those rules bind federal agencies, not private companies, and this isn't legal advice. The logic carries all the same: buy one job, see it work on your own documents, then decide on the next. Our offer has that shape, one job at a time, each priced on its own.

You get a price range for the live job before the proof of concept starts, on the first call, as soon as Rob knows the job and roughly how many of those documents arrive each month. The fixed price follows the proof of concept, inside that range and before you sign. Monthly support starts once the job is live. If the test says no, you have spent the staff time above and nothing more.

The range serves a decision that belongs before any test. The UK government's service manual says that moving on from discovery means a team has decided the benefits of looking further outweigh the cost, and it asks teams to understand how much the problem is currently costing. For a desk, that means knowing roughly what the job costs you now, in people, delays and fixes, and setting it beside the range.

If the range is more than the job is worth to you, stop on the first call, before your reviewer has scored anything. The same manual says stopping at the end of discovery is not a failure when the research shows it is the best thing to do.

A free test has no invoice to read, so its scope is easy to leave vague. Before agreeing to any provider's test, ours included, get the scope in writing. FAR 37.602 gives federal buyers a usable outline: a statement of objectives covers the purpose, scope, period and place of performance, background, required results and operating constraints, and the work is described by its results rather than by method or hours.

The UK manual adds a step that is easy to skip, agreeing what is not part of the problem, because a test's exclusions matter as much as its scope. Ask, and get the answers in writing:

• Which job, and which documents? The exact job and document types in the set, and what is left out, such as a second layout or another branch.
• Who judges, and against what? Whether your own reviewer scores the drafts against your team's finished work, with success criteria written before any draft exists.
• What does a yes leave unproven? A test on old documents says nothing about the connection to your systems, live volume or the next job. Ask for that list.
• What comes after a yes? When a price arrives, whether it can move, the type of contract and what support costs once the job is live. In federal market research, the FAR has agencies learn these practices of firms in the market: the type of contract, warranty terms and maintenance.
• Will you prove it on our documents? The TechFAR Hub, the federal guide to buying digital services, says the only way to truly know whether a vendor is well versed in agile development is to have them prove it, through past performance or methods such as challenges and demonstrations. A demonstration on files the provider chose proves less.
• Is anything owed after a no? Whether the test is tied to signing anything, and what happens to your copies afterward.