Ask these questions before you sign an automation contract
By the Techprime team · · 5 min read
Key takeaways
- If no one is contractually responsible for fixes, your team inherits ongoing daily firefighting.
- Put a scoped checklist and three edge-case tests into acceptance criteria to stop pilots becoming permanent support work.
- Design automation to remove routine work while routing uncertain items to a named human reviewer.
- Require a time-boxed pilot with a rollback and a tested data export before ownership transfers.
- Measure success in hours removed, exception rates, and mean time to resolution rather than vague efficiency claims.
On this page (12)
- Questions to ask automation vendors before signing — the five non-negotiables
- How should the scope and 'done' be written?
- Who owns data, backups and access?
- How will errors and exceptions be handled?
- What happens when the automation breaks — SLAs, fixes and ownership
- Pilot, exit and rollback — don’t accept a one-way gate
- Where this fails in practice and the exact sequence that kills projects
- Implementation realism — where humans must stay in the loop
- Checklist to demand before you sign
- Key metrics to demand and how to measure them
- When not to sign — three honest situations
- Next step you can take this week
Before signing, get written answers for five things: a checklist scope with pass/fail tests; who handles exceptions and approvals; where data and backups live; response times and who fixes bugs; and a time-boxed pilot with a rollback and export test. Without these, pilots become unpaid maintenance.
Questions to ask automation vendors before signing — the five non-negotiables
Get written answers to five items before you sign: a scoped checklist with pass/fail tests; the exception workflow and named approver; where data, logs and backups are stored and how you export them; response times and who owns fixes; and a time-boxed pilot with a rollback. If any answer is vague, don’t sign.
- Scope with examples of inputs and outputs
- Exception workflow with named approver
- Data residency and access list
- Fix and response SLA with ownership
- Pilot length and rollback conditions
How should the scope and 'done' be written?
Write scope as a checklist of concrete inputs, outputs and pass/fail tests that include three edge cases and sample files. The contract should state exactly which file types, field mappings and naming patterns the automation accepts and the acceptance criteria used during the pilot.
- List file types, naming patterns and example bad inputs
- Define which fields must be correct and which can be human-reviewed
- Include three edge-case examples that must pass in the pilot
Who owns data, backups and access?
Ask who stores your data, which named roles can access it, and how long logs and backups are retained. Require a written export format and a test export during the pilot so you can recover records without opening a support ticket.
- Named people or roles with access
- Where logs and backups live and retention period
- A tested export of your data during the pilot
How will errors and exceptions be handled?
Demand an exception workflow that classifies failures, shows the human queue and names who reviews items. The vendor must map which failures the automation will auto-resolve, which route to your team, and what a human sees to approve or correct decisions.
- Classify failures and routing rules
- Who reviews exceptions and what they see
- Expected time to resolve each class
What happens when the automation breaks — SLAs, fixes and ownership
Get response times by severity and a clear ownership clause: vendor code failures are fixed by the vendor within the agreed window; input changes on your side are documented and either accepted, adjusted, or scheduled for a fix. Without this the vendor has no incentive to finish the job.
- Severity tiers with response times
- Defined ownership for bug fixes
- A documented process for input-format changes
Pilot, exit and rollback — don’t accept a one-way gate
Insist on a live, time-boxed pilot that runs your real data and ends with a signed acceptance or a rollback. Require a performance report during the pilot, a tested data export, and an explicit right to pause or revert without penalty if the pass/fail checks are not met.
- Time-boxed pilot with pass/fail criteria
- Test data export during pilot
- Right to pause or roll back without charges
Where this fails in practice and the exact sequence that kills projects
Projects follow a predictable sequence: a clean demo, a vague contract, missed edge cases, a queue of vendor tickets, and finally your team accepting daily errors. Tickets pile up because the contract did not name ownership, and the automation becomes maintenance your people must manage.
- Demo → vague contract → missed edge cases
- Operator sees exceptions → tickets opened → slow fixes
- Automation becomes maintenance without vendor accountability
Implementation realism — where humans must stay in the loop
Design the handoffs: the vendor must show the screens humans use, what fields they can edit, and which actions are logged. Put a list into the statement of work of tasks that remain human, for example final approvals, high-risk decisions and ambiguous-input remediation.
- Who approves exceptions and what they can change
- Which decisions remain manual (approvals, disputes, high value)
- How humans get a clear, single queue of items to act on
Checklist to demand before you sign
Require these deliverables as acceptance criteria: the scope checklist, three passing edge-case tests, a pilot plan with rollback, a data export test, named access lists, an SLA for fixes, and a maintenance handover plan. Acceptance must be a signed statement after the pilot, not an automatic calendar date.
- Scope checklist in contract
- Edge-case tests passed in pilot
- Data export and access test
- SLA and ownership for fixes
- Signed acceptance after pilot
Key metrics to demand and how to measure them
Require measurements you can calculate from logs: hours removed, exceptions per processed volume, mean time to resolve, and the rate of automated actions later corrected by humans. Ask the vendor to report weekly during the pilot and monthly after handover.
- Hours removed from the team
- Exceptions per 1,000 processed items
- Mean time to resolve an exception
- Percentage of items requiring human correction
How to fail gracefully: an example exception workflow
Use three states: automated, needs review, escalated. Each state names who acts and in what time frame so items never sit orphaned. 'Needs review' must appear in a single queue showing the original input, suggested output and one-click approve or reject; repeated rejections escalate to a manager.
- Automated → success or failure
- Needs review → human queue with suggested action
- Escalated → manager decision and vendor ticket if needed
When not to sign — three honest situations
Don't sign if you cannot list the inputs the automation will handle, if the vendor refuses a pilot on your data, or if your team lacks a named owner to manage exceptions after launch. A vendor who says 'we’ll figure it out live' is signalling ongoing change work, not a delivered product.
- Inputs and edge cases are undefined
- Vendor refuses a live pilot with your data
- No internal owner for exception management
Next step you can take this week
Map one manual process: list the inputs, outputs, three edge-case examples, the people who touch exceptions, and the hours they spend each week. Use that checklist to demand the five non-negotiables from any vendor before signing. If you want a quick review, send the list to Techprime.
| Operational area | The manual way | The automated way | Annual business impact |
|---|---|---|---|
| Invoice entry | People re-key invoices into accounting | System reads invoices and creates draft entries | Hundreds of hours reclaimed and fewer entry errors |
| Customer lead routing | Sales reads incoming leads and assigns manually | Leads are categorised and assigned automatically with a human reviewing edge cases | Faster responses and fewer missed leads across the year |
| Order confirmation | Staff check stock and send confirmations one by one | Confirmations are auto-generated; exceptions flagged for review | Fewer delivery delays and reduced complaints over the year |
| Monthly reporting | Reports compiled by copying numbers into sheets | Data pulled into a report template automatically with human sign-off | Shorter month-end cycles and less overtime each month |
| Supplier reconciliation | Teams match statements manually | Matches are auto-suggested; mismatches routed to a reviewer | Faster supplier closures and fewer payment errors annually |
Invoice entry
- The manual way
- People re-key invoices into accounting
- The automated way
- System reads invoices and creates draft entries
- Annual business impact
- Hundreds of hours reclaimed and fewer entry errors
Customer lead routing
- The manual way
- Sales reads incoming leads and assigns manually
- The automated way
- Leads are categorised and assigned automatically with a human reviewing edge cases
- Annual business impact
- Faster responses and fewer missed leads across the year
Order confirmation
- The manual way
- Staff check stock and send confirmations one by one
- The automated way
- Confirmations are auto-generated; exceptions flagged for review
- Annual business impact
- Fewer delivery delays and reduced complaints over the year
Monthly reporting
- The manual way
- Reports compiled by copying numbers into sheets
- The automated way
- Data pulled into a report template automatically with human sign-off
- Annual business impact
- Shorter month-end cycles and less overtime each month
Supplier reconciliation
- The manual way
- Teams match statements manually
- The automated way
- Matches are auto-suggested; mismatches routed to a reviewer
- Annual business impact
- Faster supplier closures and fewer payment errors annually
Questions, answered.
What is the single most important question to ask before signing?
Who will fix problems after go-live and in what time frame. If that person, role or clause is missing, the vendor may treat post-launch bugs as a new billable project; ask for named ownership and response times in the contract.
How long should a pilot be?
Keep pilots time-boxed and long enough to exercise edge cases — commonly four to eight weeks depending on volume. The goal is to run your actual data through the automation and confirm the pass/fail checklist, not to polish features.
Should I demand a refund or penalty for missed SLAs?
Practical remedies work better than punitive penalties. Ask for remedies such as free support hours or credit toward maintenance until the SLA is met, and a clear path to rollback if problems persist.
Can we keep our existing software and still automate?
Yes. Ask the vendor to integrate with your current systems and show how data will flow without replacing tools. The contract should say the automation writes to your systems and how to export your data.
What should be in the acceptance criteria?
A checklist of inputs, expected outputs, three edge-case tests that must pass, a data export, and an exception-rate threshold. Acceptance should be a signed statement after the pilot, not a calendar date.
What do I measure after launch?
Track hours removed, exceptions per volume, time to resolve exceptions, and any rework caused by automation errors. Require weekly reports for the first quarter to ensure the vendor is delivering the promised reduction in manual work.
Related articles
Two-week AI pilot checklist to validate automation quickly
You have a slow, manual process and two weeks to prove automation works. This checklist shows who to involve, what to measure, and the build-run-review steps
Which operational tasks must keep a human in the loop
Stop rework and missed follow-ups by keeping humans at specific decision points. Use short, visible checks and a one-week shadow audit to cut hours and backlog.
Human-first WhatsApp lead qualification with automation
Salespeople waste hours reading chats and copying details. Use a short WhatsApp triage script that mimics human pacing, escalates ambiguous or urgent cases to