Writing an AI automation brief your vendor can actually price

What a priceable brief actually contains

Most automation briefs are written as a description of a problem. A vendor cannot quote a problem. They quote a bounded piece of work with a definition of done, and everything your brief does not pin down becomes an assumption they make privately and price defensively. The brief below is not longer than the one you were going to write. It is differently shaped: less narrative, more schema, and built around samples of real work rather than descriptions of it.

This guide assumes you already know which process you are automating. If you do not, start with mapping the process and with what not to automate, because a well written brief for the wrong process is an expensive way to be precise.

Vendors price ambiguity, not effort

The number on a quote is rarely a guess about how long the work takes. Experienced teams are reasonably good at estimating work they have seen before. What they are guessing about is how much of your process they have not seen yet, and that uncertainty gets converted into money in one of three ways: a padded line item, a contingency buffer, or a refusal to fix the price at all. You can remove most of it in an afternoon by writing down things you already know.

Define the unit of work before anything else

The unit of work is the single thing the system processes from end to end: one supplier invoice, one inbound email thread, one candidate application, one weekly report. Everything downstream depends on this choice. It sets the architecture, because a per-item unit implies a queue and a batch unit implies a scheduled job. It sets the retry model, because retries only make sense on units that are independent. It sets the pricing unit, because a vendor who knows your monthly volume can compute a per-unit cost and so can you.

Three tests for a well defined unit

1. It is countable. You can say how many happened last month, from a system, without asking anybody. If nobody can count it, nobody can measure the automation afterwards either.
2. It has one trigger event and one terminal state. Not a vague start and a fuzzy end. 'Message arrives in the shared mailbox' and 'posted to the ledger, or sitting in the review queue with a reason attached' are both events a machine can observe.
3. It can be judged right or wrong on its own. If you have to look at the other units to decide whether this one is correct, you have a batch problem wearing the costume of an item problem, and the automation will need state you have not accounted for.

A unit like 'the month end close' fails all three. Break it down until each unit fits in one queue message and one review decision. The breaking down is not administrative work, it is the design. Most projects that fail an acceptance test fail because the unit was too big and the definition of correct was therefore never stable.

Write the out of scope list in the same breath. A vendor who reads an explicit list of things the system will not do prices a narrower, cheaper, more likely to ship project.

The PRICED brief, section by section

The order is deliberate. You cannot define correctness before you have samples, and you cannot design an escape hatch before you know which fields are critical. Teams that write the brief in a different order usually end up with a correctness definition that fits their idea of the process rather than the process itself.

The samples are the brief

If you send only one thing, send the samples. Forty real inputs tell a vendor more than four pages of description, and they tell it more honestly, because the description is written by someone who has stopped noticing the odd cases and the samples are not. A good vendor reads the samples first and your prose second.

• Keep the natural distribution. Take every unit from a few randomly chosen working days rather than picking the interesting ones. The proportion of ugly cases is itself a specification, and it is the figure that decides whether this project is a two week build or a two month one.
• Include the cases you argue about internally. The ones where two people on your team would fill a field differently. Those decide the acceptance test, so surface them now while they are cheap.
• Redact by substitution, never by deletion. Replace a bank account with a different bank account of the same shape. Replacing it with the word REDACTED changes the structure of the document and quietly deletes the field the parser has to find.
• Include the failures. The unit that got rejected, the one that needed a phone call, the one that took six weeks. If they never reach the vendor, the vendor will not build for them, and you will meet them again in production.
• Say what happened to each one. For a subset, twenty is plenty, attach the correct output. That subset becomes the seed of your evaluation set and later of your regression suite.

Write the acceptance test before the build starts

An acceptance test is four things: a held-out set of real units, a threshold expressed per field class, a named adjudicator, and the date the set was frozen. Agreeing it before the build costs an hour. Agreeing it after the build costs a relationship, because by then both sides have a financial position and the test is being negotiated rather than designed.

1. Hold units back before the vendor sees anythingday one

   Split your sample set. The vendor gets the development portion and never sees the held-out portion. If the vendor can tune against the test set, the test measures memorisation rather than capability, which is the oldest failure mode in applied machine learning and it happens on small projects constantly.

2. Classify the output fieldsone hour

   Critical fields are the ones where a wrong value causes money to move, a person to be contacted, or a record to become untrustworthy. Tolerated fields are cosmetic. A single blended accuracy figure hides the only thing you actually care about, which is whether the bank account was ever wrong.

3. Set thresholds per class, not overallone hour

   Something like: zero critical field errors across the held-out set, and no more than a stated fraction routed to human review. Notice that routing to review is not a failure. A system that knows it does not know is behaving correctly, and confusing those two outcomes is how teams end up demanding accuracy they do not need and paying for it.

4. Name the adjudicator and the turnaroundfive minutes

   One person decides disputed cases, within one working day. Two people means an escalation path and a delay. No named person means the argument goes to whoever is most senior and most annoyed.

5. Write down who runs the test and who watchesfive minutes

   The vendor runs it, you observe, both parties sign the same result sheet on the day. Tests run privately and reported by email get re-run in the meeting anyway.

If you want to go further than a single acceptance gate, the same held-out set becomes your regression suite after launch, which is the subject of writing evals for LLM systems. At the brief stage most teams need only the acceptance version.

The arithmetic a vendor runs while reading your brief

Any competent vendor works out roughly what the process costs you today, because that sets the ceiling on what they can charge and still be worth hiring. Run the same arithmetic before you send the brief, and put the result in it. A brief that states a budget ceiling with the working shown gets quotes you can compare. A brief that hides the budget gets quotes calibrated to what the vendor thinks you can afford.

Two things usually surprise people here. The residual rate matters more than the build cost, because it recurs every year while the build happens once, so the argument about whether the review queue holds ten percent or twenty five percent of units is worth more than the argument about the quote. And a twelve month payback is a strict test that plenty of worthwhile projects fail, which is why the honest version of this arithmetic sometimes ends a project before the brief is finished.

The brief skeleton, ready to fill in

Copy this, replace every value, and delete the fields that do not apply to your process. YAML rather than a document is deliberate: it makes missing information visible, it diffs cleanly when you revise it, and it discourages the paragraph of explanation that usually hides an undecided question.

# automation-brief.yaml
# Fill every field, because a field you cannot fill is a question the vendor prices as risk.
# Values below are illustrative examples only, replace all of them with your own.

unit_of_work:
  name: "one supplier invoice arriving by email"
  trigger: "message lands in the AP mailbox with at least one PDF attached"
  terminal_state: "posted to the ledger with a cost centre, or queued for review with a reason"
  volume_per_month: 620
  peak_shape: "most of the month's volume arrives in the last three working days"
  out_of_scope: ["expense claims", "anything that arrives on paper", "card statements"]

systems:
  - name: "accounting ledger"
    role: "system of record, written to"
    owner: "finance ops lead"
    auth: "OAuth app, sandbox tenant available"
    write_access: true
    rate_limit: "unknown, vendor to confirm in week one"
  - name: "document archive"
    role: "read only, holds signed purchase orders"
    owner: "IT service desk"
    auth: "service account, request cycle is about two weeks"
    write_access: false

inputs:
  sample_count: 40
  sampling_method: "every invoice received on four randomly chosen working days, unedited"
  redaction: "values replaced with same-shape fakes, structure untouched"
  known_ugly_cases:
    - "scanned documents from two suppliers, no text layer"
    - "line items continuing onto a second page"
    - "credit notes that look like invoices until you read the total"

correctness:
  critical_fields: ["supplier", "total", "currency", "bank account", "purchase order number"]
  tolerated_fields: ["line description wording", "line item order"]
  definition: "a critical field is correct when it matches what a senior clerk would enter"
  adjudicator: "finance ops lead, one working day to rule on any disagreement"

uncertainty:
  behaviour_when_unsure: "never post, write to the review queue with fields and a reason string"
  who_reviews: "clerk on rota"
  target_review_rate: "a number we set together after the first month of live data"
  escalation_sla: "reviewed the same working day"

acceptance:
  test_set: "30 units held back from the samples, frozen the day the contract is signed"
  pass_threshold: "zero critical field errors, and no more than 5 of 30 routed to review"
  who_runs_it: "vendor runs it, client observes, both sign the result sheet"
  when: "before the final payment milestone, on the frozen set only"

commercials:
  build_budget_ceiling: "derived from the arithmetic in this brief, stated so quotes compare"
  running_cost_expectation: "vendor states model, infrastructure and support cost per month"
  change_control: "anything outside unit_of_work is a change order, priced separately"

Attach the sample set as a folder alongside it, with the correct outputs for the labelled subset in a separate file. Send the same package to every vendor on the same day. If you send different versions, you cannot compare the quotes, and you have wasted the work of writing a precise brief.

What to leave out of the brief

Do not specify the solution. A brief that says build this in a particular workflow tool using a particular model has chosen an architecture before anyone has seen the exception distribution, and it removes the one thing you are actually buying, which is judgement about how to build it. State the constraint behind your preference instead: data cannot leave a jurisdiction, our team must be able to modify it after handover, no new vendor contracts this quarter. Constraints are useful. Implementation instructions are you doing the vendor's job with less information than they will have.

The right hand column is not a careless brief. It is the normal output of an intelligent person describing a process they know well, in prose, from memory. The difference is structural rather than a matter of effort.

Definitions, and the check before you send

Terms worth agreeing on before you write

Unit of work

The single item an automated process handles from trigger to terminal state, countable in a system, and judgeable as correct or incorrect on its own without reference to other units.

Held-out set

A portion of real samples withheld from the build team and frozen on a stated date, used once to decide whether a system passes acceptance. Its value comes entirely from the fact that nobody was able to tune against it.

Critical field

An output field where a wrong value causes money to move, a person to be contacted, or a record to become untrustworthy. Critical fields get a zero-error threshold; everything else gets a tolerance.

Escape hatch

The defined behaviour of a system when its confidence is low: stop, route the unit to a named human with the working shown, and record the reason. A system without one guesses and carries on.

Change order

Work outside the written unit of work, priced separately. Its existence in the contract is what allows the base price to be low, so a brief with a precise scope and a clear change process is cheaper than a vague brief with neither.

A brief written this way takes most teams a day, and about half of that day goes on discovering that two people disagree about what the process actually does. That discovery is cheaper to have on your own time than during a build. If you would rather run the exercise with someone who has priced these projects before, that is what a scoping engagement inside business process automation is for.