From Fragmented Fulfillment to Real-Time Visibility: A 6-Month Omnichannel Logistics Transformation
SkyRetail, a fast-growing omnichannel retailer with 120K monthly orders, struggled with fragmented warehouse processes, delayed status updates, and rising customer support volume. We delivered a full-stack logistics visibility platform—integrating WMS, carrier APIs, and a new operations dashboard—while automating exception handling and demand-based labor planning. In six months, the client reduced pick/pack cycle time by 38%, cut shipment exceptions by 46%, and lifted on-time delivery from 84% to 95%. Support tickets per 1,000 orders fell by 52% as proactive alerts and self-serve tracking went live. This case study details the challenge, goals, approach, implementation, and the measurable impact, including a phased rollout, data quality remediation, and a reliability-first architecture on AWS. It concludes with lessons learned on change management, schema governance, and building resilient integrations.
Case Studylogisticsomnichanneloperationsdata-integrationawsautomationcustomer-experience
## Overview
SkyRetail is a mid‑market omnichannel retailer selling home essentials across web, mobile, and 30 physical stores. Rapid growth during the last two years brought a surge to ~120,000 orders/month, but fulfillment operations did not scale at the same pace. Status updates were delayed, exception handling was manual, and warehouse supervisors lacked real‑time visibility into bottlenecks. Customers felt the pain through late shipments, and the support team absorbed the rest in the form of “Where is my order?” tickets.
We partnered with SkyRetail to deliver a logistics visibility platform and process redesign that linked warehouse events, carrier tracking, and order management in a single operational picture. The project delivered a measurable lift in on‑time delivery, reduced handling errors, and improved customer satisfaction while preparing the company for peak seasons and new distribution centers.

## Challenge
SkyRetail’s fulfillment stack grew organically. The warehouse management system (WMS) was customized heavily, while store fulfillment used a separate order allocation tool. Carrier updates arrived through emails or inconsistent webhook payloads. As a result:
- **Fragmented visibility:** Operations managers stitched together dashboards from spreadsheets, WMS exports, and carrier portals. There was no single source of truth.
- **Delayed status updates:** The customer‑facing tracking page updated once every few hours, even if shipments were already out for delivery or delayed.
- **Manual exception handling:** Damaged items, carrier delays, and inventory mismatches required manual intervention via email threads.
- **Rising support load:** Support tickets averaged 19 per 1,000 orders, largely due to status ambiguity.
- **Unreliable reporting:** KPI reports were stale and inconsistent across teams, creating mistrust in the data.
The business risk was clear: poor delivery reliability and lack of transparency eroded customer trust. The operations team also needed a scalable system before a planned second distribution center went live.
## Goals
Together with stakeholders across operations, engineering, and customer experience, we defined specific goals:
1. **Real‑time visibility** into warehouse events and carrier status, available to operations and customer support.
2. **Accurate, near‑instant customer tracking** with proactive exception alerts.
3. **Automated exception workflows** to reduce manual intervention and rework.
4. **Operational KPIs** with trusted data: pick/pack time, carrier SLA adherence, exception rate, and support tickets per 1,000 orders.
5. **Scalable architecture** that could support a second distribution center and 2x order volume.
## Approach
We used a phased, reliability‑first approach focusing on data fidelity before UI polish. The work was structured into four tracks:
- **Discovery & process mapping:** We documented every fulfillment touchpoint from order allocation to carrier handoff and returns. We created a shared event taxonomy that both warehouse and engineering could understand.
- **Data integration & normalization:** We built a canonical event stream that normalized WMS events and carrier tracking updates into a unified schema.
- **Operational dashboard + APIs:** We delivered a role‑based operations dashboard and a customer tracking API that the website and mobile app could consume.
- **Change management:** We partnered with operations leaders to align SOPs and train teams on exception workflows and dashboards.
This approach ensured we solved root causes (missing event data and weak exception handling) rather than only improving surfaces.
## Implementation
### 1) Event Taxonomy and Canonical Schema
The most critical early milestone was defining “what” we track. We established an event taxonomy with 37 standardized events mapped to three stages: **Fulfillment**, **Carrier**, and **Post‑Delivery**. Examples included `PICK_STARTED`, `PACK_COMPLETED`, `LABEL_PRINTED`, `CARRIER_PICKUP`, `OUT_FOR_DELIVERY`, and `DELIVERY_EXCEPTION`.
We built a canonical schema in JSON with strict validation and explicit time zones. This allowed events to be compared consistently, even across multiple systems. A schema registry ensured new event types could be added safely as business needs evolved.
### 2) WMS Integration Layer
SkyRetail’s WMS had custom extensions and inconsistent event timestamps. We implemented a lightweight integration service that:
- Consumed WMS events via database change feeds and API polling
- Standardized timestamps to UTC while preserving local facility time
- Enforced event ordering using sequence IDs
- Enriched events with order and inventory metadata
This service published normalized events to a message bus, which became the foundation for all downstream visibility.
### 3) Carrier Aggregation and Tracking Normalization
We integrated five carriers plus a regional last‑mile partner. Each provided tracking data with different field names and exception codes. We created a mapping layer that:
- Translated carrier codes into the canonical event taxonomy
- Normalized “out for delivery” and “exception” statuses to consistent severity levels
- Deduplicated events to prevent UI thrash
This layer updated the customer‑facing tracking API within minutes of carrier status changes.
### 4) Operations Dashboard
The operations team needed a real‑time, actionable view—not a static report. We built a dashboard with three primary views:
- **Live Flow View:** Displays orders moving through pick/pack/ship, with bottlenecks highlighted in red.
- **Exception Queue:** A prioritized list of orders needing human action, grouped by root cause.
- **KPI Summary:** On‑time shipment %, average pick/pack time, exception rate, and daily throughput.
We kept the UI clean and functional, prioritizing clarity over visual complexity. The dashboard was role‑based so supervisors and floor leads could focus on what mattered most.

### 5) Customer Tracking Experience
We replaced the slow, batch‑updated tracking page with a near‑real‑time API powering web and mobile. Features included:
- Event timeline with clear human‑readable statuses
- Proactive alerts for exceptions (e.g., “Weather delay in your area”)
- Estimated delivery updates based on carrier SLA and historical lane data
Support agents also gained a more detailed internal view to answer customer inquiries without escalating to operations.
### 6) Exception Automation
Manual exception handling was a major cost. We introduced automation for the most common issues:
- **Inventory mismatch:** Automatically re‑allocate from alternate locations or trigger a split shipment
- **Carrier delay:** Notify the customer and adjust ETA using predictive heuristics
- **Address issues:** Prompt customer confirmation via email/SMS before re‑routing
These automation flows reduced the number of human interventions and shortened resolution time.
### 7) Data Quality Remediation
The project exposed historical data inconsistencies. We ran a dedicated data remediation effort to:
- Backfill missing events for active orders
- Identify WMS events with invalid timestamps
- Cleanse SKU metadata and unit conversion errors
This step was essential to building trust in the dashboards and analytics.
### 8) Reliability and Observability
We used a reliability‑first architecture on AWS:
- Event ingestion and normalization on a message bus with retry policies
- Serverless processing for burst capacity during peak hours
- Centralized logging with correlation IDs per order
- Monitoring for missing events and latency thresholds
A dedicated reliability playbook provided on‑call procedures for integration failures or carrier API outages.
## Results
The first distribution center launched on the new platform within four months. The second distribution center went live two months later, onboarding in half the time because the event model and integrations were already standardized.
Key outcomes after six months:
- **Pick/pack cycle time reduced by 38%** (from 42 minutes to 26 minutes on average)
- **Shipment exceptions reduced by 46%** through automation and early detection
- **On‑time delivery improved from 84% to 95%**
- **Support tickets per 1,000 orders dropped 52%**
- **Warehouse throughput increased 29%** with no additional headcount
Operational teams reported higher confidence in daily metrics and fewer “surprise” escalations. Customer experience also improved, with a measurable lift in CSAT and repeat purchase rates.
## Metrics
Below are the most relevant metrics tracked in the first six months after launch:
- **On‑time delivery:** 84% → 95%
- **Average pick/pack time:** 42 min → 26 min (‑38%)
- **Exception rate (per 1,000 orders):** 31 → 17 (‑46%)
- **Support tickets per 1,000 orders:** 19 → 9 (‑52%)
- **Warehouse throughput:** +29% (orders processed per shift)
- **Carrier SLA adherence:** +12 percentage points
- **Customer satisfaction (post‑delivery survey):** +14% improvement
## Lessons Learned
1. **Visibility is a data problem first.** Without a consistent event model, dashboards become decoration. The canonical schema was the turning point.
2. **Normalizing timestamps saves weeks of confusion.** Unified UTC time plus local facility context eliminated disputes between teams.
3. **Automation must be paired with clear human escalation paths.** When automation fails, the system should guide the operator toward resolution in under two clicks.
4. **Trust in metrics is earned, not assumed.** Early data quality work is unglamorous but vital to adoption.
5. **Change management is as important as engineering.** Training, SOP updates, and weekly check‑ins kept operations invested and reduced shadow processes.
6. **Resilience beats over‑optimization.** Carrier APIs fail. Retry policies, fallbacks, and observability prevented outages from becoming chaos.
## Conclusion
This transformation repositioned SkyRetail’s fulfillment operation from reactive to proactive. Real‑time visibility, exception automation, and reliable metrics delivered tangible performance gains while freeing teams to focus on strategic improvements instead of daily firefighting. The platform now acts as the company’s operational nervous system, making it easier to scale, onboard new facilities, and deliver a consistently excellent customer experience.
With the groundwork in place, the next phase will focus on predictive staffing, inventory pooling across facilities, and deeper ML‑based ETA accuracy—built on the same clean, standardized event stream that made this project a success.