Designing a Customer-First Post-Purchase Platform

Post-purchase support at The Sleep Company was fragmented across calls, email, Freshdesk, third-party logistics portals, and POS, run on tribal agent knowledge and five separate SOPs. Agents applied policy from memory, so two customers with the identical issue could get different answers depending on who picked up.

That inconsistency had a direct revenue cost: with no faster alternative surfaced, 'cancel' and 'return' were the easiest path for both the customer and the agent, even when a cheaper lever (hold, edit, repair, part-replacement) would have kept the order and solved the actual problem.

I worked through the order lifecycle end to end — 29 distinct order states, from Order Created through delivery, installation, and warranty — and mapped them down to 7 UI phases the customer actually needs to reason about (pre-dispatch, in transit, out for delivery, delivered 0–10 days, 11–100 days, post-100 warranty, terminal).

In parallel, I built a full VOC (voice-of-customer) disposition tree from real complaint, request, and query volume — delivery complaints, delivery queries, delivery requests, double-delivery, RTO-replacement, and more — tagging each leaf with its automation tier and the entry→exit states it moves through. That tree is what proved which issues could be fully self-served, which needed a single automated gate (like a technician verdict), and which had to stay human.

The policy itself turned out to depend on 11 inputs, not one: product category, stated reason, who's at fault (TSC vs. customer), days since delivery, installation state, technician verdict, approval state, order value, stateful counters (how many times this order has already been replaced or returned), sales channel, and customer segment. Any post-purchase decision engine that didn't model all 11 would just be another inconsistent agent, expressed in code instead of memory.

The organizing bet: every option list is ordered cheapest-fix-first — keep as-is → expedite/hold/reschedule → edit or swap the product → repair → part-replace → replace → return/refund, always last. Cancel and Return are never offered as a first action anywhere in the app; a flow that surfaces either before the ladder is treated as a defect, not a design choice.

The second bet, which is what makes the first one enforceable: the app ships no policy logic. Every decision comes from three pure server contracts — a status projection, an action-availability check, and a resolution verdict — and the UI only renders their output. No policy constant (a return window, a shipping charge, an approval cap) is allowed to be hardcoded into a screen. That's what turns a policy change from an engineering rebuild into a config edit, and what makes every decision traceable to a named rule instead of an agent's memory.

I also designed the Case object as the contract between this customer app and the internal agent app that comes later: every self-resolution, booked action, and human escalation writes one Case, with the full rule trace attached — so Phase 4 (the agent console) plugs into the same data with zero rework.

My focus was the customer-facing flow, screen by screen: Home and Order-360 lead with 'What can we help with?' in plain language, never a raw Cancel/Return tile. Ineligible actions render greyed out with their reason instead of disappearing silently, so the customer always understands why, not just that something isn't available.

Cancellation asks why before it shows an exit: 'taking too long' surfaces the real delivery date plus expedite/hold, 'found it cheaper' routes to price-match, 'changed my mind' offers an edit or swap. Only after that reason-specific retention step does a cancel path exist — instant refund pre-dispatch, an honest 'not guaranteed' recall attempt post-dispatch.

Returns and replacements run through evidence and technician gates matched to the actual product and situation — a non-mattress item damaged after installation needs a technician verdict before any remediation books; a mattress discomfort case walks posture-correction education → topper offer → replacement, only reaching return once that ladder is exhausted. Every escalation to a human — approvals, technician disputes, general support — carries the full case context forward, so the customer is never asked to re-explain what they already told the app.

Phase 1 was scoped and validated end to end on realistic demo orders: a non-technical person could open an order, try to cancel and get retained, report a damaged item and be guided to the correct replacement mode (and see why), report a delivery problem, book a technician, check a refund, and escalate to a human at any point with full context carried — with every policy number traceable to a named rule.

That acceptance bar mattered more than a feature checklist: it forced the retention ladder and the context-carrying handover to actually work across the full customer journey, not just in isolated flows.