Untangling a Fragmented Order Ecosystem

Four support teams. Eight disconnected tools. Zero shared understanding of what an order even was. I led a 4-month systems discovery that turned organizational complexity into an aligned modernization strategy for a $30B+ regional grocery retailer.

Service design · Systems design · Ecosystem mapping · Domain modeling · Research synthesis · Engineering alignment

The Problem

One customer issue. Three teams. Five systems.

A customer calls to add wine to their curbside order. Later, their discount doesn’t apply. The Contact Center agent opens CSR — can’t see coupon details. They message Accounting on Teams. Accounting checks Clear Commerce and ERGC, finds the issue, but can’t apply a fix. The agent logs into COMS separately to resolve the order state, then calls the customer back. The customer gets the discount — but no receipt. Three teams. Four handoffs. Still no clean resolution.

This wasn’t a rare edge case. It was how the system worked every day.

One customer issue. Three teams. Four handoffs. Still no clean resolution.

COVID-19 had dramatically increased digital order volume — a single store went from ~170 curbside orders per day to ~280 virtually overnight. Across 400+ stores, the order management ecosystem was buckling. The legacy system (COMS) had grown far beyond its original scope, and partner tools had been built piecemeal with no unified strategy.

The company needed to modernize. But before anyone could plan a migration, someone needed to make the full complexity visible — across customers, partners, and systems — so that leadership, product, and engineering could align on what to fix and in what order.

My Role

I led the research and made the invisible visible.

I worked alongside a design partner (who focused on planning and coordination) and a PM (who took the recommendations forward once we had them). Three engineering leads — covering fulfillment, front-end, and the legacy COMS system — were our key technical collaborators.

I personally led: the partner shadowing sessions, synthesis of all research findings, creation of the ecosystem map, the future-state customer storyboard, and the presentation of recommendations to leadership.

I co-led: the research synthesis across 8 existing sources, the lifecycle journey map, forming the four recommendations, and designing the One Order UI concept.

The Approach

Future first. Then current state. Then close the gaps.

The most important framing decision was to start with the future, not the current mess. If we’d started by auditing tools, we would have inherited the existing framing — “fix COMS,” “add a field to CSR” — and never gotten to the systemic questions.

Instead, I co-led the decision to define what a good customer order experience should look like 1–2 years out, then work backward to understand where the current state fell short, and finally close the gaps with concrete recommendations.

Phase 1 — Defining the Future Customer Experience

July / August 2020

I synthesized 8 existing research sources — retention studies, voice-of-customer reports, substitution and post-order research, CIC reports, SurveyAid cases, and foundational in-store research — into a unified view of customer needs.

Eight existing research sources, synthesized into shared themes.

Five core customer need themes emerged: on-demand, flexibility and control, effortless recovery, connected experience, and personal and human.

I then created a customer storyboard — a narrative scenario showing a family using future-state ordering across grocery, pharmacy, flowers, and restaurant pickup in a single trip. This was not a roadmap. It was a requirements-discovery tool disguised as a customer story.

Each scene maps to system implications below it.

Why this mattered: The storyboard gave engineering a customer-experience reason to care about backend flexibility. It shifted the conversation from “COMS is slow” to “the system can’t support the experiences customers will expect.”

Phase 2 — Making the Current Complexity Visible

September / October 2020

I planned and conducted shadowing sessions with four partner teams — Contact Center, Home Delivery Support, Accounting, and eStore Leads — through a mix of Zoom and in-person observation. I watched them work real orders, resolve real issues, and navigate the tools they used every day.

What I found was alarming.

Shadowing four partner teams across Zoom and in-person sessions.

The number of tools and handoff processes required to resolve a single customer issue was staggering — with no common thread or single place to see the full picture of an order. Partners were juggling 8+ order-specific systems (CSR, COMS, ERGC, Clear Commerce, DAS, FAST Web, FAST App, Favor Portal) plus a constellation of auxiliary tools.

Each team’s tools mapped in overlapping circles. Every team had a different slice of the truth.

Contact Center couldn’t see why a payment failed — they had to message Accounting. They couldn’t see a driver’s ETA — they had to phone Home Delivery Support. They couldn’t see refunds issued in other systems — they had to log into yet another tool. Every gap in visibility meant another handoff, another delay, another frustrated customer on hold.

Three examples of missing information that forced cross-team handoffs for basic tasks.

What Is an Order, Actually?

One of the most important things I did was ask a question nobody had a consistent answer to: what makes up an order? I mapped every data point — customer info, payment, fulfillment details, item statuses, coupons, refunds, driver assignments, substitution preferences, communication logs. The answer: 132+ potential data points, scattered across systems with no unified model.

Order data and functionality scattered across systems — the core finding that connected every pain point.

I co-led the creation of an end-to-end order lifecycle journey that mapped customer actions, partner actions, system statuses, and handoffs across every phase — from order placed to post-delivery recovery.

Customer and partner views mapped against system touchpoints and status changes across the full lifecycle.

Key insight: The “source of truth” changed throughout the lifecycle. Not all systems knew the same status at the same time. This wasn’t a UI problem — it was an architecture problem that no amount of tool redesign could fix.

The Turning Point

The ecosystem map became the most important artifact in the project.

As I synthesized the shadowing work, I kept seeing the same pattern: one customer issue moved through multiple teams, each relying on different systems and partial truths. I created an ecosystem map to make that pattern visible in one view: customer actions at the center, lifecycle phases around them, and the partners and systems involved at each stage.

Before the ecosystem map, the shared understanding was: people use a lot of tools. After the ecosystem map, the conversation shifted to: even with all these tools, the system itself is falling short. That reframe was worth the entire project.

The artifact that shifted the conversation from tool pain to lifecycle modernization.

Phase 3 — Recommendations

November 2020

I co-led the formation of four strategic recommendations and presented them at the November 2nd monthly readout — with PMs, design, engineering leads, and business stakeholders all present.

1. Create a unified order UI for Partners — One view replacing CSR, COMS, ERGC, DAS, and Favor Portal. Full audit trail. Flexible modifications by permission.

2. Move to event-driven architecture — Enable transparency, fault tolerance, and decoupled components.

3. Create a single source of truth — A new event stream running parallel to the legacy system, enabling gradual migration and full order auditability.

4. Break COMS into services — Decompose the monolith into discrete services to enable faster innovation and new lines of business.

As presented to leadership, November 2nd, 2020.

The North Star — One Order

I co-designed a concept for a unified partner tool showing how customer info, fulfillment details, payment, coupons, item statuses, and a real-time audit trail could all live in one view. I also provided two phased implementation options with tradeoff analysis, so leadership could make an informed sequencing decision.

It was not intended to be a polished final UI. It was meant to tell a systems story: one persistent order object, lifecycle continuity, role-based actions, source-system transparency, and a chronological event trail showing what happened, when, and by whom.

Annotated version showing source systems and data origins.
Clean version showing the partner experience.

When I presented the One Order concept at the November readout, the room changed. Engineers and PMs reacted with visible excitement — and that’s when real organizational momentum built behind the recommendations.

Impact

Strategic direction set. The four recommendations became the framework for the company’s order management modernization program. Engineering committed to next steps: building out the full order domain, setting up the infrastructure backbone, and determining the migration path.

Artifacts used long after the project. The ecosystem map, order journey, and One Order concept were referenced by engineering teams in architecture planning. A Slack message from an engineering partner months later confirmed the work was still actively shaping conversations. I reused the same artifacts in a 2023 presentation — they were still the shared reference frame three years later.

Reframed a technical problem as a human one. Before this work, the modernization conversation was about technical debt. Afterward, it was about partner and customer experience — “partners can’t see a complete order,” “customers can’t recover from errors without calling.” That reframe gave leadership a clear “why” behind the investment.

Short-term wins surfaced. Beyond the long-term vision, the research identified immediate improvements — automated order lookups, copy-paste shortcuts, FAQ deflection for common Contact Center questions, displaying driver ETAs in CSR — that could reduce partner burden while the bigger migration was planned.

Service blueprint + Slack message from engineering

"We will be using all this hard work for a long, long time" — proof the work outlasted the project.

Reflection

I’d quantify the operational cost earlier. Time-per-resolution, number of handoffs per issue type, hours lost to tool-switching — these numbers would have made the business case sharper. I had the qualitative evidence. I wish I’d invested in making it numerical.

I’d push the One Order concept further into prototype. The static concept generated enormous excitement. An interactive prototype might have accelerated the commitment even more.

I wouldn’t change starting with the future. That decision prevented the team from inheriting the legacy system’s framing. It kept the conversation about customer and partner experience, not about database schemas and API contracts.

The work that mattered most wasn’t a UI or a research report. It was building the shared models — ecosystem maps, domain models, journey maps — that helped an organization understand its own complexity well enough to act.