The situation
The client is a direct-to-consumer apparel brand doing roughly $18M in annual revenue, running its store on Shopify with a small in-house support team of four handling all customer contact through a standard help desk. Return and exchange requests made up about 35% of total ticket volume, and while each individual ticket was simple in isolation (check order status, confirm the item is eligible for return, issue a label, process the refund once the item scanned back in) the sheer repetition was consuming roughly a third of the team's total weekly hours, according to their own help-desk time tracking.
The team wasn't unhappy with the work exactly, but the founder, who still reviewed support metrics personally, was concerned that the same four people were both the entire support function and increasingly the bottleneck on response time during any sales spike, because return volume scales with sales volume on roughly the same delay as the returns themselves.
Why off-the-shelf didn't fit
There is no shortage of returns-management SaaS products built specifically for Shopify stores, and the client had actually tried one twelve months prior. It handled the mechanical part well, generating labels and tracking scanned returns, but it operated as a self-service customer portal, not a conversational agent, and the client's own data showed a meaningful share of customers still emailed support anyway rather than using the self-service flow, often because their situation didn't fit the portal's standard categories (a gift return with no order number on hand, a partial exchange where only one item in a multi-item order needed to come back, a "this arrived damaged" report that needed to skip the standard returns flow entirely and go straight to a replacement). The self-service tool handled the easy 60% and left the more annoying 40% landing in the support inbox anyway, which, from the team's point of view, didn't feel like it had solved anything.
Scoping the real workflow
Because this was a smaller, more contained workflow than some of our other engagements, the scope call was a single 75-minute session with the support lead and one senior agent, working through the last 60 days of return-related tickets together to categorize them by pattern. That review surfaced that the "hard 40%" the self-service tool couldn't handle broke down into about six recurring categories: gift returns, partial exchanges, damaged-in-transit reports, late returns just outside the policy window where the team had an informal practice of using judgment, sizing-related exchanges bundled with a return, and international returns with different label logistics, each of which had its own handling logic the team could articulate clearly once asked directly.
What we built
The agent sits inside the existing help desk, picking up return- and exchange-related tickets (and a live chat widget for real-time requests), pulling order data directly from Shopify, and handling the conversation end to end for the six categories mapped during scoping: verifying eligibility, generating and emailing a return label through the 3PL's returns portal API, processing store credit or a refund once a return scans in, and handling exchanges by placing a new order alongside the return rather than requiring a separate manual step. For the late-return judgment calls, we built a specific, bounded rule rather than asking the agent to freelance: returns up to 14 days past the stated window are approved automatically if the customer has no prior returns flagged as abusive in the system, and anything beyond that is escalated with the relevant order and return history summarized for a human to decide, a threshold the founder set explicitly, because it reflected a business risk tolerance decision, not a workflow-automation decision, and that distinction mattered enough that we were deliberate about keeping it a human-set policy input rather than something the model inferred on its own.
Where it got hard
The genuinely tricky part of this build wasn't technical integration, since Shopify and the 3PL's returns portal both had solid, well-documented APIs, and that part came together in the first week. It was defining the abuse-pattern boundary for the late-return rule cleanly enough to encode it as a deterministic check rather than leaving it to model judgment. Early in the build, we'd proposed letting the agent use contextual judgment about whether a late return "seemed reasonable" based on the customer's message, and the support lead pushed back hard on this in a build review, pointing out, correctly, that a model forming its own opinion about customer honesty was exactly the kind of unaccountable, inconsistent decision-making that a fixed, written rule was supposed to prevent. We rebuilt that logic as an explicit, auditable rule (days past window, prior return count, prior flags) rather than a model judgment call, an example of scope catching a design mistake before it shipped rather than after a customer complained about inconsistent treatment.
Damaged-in-transit reports also needed more care than expected: the agent needed to request photos before approving a no-return-required replacement, but customers frequently sent photos in a follow-up message rather than the first one, and our first version handled multi-message conversations less gracefully than a single-message request, occasionally asking for a photo the customer had, in fact, already sent two messages earlier. We rebuilt the conversation-state handling to track the full thread rather than just the most recent message before this went live broadly.
Rollout & results
Within the first month post-launch, the agent fully resolved 82% of return and exchange tickets without any human touch, with the remaining 18%, largely genuine edge cases like international customs disputes and multi-order returns spanning different fulfillment batches, escalated with full context attached. The support team's own time tracking showed roughly 11 hours a week freed up across the team, which they redirected toward proactive outreach on delayed shipments, something that had been on their wish list for over a year but never had the capacity to start.
"I expected the automation to feel cold to customers. It didn't, because it wasn't trying to sound like a person pretending. It just handled the boring part fast and got out of the way." Head of Customer Experience, client engagement
What we'd do differently
We'd bring the "should this be a rule or a model judgment call" question to the client explicitly and early on every engagement, rather than defaulting to model judgment for anything that seems reasonably bounded and waiting for someone to object. The late-return incident cost us a build-review cycle we didn't need to lose; on every engagement since, we now flag any decision point that touches customer trust or fairness as a specific "rule vs. judgment" decision for the client to make explicitly during scoping.