From 9,000 Manual Steps to Zero

What does it mean to go from 9,000 steps to zero?

Going from 9,000 steps to zero means not automating each step individually but redesigning the entire process so that the steps no longer need to exist, eliminating work rather than transferring it from human to machine.

The scheduling operation I inherited processed 1,000+ programs per year. Each program required enrollment management, room assignment, instructor scheduling, material preparation, and communication workflows. The total manual interaction count, verified through process mapping, was 9,000 discrete steps per scheduling cycle. Each step involved a human navigating a screen, entering a value, clicking a button, or copying information from one system to another.

The initial instinct was to automate: build scripts to click the buttons, enter the values, copy the data. This would have reduced human time while preserving the same 9,000 interactions, now performed by machines instead of people. I chose a different approach: understand why each step existed and eliminate the ones that should not.

How were 9,000 steps categorized and eliminated?

The 9,000 steps were categorized into three types (value-adding, error-correcting, and redundant), and only the value-adding steps survived into the redesigned process.

The categorization took 3 weeks of process observation and produced these proportions:

• 4,200 value-adding steps (47%): Steps that moved the process toward its intended output. Assigning rooms, scheduling instructors, generating confirmation emails. These were candidates for automation.
• 2,100 error-correcting steps (23%): Steps that fixed mistakes introduced by earlier steps. Correcting room conflicts, updating records after double-entries, reconciling discrepancies between systems. These were not automated. They were eliminated by fixing the upstream steps that caused the errors.
• 2,700 redundant steps (30%): Steps inherited from previous process versions that no longer served any function. Data entry into a system that had been replaced. Reports generated for stakeholders who no longer needed them. Approval steps for decisions that no longer required approval. These were deleted entirely.

After elimination and upstream fixes, the process contained 1,800 value-adding steps, an 80% reduction before any automation was applied.

What was the automation architecture for the remaining steps?

The remaining 1,800 value-adding steps were consolidated into a 3-stage automated pipeline: data synchronization, algorithmic scheduling, and exception-only human review.

• Stage 1: Data synchronization: A Power Automate flow pulls enrollment data, room availability, and instructor schedules from their respective source systems into a unified staging table. This replaces approximately 600 copy-paste operations per cycle.
• Stage 2: Algorithmic scheduling: A Python script applies the scheduling rules (room capacity, instructor availability, time-slot constraints, equipment requirements) to generate optimal assignments. This replaces approximately 900 manual assignment decisions per cycle. The algorithm handles constraint satisfaction. Humans previously performed this through trial-and-error, averaging 18 minutes per conflict resolution. The algorithm resolves conflicts in under 2 seconds.
• Stage 3: Exception review: The remaining 300 steps are genuine exceptions: edge cases where constraints cannot be satisfied automatically. These are surfaced in a review dashboard where a scheduler resolves them with full context. The system does not hide exceptions. It isolates them.

Total automated pipeline runtime: 47 minutes. Previous manual process: 3-5 business days.

What does this transformation reveal about the nature of operational work?

This transformation reveals that the majority of operational work in mature organizations is not productive work but accumulated friction: error correction, redundancy, and legacy processes that persist because no one has examined why they exist.

The 9,000-step process had been operating for 4 years. During that time, three process improvement initiatives had been attempted. Each one focused on making individual steps faster: better keyboard shortcuts, improved screen layouts, additional monitors. None questioned whether the steps should exist at all.

This is the fundamental error in most efficiency programs. They optimize the execution of work without questioning the existence of work. They make the wrong thing faster instead of asking whether the wrong thing should be done at all. The 80% reduction I achieved came not from speed but from subtraction: removing work that served no purpose, fixing upstream causes rather than patching downstream symptoms, and designing a process that matched the actual requirements rather than the historical accumulation of workarounds.

The Stoic principle of preferring less applies here with operational precision. The best process is not the fastest one. It is the one with the fewest steps that achieve the intended outcome. Every additional step is a potential failure point, a maintenance burden, and a cognitive demand on the person performing it. The journey from 9,000 to zero was not a story about technology. It was a story about the discipline of seeing clearly what exists, having the courage to question why it exists, and accepting the organizational friction of eliminating what should not.