How to Audit Your Company for Repeated Work in One Afternoon

Most companies do not need a six-month transformation program to discover where time is disappearing.
You can learn a lot by tracing three real workflows for a few hours.
Not asking teams where the process is inefficient.
Not drawing the ideal workflow from memory.
Actually following work that happened.
For developers and engineering leaders, think of this as tracing a request through a distributed system.
The difference is that some of the services are humans, spreadsheets, inboxes, approvals, and Slack messages.
Asking Finds Symptoms. Tracing Finds Causes.
Ask a team what slows them down and you will usually hear:

• too many approvals
• bad tools
• duplicate data entry
• unclear ownership
• slow responses from another team Those answers are useful. But they are observations from one point in the system. Instead, pick a real transaction and follow it end to end. For example: Lead ↓ Sales qualification ↓ Proposal ↓ Contract ↓ Customer setup ↓ Delivery ↓ Billing

Then use an actual customer that recently went through that workflow.
What really happened?
You might discover something closer to:
CRM
↓
Salesperson exports data
↓
Spreadsheet
↓
Operations re-enters data
↓
Manager checks it
↓
Waits for approval
↓
Someone follows up in Slack
↓
Data entered into another system
↓
Customer setup completed

That is considerably more useful.
Pick Three Workflows
Do not attempt to document the whole company.
Pick three workflows that are frequent enough to matter.
Good candidates include:

• customer onboarding
• support tickets
• invoice processing
• purchase approvals
• employee onboarding
• project handoffs
• release approvals Choose one recent real example from each. You are not designing anything yet. You are collecting traces. Marker 1: Duplicate Entry The easiest thing to spot is information being entered more than once. For example: Customer submits details ↓ CRM ↓ Spreadsheet ↓ Internal admin system ↓ Accounting system

The same information may now exist in four locations.
Developers immediately recognize the architectural problem.
You have duplicated state.
Now somebody eventually needs to reconcile it.
Ask:

• Why is this information copied?
• Which system is authoritative?
• Can the receiving system consume it directly?
• Does every copy still need to exist? Do not assume integration is automatically the answer. Sometimes one of the copies can simply be deleted. Marker 2: Queues This one gets underestimated. Find every place where work is waiting. Task created ↓ 12 minutes of work ↓ 26 hours waiting ↓ approval ↓ 8 minutes of work

The active processing time is 20 minutes.
The elapsed time may be two days.
That distinction matters.
Software teams already understand this concept.
A service can execute quickly while requests still experience terrible latency because they are sitting in queues.
Companies work the same way.
Look for work waiting on:

• approvals
• missing information
• another department
• customer responses
• manager availability
• someone noticing an inbox Record both: Active time: 20 minutes Elapsed time: 2 days

The difference tells you where to investigate.
Marker 3: Manual Checks
Watch for humans acting as monitoring systems.
Examples:
"Check whether the sync worked."

"Verify that Finance received it."

"Make sure the amount matches."

"Check the spreadsheet before sending."

"Confirm that the status changed."

A manual check can be valid.
But repeated checks usually mean something interesting.
Perhaps the system is unreliable.
Perhaps the team does not trust the data.
Perhaps there is no validation.
Perhaps visibility is poor.
The check itself may not be the root problem.
It is a signal.
For an engineer, this is similar to discovering that production reliability depends on someone manually refreshing a dashboard every morning.
You would not immediately automate the refresh.
You would ask why the system requires that human intervention.
Marker 4: Repeat or Rebuild
Now find work that gets recreated.
A report is manually assembled each Friday.
A decision discussed in one meeting gets explained again to another team.
Information already stored somewhere is copied into a new document.
A dashboard exists, but somebody recreates its numbers in Excel before leadership sees them.
It often looks like:
Existing information
↓
Export
↓
Reformat
↓
Copy
↓
Rebuild
↓
Send

Ask whether the final output actually requires all those transformations.
Sometimes the answer is automation.
Sometimes the answer is giving people access to the original information.
Measure the Cost
Now translate every finding into a rough annual cost.
You do not need finance-grade precision.
You need enough accuracy to prioritize.
A simple model works:
annual_cost =
time_per_occurrence
× occurrences_per_year
× people_involved
× hourly_cost

Suppose someone spends six minutes copying data.
It happens 40 times each week.
6 minutes × 40 = 240 minutes/week
= 4 hours/week

4 × 52 = 208 hours/year

And that is one step.
Do this across several workflows and the economics become much clearer.
Rank by Cost, Not Irritation
This is important.
The process everyone complains about may not be the best place to start.
A painful process that happens six times a year may cost less than a boring five-minute task happening thousands of times.
Rank findings using something like:
priority =
frequency
× time
× people
× business_impact

You do not need an elaborate scoring algorithm.
The goal is simply to stop prioritizing operational work based entirely on whoever complains loudest.
Do Not Automatically Create Engineering Tickets
Once repeated work is identified, technical teams often hear:
Can we automate this?

Sometimes yes.
But first classify the problem.
Delete
Some work should no longer exist.
Examples:

• an obsolete report
• an unnecessary approval
• duplicate records
• a check created for a problem that was fixed Best automation: rm unnecessary_process

Conceptually, anyway.
Team-Owned Fix
Some improvements do not require engineering.
Examples:

• clearer ownership
• a standardized template
• a better handoff
• changing notification rules
• removing an approval Do not create software just because a process is poorly defined. Technology Work Some findings genuinely belong in engineering. For example: CRM → Billing integration

Webhook-based status updates

Automated validation

Shared source of truth

Internal workflow application

Now you have something useful to scope.
You know the current process.
You know the frequency.
You know the cost.
You know the expected improvement.
That makes for a much better engineering request than:
Operations wants automation.

Turn Findings Into Execution
An audit is worthless if it becomes a slide deck.
Every meaningful finding should end in one of these states:
REMOVE
ASSIGN
AUTOMATE
INTEGRATE
INVESTIGATE
IGNORE INTENTIONALLY

And anything moving forward needs one owner.
The full sequence is:
Trace
↓
Mark
↓
Measure
↓
Rank
↓
Remove
↓
Assign
↓
Execute

That last part is usually harder than the audit.
Finding inefficiency is relatively easy.
Getting a cross-functional process changed is where ownership matters.
Measure the Workflow Again
After making a change, rerun the trace.
Compare:
Before:
Active work: 42 min
Elapsed time: 3.2 days
Manual touches: 8
Systems touched: 5

After:
Active work: 18 min
Elapsed time: 6 hours
Manual touches: 3
Systems touched: 3

Those are the kinds of numbers that tell you whether something improved.
Do not measure success by saying:
Automation shipped.

Measure the process.
The One-Afternoon Checklist
If you want to run this audit, keep it simple:

1. Pick three high-frequency workflows.
2. Select one recent real example from each.
3. Trace every step from start to completion.
4. Record active time and waiting time separately.
5. Mark duplicate entry.
6. Mark queues.
7. Mark manual checks.
8. Mark repeated or rebuilt work.
9. Estimate annual cost for each issue.
10. Rank findings by cost and business impact.
11. Decide: delete, team fix, or technology work.
12. Assign one owner to each accepted action.
13. Measure the workflow again after the change. That is enough for a first pass. You are not building the perfect process architecture. You are finding where real work is actually disappearing. For me, this is also where the Fractional Integrator role becomes useful: turning the trace into ownership and completed changes rather than leaving another backlog of “improvements” nobody drives. If you want the longer operational version, I wrote it here: How to Audit Your Company for Repeated Work in One Afternoon.