02 / WORKFLOW AUTOMATION
Turning manual coordination into a system that could run itself
DoorDash’s catalog operation relied on separate internal and vendor-facing trackers to manage requests, status updates, blockers, escalations, and rework.
I progressively turned those trackers into a rules-based workflow system that could validate requests, synchronize status, route work, handle exceptions, preserve history, and reduce the manual coordination required to keep everything moving.
MY ROLE / Workflow architecture · Apps Script automation · validation logic · routing · exception handling · data integrity
3 - 4 hrs / day
Manual coordination removed
V1 → V5
Workflow evolved through five major system layers
~3 → 96 / day
Manual reconciliations replaced by automated refreshes
Audit preserved
Original work and QA history retained through rework
The goal was not to replace the teams doing the work. It was to stop making a manager manually connect every step between them.
THE PROBLEM
The trackers recorded the work. They didn’t operate the workflow.
Requests moved between separate internal and vendor-facing trackers. The trackers showed what existed, but keeping the workflow synchronized still depended on manual coordination.
I was copying requests, reconciling statuses, checking whether work was actually ready, routing tasks, resolving blockers, managing escalations, and making sure rework didn’t erase the history we needed later.
The spreadsheet was functioning as a record of the process. I was functioning as the process.
INTERNAL REQUESTS
VENDOR
TEAM
UPDATED
STATUS
MANUAL COORDINATION
MANUAL
RECONCILIATION
THE COORDINATION LAYER LIVED IN A PERSON
01 / STATUS DRIFT
Two trackers could tell different stories
Internal and vendor-facing boards had to be reconciled manually, so statuses could lag behind the actual state of the work.
02 / BAD INPUTS TRAVELED DOWNSTREAM
Problems were discovered after work had already started
Missing fields, bad links, duplicate requests, incorrect task types, or permission issues created avoidable rework later in the process.
03 / EXCEPTIONS REQUIRED MEMORY
Blockers and escalations depended on manual handling
Paused work, SLA impacts, ownership changes, and revalidation had to be managed consistently across edge cases.
04 / REWORK COULD ERASE HISTORY
Fixing the work could destroy the evidence
Without preserving the original submission and QA result, rework made it harder to audit performance or understand what had actually gone wrong.
The problem wasn’t that we needed a better tracker. We needed an operating system.
So I started with the smallest useful fix—and kept building as each new bottleneck revealed itself.
V1 / CONNECT
Start by making the two sides see the same thing.
The first problem was simple: the internal tracker and the vendor-facing tracker could drift apart because updates had to be reconciled manually.
I linked the two boards so status changes could synchronize automatically instead of waiting for the next manual reconciliation.
BEFORE
INTERNAL TRACKER
MANUAL RECONCILIATION
VENDOR TRACKER
V1 / CONNECT
INTERNAL TRACKER
SYNC LAYER
VENDOR TRACKER
The first version didn’t automate the workflow. It removed the need to keep two versions of reality aligned by hand.
Once synchronization was no longer the bottleneck, the next problem became obvious: bad requests were still entering the workflow.
V2 / VALIDATE
Stop bad requests before they become downstream work.
Once the trackers were synchronized, the next bottleneck was input quality. Requests could still enter the workflow with missing information, bad URLs, duplicate entries, incorrect task types, inaccessible files, or other issues that made the work unusable downstream.
I added a validation layer that checked whether a request was actually ready before it could move forward.
REQUEST SUBMITTED
REVALIDATE
BLOCKED + RETURN
FOR FIX
VALIDATION CHECKS
FAIL
PASS
READY FOR ROUTING
· Required fields
· Valid task type
· SKU present
· Dates/times complete
· URL present
· Duplicate URL
· Correct permissions
WHAT THE SYSTEM CHECKED
Validation moved error detection to the front of the workflow.
Instead of discovering preventable problems after work had already started, the system could block them early and recheck them once corrected.
V3 / ROUTE
Once a request was valid, the system could decide where it belonged.
Validation made sure a request was ready. Routing determined what should happen next.
I added rules that used request attributes to send work to the appropriate queue or owner automatically, reducing another layer of manual triage and handoff.
QUEUE A
VALID REQUEST
ROUTING RULES
TASK TYPE · WORK TYPE · OWNERSHIP · PRIORITY
QUEUE B
QUEUE C
WHAT CHANGED
Before: someone had to inspect the request and decide where to send it.
After: the system could apply the same routing logic consistently every time.
Routing turned a valid request into a next action.
The workflow no longer depended on someone noticing a request, interpreting it, and manually moving it to the right place.
V4 / HANDLE EXCEPTIONS
Exceptions happened on both sides of the handoff. The system needed to know the difference.
By this point, the happy path was increasingly automated—but not every request followed it.
Some requests failed validation before they ever reached a vendor. Others became ambiguous only after the vendor had started the work and needed an internal decision. Those were fundamentally different exceptions, so I designed different paths for each.
REQUEST
VALIDATE
ROUTE
VENDOR WORK
COMPLETE
FAIL
REQUIRES CLARIFICATION
TWO DIFFERENT EXCEPTIONS
Blocked
Generated by validation before vendor routing.
Escalated
Raised by the vendor after work had already begun.
FIX INPUT
BLOCKED
INTERNAL
RESOLUTION
ESCALATED
Both needed explicit rules for when the request stopped being actionable and how it re-entered the workflow.
A robust workflow doesn’t just handle exceptions. It knows what kind of exception happened—and where.
Validation failures returned upstream for correction. Vendor escalations moved sideways for a decision. Each had its own path back into the workflow.
V5 / PRESERVE + SCALE
Scale the workflow without erasing what happened before.
As the workflow matured, two new problems became more important: preserving history through rework and keeping the system responsive as the trackers grew.
I added an archive layer that captured the original work and QA result before rework was routed back through the process. That preserved the evidence needed for audit, performance analysis, and coaching instead of allowing the corrected version to overwrite what had actually happened.
I also optimized the trackers for scale as thousands of rows and formula dependencies began to slow them down.
WITHOUT PRESERVATION
ORIGINAL WORK
QA RESULT
REWORK
CORRECTED VERSION
WITH PRESERVATION
ORIGINAL WORK + QA
ARCHIVE
AUDIT / PERFORMANCE HISTORY
REWORK
CORRECTED VERSION + HISTORICAL RECORDS
DATA INTEGRITY
Validation rules, protected ranges, locked rows, and status controls reduced accidental corruption.
PERFORMANCE
Heavy formula logic was converted to static values where appropriate to reduce lag as the trackers grew.
HISTORY
Original work, QA outcomes, and rework states remained traceable over time.
A workflow can only scale if its history, controls, and performance scale with it.
By V5, the tracker was no longer just coordinating work. It was preserving state, enforcing rules, handling exceptions, and supporting the operation as a system.
RESULTS
The workflow stopped depending on someone to keep it moving.
What began as two trackers connected by formulas evolved into a workflow system that could synchronize status, validate requests, route work, manage exceptions, preserve rework history, and keep the operation current without constant manual reconciliation.
The biggest change was not any one automation. It was moving the coordination logic out of a person and into the system.
01 / LESS MANUAL COORDINATION
Hours of daily tracker maintenance disappeared
Work that had required roughly 3–4 hours per day of copying, reconciling, routing, validating, and exception handling was largely automated.
02 / FRESHER OPERATIONAL STATE
The trackers could stay current throughout the day
Instead of waiting for roughly three manual reconciliations, automated refreshes could run every ~15 minutes—about 96 update cycles per day.
03 / STRONGER DATA INTEGRITY
Bad states became harder to create
Validation, permissions, protected ranges, status controls, and routing rules shifted quality control from cleanup after the fact toward prevention inside the workflow.
04 / AUDITABLE REWORK
Correcting work no longer erased the original result
The archive preserved pre-rework submissions and QA outcomes, making performance history available for audit, coaching, and process improvement.
~3–4 hrs/day → largely automated
Manual coordination previously required to keep the workflow moving
I stopped being the connective tissue. The system became the connective tissue.
By the final version, coordination, control, and history were increasingly properties of the workflow itself—not tasks someone had to remember to perform.
LESSONS
What this changed about how I think about operational systems.
01 / Coordination is often the best automation target
The handoffs can matter more than the task itself.
The work was not especially hard because any one step was complicated. It was hard because so much effort went into moving information between people, trackers, statuses, and exceptions. Automating that coordination layer created disproportionate leverage.
02 / Prevent bad states instead of cleaning them up later
The best fix is often upstream.
Validation changed the system from detecting problems after work had started to preventing unusable requests from entering the workflow in the first place.
03 / Exception handling is part of the system
The happy path is only part of the design.
Blocked requests and vendor escalations happened at different stages and needed different paths back into the workflow. Treating those states explicitly made the system more reliable than relying on manual memory and follow-up.
04 / Real usage reveals what to build next
I didn’t design V5 on day one.
Each version solved the most visible constraint, then exposed the next one—synchronization, input quality, routing, exceptions, history, and scale. The system got better because people used it.
Good workflow design removes the need for someone to remember how the system works.
WORKFLOW AUTOMATION · EXCEPTION DESIGN · DATA INTEGRITY · ITERATIVE SYSTEMS
NEXT PROJECT
AI Job Search OS
Building AI around judgment, not instead of it.