I recommend you budget 6–12 weeks to automate a single fixed-scope process: discovery, design, build/integration, testing/UAT, handover and adoption. Promises of 1–2 weeks usually skip discovery or adoption. Budget internal calendar time, contractual milestones and a short warranty window to realise savings.
- Budget 6–12 weeks for a single fixed-scope automation; shorter timelines omit essential work.
- Reserve specific calendar time for operators, finance approvers and IT to avoid stalls.
- Write acceptance criteria into the contract and tie payments to sign-off.
- Force quick data checks in discovery; most overruns come from bad data and unclear rules.
- Plan a short warranty window so early fixes do not fall to internal payroll.
Signs this is happening in your business
- Three people spend an hour each day copying client details from the CRM into billing.
- Invoices contain errors because fields are entered differently between systems.
- Staff escalate simple enquiries because nobody owns the transfer process.
- An automation is rolled out in Slack but no one uses it after two months.
- Projects stall waiting for a product owner to sign off on acceptance tests.
- Finance runs a manual reconciliation every month because automated matching fails.
- New joiners are trained on manual steps because the automation is unreliable.
- IT says 'we need access' and the project sits in a queue for weeks.
- Vendors ask for 'a week of client time' but never say which people or when.
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 wasted on manual re-keying across four people.
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.
How long to automate one business process — plan 6–12 weeks
You should plan 6–12 weeks to automate a single, fixed-scope process: discovery, design, build/integration, testing, handover and adoption. Promises of 1–2 weeks usually deliver only a partial build and skip discovery or adoption, which leaves old work in place and pushes costs into support and rework.
This estimate is phase-based: each phase exists because skipping it produces errors, unpaid invoices or staff resistance.
- Discovery and scoping: 1–2 weeks.
- Design and mapping: 1 week.
- Build/integration: 1–4 weeks depending on complexity.
- Testing and user acceptance: 1–2 weeks.
- Handover, training and adoption: 1–2 weeks.
- Initial support and tweaks: 1–4 weeks of SLA-covered fixes.
Discovery is not optional — what happens in the first 1–2 weeks
Discovery identifies decision points, exceptions and success measures. In the first 1–2 weeks the vendor and your operator map who touches the data, when they do it, and what a correct transfer looks like. Skipping discovery guarantees the team will get the wrong automation and pay later in fixes and missed invoices.
Good discovery produces a clear process map, a short list of required data fields and a short acceptance checklist for testing.
- Walk the process with the person who does the work — not their manager.
- Collect 20 representative examples of problematic records.
- Agree on what a correct record looks like and how to recognise failures.
Design and mapping — convert work into rules (about 1 week)
Design converts the process map into explicit rules and checks. In about a week you must settle the source of truth for each field, duplicate handling, and the exact sequence for multi-address clients. Design delivers a build flow, transformation rules and an error plan that separates blocking failures from ticketed exceptions.
The outputs are a step-by-step flow for the build, a list of transformation rules, and an error-handling plan that states which failures stop the automation.
- List every field to transfer and who owns each field.
- Decide the rule for ambiguous data (for example, use billing address if present).
- Define fallbacks and the escalation path.
Build and integration — what 1–4 weeks buys you
Build implements the transfer routine and the checks the design specifies. Time hinges on how many special cases you accept and whether the systems allow a direct connection. A short build is possible only when systems are modern, fields are straightforward and discovery was thorough.
Expect 2–4 weeks if you need to normalise addresses, consolidate duplicates, or add a reconciliation report.
- Simple direct transfers with predictable fields: 1 week.
- Transfers requiring de-duplication or transformation: 2–3 weeks.
- Transfers needing a reconciliation report: add 1 week.
If manual work remains after go-live, the failure is adoption, not technology.
Testing and UAT — 1–2 weeks that stop rework
Testing is where the operators who did the work verify the automation on real examples. Operators—not IT—should run the checklist from discovery and a batch run that matches a typical day's volume. Allow two rounds of fixes and a final acceptance sign-off from the downstream owner, usually finance.
Use the 20 representative records from discovery plus a batch run of about 200 records to expose edge cases.
- Operator-run tests on representative records.
- One batch-run simulating normal volume.
- Acceptance sign-off documented against agreed criteria.
Handover, training and adoption — 1–2 weeks to make the work stay automated
Handover transfers fix responsibility to your team: short training, a one-page runbook and a rollback plan for the first month. Treat this as change management; operators must stop the manual step the day the automation goes live or the automation will have no effect.
Make adoption explicit: block calendars so operators cannot continue the old habit and the automation produces real savings.
- Two 45-minute training sessions for operators and managers.
- A one-page runbook describing common failures and recovery.
- A three-week support window with clear SLAs for fixes.
Support and initial tweaks — 1–4 weeks of guaranteed fixes
Plan 2–4 weeks of vendor-covered fixes after handover for tuning rules against edge cases and adoption problems. That warranty window keeps early fixes off your payroll and prevents surprise invoices. If your contract has no warranty, expect to fund initial fixes from headcount or extra vendor charges.
Treat this as part of the delivery, not optional extras the vendor will bill later.
- Two weeks of included fixes is the minimum for a small process.
- Four weeks is reasonable if the process touches finance or billing.
Who must be available and when — commit calendars or expect delays
People are not optional. Reserve operator, finance approver, IT admin and a decision-maker for defined phases: discovery, design, testing and handover. Vendors wait when calendars are vague and the clock stops; budget specific hours per role and phase instead of vague 'availability'.
Treat this as the internal calendar cost that determines your delivery date.
- Discovery: operator 4–6 hours across 2–3 days; decision-maker 1 hour.
- Design: operator and finance approver 4 hours in a single workshop.
- Testing/UAT: operators 8–12 hours over 1 week; finance approver 4 hours.
- Handover: operators 4 hours for training; owner 2 hours to accept.
Vendors who refuse to document acceptance criteria are shifting scope risk onto you.
How delivery model changes the timeline: buy, fixed-scope consultant, custom build, or hire
Your delivery model changes lead time and hidden calendar cost. Off-the-shelf tools can be quick but still need configuration and adoption; fixed-scope consultants give predictable phased delivery if discovery is priced separately; custom builds and hires take longer and need technical leadership and ramp time.
I favour a fixed-scope consultant for a single reliable process and rapid ROI because they usually minimise scheduling and calendar risk.
- Off-the-shelf tool: fastest for common processes, still needs discovery and adoption (total 4–8 weeks).
- Fixed-scope consultant: predictable 6–12 week phase-based delivery if discovery is quoted separately.
- Custom internal build: 8+ weeks plus hiring or allocation time; needs a technical lead.
- Hiring full-time: hiring and ramp typically 8–16 weeks before value arrives.
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 timeline risks extend delivery and what to do first
Unclear requirements, legacy access work, poor data quality and missed sign-offs turn days into weeks. The first mitigation is to trade vague availability for fixed decision points and written acceptance criteria. Put sign-offs in the contract and book meetings in calendars at project start.
Practical mitigations reduce delays and limit scope creep.
- Unclear requirements — mitigation: rapid one-day workshop with the person doing the work.
- Legacy access delays — mitigation: schedule access and admin support during discovery.
- Data quality issues — mitigation: assign a short clean-up task to an operator before build.
- Stakeholder sign-off delays — mitigation: book sign-off meetings in calendars at project start.
What a healthy vendor contract and timeline looks like
A healthy contract breaks the work into phases with milestones, measurable acceptance criteria, a warranty window and explicit handover obligations. Vendors who resist are pricing scope risk into your quote. Require deliverables per phase, UAT checks signed by the operator, a 2–4 week warranty and a one-page runbook at close.
Tie milestone payments to acceptance sign-off, not delivery dates.
- Milestone payments tied to acceptance sign-off, not delivery date.
- Acceptance criteria: documented and signed by the operator and finance approver.
- Rollback obligation: vendor provides steps to revert to the manual process if required.
- Warranty: at least two weeks of included fixes; three to four for billing processes.
Measuring payback — when the automation begins to save money
Payback starts when manual hours fall and staff stop doing the old steps. Measure weekly hours saved and the total project cost including vendor fees and internal calendar time. Divide project cost by weekly payroll savings to estimate weeks to payback and track a four-week baseline before go-live.
Timeline delays push the payback date out week-for-week because internal time and vendor invoices still accrue.
- Baseline: count operator hours for four weeks before project start.
- Post-live: measure hours saved for the first eight weeks.
- Payback calculation: project cost divided by annualised payroll savings.
Most 'fast' automations are partial fixes that move cost to support.
Why pilots impress then die — the failure sequence you will see
Pilots fail when they handle only easy cases and leave operators to manage exceptions. The sequence is predictable: pilot shows good results, management assumes the problem is solved, operators keep running manual work for exceptions, usage drops, and the automation is abandoned. Contract the pilot with edge-case rules and a handover plan.
Require the pilot's acceptance to include rules for edge cases and a handover that removes manual work on sign-off.
- Pilot uses sanitized data — operators see differences with live data.
- Operators continue manual steps for exceptions — old work persists.
- Automation usage falls — project loses priority and support.
What to watch for in practice — real failure modes and the sequence they follow
Typical failure starts with a rushed build, thin test and a go-live that leaves operators unimpressed. Tickets rise, the vendor blames edge cases, and the team reverts to manual work. Insist on representative records for testing and plan to stop the old manual step when go-live happens, otherwise you pay for ongoing support.
Without both representative tests and a stop-the-old-step plan the project becomes a recurring cost.
- Rushed build → insufficient test cases → go-live with errors → users revert to manual → project deprioritised.
What to do tomorrow — the first concrete step
Reserve four hours for discovery with the person who does the re-keying and the finance approver. In those four hours you will map the steps, gather 20 representative records, and create an acceptance checklist — enough information for any vendor to give a realistic 6–12 week timetable and a firm quote.
If you want that scoping call turned into a fixed-phase quote and a checklist of internal time commitments, book a scoping call at How to work together.
- Book two 90-minute workshops on consecutive days for discovery.
- Collect 20 real examples and one typical batch of records.
- Put the acceptance sign-off meeting in the calendar now.
Where I stand and why I write this
I charge and structure work to make discovery and adoption visible line items so you pay for fewer surprises and get a usable result. I sell phased quotes that name internal time commitments and a warranty window to protect your ROI and reduce later support invoices.
Read more about what an engagement covers on Services and examples of the problems I solve on Portfolio and case studies. If you want to check whether I’m the right person to run the scoping, see About the author.
Where businesses waste the most time
- Re-keying customer dataHours per week across multiple operators and frequent entry errorsCreate a direct connection that moves agreed fields from the CRM to billing and flags exceptions for review without replacing either systemA person still checks: Operator reviews flagged exceptions and approves ambiguous records
- Manual invoice matchingFinance spends time matching records and chasing discrepanciesAdd a daily reconciliation view that matches invoices to records and shows only mismatches for human review without changing source systemsA person still checks: Finance approves mismatches and corrects source data
- Copying addresses into multiple recordsInconsistent addresses create client confusion and failed invoicesApply a single rule set to standardize address fields during transfer while keeping the original field in the CRMA person still checks: Operator checks unusual addresses flagged by the rule set
How this compares with what you already run
| Operational area | The manual way | The automated way | Annual business impact |
|---|---|---|---|
| Re-keying client data | Operators copy fields by hand | Automatic transfer with checks | Lower annual payroll costs |
| Onboarding client records | Multiple teams repeat entries | Single input triggers downstream | Fewer missed charges per year |
| Invoice reconciliation | Manual matching and spreadsheets | Automated match with exception queue | Reduced year-end overtime |
| Address normalization | Operators edit fields manually | Standardized address rules applied | Fewer failed deliveries annually |
| Duplicate client detection | Duplicates create billing errors | Automated detection and review | Fewer write-offs each year |
What the end-to-end workflow looks like
- Entry in CRMClient details are entered or updated in the CRM by sales or operations.Triggers the transfer process to start
- ValidationFields are checked against the agreed rules for required fields and formats.Applies validation rules and flags failures
- TransformFields are transformed to match billing system requirements.Performs the field mapping and normalization
- TransferThe processed record is handed to the billing system for creation or update.Executes the transfer and records the result
- Exception queueRecords that fail validation or need judgement are routed for review.Places items in a queue for a person to review
- Operator reviewA named person reviews exceptions, corrects data, and approves the record.Stays human
- Reconciliation reportA daily or weekly report compares expected vs actual transfers and highlights mismatches.Generates the reconciliation for finance to check
The metrics that tell you it worked
| Metric | What it tells you |
|---|---|
| Operator hours on process per week | Total person-hours spent executing the manual steps each week; it falls as automation succeeds |
| Error rate per 1,000 records | Number of records needing correction after transfer; measures the quality of the automation |
| Time to resolve exceptions | Average hours between an exception appearing and being resolved; shows if the queue is manageable |
| Acceptance sign-off time | Days between test completion and formal acceptance; indicates bottlenecks in decision-making |
| Monthly rework hours | Hours spent fixing issues caused by the automation or manual fallbacks; should trend down |
| Number of manual steps remaining | Count of actions operators still perform; a direct measure of how much work remains to remove |
When this is the wrong move
- When the process changes weekly and rules would need constant updates.
- When no one will stop doing the manual task — automation just creates shadow work.
- When the data requires weeks of cleanup before a reliable transfer is possible.
- When the process handles regulated data and compliance approvals will delay delivery beyond the window.
- When the business case relies on fuzzy time savings without a measured baseline.
The mistakes that cost the most
- Skipping discoveryTeams rush into building; the vendor guesses field mappings; after go-live operators see missing cases; vendor bills for rework and the team reverts to manual steps.
- Underestimating calendar costVendor assumes 'one hour here and there' from operators; in reality the operator needs dedicated blocks; the project stalls until that time is freed.
- Treating adoption as optionalGo-live happens with no training; operators keep old habits; automation usage drops and the automation becomes a box on a shelf.
- No acceptance criteriaVendor delivers 'it works' with no measurable tests; finance discovers mismatches; dispute over whether the milestone was met delays payment and fixes.
Frequently asked questions
Can a vendor really deliver a reliable automation in 1–2 weeks?
No. A credible 1–2 week delivery usually covers only a trivial build without discovery or adoption. Without discovery you won't know the exceptions; without adoption the old work continues. Plan for discovery and operator testing before you accept a 'fast' timeline.
How much internal time should I book for my team?
Reserve about 16–24 hours of operator time for discovery, testing and training, plus 4–6 hours from a decision-maker. Put these blocks in calendars before the vendor starts to avoid delays.
Which delivery model gives the fastest real ROI?
A fixed-scope consultant who prices discovery separately typically gives the fastest and least risky ROI for a one-off process. Off-the-shelf tools can be fast for common cases but still require discovery and adoption to deliver real savings.
How do timeline delays affect ROI?
Every week of delay pushes back when payroll hours begin to fall, so payback slides out week-for-week. Delays also increase internal and vendor costs, which reduce the annualised savings you expected.
What should acceptance criteria include?
Acceptance criteria should be a short list of concrete checks the operator runs on representative records and a sample batch run. Include tolerances for acceptable failures and a signed acceptance by the operator and finance approver.
Is it worth hiring a full-time person to automate a single process?
Usually not. Hiring adds recruitment lead time and an ongoing salary that often exceeds a consultant's project cost for a single task. Hire when you have a steady pipeline of automation needs or need permanent technical leadership.
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.