Customer Support System

Overview

Support load was rising at Laced and the only visible solution was hiring more agents. That's the corporate equivalent of putting a bigger bucket under a leaking pipe. I framed the problem differently: the issue wasn't ticket volume per se, it was that the system had no context, no intelligent prioritisation, no root-cause aggregation, and no proactive prevention. I redesigned support as a signal and prevention system rather than an inbox-clearing operation.

The problem

CS wasn't failing because agents were slow. It was failing because the system forced them to triage without context (manual lookups for order value, seller status, fulfilment state), treat every ticket as unique (no clustering of repeat root causes), and respond after failure rather than preventing it. Escalation was ad hoc — CS acted as a buffer between Ops and Product without clear ownership over what each team should actually resolve.

The result was that the same issues kept repeating, high-impact tickets weren't handled any faster than low-impact ones, and Product and Ops only ever heard about problems through anecdote rather than systematic data.

What I did

Before building anything, I validated three assumptions with evidence:

1. Context reduces handling time: I manually attached order value, fulfilment status, and seller reliability to a sample of tickets and compared handling speed and escalation rate. Agents made faster decisions with fewer clarifying steps.
2. Most tickets share root causes: I manually clustered a week of tickets by underlying cause rather than message text. A small number of root causes drove the majority of volume.
3. Arrival-order prioritisation is wrong: I compared "arrival order" with "impact order" (revenue at risk, customer value, escalation risk). The queue was optimised for fairness, not outcomes.

These three validations justified the investment. I then designed and shipped the system in phases.

Systems I built

Ticket enrichment layer: Every incoming ticket auto-attached order value, seller reliability score, fulfilment status, and customer history — so agents never needed to do manual lookups before making a decision.

Root-cause categorisation and clustering: Tickets were categorised by underlying issue type and clustered into recurring problem families. This gave Product and Ops trend visibility instead of anecdotes — support became an observability layer for the platform.

Impact-based prioritisation: A priority score calculated from revenue at risk, customer lifetime value proxy, and escalation likelihood replaced arrival-order queue logic. High-impact issues surfaced to the top automatically.

Proactive alert system: Known failure signals — high-risk fulfilment states, risky seller behaviour, orders delayed past defined thresholds — triggered internal alerts before buyers contacted CS. The cheapest ticket is the one that never gets created.

Explicit escalation paths: Defined clear rules for what CS could resolve, what Ops owned, and what Product had to fix. CS stopped acting as a general buffer. Root-cause fixes became possible because ownership was clear.

Rollout approach: Phased delivery with manual override capability preserved in early stages; reason codes added so agents understood why a ticket was prioritised; false-positive rates monitored on alerts; misclassification tracked on categorisation.

Impact

CS ticket volume dropped 40% without a proportional increase in headcount. The reduction came from preventing common failures at the operational level and fixing root causes — not from agents replying faster. High-impact issues were resolved sooner. Product and Ops gained systematic visibility into what was generating support load, which fed directly into prioritisation of platform improvements.