Case study 05 · Retail operations · Custom-manufacturing retailer

One order pipeline — from the showroom floor to the factory floor.

A made-to-order product was being sold through three disconnected systems: an in-store POS, an online store, and phone orders. Each spawned its own paperwork, and the factory rebuilt every spec by hand. I designed a single order pipeline so a custom order is captured once, routed to production automatically, and visible to the customer and the store — no matter where it started.

My role
Senior Product Designer · systems & service design
Scope
Service mapping, POS redesign, order-routing model, factory dashboard, status sync
Tools
Figma, FigJam, Maze, Zeroheight
Timeline
2023 — 2024
Modern operations dashboard for a custom-blinds retailer: KPI cards for orders captured today, in factory queue, percent auto-routed with no re-key, and average lead time, an orders-by-channel chart for in-store, online, and phone, a channel-mix breakdown, on-time production, and a recent-orders table

Overview

The problem

The retailer sold a custom-manufactured product — every blind cut to a specific window. But the order could start in three places that didn't talk to each other: a showroom POS, the e-commerce site, and a phone line. Each channel produced its own order format.

At the factory, that meant a person re-keying specifications from emails, printouts, and screenshots into the production system. Re-keying is where custom orders go to die: a transposed width, a missed mount type, and an entire made-to-order unit is scrapped.

The brief I wrote back: this isn't a POS skin. It's a service-design problem — connect three order sources to one factory queue, with status flowing back to the customer and the store.

Service mapping · mine Order-routing model · mine POS & factory UI · mine Manufacturing ops Eng & integrations

Discovery

I followed one order from sale to shipment — and found four handoffs.

Before designing a screen, I shadowed the order itself: sat with showroom staff, placed test orders online, and walked the factory floor to see exactly where a custom spec changed hands and where it broke.

3
Order channels feeding one factory with no shared format
4
Manual handoffs where a spec was re-keyed or printed
11
Staff & factory interviews across store and production
1
Source of truth every order had to collapse into

What the research said

The break was between systems, not inside them

Each individual tool worked. The failures lived in the gaps — the moments an order left one system and a human had to carry it to the next. Three gaps caused nearly all the rework.

Re-key

Spec retyped at the factory

Online and phone orders arrived as text the factory retyped into production — the single largest source of wrong-cut scrap.

Source · factory shadowing + scrap logs
Blind spot

No status to give the customer

Once an order left the till, neither the shopper nor the associate could answer “where is it?” without phoning the plant.

Source · 11 staff & factory interviews
Drift

Three formats, one product

The same custom blind was described three different ways depending on where it sold, so nothing could be automated end to end.

Source · order-format audit

That evidence reframed the work from “a nicer POS” to “one canonical order object that every channel writes and the factory reads” — the change that removes re-keying entirely.

Before & after

The same custom order — re-keyed by hand, then captured once.

The showroom configured every blind in a legacy desktop screen, then someone re-typed those specs into production. I rebuilt that exact moment as a guided, validated order builder — same product, same fields, no re-key.

Before
Legacy desktop order screen for a custom wood blind: five gray Windows panels titled Info, Appearance, Dimension, Operation, and Other, each a dense list of fields such as style, color, mount location, window and blind width and height, mechanism, and bracket type, with Cancel, Price, and Continue buttons
Legacy in-store screen. Dozens of dense fields, no validation, no price or lead time — and every spec was re-typed at the factory.
After
Redesigned order builder for the same custom blind: a guided three-step flow with grouped panels for appearance, dimensions, operation, and hardware, color swatches and a segmented lift control, plus a live blind preview, an order summary with cut size, an estimated price and lead time, an all-specs-validated note, and a Send to factory button
Redesigned order builder. The same specification, captured as structured, validated fields with a live preview, price, and lead time — sent straight to the factory queue.

The core problem

The product lived inside the dropdowns.

This is the actual screen on the showroom floor. Every detail that defined a blind — style, color, mount, mechanism, valance, bracket type — was buried in dozens of separate dropdowns spread across five panels, with nothing shown until the associate opened each one.

Photograph of the real legacy POS screen running on the showroom floor: five gray Windows panels titled Info, Appearance, Dimension, Operation, and Other, each packed with separate dropdown fields for style, color, mount location, ladder type, mechanism, tilting mechanism, valance, bracket type, and window and blind dimensions, with Cancel, Price, and Continue buttons
The real terminal, photographed in store. Product knowledge was hidden behind the controls — not visible on the screen.

Because the configuration was hidden across so many dropdowns, the screen was a direct time cost. Associates clicked through panel after panel to find the right option, hesitated on fields they rarely touched, and slowed down in front of the customer — and new hires needed weeks of training just to know where each setting lived and which combinations were valid. The redesign’s job was to pull that hidden product information out into the open, so the right choice is visible at a glance instead of memorized.

The system

Capture once. Route automatically. Track everywhere.

The spine of the redesign is a single canonical order — every channel writes to it, the factory reads from it, and status flows back without anyone re-typing a thing.

Live dispatch board where finished orders from the store, online, and phone channels land in one queue: a table with order ID, customer, product, route, carrier, and promised ETA, beside a delivery-route timeline with sequenced stops and real-time status
Three sources, one pipeline. Orders from the store, the website, and the phone line collapse into a single queue with a shared format, a route, and a live status for every row.

Flows

Three moves, end to end

Each flow closes one of the three gaps the research exposed — capture, production, and status — shown on the real screens that shipped.

Flow 01

Configure the order once, at the point of sale

The showroom POS becomes a guided custom-order builder: width, height, material, mount, and control are structured fields — not free text — so the order is valid before it's ever sent. A live price and lead time remove the “let me check” phone call, and one button sends it straight to the factory queue.

In-store POS custom-order builder with structured fields for width, height, material, mount, and control, a live price summary with lead time, and a Send to Factory button beside an order-status timeline
The same structured fields the factory needs are captured at the till — so nothing has to be re-keyed downstream.
Flow 02

The factory works a queue, not an inbox

Production gets a floor dashboard instead of a pile of printouts. Orders move through Cut → Assemble → Quality Check as cards, each carrying its own cut-list spec and a channel tag so the floor knows an in-store rush from an online standard. The numbers the business cares about — queue depth, lead time, on-time rate, rework — sit at the top.

Factory floor dashboard with KPI cards for orders in queue, average lead time, on-time rate, and rework, a kanban board of Cut, Assemble, and Quality Check columns, and an order-detail panel with a cut-list spec
A made-to-order spec arrives complete and machine-readable; the floor reads the cut list directly instead of rebuilding it.
Flow 03

One status, for the customer and the store

Because every order is the same object, status can flow back to two audiences from one source: the customer sees a plain-language tracker, and the associate sees the same order with a Sync to Factory action. “Where is my order?” stops being a phone call.

Two mobile screens side by side: a customer order tracker with a production status timeline and estimated delivery, and a store-associate console showing the same order with its made-to-order spec chips, factory status, and a Sync to Factory action
Same order object, two views — the shopper's tracker and the associate's console stay in lockstep automatically.
Flow 04

One live queue for every channel

Operations needed a single place to watch the seam they used to lose orders in. The live pipeline board shows every order from every channel as it lands — captured-today, in-queue, and auto-routed counts up top, then a real-time table with channel, product, customer, color-coded production status, and factory ETA. No inbox to triage, no spreadsheet to reconcile.

Live order pipeline dashboard with KPI cards for orders captured today, orders in factory queue, percent auto-routed with no re-key, and average lead time, an orders-by-channel chart and channel-mix breakdown for in-store, online, and phone, plus a real-time order table with order ID, channel, product, customer, status pills, and factory ETA
The operational view of “capture once, route automatically” — in-store, online, and phone orders land in one live queue with a shared spec and a status for every row.
Flow 05

The status the customer actually sees

The same order object powers the page the shopper lands on. A branded tracker shows a production timeline — placed, spec sent to factory (auto-routed, no re-key), cut, assembling, quality check, shipped — alongside the exact made-to-order specification and a delivery estimate. The blind spot that used to require a phone call to the plant becomes a self-serve answer.

Customer-facing order tracking web page: a horizontal production status timeline from order placed through delivered with completed, active, and upcoming steps, an estimated-delivery banner, an order-activity log, and an order-detail card showing the product preview, made-to-order specification, total paid, and View receipt and Reorder actions
A launched-quality customer tracker built on the same order object — the production status and full spec the floor works from, shown back to the shopper.

Results

Fewer handoffs, less scrap, a custom order you can track.

4 → 0
Manual re-key handoffs removed from the order path
3 → 1
Order formats collapsed into one canonical record
1
Source of truth shared by store, web, and factory
End-to-end
Status visible from sale to shipment for the first time
Live
Lead time and price shown at the point of sale
Validated
Flow tested with store staff and factory operators
How this was validated

This was a design-and-service engagement, so the outcomes are framed structurally rather than as launch lift. The 4 → 0 handoffs and 3 → 1 formats are facts of the redesigned order model — counted directly from the current-state service map versus the proposed flow. Validated reflects moderated walkthroughs where showroom associates placed a custom order and factory operators worked it from the queue without falling back to a printout or a phone call.

What almost broke

The factory team had built years of trust in their printed travelers and didn't want a screen between them and the machine. My first concept replaced the paper outright and was rightly rejected in testing. The version that worked kept the cut-list printable from the dashboard during a transition period — a digital source of truth that still produced the artifact the floor trusted. Designing for the rollout, not just the end state, is what got operations to adopt it instead of route around it.

Business impact · ROI

What killing the re-key is worth on the floor.

This was a design-and-service engagement, so I sized the impact from the order model itself — the scrap, the lost orders, and the labor that disappear when four manual handoffs collapse to zero and one canonical record replaces three formats.

~$900K
Modeled annual scrap & rework avoided from upstream spec validation
−70%
Projected custom-order defect rate — re-key errors designed out
4 → 0
Manual handoffs removed — ~6 min of labor recovered per order
~$310K
Estimated yearly labor recovered across store + factory re-entry
−2–3 days
Projected order lead-time cut from a single source of truth
<12 mo
Estimated payback on build, scrap and labor savings combined
How this was modeled

These are projections, not post-launch measurements — stated as ranges on purpose. Scrap savings apply the plant's reported custom-order defect rate and per-unit material cost to the share of defects traced to re-keyed specs, then assume the modeled −70% reduction from validating the spec at the point of sale. The labor figure multiplies the per-order handoff time (counted from the current-state service map) by annual custom-order volume at a fully-loaded floor rate. Lead-time and payback are derived from the same operational inputs. The handoff and format counts (4 → 0, 3 → 1) are facts of the redesigned order model, not estimates.

Reflection

What designing across the seam taught me

01

Design the order, not the screen

Defining one canonical order object did more than any interface could — it made automation possible and re-keying impossible.

02

The expensive bugs live in the gaps

Every system worked alone. The scrap, the lost orders, and the phone calls all happened in the handoffs between them.

03

Capture structure where the order is born

Validating a custom spec at the point of sale is cheaper than catching it at the saw — push correctness upstream.

04

Earn adoption with the rollout, not the demo

Respecting the factory's trusted paper traveler during transition is what turned a good design into one operations actually used.