OPERATIONS / SYSTEM DESIGN
Designing an Operating System for Scale
How I redesigned core operating workflows as a livestream commerce business grew from roughly $150K to $1M+ in monthly GMV.
Monthly GMV during the scaling period
Approximate increase in order volume
Problematic orders per month
THE SCALING PROBLEM
The processes were not broken.
The scale changed.
At lower volume, informal coordination was fast and effective. Experienced employees made good decisions through intuition, teams communicated directly, and exceptions could be handled case by case.
As transaction volume and team size expanded, those same processes became harder to reproduce. More people meant more handoffs, more exceptions, and more opportunities for information or judgment to remain trapped inside individuals.
THE DIAGNOSIS
Too much of the operating system still lived inside people.
The recurring failures looked different across departments, but they shared the same underlying problem: execution still depended on what individual employees could remember, judge, or catch manually.
Knowledge
Strong livestream execution depended on experience that was difficult to transfer.
Decisions
Customer-service boundaries were unclear and depended heavily on individual judgment.
Errors
Fulfillment quality depended on people manually catching mistakes before shipment.
THE RESPONSE
Three systems. Three different scaling constraints.
Instead of adding supervision to every problem, I focused on redesigning where knowledge, decisions, and controls lived inside the workflow.
Tacit knowledge → Repeatable execution
Livestream Operations
Strong hosts and directors relied heavily on experience. They could adjust pacing, product selection, and selling approach intuitively, but new team members struggled to understand the logic behind those decisions.
Ambiguous judgment → Structured decision rights
Customer Service
Customer issues varied widely in risk. Without clear decision boundaries, inexperienced staff could escalate routine cases unnecessarily—or mishandle sensitive disputes involving condition, authenticity, returns, and potential chargebacks.
Informal coordination → Embedded controls
Fulfillment
Verbal communication worked well at low volume. As orders and team size expanded, special requests were easier to lose and interruptions created opportunities for SKU, accessory, and packing errors.
01 / LIVESTREAM OPERATIONS
Turning experience into a system.
The goal was not to script strong hosts and directors. It was to identify which parts of their performance could be made repeatable without removing the judgment that made them effective.
BEFORE
Learn by watching.
AFTER
Learn through structure.
Host Playbook
Established a consistent presentation flow for every product, then added situational modules for scarcity, energy, value, and other selling contexts.
Individual Feedback
Created host profiles and post-stream reviews so specific improvement areas could be documented, revisited, and tracked over time.
Director Checklist
Converted previously implicit responsibilities into a visible self-check system that directors could reference throughout a stream.
Inventory Logic
Classified products as traffic drivers, proven sellers, or scarce products—and physically separated those sets so product strategy became part of the workspace itself.
02 / CUSTOMER SERVICE
Turning judgment into decision architecture.
The objective was to let routine cases move quickly while preventing inexperienced staff from independently making decisions with significant financial or reputational risk.
Frontline
Pre-sale and standard after-sale cases.
Price · Condition · Shipping · Accessories · Basic order issuesExperienced Staff
Risk cases within documented decision boundaries.
Condition disputes · Return requests · Existing risk scenariosManagement
Novel, ambiguous, or high-risk exceptions.
New scenarios · Policy decisions · Unclear resolution boundariesTHE LEARNING LOOP
A new exception may require management judgment once.
It should not require the same judgment forever.
03 / FULFILLMENT
Replacing memory with controls.
As order volume increased roughly tenfold, verbal communication and manual checking stopped being sufficient. Critical information needed to travel with the order itself.
INFORMATION TRACEABILITY
Make exceptions visible.
Special requests moved from verbal communication to written records, with simple product-tag notation ensuring that important information remained attached to the item through fulfillment.
PREVENTIVE CONTROL
Make errors harder.
A quick reference system surfaced accessory images before shipment, while SKU photos and markings on both boxes and shipping labels created multiple independent verification points.
MEASURED RESULT
Problematic fulfillment orders per month.
The reduction occurred while the business was operating at substantially higher order volume. The goal was not to eliminate human judgment, but to stop asking people to remember or manually catch things the operating system could make visible instead.
OPERATING PRINCIPLES
What I carried forward.
The individual systems were different, but the design principles behind them were consistent.
Make tacit knowledge explicit
If strong execution depends on what experienced employees know intuitively, the organization cannot reproduce it reliably.
Standardize without removing judgment
Define the repeatable core while preserving flexibility where context and experience still create value.
Push decisions to the right level
Routine decisions should not require management involvement. Risk and novelty should determine when escalation is necessary.
Build controls before failure
Critical processes should rely on checkpoints and visible information rather than reminders to simply be more careful.
REFLECTION
Scaling operations did not mean adding more supervision.
It meant identifying what the organization still expected individuals to remember, judge, or catch manually—and redesigning the system so the organization could carry more of that complexity itself.