Combine three evidence sources: transaction logs, an access/permissions matrix and a 60–90 minute process walk with the person doing the typing. That set reveals where identical data is retyped, gives you frequency and time metrics, and produces the brief required to scope a fixed-price automation with testable acceptance criteria.
- You can find most rekeying candidates without a full audit by using logs, access data and a single process walk.
- Price the problem across the team — small per-person time adds up to a meaningful annual payroll drain.
- Vendors that refuse to show sample traces or error handling are the common source of scope creep.
- A fixed-scope automation brief must include explicit acceptance tests, reconciliation rules and an owner for failures.
- Automating a broken process makes the problem permanent; fix the process first, automate second.
Signs this is happening in your business
- Sales ops copies order lines into the billing system after each closed deal
- Recruiters paste candidate fields from the applicant tracker into payroll every month
- Monthly reports are rebuilt from exported CSVs and hand‑cleaned in a spreadsheet
- A single person is the only one who knows how to translate one system’s codes into another
- Teams email CSVs as attachments and someone retypes rows into the destination tool
- Errors spike when headcount or prices change and someone must chase reconciliations
- Vendors promise direct connections but ask for screenshots and manual steps instead
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 each spending six hours a week on manual rekeying
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 to map manual rekeying across SaaS
Use three concrete inputs: system transaction logs, an access/permissions matrix and a 60–90 minute process walk with the operator. Together these show where the same data appears in multiple tools, how often humans move it, and how brittle the handoffs are. I use this set to measure frequency, minutes per rekey and error burden.
I use those three items in every scoping conversation because they produce measurable evidence and a scoping brief you can act on.
- Pull system transaction logs covering the last month for the involved tools
- Map who can view or change the fields being retyped
- Walk one full example from start to finish with the operator doing the work
What manual rekeying looks like in day‑to‑day work
Manual rekeying is repeatedly moving the same data by hand between SaaS tools: copying order lines into billing, pasting candidate fields into payroll, exporting invoices and rebuilding them, or summarising tickets into reports. Each instance feels small; the cost appears when many people repeat it weekly or when exceptions require manual fixes.
Recognise it by repeated copy/paste, exported CSVs routed through sheets, and single‑person knowledge of mapping rules.
- Sales > Billing: order items, discount codes and delivery instructions retyped
- ATS > Payroll: candidate IDs, start dates and pay rates copied manually
- Exports > Reporting: CSV exports merged and cleaned in a sheet
- Support > CRM: ticket outcomes summarised and pasted into account records
A one‑day discovery you can run yourself
You can discover the main rekeying flows in a single day by pulling transaction logs, exporting permissions, mapping fields and running a 60–90 minute process walk. That produces the evidence to price an automation or to disprove a vendor’s direct‑connection claim and gives you the sample records for acceptance tests.
Below I list the exact steps I run with operations leads and the artifacts I collect.
- Step 1: pull transaction logs for each system for the last 30 days
- Step 2: export a user permissions report from each system
- Step 3: build a simple sheet mapping the common fields between systems
- Step 4: run a single 60–90 minute process walk and record timestamps
Which logs to pull and how to read them
Pull logs that show created and updated records with timestamps and user identifiers. Look for identical reference numbers, emails or IDs appearing in two systems within a short window; those are candidate rekey paths. Count matches to estimate frequency and flag destination events where the actor is a human user — that signals manual entry.
If reading raw output is hard, ask for an admin export of created/updated rows with timestamp and username columns.
- Look for identical reference numbers, customer emails, invoice numbers or candidate IDs in both systems
- Sort by timestamp and find events where System A has a create/update and System B has a create/update within minutes or days
- Flag events where a human user is listed as the actor in the second system
Small, repeated typing tasks are the sneakiest payroll leak — they never look urgent until you total them across the team.
A 60–90 minute process‑walk script that exposes rekeying
Sit with the operator and run one real example from start to finish while you time each step and take notes. Ask them to show every tool, every spreadsheet and every email they use and to think aloud. That single run captures the exceptions they handle and the hidden artifacts they rely on.
Record three things per step: time spent, source of the data, and any transformation or lookup rules applied.
- Begin: ask for the trigger that starts the work and observe the source record
- Record: every copy/paste, export/save‑as and manual lookup
- Finish: show how they verify success and what they do when it fails
How to measure frequency, time per rekey and annualise the cost
Measure three inputs: frequency per week, average minutes per rekey, and the hourly cost of the people doing the work. Multiply people × hours × rate × 52 and add time spent on error corrections to annualise payroll cost. That gives a defensible number to compare with a fixed‑price quote.
Use the process walk timing for minutes per rekey; sample three runs if unsure and average them.
- Frequency: count matched events found in logs per week
- Time per rekey: use process walk timing or average three runs
- Error rate: count reconciliations per month and estimate time per correction
Simple formulas and thresholds for worth automating
Use a money test: if the annual payroll cost plus error costs exceeds the fixed price a vendor or builder quotes, automation clears the budget. Factor in single‑person dependency and operational impact. I prefer fixed‑price pilots with explicit acceptance tests rather than open‑ended contracts that hide exception work.
Make the threshold a line item in the decision document so procurement can compare quotes objectively.
- Payroll cost = (people × hours per week × hourly cost × 52)
- Add: estimated time on error corrections per month × hourly cost × 12
- Threshold: if total annual cost exceeds the fixed‑scope quote, the project passes the money test
How to validate vendor claims and the evidence to ask for
Ask vendors for three concrete items: a recorded trace of an automated run for a real example, a mapping sheet listing source fields, destination fields and transformations, and documented error handling including retries and idempotency. If they refuse any of these, assume scope will grow and costs will rise.
Demand end‑to‑end traces that show the source record, the time the automation ran and the destination change.
- Request a recorded trace showing source record, the automation event and the destination change
- Request a sample mapping sheet listing source field, destination field and transformation rule
- Ask for examples of failure handling, retries and how reconciliations are surfaced
Vendors sell direct connections; poorly scoped projects sell you exceptions handling and a growing backlog.
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.
Red flags that mean the vendor's scope will balloon
Immediate red flags are: no sample trace, promises to 'handle exceptions later', or refusal to name who owns reconciliation after failures. Vendors who treat spreadsheets or emailed attachments as immutable inputs usually hide complexity. Those signs predict scope creep, longer timelines and increased costs.
If a vendor cannot show how they handle the three most common exceptions, assume the headline quote is optimistic.
- No sample trace for your data
- No clear mapping for ambiguous fields
- Vague error handling or no reconciliation plan
Turning findings into a fixed‑scope automation brief
Convert discovery outputs into a brief containing acceptance criteria, test cases, a data mapping sheet and a handover checklist. That makes the pilot testable and prevents the usual pilot drift where partial automation is abandoned. Each acceptance test must use real sample records and reconciliations you collected in discovery.
Produce a short brief that a vendor can price against and that you can use to sign off delivery.
- Acceptance criteria: explicit checks using sample records and reconciliations
- Test cases: real examples including the three most common exceptions
- Data mapping: source field, destination field, transformation rule and mapping owner
What failure looks like in practice and the usual sequence
Failure follows a pattern: vendor builds happy‑path automation, exceptions appear, manual cleanups continue, no owner is named for reconciliation, and the automation is deprioritised. The visible consequence is the same work plus more complexity. Acceptance tests must include reconciliation scenarios and named owners to prevent that sequence.
The operator who runs reconciliations will spot this first; include them in test acceptance.
- Vendor delivers happy‑path automation
- Exceptions generate manual cleanups
- No owner for reconciliation; manual work remains
- Automation is considered incomplete and deprioritised
Hidden sources and quick ways to uncover them
Shadow spreadsheets, emailed CSVs, screenshots and manual cleanups are usually the real source of work. Someone with broad access exports data and distributes it off‑system. Discover them by asking for the last three exports and the last three corrected records and by probing one process walk question that exposes off‑system artifacts.
A targeted question in the process walk will reveal who exported or emailed the last copies.
- Ask: 'When was the last time you exported this data and who did you send it to?'
- Request named examples: last three corrected records and how they were fixed
- Look for spreadsheets with column names matching both systems and dated tabs
Next step: run the checklist and scope your top opportunity
Run the logs + process walk checklist this week and you will have the evidence to price a fixed‑scope automation. If you want help turning the top candidate into a brief I scope fixed‑price pilots that include acceptance tests and a handover plan — see how I work with you or take the delivery route via services.
Deliver a short brief with acceptance criteria and three test cases to hand to any vendor or builder.
- Checklist: pull logs, export permissions, run a process walk, map fields, estimate time and error cost
- Deliverable: a short brief with acceptance criteria and three test cases you can give to a vendor or builder
Where to get help turning this into a build
If the top candidate passes the money test you will need technical leadership or a small build. For advisory work see tech consulting or for delivery see build tech for you. Both paths include the fixed acceptance tests I insist on and a handover checklist.
If you want examples of scoped pilots and how I keep them alive, browse portfolio and case studies.
- Advisory: decision document, vendor validation, acceptance criteria
- Delivery: fixed‑scope pilot, test runs, handover checklist
Where businesses waste the most time
- Re-keying customer ordersMultiple staff hours each week and delayed billingMap order fields from the sales tool to billing and transfer them without replacing either toolA person still checks: A person reviews mismatches and approves corrected orders
- Copying candidate details to payrollWeekly manual entry and single-person knowledge riskCreate a mapped transfer from the applicant tracker to payroll with a verification stepA person still checks: HR approves new starter records before the payroll run
- Rebuilding reports from exportsAnalyst time cleaning CSVs and manual reconciliationsAutomate scheduled extracts and canonical field mapping that feed the report toolA person still checks: Analyst reviews anomalies flagged by the transfer
How this compares with what you already run
| Operational area | The manual way | The automated way | Annual business impact |
|---|---|---|---|
| Sales to billing | Sales ops copy order items into billing | Orders appear in billing after a verified sale | Lower payroll spent on order entry |
| ATS to payroll | Recruiter pastes candidate data into payroll | Candidate records flow with mapping rules and checks | Fewer onboarding delays and lower single‑person risk |
| Invoicing | Invoices exported and retyped into accounting | Invoices transmitted automatically with validation | Fewer late payments and less time fixing invoices |
| Reporting | CSV exports cleaned in sheets then pasted into dashboards | Reports pull validated data from sources on schedule | Analyst hours freed and timelier reports |
| Support summaries | Agents copy ticket outcomes into CRM manually | Ticket outcomes update account records automatically | Faster SLA reporting and reduced reconciliation time |
What the end-to-end workflow looks like
- Order captureSales records the order in the CRMStays human
- Order validationSales ops checks pricing and approval rulesAutomation flags missing approvals for review
- Export or triggerA record is prepared for billing, often as an export or copyAutomation prepares the mapped record automatically
- Creation in billingSomeone types the order into billing or pastes fieldsAutomation creates the billing record and records the trace
- ReconciliationFinance checks invoices against orders and fixes exceptionsAutomation produces a reconciliation report for exceptions
- Exception handlingOperators fix items that failed mapping or validationStays human
- ConfirmationBilling confirms invoice and payment terms with salesAutomation notifies stakeholders of completed transfers
- Audit trailRecords and traces are stored for later reviewAutomation records a full trace for each transferred order
The metrics that tell you it worked
| Metric | What it tells you |
|---|---|
| Weekly rekey events | Count of times identical data is moved manually between systems; it shows exposure and frequency |
| Average minutes per rekey | Time from starting the manual transfer to completion; it drives labour cost |
| Monthly correction incidents | Number of reconciliations or corrections logged per month; it measures error burden |
| Single‑person dependency | Number of processes only one person can complete; it measures operational risk |
| Time to detect failure | Hours between a transfer failing and someone noticing; it measures recovery exposure |
| Exports per week | How often data is exported and moved into external sheets; it uncovers hidden workflows |
| Percentage of records passing validation | Share of transferred records that need no manual correction; it measures automation readiness |
When this is the wrong move
- When the work is infrequent (fewer than a handful of times per month) and exceptions dominate every run
- When the source system will be retired within 3–6 months and a short-term manual fix is cheaper
- When data quality is so poor that automation would repeatedly create incorrect outcomes
- When the cost of fixing the upstream process exceeds the value of automating the transfer
The mistakes that cost the most
- Automating a broken processTeam automates the current steps without fixing upstream data or rules, then faces more errors and a growing exception backlog
- No acceptance testsPilot is judged by vendor delivery rather than by concrete reconciliation examples, leaving key exceptions unaddressed and the pilot abandoned
- Ignoring hidden exportsThe build moves visible fields but misses spreadsheets and emailed CSVs, leaving most manual work unchanged
- Single‑owner handoverHandover assumes one person will maintain the automation; when they leave, the automation fails and no one knows how to fix it
- Accepting vague vendor claimsVendor promises a direct connection but has not mapped fields or shown error handling; scope increases and costs rise
Frequently asked questions
How long does the quick discovery take and who should run it?
A focused discovery is a working day: pull logs and permissions in the morning, run a 60–90 minute process walk in the afternoon. Operations or someone with admin export rights plus the person who does the work should run it.
What if my admin cannot export the logs?
Ask the admin to export created/updated rows with timestamps and user names for the last 30 days; if they refuse, escalate as a governance issue because you cannot map rekeying without that evidence.
How do I estimate error cost without exact figures?
Count reconciliations each month and time three correction runs. Multiply average time by the hourly cost and by 12 to annualise. That gives a defensible error cost you can add to the payroll calculation.
Can a vendor deliver a fixed‑price automation?
Yes, but only if the scope includes mapped fields, acceptance tests with real examples, and a reconciliation plan. If the vendor will not sign up to those items, expect the price or timeline to grow.
What are the minimum acceptance tests I should insist on?
Insist on three real examples: a happy path record, the most common exception, and the most damaging exception. The automation must pass all three with documented outcomes before you accept delivery.
Who should own the automation after delivery?
Operations should own day‑to‑day monitoring and reconciliation, with a named technical contact for fixes. Handover documentation and a runbook listing common failures and fixes prevents the pilot from fading.
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.