04 / OPERATIONAL ANALYTICS
Turning QA data into a map of where to look next.
DoorDash’s catalog operations spanned dozens of workflows, multiple BPO vendors, and roughly 100–250 QA files each week. Each process produced quality data differently, making it difficult to see aggregate performance or quickly understand what was driving a miss.
I standardized the reporting layer and built Google Apps Script automation that converted those fragmented QA outputs into consistent, weighted performance data, surfaced the leading error drivers, preserved historical performance, and gave the operation a centralized view of where attention was needed.
MY ROLE / Reporting architecture · Apps Script automation · metric design · root-cause analysis · vendor performance · continuous improvement
100 – 250 / week
QA files processed across the operation
8 – 21 hrs → ~0
Weekly QA reporting administration
~20 → ~5 hrs
Diagnostic review during heavy investigation weeks
~10 pts
Aggregate QA improvement supported by targeted interventions
The dashboard did not fix quality by itself. It reduced the distance between seeing a problem and knowing where to investigate.
THE PROBLEM
The operation had quality data everywhere—but no reliable way to see it as one system.
QA was happening across dozens of operational workflows, but the reporting infrastructure had grown organically alongside them.
Each process used its own spreadsheet template, columns, layouts, QA structure, formulas, file links, and naming conventions. Weekly performance still had to be assembled across roughly 20–36 active processes, 2–4 BPO vendors, and about 100–250 files.
The result was a reporting layer that was slow to maintain, vulnerable to broken references and inconsistent templates, and difficult to use for historical analysis. And even when the numbers were correct, a headline accuracy percentage only told me that something was wrong—not why.
PROCESS A
PROCESS B
PROCESS C
PROCESS D
TEMPLATE A
QA STRUCTURE B
FILE D
FORMULA C
MANUAL WEEKLY REPORTING
DIFFERENT STRUCTURES · FRAGILE REFERENCES · MANUAL AGGREGATION
WHAT I ACTUALLY LEARNED
A common reporting layer above different workflows.
The underlying work did not need to become identical. The quality data needed to become predictable enough that one system could interpret it.
01 / FRAGMENTED STRUCTURE
Every process reported quality differently
Different templates, formulas, layouts, naming conventions, and QA structures made aggregation brittle.
03 / WEAK HISTORY
The past was harder to trust
Live formulas, changing templates, and rework made it difficult to preserve a stable view of what performance had actually looked like at the time.
02 / MANUAL COMPILATION
Weekly reporting scaled with file volume
Aggregate performance had to be assembled across as many as 100–250 QA files each week.
04 / NOT DIAGNOSTIC
Accuracy showed the miss—not what to fix
A process could fall below its threshold without revealing which errors were contributing most heavily to the result.
The problem wasn’t that the workflows were different.
It was that their quality data had no common language.
I didn’t need to standardize the work itself. I needed to standardize the interface the reporting system could read.
STANDARDIZE THE INTERFACE
Different workflows could stay different. Their reporting interface could not.
A single universal operational template was not practical. Different workflows genuinely needed different data, tools, and QA methodologies.
Instead, I worked with the internal QA team to define a common reporting structure that could sit inside each process template. I established the specifications, and QA helped migrate the individual workflows to conform to that shared interface.
PROCESS A
different fields
QA REPORTING INTERFACE
QA PASSES · RECORDS REVIEWED · QA % · ERROR CATEGORIES · QA COMPLETE · COMPLETION DATE
attribute-level results
DIFFERENT WORKFLOWS · ONE REPORTING CONTRACT
PROCESS B
different tooling
CENTRAL REPORTING SYSTEM
PROCESS C
different QA logic
PROCESS D
different structure
THE DESIGN CHOICE
Standardize the interface, not the underlying work.
Once every process exposed quality through the same reporting schema, one system could interpret all of them without requiring the operational workflows themselves to become identical.
The workflows didn’t need to speak the same language internally. They only needed to speak the same language to the reporting system.
Once that interface existed, I could automate everything that happened above it.
AUTOMATE THE REPORTING LAYER
Once QA finished, the reporting system could take over.
I built a Google Apps Script workflow around the standardized reporting layer.
When QA finished reviewing a file, the reviewer marked a standardized QA COMPLETE field as true. That event triggered the rest of the reporting pipeline automatically.
QA COMPLETE = TRUE
CALCULATE RESULTS
WRITE STATIC VALUES
CAPTURE QA DATE
SEND TO DASHBOARD
AGGREGATE PERFORMANCE
SURFACE TOP ERROR DRIVERS
ONE QA ACTION → AUTOMATED REPORTING PIPELINE
BEFORE / MANUAL REPORTING
Open files, calculate results, copy data, update weekly reporting
Reporting effort increased with every additional QA file.
AFTER / EVENT-DRIVEN REPORTING
QA completes the review; the system handles the reporting layer
One standardized completion signal triggered the same reporting logic every time.
~8–21 hrs/week → essentially zero
Manual QA reporting administration was largely eliminated across roughly 100–250 files per week.
The automation didn’t replace QA. It removed the reporting work wrapped around QA.
Reviewers could focus on evaluating quality instead of administering the reporting layer.
MEASURE WHAT ACTUALLY HAPPENED
Faster reporting was only useful if the numbers meant the right thing.
Building the reporting system exposed weaknesses in how performance had historically been calculated and preserved.
I changed the measurement logic so aggregate scores reflected the underlying volume of work, reporting periods stayed stable once QA was complete, and rework no longer erased the original performance record.
FIX 01 / WEIGHT BY UNDERLYING VOLUME
BEFORE / FILE-LEVEL AVERAGING
AVERAGE (90%, 85%, 98%, 99%)
A small file and a large file counted equally.
File-level percentages could distort actual performance when underlying file sizes differed substantially.
AFTER / TRUE AGGREGATE
SUM (QA PASSES) / SUM (RECORDS QA'D)
Performance reflected the actual volume represented in QA.
The same principle was applied at the vendor level so high-volume work appropriately influenced aggregate performance.
FIX 02 / REPORT BY QA COMPLETION DATE
A score should stop moving once the period is closed.
Results were originally grouped by when the vendor completed the work. If internal QA finished later, an earlier week could unexpectedly change while the next reporting period was already underway.
I changed the logic to group results by QA completion date, creating more stable historical periods and more meaningful week-over-week comparisons.
OLD / GROUP BY VENDOR COMPLETION DATE
VENDOR COMPLETE
WEEK 1
WEEK 1 SCORE CHANGES AFTER THE FACT
↓ OLD LOGIC
QA COMPLETE
WEEK 2
NEW / GROUP BY QA COMPLETION DATE
VENDOR COMPLETE
WEEK 1
FINALIZED WEEK 2 SCORE
REPORT WHEN QA ACTUALLY FINALIZES THE RESULT
↓ NEW LOGIC
QA COMPLETE
WEEK 2
FIX 03 / PRESERVE PRE-REWORK PERFORMANCE
Fixing the work should not erase the evidence that it failed.
Previously, corrected work could overwrite the original QA result. That made it harder to understand baseline vendor performance or measure the effect of remediation.
I built automation that archived the original completed work and QA result before the file was returned for rework.
ORIGINAL PERFORMANCE
PRESERVE ALL THREE STATES
VENDOR REWORK
REVISED PERFORMANCE
01 / WEIGHT WHAT MATTERS
Aggregate from the underlying records, not the percentages.
02 / CLOSE PERIODS CLEANLY
Report performance when QA is complete, not when work first arrived.
03 / PRESERVE HISTORY
Never let correction overwrite the original signal.
A reporting system is only as useful as the measurement logic underneath it.
Better automation did not just produce numbers faster. It made the numbers more stable, comparable, and trustworthy.
DIAGNOSE WHERE TO LOOK
The dashboard didn’t need to explain every problem. It needed to tell me where to investigate first.
Once the reporting layer was stable, I could use it as a navigation system across dozens of active workflows.
Instead of manually investigating every miss, I could quickly see which processes were below threshold, where performance was declining, which vendors or attributes were contributing disproportionately, and which error categories were driving the score.
01 / PERFORMANCE SIGNALS
· Below threshold
· Declining trend
· High rework
· Vendor difference
02 / TOP ERROR DRIVERS
· Error category
· Attribute
· Failure concentration
03 / TARGETED INVESTIGATION
· Inspect underlying QA
· Find recurring problem
· Identify likely root causes
04 / INTERVENTION
· SOP clarification
· Retraining
· QA alignment
· Template change
· Tooling escalation
DETECT → PRIORITIZE → INVESTIGATE → INTERVENE
DIAGNOSTIC REVIEW
~20 hrs → ~5 hrs
During heavy investigation weeks, the dashboard reduced hands-on diagnostic review by roughly 75% because I could focus immediately on the error categories contributing most heavily to the score.
BEFORE / INVESTIGATE EVERYTHING
Every below-threshold file competed for the same attention.
Root-cause analysis could require reviewing every error in every failed file, often taking 30–60 minutes per file.
AFTER / FOLLOW THE SIGNAL
Start with the few error drivers creating the most impact.
The dashboard narrowed the search space before the deeper investigation began.
WHAT HAPPENED AFTER THE SIGNAL
QA · STRATEGY & OPS · VENDOR LEADERSHIP · PRODUCT / ENGINEERING
The data gave me the starting point. The actual fix still required understanding the root cause and coordinating the right operational, training, process, or tooling response.
Good reporting reduced the distance between seeing a problem and knowing where to look.
I didn’t need to understand every issue at the same depth. I needed a reliable signal for where deeper investigation would have the highest return.
RESULTS
The system made quality easier to see, easier to diagnose, and easier to improve.
The reporting system improved both the efficiency and the quality of the vendor-management operation.
It reduced repetitive reporting work, shortened root-cause analysis, created a more stable historical record, and gave stakeholders a centralized source of truth across roughly 20–36 processes and 2–4 vendors.
01 / REPORTING EFFICIENCY
Hours of weekly reporting administration disappeared
Manual QA reporting work dropped from roughly 8–21 hours per week to essentially zero.
02 / FASTER DIAGNOSIS
Heavy investigation weeks became much more manageable
Diagnostic review fell from as much as ~20 hours to ~5 hours because the dashboard surfaced the highest-impact error drivers first.
03 / TRUSTWORTHY HISTORY
Performance became easier to compare over time
Reporting periods became more stable, and pre- versus post-rework performance could be compared directly instead of overwritten.
04 / QUALITY IMPROVEMENT
Better visibility supported targeted quality gains
Aggregate vendor QA improved about 6 percentage points from January through April, roughly 10 points across about five months, and ultimately reached approximately 97% aggregate accuracy.
REPORTING ADMIN
~8–21 hrs/week → ~0
DIAGNOSTIC REVIEW
~20 hrs → ~5 hrs
AGGREGATE
~+10 pts over ~5 months
Ultimately ~97% aggregate accuracy
WHAT THE SYSTEM ACTUALLY CHANGED
The dashboard did not improve quality by itself. It made better interventions possible.
The system provided reliable measurement and root-cause visibility. I used those signals to identify the highest-impact problems, coordinate with cross-functional partners, and improve performance through targeted process changes, SOP clarification, calibration, and vendor retraining.
The system didn’t solve every quality problem. It made the highest-value problems easier to find and fix.
Better measurement created leverage by helping limited time and attention go where they could have the greatest impact.
LESSONS
What this changed about how I think about measurement systems.
01 / STANDARDIZE THE INTERFACE
Different work can still expose a common signal.
I didn’t need dozens of workflows to become identical. I needed each one to expose quality through a predictable enough structure that one reporting system could interpret them all.
02 / USE MEASUREMENT TO NAVIGATE
Good metrics should tell you where attention will have the highest return.
When you’re responsible for dozens of simultaneous processes, understanding every issue at the same depth isn’t scalable. A strong measurement system can narrow the search space before deeper investigation begins.
03 / LET INTERVENTIONS COMPOUND
You don’t need one dramatic fix if you can repeatedly find the right small ones.
Reliable signals made it possible to work through problems systematically—identifying the highest-impact issue, making a targeted intervention, and repeating that cycle as performance changed.
04 / AUTOMATE TOWARD BETTER JUDGMENT
The most valuable automation didn’t replace the analysis. It made the analysis more targeted.
Instead of spending hours searching manually for patterns, I could spend that time understanding the highest-impact problems, working with the right stakeholders, and deciding what intervention would actually improve the process.
Good reporting shouldn’t just describe performance.
It should reduce the distance between seeing a problem and knowing where to look next.
OPERATIONAL ANALYTICS · MEASUREMENT DESIGN · PRIORITIZATION · AUTOMATION
NEXT PROJECT
Duplicate Item Burn-Down
Automating the easy decisions. Saving human judgment for the risky ones.