Turning complaints into store improvements

Product came to us with a clear brief: design a new customer complaint resolution tool, because the current operation was badly fragmented. Resolving a single complaint meant moving across four or more core platforms: C-CRM, Zendesk, BrandAdmin, and OSSOM/I-ROC. Each was owned by different stakeholders and each worked in its own silo. The job was to unify that into one coherent system.

The fragmentation wasn't only technical, it was organisational. Those platforms were spread across four different groups who all touched a complaint: store staff, the guest services team, the call centre team, and an external social media agency. No single tool, and no single team, held the whole picture.

We mapped the existing state as a service blueprint before designing anything: a complaint travelled through registration, resolution, reporting, and insight, touching all of these disconnected systems along the way, with no centralised log, no live status for stakeholders, and prioritisation done by hand. Reaching an actionable insight could take days. That blueprint became the argument for why consolidation mattered, and the baseline the new system had to beat.

That is a hard systems problem on its own. You have to collapse the sprawl into one tool with access tied to roles, keep the capabilities each stakeholder depends on, and avoid making the new system so unfamiliar that it creates its own adoption tax.

I led this as a design manager. I mentored two designers through the full arc, from research to final design. I was hands on at the start to set the foundation, then moved to oversight as they carried it forward. So far the team has designed the ticketing page and the core resolution flow, with more flows in progress. The direction is deliberately modern while preserving enough familiarity that existing users aren't relearning their job.

That's the execution layer, and it's solid consolidation work. But the part I want to be clearest about is a strategic move I made on top of it.

Consolidation was the brief, but the research surfaced four problems that a tidier support tool wouldn't fix, and together they're what turned this from a complaint tool into a store health system:

• Fragmented systems. Because the data lived in separate tools, managers built their own manual trackers, making performance monitoring inconsistent and slow.
• Manual RCA. Root cause analysis, concern validation, and staff retraining were all done by hand, so they were inconsistent and missed the window for early intervention.
• No customer view. A customer's authenticity was hard to verify because order history, past concerns, and refund patterns weren't available in one place.
• No loop closure. GDMs and leadership had no visibility into resolutions, recurring issues, or patterns at the store level, and no way to track whether anything preventive was actually working.

The four findings that a consolidation alone wouldn't solve, and the case for layering intelligence on top of the system of record.

The brief was a complaint resolution tool. I argued it should be more: a store health system, not just a support tool. A resolution tool clears tickets. A store health system uses what those tickets contain to tell a manager what's actually going wrong in their store and what to do about it.

A dashboard tells you what happened. Store.AI tells you what to do about it.

This wasn't a hunch. It came from research I'd done on my own initiative earlier, not a scoped assignment. I wanted to understand how store managers actually work to improve the customer experience. The discovery that stuck with me was the opposite of what I expected: at most stores, managers weren't connecting complaints to causes at all. They were resolving tickets, not asking what kept producing them. The only people doing real root cause analysis were one or two unusually driven managers, and the system gave them nothing to do it with. In one case a manager was tracking it by hand, literally tagging on paper which makeline person was attached to the most complaints or the lowest food ratings.

That reframed the opportunity. The AI layer wasn't about automating something everyone already did. It was about making a whole category of better management possible. For the rare manager with the instinct, it removed a system that actively failed them. For everyone else, it surfaced root causes they weren't even looking for.

The tool still has a dashboard. Stakeholders need one, and removing it would be solving the wrong problem. A dashboard tells you what happened; Store.AI sits on top and tells you what to do. The two are additive by design: the system of record stays, and intelligence is layered over it. Powerful, but not dumbed down.

Concretely, Store.AI reads across all complaints and surfaces where attention is needed right now, by finding patterns a person would be slow to catch:

• Deliveries running late in a particular area
• Multiple poor food reviews tracing back to one specific makeline person

It doesn't just report from those patterns. It proposes actions. A manager can turn a surfaced issue into a task, assign it, and track it to closure on a Kanban board. The loop closes: complaint → detected pattern → root cause → assigned action → resolution. That's the path from a support tool to a store health system.

I introduced and pitched these AI use cases to leadership myself: pattern detection and RCA, ticket summaries, and a prioritisation layer. I branded this intelligence layer Store.AI when I first developed the concept with a team at a designathon, built on that same research I started on my own. The name has stuck and is now used internally as the term for the product's AI use cases.

The resolution platform is in active design, with the core flows being built first. Store.AI is designed and pitched, and planned for a later phase of the roadmap. I've included it here as what it is: product strategy I proposed, scoped for phase two rather than shipped yet.

The lesson is about where good product ideas hide. The signal here wasn't a common behaviour to automate. It was a rare one being quietly throttled by the system, while most people had given up on it entirely. The best opportunities in a complex system often look like that: one or two people straining against a tool that won't let them do the smart thing. Find them, understand what they're reaching for, and you've usually found what the product should become for everyone.