A vendor handover must deliver exportable artifacts, an ops account you control, runnable runbooks for non‑engineers, end‑to‑end and regression tests, visible monitoring and alerts, recorded training plus a shadowing period, an ownership and escalation plan, and signed acceptance evidence before final payment.
- If the vendor cannot export artifacts and give you live ops access, you inherit opaque technical debt.
- A usable handover proves your ops person can run and recover the automation without engineers.
- End‑to‑end acceptance tests and visible monitoring are the difference between a pilot and an operable service.
- Price post‑handover support as a fixed short window plus a capped hourly band to avoid surprise invoices.
- A 60–90 minute scorecard session with your ops person exposes most handover gaps faster than proposals.
Signs this is happening in your business
- Only one vendor employee knows how the automation starts, stops and recovers.
- Vendor provides access that expires or a single vendor‑owned account you cannot export from.
- Operations says the documentation is 'too technical' or misses routine recovery steps.
- You receive invoices for 'maintenance' immediately after go‑live instead of a handover plan and export.
- Monitoring is an email from the vendor rather than dashboards and explicit alerts you can see.
- Config changes are billed as new projects because configs live in the vendor's private workspace.
- No rollback or exit plan exists and the vendor offers a fresh build at full price to leave.
- Vendor refuses to run the automation while your ops person watches a controlled failure.
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
The annual payroll cost of four people spending six hours a week each on this manual work.
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.
Automation vendor handover checklist: required deliverables and access
Contract the handover as a deliverable that includes exportable automation artifacts, an ops account you control for the live workspace, all source and configuration files in plain formats, a credential or managed‑secrets transfer plan you own, and downloadable logs from a vendor-run demonstration during the review.
- Exportable artifacts: the automation logic in files you can run elsewhere (not screenshots).
- Workspace/project access: live ops account with the same environment the vendor runs.
- Source/config files: exact files for behaviour and configuration exported in plain formats.
- Credential plan: transfer credentials to your vault or a documented managed‑secrets handover with rotation steps.
- Evidence: vendor runs the automation from your ops account and provides downloadable logs.
Non‑engineer runbooks and documentation that actually work
Deliver documentation your ops person can use without engineering help: a one‑page process map, a short data dictionary, step‑by‑step troubleshooting for common failures, an onboarding checklist, and a change log that ties each release to rollback steps and who deployed it.
- Process map: one page with swimlanes showing inputs, decisions, human checks and outputs.
- Data dictionary: field names, sources, valid values and actions for missing data.
- Troubleshooting runbook: top failure modes with symptom, immediate check, action and expected success signal.
- Onboarding template: 60‑minute agenda and certification checklist your manager can run.
- Change log: who deployed, what changed and explicit rollback steps.
Where time and money go in a process (per‑process breakdown)
Map a representative week and record hours per step to see where manual time concentrates and where automation will create maintenance responsibilities. Use that mapping to focus documentation and testing on the high‑hour and exception points that will otherwise become recurring operational cost.
- Data normalization: repetitive edits that consume the largest share of manual hours.
- Exception review: intermittent, high‑cost human judgement that needs clear rules.
- Status updates: low‑skill, high‑frequency tasks suitable for automation.
- Reporting and reconciliation: needs audit trails and an owner for disputes.
A pilot without verified handover becomes an ongoing vendor subscription you will pay for indefinitely.
How to test, monitor and prove the automation is operable
Require scripted end‑to‑end acceptance tests, a compact regression pack, visible dashboards your ops account can access, and explicit alert rules. Make the vendor run tests, show failures, fix one, and rerun so your ops person sees the logs, timestamps and notifications firsthand.
- Acceptance tests: scripted scenarios with pass/fail logs that mirror real cases.
- Regression tests: a pack ops can run after changes to prove nothing else broke.
- Monitoring: a dashboard showing throughput, success rate and queue counts your ops account can view.
- Alerts: clear trigger conditions, who is notified and expected response times.
- Error semantics and retry logic: classify transient versus permanent errors and document retry rules.
Who owns the automation after handover and how training must happen
Name a production owner in your company, require vendor escalation contacts with response windows, supply recorded training, run two live workshops and enforce a shadowing period where your ops person leads incidents while the vendor supports. Your ops person must perform every routine action once in front of the vendor and be recorded doing it.
- Ownership: a named role responsible for production health and change decisions.
- Escalation: vendor contact names, expected response windows and severity procedures.
- Training: recorded sessions plus two live workshops — a walkthrough and a failure rehearsal.
- Shadowing: a minimum two‑week window where vendor supports live incidents while your ops operates.
- Sign-off: signed checklist confirming training, access transfer and passed tests.
Contractual protections and transition economics to negotiate
Put exports, a code‑escrow or export clause, SLAs for post‑handover support, a priced transition window, capped support rates and a tested rollback/exit plan into the contract. Require a binding export of the final configuration within a contractually defined timeframe after termination so you can continue without negotiation.
- IP and licensing: perpetual right to use exported artifacts needed to run the automation.
- Export requirement: final config and artifacts exported in open formats within an agreed timeframe after acceptance.
- Code escrow: a release mechanism if the vendor stops supporting the product.
- SLA and support rates: baseline SLA for a short post‑handover window and fixed vs hourly rates afterward.
- Rollback/exit plan: tested steps and fixed prices for a clean transition in‑house or to another vendor.
Documentation only engineers can read is a plan for vendor dependency, not a handover.
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.
Acceptance scorecard you can run in 60–90 minutes with ops
Run a focused session where the vendor provides ops access, exports artifacts, runs acceptance tests, walks operations through three failure recoveries and produces training evidence. Use a pass/fail scorecard so acceptance ties directly to evidence rather than sales language and so gaps show up in under 90 minutes.
- Start: ops account provided and ops logs in (pass if login succeeds).
- Artifacts: logic and configs exported and opened (pass if files usable).
- Acceptance tests: run three representative end‑to‑end tests and save logs (pass if outcomes match expectations).
- Failure rehearsal: vendor injects a known failure; ops recovers via runbook (pass if steps followed).
- Monitoring and alerts: ops triggers an alert and confirms notification chain (pass if alert arrives and is acknowledged).
- Training evidence: recordings and a signed checklist (pass if recording and checklist exist).
- Sign-off: final payment conditional on full pass and signed checklist.
Common red flags that should make you walk away
Walk away from vendors who refuse live ops access during review, decline to export artifacts, or only offer vendor‑owned accounts with no export plan. Treat documentation promised as 'future work' as a deliberate plan to keep you dependent rather than a genuine handover.
- Access that expires after the session instead of being transferred.
- Documentation heavy on architecture but lacking step‑by‑step recovery actions.
- Support sold as the only way to keep the system running after handover.
How this fails in practice and the sequence of symptoms to watch
Failed handovers follow a predictable sequence: gated access, thin documentation, surprise maintenance invoices and then vendor‑only fixes. Stop the process at the first sign. Tie final payment to a signed acceptance checklist so you do not let the vendor convert a build into an ongoing revenue stream.
- Phase 1: Demo delivered but no exportable artifacts—buyers confuse demo with deliverable.
- Phase 2: Documentation arrives late and is too technical; ops cannot reproduce actions.
- Phase 3: Post‑go‑live issues; vendor charges for 'maintenance' not covered by contract.
- Phase 4: Buyer pays ongoing invoices rather than demanding migration or export.
What you should do next
Book a 60–90 minute handover review with your shortlisted vendor and your operations lead and run the scorecard before final payment. Use the session results to negotiate contract terms or a priced remediation. I offer handover reviews as part of my services and a follow-up engagement; book via how I work.
- Run the scorecard with your ops person and refuse final payment until the checklist passes.
- Add export, training, shadowing and SLA clauses into procurement before signing the next SOW.
- If you lack technical leadership, consider interim direction via my fractional CTO service.
Where businesses waste the most time
- Re-keying customer dataRepeated manual typing, errors and follow-up correctionsCreate a direct transfer between systems and a validation step before final save, keeping existing toolsA person still checks: A person spot-checks exceptions and approves ambiguous records
- Manual status emailsTime composing updates and chasing confirmationsGenerate status from the authoritative source and route to recipients automatically, keeping current email toolsA person still checks: A person reviews and sends client‑facing anomalies
- Ad‑hoc reconciliationsEndless spreadsheet work and reconciliation debtSchedule automatic reconciliation runs that produce exception lists stored in the same toolA person still checks: A person resolves exceptions and signs off the reconciliation
How this compares with what you already run
| Operational area | The manual way | The automated way | Annual business impact |
|---|---|---|---|
| Data entry | Staff rekey fields between systems | Automatic transfer and validation | Reduces annual staff hours |
| Exception review | Manager inspects and corrects outliers | Exceptions flagged for human review | Lowers annual overtime costs |
| Status updates | Manual status emails and dashboards | Automated status updates and reports | Cuts annual hours spent on client updates |
| Reporting | Ad‑hoc spreadsheet reconciliation | Scheduled report generation and reconciliation | Reduces annual reconciliation effort |
| Onboarding | Training by shadowing and error‑prone handover | Template onboarding with recorded training | Fewer annual senior staff training hours |
What the end-to-end workflow looks like
- DiscoveryMap the current manual process and identify failure modes.Stays human
- DesignVendor defines the automation logic and acceptance tests.Vendor provides the automated logic
- BuildVendor implements automation and documents configuration.Vendor provides exportable artifacts
- Acceptance testsRun end‑to‑end tests that simulate real cases and record results.Automated tests run with ops present
- Training and shadowingOps performs tasks while vendor supports for a defined period.Stays human
- TransferExport artifacts, hand over access and sign the acceptance checklist.Exported artifacts handed to your ops
- Post‑handover supportVendor supports to fix defects during a priced transition window.Vendor provides time‑limited support
The metrics that tell you it worked
| Metric | What it tells you |
|---|---|
| Hours saved per week | Total staff hours recovered each week by automation measured from timesheets before and after. |
| Mean time to recover (MTR) | Average minutes ops takes to restore normal operation after a failure using the runbook. |
| Acceptance test pass rate | Share of scripted acceptance tests that pass during handover sessions; measured per session. |
| Number of vendor-only incidents | Count of incidents where ops could not operate or recover the automation and vendor intervention was required. |
| Support cost per month post-handover | Actual dollars spent on vendor support after acceptance compared to the contracted capped rate. |
| Time to onboard a new operator | Hours required for a new ops person to be competent using the onboarding template and recordings. |
| Unrecoverable failures per quarter | Count of incidents that required rollback or vendor intervention and could not be handled by ops. |
When this is the wrong move
- When the process changes weekly and the vendor cannot provide a clear change‑management plan.
- When you have no internal person who can be trained to own production during the shadowing period.
- When the vendor refuses to export artifacts or provide a time‑limited transition at a fixed price.
- When the business impact is trivial and automation cost exceeds salary savings over 18 months.
- When the work requires replacing a core system rather than connecting existing tools.
The mistakes that cost the most
- Accepting demos as deliveryVendor shows a polished demo; buyer assumes the demo equals deliverables; after go‑live there are no exports or runbooks and the vendor bills for every follow-up.
- Releasing final payment on deployment aloneBuyer pays on deployment rather than on evidence; vendor stops active support; ops cannot reproduce vendor actions and the system degrades.
- No ops involvement during acceptanceProcurement and IT sign off without operations present; documentation is too technical and ops cannot run or recover the system.
- Vague support pricingSupport billed 'as needed' without caps; vendor invoices high hourly rates for routine work and buyer faces steady post‑handover expense.
- Skipping failure rehearsalsVendor never simulates outages; ops is never tested and when a real outage occurs recovery time balloons.
- Keeping vendor‑owned accountsVendor insists on using its accounts; buyer cannot renew access or extract data if relationship ends, forcing a costly rebuild.
Frequently asked questions
What is the minimum handover evidence I should require?
Require exportable artifacts, live ops account access, a signed runbook, recorded training, two weeks of shadowing, and passing end‑to‑end tests. If any are missing, withhold final payment until they are delivered and verified by your ops person.
How do I verify the vendor's monitoring and alerts?
Have your ops person log into the vendor dashboard and trigger a controlled alert during the session. Confirm the alert reaches documented contacts and that vendor and ops see identical logs and timestamps.
Should I insist on code escrow or an export clause?
Yes. If the automation cannot run without vendor tools, insist on a code escrow mechanism or an explicit export of the final configuration within a contractually defined time after acceptance.
How long should the shadowing period be?
At least two weeks for frequent processes; longer if the process runs infrequently or has complex exceptions. The period must include live incidents, not just walkthroughs, so ops proves competence under real conditions.
Fixed price support or hourly—what do I choose post-handover?
Negotiate a short fixed‑price transition window plus a capped hourly rate afterward. That gives predictable economics while you stabilise ownership and prevents surprise bills for routine fixes.
Can my non‑engineering ops person validate the handover?
Yes, if runbooks are written for non‑engineers and you run the acceptance scorecard. The ops person should perform start/stop, run the tests, recover documented failures, and access dashboards without vendor help.
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.