A warranty should be short and severity‑based (60–90 days). It must obligate the vendor to repair defects, regressions and integration breaks to defined SLAs, provide rollback or hotfix options, hand over runnable acceptance tests, monitoring and runbooks, and offer measurable remedies such as service credits, rework, or a payment holdback.
- A short, time‑boxed warranty is cheaper and clearer than an open‑ended promise and moves long‑term risk into paid maintenance.
- Define a defect with runnable, testable acceptance criteria so fixes cannot be re‑classified as enhancements.
- Vendor responsibility should cover their code and connectors; the contract must obligate timely notification and reasonable support for upstream changes.
- Make remedies measurable: response and resolution SLAs, service credits, rollback obligation, and a clear dispute path.
- Handover must include runnable tests, monitoring, runbooks, rollback snapshots and a one‑person failover document so operations can run day one.
Signs this is happening in your business
- A delivered automation breaks after a platform update and the vendor says 'that's outside warranty'.
- Operations staff spend hours nightly reversing automated changes when an exception runs.
- The vendor refuses to hand over runnable tests that prove the automation works on your data.
- Ticket resolutions are slow and labelled 'enhancements' rather than fixes.
- No rollback snapshot or clear rollback plan is delivered at sign‑off.
- You lack a single document showing who to call, how to revert, and what a working system looks like.
- The vendor's delivery has no monitoring or alerts tied to your operations team.
- Onboarding new staff is risky because nobody documented how automations behave when upstream systems change.
If several of these are true at the same time, the problem is usually the process rather than the people running it.
What this is costing you a year
(Team hours per week x hourly cost of employees x 52) = annual payroll loss
- People doing this work4
- Hours each per week6
- Hourly cost of employees$45
- Weeks52
Annual payroll cost of four people spending six hours per week on manual fixes.
Find the number before you spend anything
Run the formula above on your three most repetitive processes. If any of them clears a year of a salary, that is the one to bring to a call.
What should an automation warranty cover
A warranty must be short (60–90 days) and severity‑based: the vendor must repair defects, regressions and integration breaks to defined SLAs, provide rollback or hotfix options, deliver runnable acceptance tests and operational artifacts, and accept measurable remedies such as service credits, mandatory rework, or a payment holdback.
A narrow window prevents the warranty becoming an unstated maintenance contract and forces a real operational handover: you get working automation and the vendor has a defined, limited period to own failures that are their fault.
Exactly what 'defect' means and how to prove it
Define a defect as behaviour that fails the signed acceptance tests or makes the automation unusable against those criteria; new feature requests are enhancements. Acceptance tests must be runnable in your environment or on a copy with representative data and reproduce failures with clear steps.
Example: if five invoice fields must map and one maps to the wrong account, that is a defect. If you later ask for a new field, that is an enhancement. Performance is a defect only if the acceptance criteria included the tested batch sizes.
- Demand a written acceptance checklist with at least ten representative tests using your data.
- Require the vendor to run the tests in your environment or on a copy with your sample files.
- Make passing those tests the trigger for warranty start and final payment.
Who must fix integration and third‑party changes
The vendor must fix defects in the code and connectors they deliver and must accept responsibility for breakages caused by their integration work. For independent upstream platform changes, require prompt notification and a time‑limited plan to fix; after warranty the work may be paid if the change is outside their control.
Practical contract language allocates responsibility to the vendor for their deliverables, obliges notification of upstream provider changes within a clear window, and gives you a paid path or transfer option when external changes lie outside vendor responsibility.
- Require vendor‑owned connectors to be fixed under warranty.
- Require vendor notification within 3 business days of discovery of upstream provider changes.
- Allow the vendor one complimentary change for each major upstream version during the warranty; further work is paid.
A vague warranty is a hidden maintenance tax; vendors price ambiguity into future invoices.
Duration and SLAs: short, strict, and enforceable
Set the warranty at 60–90 days from acceptance and pair it with behaviourally defined severity levels and measurable response and resolution SLAs. Define business versus emergency hours, how you measure time, and an escalation ladder with named roles and an outside technical arbiter for disputed breaches.
Severity definitions must be concrete: for example, Severity 1 is automation unavailable or causing posting errors; Severity 2 is major functionality broken for many items; Severity 3 is a nuisance; Severity 4 is cosmetic. Assign response and resolution targets to each level.
- Suggested targets: Severity 1 response within 2 business hours, resolution within 48 hours; Severity 2 response within 8 business hours, resolution within 3 business days.
- Include an automatic service credit for missed resolutions and a one‑time termination right after repeated Severity 1 breaches.
- Specify how the clock pauses for client dependencies (for example, waiting for credentials).
Remedies and enforcement you can actually use
Make remedies precise: the vendor must offer a hotfix, a rollback to the last known good snapshot, or a patched release. Remedies should escalate from service credits for missed SLAs to mandatory rework at vendor cost and, finally, partial refund and termination rights when breaches repeat.
Add a simple dispute mechanism: name an independent technical reviewer whose written decision on defect versus enhancement is binding for remedy purposes so you avoid multi‑month arguments while operations lose time.
- Require vendor to keep a deployable rollback snapshot and to execute rollback within agreed time for Severity 1 failures.
- Specify a service credit equal to an agreed percentage of the monthly engagement per missed SLA, capped at the contract value.
- Include a 30‑day holdback on final payment until post‑warranty acceptance tests pass.
Handover and operational readiness: what you must insist on
Handover is a runnable package: runnable acceptance tests executed in your environment, monitoring and alerting configuration, credentials with clear ownership, runbooks, tested rollback snapshots, and a one‑person failover document that lets an operator keep the service running on day one.
If the one‑person failover steps cannot be followed by an operator, you do not have operational readiness. Treat inability to deliver these items as a negotiation red flag.
- Require a runnable test suite that your team can execute and re‑run.
- Ask for monitoring thresholds and sample alerts so operations know failures before customers do.
- Insist on a rollback snapshot and a tested rollback procedure executed once before sign‑off.
If the vendor refuses runnable acceptance tests, you did not receive delivery—only a demo and future bills.
Costed extensions and transition options
Move ongoing risk into a priced support arrangement: a monthly retainer for defined SLA hours or time and materials with a guaranteed response window. Put a transfer option in the contract so you can move maintenance to an internal team or third party after a defined knowledge transfer.
Require delivery of necessary credentials, read‑only logs and an export of delivered artifacts as a condition of final payment so you can continue with another supplier if needed.
- Define retainer inclusions such as X hours per month at Y rate, priority SLA, and a monthly health check.
- Require a 10‑day knowledge transfer and a final handover checklist if you switch maintainers.
- Specify that final deliverables include a clean export of workflows, runbooks and tests.
Identify your biggest operational bottleneck
Most owners already know which process is the problem. What they do not have is the annual figure attached to it. That is a 15-minute conversation, not a project.
How this warranty approach fails in practice, and why
Failure usually starts at an incomplete acceptance: you sign off after a demo while tests remain in the vendor's environment, there is no monitoring, an upstream change breaks the automation, and the vendor claims the scenario was never tested. You end up paying for fixes that should have been covered.
Prevent this by insisting on runnable acceptance tests in your environment, named SLAs, rollback snapshots executed before sign‑off, and notification obligations. Vendor resistance to any of these items is a signal about long‑term support risk.
- Who notices first: operations or customers. Without alerts, customers report problems and damage occurs before the vendor responds.
- Failure mode: vendor blames a platform change instead of owning an integration break; contract language must limit that dodge.
- Fix: require the vendor to prove tests passed in your environment and to execute a rollback once before acceptance.
Negotiable contract language and pasteable SLA snippets
Use short, practical snippets you can paste into a Statement of Work; they state operational terms plainly so counsel can draft enforceable clauses. Clear snippets make negotiations concrete and stop warranty language turning into vague promises.
Example SLA snippet: 'Warranty period: 90 days from Acceptance. Vendor obligations: fix defects, regressions and integration breaks arising from vendor deliverables. Severity 1 response within 2 business hours, resolution within 48 hours. If resolution exceeds SLA, client receives a service credit per missed day, capped at the contract value.'
- Add a holdback clause: retain 5–10% until a post‑warranty health check passes.
- Dispute clause: appoint an independent technical reviewer; their written decision on defect vs enhancement is binding for remedy purposes.
- Notification clause: vendor must notify Client in writing within 3 business days of any upstream provider changes they learn about.
Forcing indefinite support into a warranty turns the vendor into your unpaid operations team.
What most advice misses
Most guidance stays high level and skips two negotiable levers: enforceable acceptance tests and a priced maintenance path. A short, enforceable warranty plus paid maintenance is almost always cheaper and less risky than forcing indefinite vendor liability.
Also demand runnable tests and rollback snapshots. Without them, the vendor's promised 'fix' becomes months of billed consultancy while operations clean up.
The first thing to do tomorrow
Edit your current Statement of Work to add three items: a 60–90 day warranty window, a runnable acceptance test list that triggers warranty, and a rollback snapshot executed before final payment. Those changes make the warranty enforceable rather than aspirational.
Want help drafting the exact clause and the acceptance checklist? Book a clause review and get a one‑page warranty checklist from me at How to work together.
If the vendor resists these items, use that resistance as a negotiation lever: a partner that accepts a short warranty plus a priced maintenance path signals lower long‑term risk.
Why I have this view
I negotiated these deals and watched vague warranties become an operations tax; a narrowly scoped, time‑boxed warranty plus a clear paid maintenance path removes that tax. I offer advisory and build services that use this approach.
See my advisory and delivery pages at Tech consulting, Custom build and Portfolio and case studies.
Where businesses waste the most time
- Re-keying invoice fieldsOperators spend hours copying values and fixing mappings, causing delays and errorsAdd a connector that transfers and validates fields automatically while keeping your current systemsA person still checks: An operator approves exceptions and reviews flagged items
- Chasing failed transfersNightly fixes and ad‑hoc patches interrupt planned workRequire alerts and a retry mechanism the operator can trigger without replacing systemsA person still checks: An operator runs retries and confirms success
- Slow rollbackRestoring a working state takes coordination and lost time when no snapshot existsInsist on a tested rollback snapshot from the vendor executed during handoverA person still checks: An operator follows a one‑page rollback procedure
How this compares with what you already run
| Operational area | The manual way | The automated way | Annual business impact |
|---|---|---|---|
| Invoice transfer | Operators copy and check entries | Automation moves invoices; exceptions routed to operator | Reduces annual payroll cost |
| Exception handling | Errors discovered by customers or accountants | Automated alerts and a retry path | Fewer customer escalations annually |
| Platform change response | Ops detective work after breakage | Vendor fixes under warranty or offers paid update | Reduces lost revenue from delayed invoices each year |
| Handover readiness | No tested rollback, tribal knowledge | Runnable tests, rollback snapshot, runbook | Lower risk of extended outages annually |
| Ongoing maintenance | Ad‑hoc vendor billing or internal firefighting | Priced retainer or time & materials | Predictable support cost instead of surprise spend |
What the end-to-end workflow looks like
- Invoice arrivesSupplier invoice lands in your intake systemDetects arrival and triggers processing
- Read fieldsSystem extracts invoice details and line itemsReads and maps fields automatically
- ValidationFields are checked against business rulesAutomation validates and flags exceptions
- Post to accountingValid invoices are created in accountingCreates draft or final entries automatically
- Exception handlingOperator resolves flagged itemsStays human
- Monitoring and alertsSystem watches for failed batches or upstream changesSends alerts to operator and vendor for critical failures
The metrics that tell you it worked
| Metric | What it tells you |
|---|---|
| Hours spent fixing automation | Total operator hours per week spent on corrective tasks; falls as automation stabilises |
| Time to respond | Elapsed time from incident report to vendor acknowledgement; measures SLA compliance |
| Time to resolve | Elapsed time from incident report to operational resolution; used to apply remedies |
| Failed transfer rate | Number of failed transfers per 1,000 invoices; shows automation quality |
| Post‑warranty support cost | Monthly spend on vendor maintenance or internal fixes after warranty; helps evaluate retainer value |
When this is the wrong move
- The vendor refuses to provide runnable acceptance tests or a rollback snapshot; that indicates future operational risk.
- The automation touches highly sensitive regulated processes and you need a longer support window and stricter controls.
- You plan to move maintenance to an internal team immediately and the vendor refuses a defined knowledge transfer.
- The vendor cannot name a path to fix third‑party changes and will bill every update without estimates.
The mistakes that cost the most
- Signing without runnable testsYou accept a demo but no tests. After delivery a critical case fails, the vendor calls it an enhancement, and you pay for the fix while operations suffer.
- Open‑ended warrantyYou force the vendor to accept indefinite responsibility; they price that risk into higher fees or cut corners during handover to limit future liability.
- No rollbackA release breaks processing and there is no tested rollback; operations spend days restoring data and customers see errors.
Frequently asked questions
How long should the warranty window be?
60–90 days from acceptance. That gives the vendor a clear, limited window to fix delivered defects while avoiding indefinite responsibility. Longer windows increase cost and blur the line between warranty and paid maintenance.
What counts as a warranty failure versus an enhancement?
A warranty failure breaks signed acceptance tests or makes the automation unusable against agreed criteria. An enhancement is a new capability not in those tests, so put the tests in the contract to remove ambiguity.
Who pays when a third‑party platform changes?
During the warranty window the vendor should fix breaks caused by their integration code at no charge. After the window, expect paid work unless the vendor contractually agreed to continuous monitoring and free updates.
Can I hold back final payment until post‑warranty checks pass?
Yes. Use a small holdback, for example 5–10%, contingent on passing post‑warranty acceptance tests and a health check. That gives the vendor incentive to resolve defects promptly.
Should I demand source files and full access?
Demand the artifacts, runnable tests and operational access needed to run or transfer the automation. Full source may be unnecessary if you can export runnable configurations and have an agreed transfer process for maintenance.
Stop paying salary for robotic work
Bring your messiest process to a 15-minute audit and we will map where the hours actually go, live on screen. You leave with the number whether or not you work with me.