I convert pilots into production by treating them as products: define measurable KPIs and one SLO, assign an operations owner with budgeted support, replace prototype glue with a minimal reliable connection, deliver a handover package (runbook, tests, monitoring, rollback), and fund ongoing maintenance.
- A pilot that impressed stakeholders is not production until someone is paid to own failures and fixes.
- Define KPIs and an SLO before scaling; the final stretch of reliability costs more than the initial work.
- A copyable handover package removes single-person dependency and halves mean-time-to-recover when things break.
- Keep prototype code that is reliable; refactor only when scale, repeated failures, or compliance force it.
- If you will not fund maintenance or name an owner, hire a scoped partner to deliver and transfer responsibility.
Signs this is happening in your business
- The automation only runs when the original developer clicks a button or restarts a process.
- Stakeholders praise the demo but there are no logged failures, alerts, or incident records.
- Team members still re-key or correct records after the automation runs.
- No budget line exists for post-launch monitoring, small fixes or hypercare.
- IT refuses handover because documentation, credential management or security checks are missing.
- Every change to connected systems requires the developer to rewire the automation.
- Operations staff have no runbook and rely on ad-hoc Slack messages when it fails.
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 cost of four people spending six hours a week each on manual work that could be automated.
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.
convert automation pilot into production
You either promote the pilot into a funded product with an operations owner, acceptance gates and a budget, or you hire a scoped partner to do that work. Agree measurable KPIs and require a minimal handover bundle before any further development spend.
Lock KPIs and an SLO, name an operations owner with a budget line, set acceptance gates, and demand a handover bundle: runbook, tests, monitoring and rollback.
- Agree KPIs and one SLO with measurable targets.
- Set acceptance gates tied to a live-sample period.
- Name an operations owner and budget a support line.
- Require a handover bundle: runbook, tests, monitoring, rollback.
Nobody agreed what 'done' looks like — why pilots stall
Pilots stall when teams treat demos as research rather than a supported service. Without budget, documented ownership and an incident process, demo-grade prototypes rot: brittle connectors break, nobody rows to fix them, and stakeholders still expect demo-level effort to scale.
That mismatch kills momentum and makes the build team's job purely reactive.
- Technical brittleness: prototype connections fail under load or edge cases.
- Organisational and expectation gaps: the developer moves on and stakeholders assume low effort for scale.
Concrete success criteria for production
Production-ready means you can measure it and budget for it. Define three to five KPIs, an SLO tied to the acceptance sample, a binary acceptance gate, and a simple TCO that includes hypercare and annual maintenance.
If the automation fails the acceptance gate and you cannot commit budget to fix it, keep it in development.
- KPIs (examples): processing rate, error rate, human intervention rate, time saved per team.
- SLO: a measurable availability or correctness target assessed over the acceptance sample.
- Acceptance gate: a limited rollout meeting KPIs over a defined sample period before scaling.
- TCO: include developer time for fixes, monitoring costs, incident response hours and a contingency fund.
Who must own it: RACI, skills, SLAs and training handover
Ownership must be operational. I use a RACI where Operations is Responsible for runbook execution and first response, IT is Accountable for platform and compliance, the developer or vendor is Consulted for fixes, and the business process owner is Informed on KPI changes.
Fund a simple SLA for incident response and two months of hands-on training transfer to operations.
- R: Operations lead — run runbook and first response.
- A: IT or Security lead — platform compliance and permissioning.
- C: Developer/Vendor — fix code-level issues and perform refactors.
- I: Business process owner — tracks KPIs and approves changes.
If nobody is paid to own and fix the automation, it will stop working even if the code is perfect.
Handover package checklist you can copy-paste
A handover package removes the original developer's tacit knowledge. Require a one-page runbook, an automated test suite with pass/fail steps for non-developers, monitoring and alert rules, a rollback plan, credentials stored in your vault, and a documented change-control process.
Insist Operations can perform each step without the developer before any acceptance conversation.
- Runbook (one-page): purpose, owners, normal flow, top failures and recovery steps, contact list.
- Test suite: sample test cases and pass/fail instructions for non-developers.
- Monitoring & alerts: what to monitor, thresholds, alert recipients and priority levels.
- Rollback plan: quick reversal steps and decision criteria.
Runbook template (copy this)
Give this runbook to Operations and insist they can follow it without the developer. Use plain names, direct phone numbers and links to logging screens so the first responder can check green signals and run recovery steps without guessing.
Document top failures and exact clicks or commands for each recovery step.
- Title: Short name of automation
- Purpose: One sentence describing the task automated and who benefits
- Daily check: Where to look and what a green signal looks like
- Top failures: 1–5 likely failures with exact recovery steps (clicks, commands, approximate time)
- Escalation: Who to call at 5/30/60 minutes and their backup
- Rollback: Exact steps to reverse or stop the automation and the criteria to do so
- Post-incident: How to record incident data and who opens the fix ticket
Practical tech decisions: keep the pilot stack, refactor, or rebuild
Do not refactor on principle. Keep the pilot stack if it is reliable, auditable and fits the expected load; refactor when firefighting time regularly exceeds a meaningful share of the projected annual savings. Rebuild only when security or architecture choices prevent safe incremental fixes.
- Keep: prototype is stable, runs within limits and is auditable.
- Refactor: frequent edge-case failures or performance bottlenecks appear.
- Rebuild: prototype violates security or regulatory requirements or cannot be maintained.
Integration and security checkpoints to require before production
Before production require credential management in a vault with rotation, least-privilege access, an approved data retention policy, and a short security walkthrough with IT or your vendor. Do not accept brittle secrets sitting in personal accounts or scripts.
Also require production-scale testing of error handling for partial items, duplicate items and system outages; those edge cases create operational risk.
- Credential handover to a vault and rotation plan.
- Data handling and retention sign-off by compliance or IT.
- Production-like testing of failures and retries.
- A documented incident path for partial or duplicate processing.
Automating a broken process makes broken outcomes happen faster and louder.
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.
Build / Buy / Hire decision matrix for 10–200 person companies
Choose build, buy or hire based on time, risk appetite and in-house skills. Small teams with limited engineering should hire a scoped partner to finish and hand over; mid-sized firms with platform control can keep and refactor; large firms with strict security often rebuild under IT oversight.
- 10–30 people: hire a scoped partner on a fixed-price, fixed-scope contract with acceptance gates and a short hypercare.
- 30–100 people: finish in-house with a small refactor sprint if you have an operations owner and platform control; otherwise hire.
- 100–200 people: use a hybrid vendor-to-IT transfer with knowledge transfer and an SLA-backed handover.
Recommended contract model for a scoped automation partner
If you hire, use a fixed-scope contract with clear acceptance tests, a short demo at the end of each sprint, and a defined handover deliverable list. Include paid hypercare after acceptance and a set number of knowledge-transfer hours, and insist on credential transfer into your vault.
- Fixed price for transition work with clear acceptance gates.
- Two-to-eight weeks of paid hypercare after acceptance.
- Knowledge transfer hours and documentation delivery included.
How this fails in practice — the day it goes wrong
A pilot fails predictably: an unusual input arrives, the automation stalls or misroutes, no alert fires, work piles up, people revert to manual fixes, and the developer—often unavailable—gets paged. Missing visibility and ownership turn a small issue into a full outage.
- Failure trigger: unexpected input or increased volume.
- Detection gap: missing or wrong alert thresholds.
- Response gap: no clear first responder or documented recovery.
- Outcome: manual rework, angry stakeholders and de-prioritised fixes.
Staged rollout plan: pilot → limited rollout → full roll-out (sample timelines and budgets)
Promote in stages: an acceptance gate, a limited rollout on a sample of live traffic, then full rollout. Each stage has acceptance tests, a fixed budget for fixes and monitoring. Set clear rollback criteria at each stage.
- Acceptance testing: live-sample verification before rollout.
- Limited rollout: run on a small percentage of traffic with KPI monitoring.
- Full rollout: expand after acceptance with expanded monitoring and on-call support.
- Budget note: reserve funding for hypercare and an annual maintenance tranche.
When not to push a pilot to production
Do not promote when you cannot commit ongoing support and budget, when the automation causes repeated data inconsistencies, or when IT will not accept the credentials or security posture. Promotion without these creates operational liabilities that cost more than the initial demo.
- No funded owner or maintenance budget.
- Unresolved data correctness or duplicate processing issues.
- Security or compliance blockers that remain open.
What to do next
Pick one practical activity: run a 30-minute KPI and ownership workshop with stakeholders and the developer, produce a one-page acceptance checklist and submit a budget request for the next quarter. If you want help I offer scoped discovery and delivery; see How to work together and Services.
You can also review examples in Portfolio and case studies.
- Schedule a 30-minute workshop to agree KPIs, owner and budget.
- Demand the handover package from the build team before any acceptance talk.
- If you lack technical leadership, consider a fractional CTO to oversee the transition.
Where businesses waste the most time
- Re-keying customer dataWastes hours and generates mistakes during busy periodsAutomate the transfer of entered fields between systems while keeping existing software unchangedA person still checks: A person spot-checks exceptions flagged by the automation
- Manual invoice approvalsDelays payments and ties up the AP teamAutomatically present invoices to approvers with a single approve/reject action inside current systemsA person still checks: Approver signs off on flagged or high-value invoices
- Support ticket routingAgents read every ticket and forward cases manuallyAutomatically classify incoming tickets and route routine ones to queues in your existing helpdeskA person still checks: Agent handles the uncertain or escalated tickets
How this compares with what you already run
| Operational area | The manual way | The automated way | Annual business impact |
|---|---|---|---|
| Invoice processing | People read and key invoices | System reads invoices and posts them for approval | Lower payroll cost and fewer late payments |
| Customer onboarding | Manual form checks and emails | Automated checks and templated messages | Faster onboarding and reduced churn |
| Support triage | Agents read every ticket | System routes and highlights uncertain cases | Reduced agent hours and faster SLAs |
| Data reconciliation | Daily spreadsheets and manual fixes | Automated comparison and flagged mismatches | Fewer errors and reduced month-end surprises |
| Order entry | Re-keying orders from email | Orders captured and verified automatically | Fewer errors and faster fulfilment |
| Compliance reporting | Manual aggregation each month | Automated extraction and report generation | Lower risk and less senior time spent |
What the end-to-end workflow looks like
- Define valueAgree the business outcome and the KPIs you will measure.Stays human
- Audit prototypeList fragile points, credentials and known failures in the pilot.Automation documents what it does
- Agree acceptance gatesSet SLOs, sample periods and rollback criteria for promotion.Stays human
- Deliver handover packageBuild team produces runbook, tests, monitoring and rollback steps.Runs automated tests
- Limited rolloutRun the automation on a small slice of live traffic while monitoring KPIs.Carries out the work for the sample group
- Full rolloutExpand to all users after acceptance and monitor for regression.Runs at scale with alerts
- HypercareProvide increased monitoring and quick-response fixes for a fixed period.Alerts humans when thresholds hit
- Transfer to steady-stateMove responsibility to operations with a documented SLA and budget line.Stays human
The metrics that tell you it worked
| Metric | What it tells you |
|---|---|
| Processing rate | Number of items processed per day; shows capacity improvements and if throughput meets demand |
| Error rate | Share of items requiring human correction; measures correctness and drives incident triage |
| Human intervention rate | Manual touches per 100 items; indicates residual manual work to budget for |
| Mean time to recover (MTTR) | Average time from alert to recovery; signals operational readiness and staffing needs |
| Time saved per person | Average hours saved per team member per week; used in ROI and staffing calculations |
| Incidents per month | Count of failures requiring an outage or rollback; drives maintenance budgeting |
When this is the wrong move
- You cannot commit budget for ongoing maintenance and hypercare.
- The automation produces duplicates or corrupts data and fixes are undefined.
- IT or compliance refuses to accept credentials or data flow arrangements.
- You lack anyone to act as the operations owner for incidents and KPI tracking.
The mistakes that cost the most
- No acceptance gateTeams move the pilot into production based on a demo; edge-case failures appear under live traffic, nobody agreed measurable success, fixes are unbudgeted and the automation collapses into manual work.
- Single-person ownershipThe original developer is the only person who knows how to restart or fix the automation; they leave or are reassigned and the automation becomes unrecoverable.
- Automating a broken processThe pilot automates a bad input or manual workaround; when scaled the automation repeats the bad outcome faster, increasing costs and complaints.
Frequently asked questions
How long does it take to convert a pilot into production?
Plan for about 6–12 weeks to convert a pilot. Expect 2–4 weeks for acceptance testing, 4–6 weeks for a limited rollout, time for documentation and a short hypercare; complexity and governance will extend that timeline.
Who should be the operations owner?
Pick an operations generalist who already manages daily process health and can be funded from the process budget. They must be empowered to pause the automation and request developer fixes; giving the role without budget makes it ineffective.
Can we keep the prototype code?
Yes, keep prototype code if it runs reliably under expected load and meets security checks. Refactor only when repeated failures, scale limits or compliance gaps make small fixes insufficient.
What does a good handover package include?
A runbook with recovery steps, an automated test suite, monitoring and alert rules, a rollback plan, credentials handed into your vault, and a change-control procedure. Insist the build team hands this over before any acceptance conversation.
Should we hire an external partner to finish the transition?
Hire a scoped partner if you lack an operations owner, platform control, or developer capacity. Use a fixed-scope contract with acceptance gates and paid hypercare to convert the pilot without draining internal teams.
How do I budget ongoing maintenance?
Budget three months of hypercare at about 25% of one developer's time plus an annual maintenance tranche for small fixes and monitoring. Track incidents and adjust next year's budget based on MTTR and incident frequency.
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.