Fixed-scope automation SOW that forces delivery

Signs this is happening in your business

What this is costing you a year

Write the fixed-scope automation statement of work as acceptance tests and an operational contract

Write the SOW as black-box acceptance tests plus an operational contract that defines handover and day-to-day operation. That format makes bids directly comparable and forces a usable delivery: measurable outputs, runnable tests, idempotence guarantees, and credential transfer to your vault. Refuse vendors who object to testable acceptance criteria.

Start the SOW with the measurable outputs and the tests that prove them. Do not accept features, timelines or hours in place of executable pass/fail criteria.

The opening: how much this problem is costing you now

Quantify payroll leakage before you run the procurement. Multiply people, hours, hourly cost and weeks to get an annual figure you can compare to vendor prices. Use the post-automation residual cost to decide acceptable project spend and to translate hours quotes into price per acceptance test.

Run the simple team math and use that number to justify investment and to benchmark vendor proposals.

Exactly what the SOW must contain: inputs, outputs, tests and sample data

Specify exact inputs and outputs, step-by-step acceptance tests with binary pass/fail rules, and sample data vendors must use. Vague statements let vendors build assumptions into the solution; concrete data contracts and tests force alignment before money moves.

Make tests executable: name the executor, list preconditions, show exact steps, and state the pass/fail rule for each test.

• Data contracts: each input field, type, required flag, allowed values, and the exact output fields produced.
• Step-by-step tests: sequence of actions, expected state after each step, and a pass/fail condition.
• Success metrics: tolerances for error rates and throughput during business hours.
• Sample data: at least five realistic records covering happy path, common edge cases, malformed input, and reconciliation.

Inputs and outputs (data contracts) — get specific about the shape of the work

Describe every input source, the exact field name as stored, the data type, required validation rules, transformation rules and the destination field. If you cannot state a failing value and the next state, the vendor will assume flexibility you do not have.

• Source: name the event or file that starts the work and the moment the automation must begin.
• Field example: 'customer_id — 10 digits, numeric — must match current customer list'.
• Failure mapping: for each validation failure list the next step and who receives the alert.

Step‑by‑step acceptance tests with pass/fail criteria

Each test needs a name, preconditions, exact steps, expected outputs, the executor, and a binary pass/fail rule. Require a single document vendors can run to demonstrate acceptance; anything less is incomplete.

• Precondition: the data source contains record X with fields A, B, C.
• Steps: run the automation and observe the expected state in the target system.
• Pass rule: explicit statement such as 'Invoice created with matching total and no manual edits.'

A demo in staging is sales theatre; acceptance tests are the only defensible contract for delivery.

Success metrics and tolerances

Put numeric tolerances in the SOW for what 'acceptable' means at scale. Acceptance tests check correctness; metrics check behaviour under load and over time so you can spot regressions and hidden assumptions.

• Error tolerance: maximum failed items per 1,000 processed over a seven-day window with logged root cause.
• Throughput: items per hour during the business window without queued backlogs.
• Manual intervention: maximum percentage of items that can require human edits.

Sample test data you must demand from every vendor

Require vendors to run their solution against your sample data or to supply auditable test runs of their data. Sample runs expose assumption gaps far faster than discussions or demos.

• Include: one perfect record, two frequent messy records, one intentionally malformed record, one reconciliation case.
• Require the vendor to return a documented test run showing input and the exact output for each sample row.

Operational contract items every fixed-scope SOW must include

Demand an operational contract alongside tests: a runbook, monitoring and alerting, immutable logs, an idempotence guarantee and credential transfer into your vault. These items determine whether the automation lives after the vendor leaves or becomes an operations burden.

Treat monitoring, logs and idempotence as deliverables you can test during acceptance, not optional extras.

• Runbook: step-by-step start/stop/recover actions and the person to notify for each alert.
• Monitoring and alerts: exact metrics, thresholds and notification chains for business and on-call hours.
• Logging and audit trail: per-item immutable records showing who/what changed it and why.
• Idempotence guarantee: documented retry detection and avoidance to prevent duplicate downstream records.
• Credential handover: credentials deposited in your vault at handover; vendor retains no permanent access.

Who does what after handover and what 'ownership' means

Define the boundary clearly: the vendor delivers automation, runbooks and a handover session; after the warranty window your team owns daily operation unless you contract paid support. If you lack operators, hire a fractional lead before project end — ownership without people is liability.

• Handover session: recorded walkthrough of the runbook, a demo of restoring from failure, and signed acceptance.
• Credential transfer: vendor deposits credentials in your secure vault and only uses ephemeral keys during handover.

Warranty, support and the change‑request process

Set a short warranty window, a clear definition of complete, SLAs for production defects, and a priced change-request process. Require vendors to fix test-covered defects free during warranty and publish a standard rate card for out-of-scope work so negotiations stop after go-live.

A defined change process removes most of the post-delivery bargaining that consumes time and executive attention.

• Warranty window: a fixed period during which vendor fixes defects covered by the tests at no charge.
• Definition of complete: all acceptance tests pass on your sample data and operational deliverables are handed over.
• SLA for defects: response and resolution times for Sev‑1/2/3 incidents.
• Change requests: standard rate card and a fixed approval process before work starts.

Vendors who keep credentials after handover have an incentive to return and bill you for fixes.

How to compare vendor bids apples‑to‑apples

Score every bid against acceptance coverage, warranty length, handover deliverables, ongoing support cost and measurable SLAs. Convert quoted hours into a price per acceptance test and a price for operational deliverables so you compare guarantees and not salesmanship.

Reject proposals that refuse to put acceptance tests and support pricing in writing.

• Create a comparison grid showing acceptance tests covered, warranty days, runbook pages delivered, SLA response/resolution, credential transfer policy, and post-warranty hourly rate.
• Treat bids that hide support pricing or decline written tests as non-comparable.

Comparison — what to normalize in each proposal

Normalise acceptance criteria coverage, warranty scope, handover completeness and post-warranty support rate. Translate differences into expected annual risk or support cost so you can make a commercial choice between price and guarantees.

• Acceptance coverage: portion of your written tests the vendor guarantees to pass.
• Warranty: length and whether live-data incidents are included.
• Handover completeness: runbook, monitoring config, logs, credential transfer and recorded training.
• Post-warranty rate: fixed hourly rate and response expectations.

Red flags in vendor proposals and contract clauses to push back on

Reject vague deliverables, assumption lists that read like escape hatches, demo-only acceptance, opaque edge-case pricing and vendors who refuse credential transfer. Push vendors to sign explicit tests, a rollback plan and a fixed change process; resistance predicts future incidents and billable fixes.

Your job is to close options the vendor wants to keep open.

• Red flag: deliverables like 'improve processing' with no tests.
• Red flag: assumptions list longer than two pages and unverifiable facts.
• Red flag: acceptance is a demo in staging, not runnable tests.
• Push back on opaque edge-case pricing; require a fixed rate card.
• Require credential handover and a documented rollback plan.

Three acceptance test examples every buyer should demand

Require three tests per process: a happy path, a common failure, and a reconciliation test. Each must include input data, steps, expected output, executor and a binary pass/fail rule. These three reveal most vendor assumption gaps and prevent common disputes at go-live.

Start with these three and add tests for any frequent edge cases or high-risk branches.

Happy path test example

Precondition: a valid order record with clean fields arrives. Steps: run the automation end-to-end. Expected output: downstream invoice created, tax calculated correctly and status set to processed. Pass: invoice exists with matching order_total and no manual edits.

• Sample input row: valid customer_id, order_total 125.00, tax flag true.
• Who runs it: vendor and your operations lead together in staging.
• Pass/fail: binary — the system produced a correct invoice or it did not.

If your SOW leaves edge cases undefined, you bought a vendor’s assumptions, not an operational solution.

Common failure (validation) test example

Precondition: record missing a required field. Steps: run automation and observe handling. Expected: automation logs the failure, moves the record to an exceptions queue and notifies operations. Pass: record is not processed downstream and contains a clear error code in the audit trail.

• Sample input row: missing customer_id.
• Pass/fail: record trapped with error code and an alert sent within five minutes.

Reconciliation test example

Precondition: two systems disagree about a record after processing. Steps: run the reconciliation routine. Expected: automation detects the mismatch, flags the record, suggests correction and produces a reconciliation report. Pass: report lists the mismatch, root cause field and the suggested corrective action.

• Sample input rows: order appears in source but invoice missing in accounting.
• Pass/fail: reconciliation identifies the missing invoice and produces an operator-usable action.

Where these SOWs fail in practice and why

They fail in a predictable sequence: vague SOW, vendor-built assumptions, subjective acceptance, and production breaks where the vendor calls issues 'edge cases.' You will see frequent small fixes, unclear owners and missing logs in the first month after go-live — the usual signs you bought assumptions, not guarantees.

Prevent this by demanding sample-data runs, idempotence guarantees and per-item logs during acceptance.

• Sequence: vendor demos in staging, your team accepts because it 'looks fine', vendor leaves, production hits untested branches and failures surface.
• Who notices: usually the operations person who reads outputs daily, not the vendor or CTO.
• Why: missing sample data for edge cases, no idempotence guarantee and absent audit trails.

Minimal SOW checklist you can paste into an RFP

Paste this checklist into your RFP and score vendors against it: acceptance tests with pass/fail rules, a runbook, monitoring config, full logs, credential handover, 30-day warranty, documented SLAs, fixed price for tests and a change-request rate card. A short exact checklist reduces negotiation and makes handover measurable.

Score each vendor item-by-item to make comparisons objective.

• Deliverables: acceptance tests, runbook (min 6 pages), monitoring config, full per-item logs, credential handover.
• Warranty: 30 days bug fixes for acceptance-test failures or production Sev‑1 incidents.
• SLAs: response and resolution times for Sev‑1/2/3.
• Pricing: fixed price for acceptance tests; separate rate card for change requests.
• Sample data: vendor must run tests against our sample data and provide outputs.
• Ownership: credentials transferred to our vault; vendor removes permanent access.

What to do next

Replace the feature wish list in current proposals with the checklist above and demand test runs on your sample data before signing. Run a 30-minute bid review, score vendors against the checklist and require documented test runs from each bidder.

Get the editable fixed-scope SOW checklist via How to work together. If you want help writing tests or running vendor comparatives see Services or read about me at About the author.

Where businesses waste the most time

1. Re-keying customer dataRepeated typing across systems, causing errors and delaysCopy required fields between systems automatically and flag mismatches for reviewA person still checks: An operator spot-checks flagged mismatches and corrects them
2. Manual invoice creationSeveral minutes per invoice multiplied across hundreds of invoicesCreate invoices automatically from order records and send exceptions to staffA person still checks: An accountant reviews exceptions and signs off monthly
3. Weekly reconciliationHalf-day each week hunting for why numbers differRun an automatic reconciliation that lists mismatches with suggested corrective actionsA person still checks: Operations reviews the report and approves suggested fixes

How this compares with what you already run

Operational area	The manual way	The automated way	Annual business impact
Order processing	Staff read orders and type invoices	Automation creates invoices and flags exceptions	Payroll saved; fewer late invoices
Data validation	Errors found by staff after processing	Validation blocks bad records and alerts operators	Reduced rework and fewer refunds
Reconciliation	Manual cross‑checking across systems weekly	Automatic reconciliation report and suggested fixes	Less headcount time and faster close cycles
Customer updates	Support agents update multiple systems by hand	Single action updates all systems	Lower response times and reduced churn
Exception handling	Teams hunt for missing info and escalate ad hoc	Exceptions routed with clear error codes and runbook actions	Fewer escalations and faster resolutions

What the end-to-end workflow looks like

The metrics that tell you it worked

Metric	What it tells you
Failed items per 1,000	Number of processed items that fail automated validation; measures reliability and need for manual fixes
Operator hours per week	Total weekly hours your team spends handling exceptions; measures residual operational load
Mean time to acknowledge (MTTA)	Time from alert to an operator starting work on it; measures responsiveness
Mean time to resolve (MTTR)	Time from alert to resolution; measures operational capacity and SLA adherence
Reconciliation gap count	Number of mismatches found in reconciliation runs; measures data consistency
Duplicate downstream records	Count of duplicates created by retries; measures idempotence and risk to operations
Processing throughput	Items processed per hour during the business window; measures capacity

When this is the wrong move

The mistakes that cost the most

• Vague acceptance criteriaVendors deliver something that looks right in a demo but fails edge cases in production because the criteria never specified handling rules.
• No operational handoverVendor leaves with access and your team gets a slide deck; when production fails there are no logs or runbooks and the fix takes weeks.
• Pricing by hours onlyYou pick the cheapest hourly rate; vendor delivers minimal tests and charges for every realistic change, driving total cost far above other bids.

Frequently asked questions