06 / REVENUE ENABLEMENT + OPERATIONAL ANALYTICS
Turning operational performance into proof of business viability.
DoorDash was expanding its work with consumer packaged goods brands that wanted to run promotions across products sold by multiple merchants on the platform.
That commercial opportunity depended on a supporting catalog operation that could reliably identify and audit the right products. I helped formalize the workflow, define a trustworthy vendor SLA, and build the reporting leadership needed to understand whether the operation could support a growing revenue program.
MY ROLE / SLA design · Jira workflow design · SQL / reporting · executive visibility · vendor management · cross-functional process design · revenue enablement
54% → 100%
Priority requests completed within SLA
~4 weeks
Time to reach 100%
48 hours
Priority-request service-level target
Shared visibility
One performance view across teams
The dashboard did more than measure speed. It gave the business evidence that the supporting operation could perform reliably enough to scale.
THE BUSINESS QUESTION
Before the business could scale the opportunity, it needed to know whether the operation could support it.
CPG promotions depended on DoorDash knowing which merchant items corresponded to the correct standardized products in the catalog. Before a campaign could launch broadly, teams needed to audit the existing catalog, identify products that were not linked correctly, and ensure the right items were associated with the appropriate standardized product IDs.
That work was handled by BPO vendor teams. Because the workflow directly supported advertising and promotional programs for major brands, delays or inconsistent execution created risk not just for operations, but for the commercial program itself.
CATALOG OPERATION
audit + vendor execution
RELIABLE TURNAROUND
consistent SLA performance
OPERATIONAL SYSTEM
OPERATIONAL PROOF
performance becomes evidence
VIABILITY TEST
can the model support growth?
BUSINESS DECISION
CONFIDENCE TO SCALE
commercial opportunity
OPERATING PERFORMANCE → EVIDENCE → CONFIDENCE TO SCALE
The real question wasn’t just “Can the vendor hit an SLA?” It was “Can this operating model reliably support the business we want to build?”
The SLA became a way to turn operational performance into evidence.
STRUCTURE THE INTAKE
The first step was replacing ad-hoc requests with a workflow the operation could actually measure.
Initially, CPG requests reached the vendor team through channels such as Slack and email. That provided some evidence that a request had been sent, but it was not a scalable system for managing priority, status, ownership, or turnaround.
I helped move the workflow into Jira so requests entered through a consistent intake path and generated structured status data that could support reliable measurement.
BEFORE / AD HOC INTAKE
SLACK
REQUEST EXISTS, BUT THE STATE IS UNCLEAR
priority · ownership · status · timing
MANUAL FOLLOW-UP
MULTIPLE CHANNELS · INCONSISTENT EVIDENCE
STANDARDIZE THE INTAKE
JIRA REQUEST
one consistent intake path
STRUCTURED STATUS DATA
priority · owner · status · timestamps
MEASURABLE WORKFLOW
ready for SLA reporting
AFTER / STRUCTURED WORKFLOW
ONE PATH · CONSISTENT STATE · REPORTABLE DATA
You can’t measure a workflow consistently if the work itself leaves inconsistent evidence behind.
Structured intake created the foundation for meaningful SLA measurement.
DEFINE THE SLA
A 48-hour SLA sounds simple until you try to measure it fairly.
The calculation had to reflect the actual operating reality rather than simple elapsed clock time.
I worked cross-functionally to define how vendor operating hours, weekends and non-working periods, U.S./India/Bangladesh time-zone differences, blocked states outside the vendor’s control, and the correct start and stop events should affect the SLA.
01 / WORKING HOURS
When was the vendor actually accountable?
02 / NON-WORKING PERIODS
What happened on weekends or outside operating hours?
03 / TIME ZONES
How should geographically distributed teams be treated consistently?
04 / BLOCKED STATES
When should the clock pause for something outside vendor control?
05 / START EVENT
Which status transition actually began accountable time?
06 / STOP EVENT
What counted as completion?
RAW CLOCK TIME
REQUEST RECEIVED
SIMPLE TIMESTAMP DIFFERENCE
>48 HOURS ELAPSED
COMPLETED
ACCOUNTABLE SLA TIME
SLA START
WORKING
NORMALIZED TO VENDOR OPERATING HOURS ACROSS TIME ZONES
COUNTED TIME + COUNTED TIME + COUNTED TIME = 48 ACCOUNTABLE HOURS
BLOCKED + NON-WORKING TIME = 0 SLA HOURS
48 ACCOUNTABLE HOURS ≠ 48 RAW CLOCK HOURS
BLOCKED
[PAUSED]
WORKING
NON-WORKING
[WEEKEND]
WORKING
SLA STOP
Define the business rule first. Then build the metric.
Until the operating rules were explicit, the number could create false conclusions about performance.
BUILD THE MEASUREMENT LAYER
Once the SLA meant something, I could build reporting people could trust.
I built the query and executive dashboard used to track priority CPG requests.
The reporting layer gave teams a shared view of total volume, work in progress, requests within SLA, requests past SLA, and completed work inside or outside the target window. More importantly, it created one agreed-upon interpretation of whether the vendor operation was meeting the service level the business expected.
WHAT THE DASHBOARD MADE VISIBLE
01 / VOLUME
How much work was entering the system?
Total priority-request volume
02 / ACTIVE WORK
What was still in progress?
Open requests + current status
03 / SLA HEALTH
What was still on track?
Requests currently within SLA
04 / RISK
What had crossed the limit?
Requests already past SLA
05 / OUTCOME
How reliably were we delivering?
Completed inside vs. outside SLA
SLA CALCULATION
apply business rules
QUERY
assemble structured events
EXECUTIVE DASHBOARD
shared performance view
OPERATIONS
VENDOR LEADERSHIP
BUSINESS LEADERSHIP
JIRA STATUS DATA
request · owner · status · timestamps
SLA BUSINESS RULES
working hours · blockers · start / stop logic
INPUTS
MEASUREMENT LAYER
USERS
ONE OPERATING DEFINITION → ONE SHARED VIEW
the same underlying logic informed every audience
The dashboard mattered because everyone was finally looking at the same definition of performance.
That shared definition made comparisons meaningful, surfaced disagreements about the process itself, and gave operations, vendors, and leadership a common basis for deciding what needed attention.
TURN MEASUREMENT INTO MANAGEMENT
Once performance was visible, the dashboard became a management tool instead of a reporting artifact.
Reliable measurement established a baseline: only about 54% of priority requests were initially being returned within the two-day SLA.
From there, the dashboard made it possible to see which requests were approaching the limit, where work was falling behind, whether delays came from vendor execution or legitimate blockers, whether process changes were working, and whether the vendor operation could reliably support the service level expected by the business.
01 / RISK
Which requests were approaching the SLA limit?
02 / CAUSE
Was the delay execution-related or legitimately blocked?
03 / TREND
Were process changes actually improving performance?
04 / CAPABILITY
Could the operation reliably support the expected service level?
WHAT'S WRONG?
01 / SEE THE SIGNAL
SLA RISK + PERFORMANCE GAPS
VENDOR DELAY · BLOCKER · PROCESS ISSUE
02 / DIAGNOSE THE CAUSE
WHAT NEEDS ATTENTION NOW?
MANAGEMENT LOOP
shared visibility → coordinated action
WHAT SHOULD CHANGE?
DID PERFORMANCE IMPROVE?
04 / MEASURE AGAIN
FOLLOW-UP · ESCALATION · WORKFLOW CHANGE
03 / INTERVENE
DID IT WORK?
VISIBILITY → DIAGNOSIS → ACTION → LEARNING
reporting became an operating control loop
Measurement created value when it changed what the team could see—and therefore what it could act on.
Instead of reacting to isolated misses, the team could prioritize the requests and failure patterns that posed the greatest risk to the service level.
RESULTS
Within four weeks, priority-request SLA attainment reached 100%.
Priority CPG requests completed within the 48-hour vendor SLA improved from roughly 54% to 100% within approximately four weeks.
The dashboard itself did not cause that improvement. Its role was to provide accurate measurement, shared visibility, and accountability so the cross-functional team could identify performance gaps and manage against a clearly defined target.
01 / SLA PERFORMANCE
54% → 100%
Priority-request attainment
02 / SPEED OF IMPROVEMENT
~4 weeks
Time to reach full attainment
03 / ACCOUNTABILITY
Delays became attributable
Vendor execution vs. legitimate blocker
04 / BUSINESS CONFIDENCE
Leadership gained a reliable operating signal
Evidence that the workflow could support growth
Leadership no longer had to rely on anecdotal updates or inconsistent Slack and email timestamps. They could see whether priority CPG work was actually being completed within the promised turnaround window. That helped give the organization greater confidence in scaling the process and expanding its work with CPG brands.
DESIGN BOUNDARY
The dashboard didn’t create the improvement by itself. It made coordinated improvement possible.
Reliable measurement created the shared visibility and accountability needed for teams to identify performance gaps, respond operationally, and determine whether those changes were working.
The most important output wasn’t the dashboard. It was confidence that the operation could support a growing commercial program.
Reliable performance data gave leadership something more useful than anecdotal reassurance: evidence that the operating model could deliver consistently as the business expanded.
LESSONS
What this changed about how I think about operational metrics.
01 / DEFINE REALITY BEFORE THE KPI
A metric is only trustworthy if the operating rules underneath it are explicit.
Working hours, blocked time, ownership, status transitions, and time zones all changed what “48 hours” actually meant.
02 / VISIBILITY CHANGES BEHAVIOR
Shared measurement makes accountability actionable.
Once teams could see the same metric, they could distinguish isolated delays from broader patterns and manage performance more deliberately.
03 / MEASURE TO SUPPORT A DECISION
Reporting matters when someone can act differently because it exists.
The dashboard helped operations manage the workflow while giving leadership evidence about whether the supporting system was reliable enough to scale.
04 / OPERATIONS CAN BE BUSINESS EVIDENCE
Operational reliability can become proof of commercial viability.
In a new business workflow, trustworthy performance data can reduce uncertainty about whether the operating model is ready to support growth.
Measurement creates the most value when it gives teams enough confidence to act—and leadership enough confidence to scale.
OPERATIONAL ANALYTICS · SLA DESIGN · REVENUE ENABLEMENT · EXECUTIVE VISIBILITY
EXPLORE MORE WORK
Selected Work
More systems for turning ambiguity into operable insights.