Turning Device Retirement Into a Revenue Opportunity
How I redesigned a fully manual, off-platform device retirement process into a bulk, self-service workflow, and created a new path to replacement revenue in the process.
Context
Retirement lived everywhere except the platform
Before this project, retiring a device, destroying it, donating it, recycling it, or buying it back, wasn't something GroWrk's platform could do anything about. It happened, but off to the side: tracked across spreadsheets, coordinated by hand, with no record of it anywhere a client or a teammate could actually see. GroWrk supports four disposition types, and each one can apply either to a device already sitting in a warehouse or to one still out with an employee that needs to be collected first. None of that combinatorics lived in the product. It lived in Operations' heads and inboxes.
The logic for handling this had already been worked out once, for All In and Subscription companies, through the EOL V3 epic. Extending it into a self-service flow for A La Carte, under "Add EOL Orders to ALC," was the project that made retirement something a client could actually do themselves.
The Problem
A service nobody could see, trust, or request
GroWrk had no reliable way to process device retirement, and no way for clients to even know the service existed. Operations tracked it manually across multiple spreadsheets, with no shared source of truth and no consistent follow-up once a request was made.
Even if a client had known to ask, the platform's existing order model would have worked against them. Every other order type assumes you already know exactly which product you want and exactly which order type to apply to it. That's a reasonable assumption for a single laptop repair. It falls apart the moment someone's retiring twelve devices at once and just wants a place to say "these are done, deal with them."
The cost of that gap wasn't abstract. It meant slower, error-prone operations work, no visibility for clients into a process they were paying for indirectly, and, most concretely, no connection at all between a device being retired and a client buying its replacement, a revenue moment that simply didn't exist yet.
Constraints & Complexity
Eight order types, hidden from the user
The naive version of this feature is a form: pick a device, pick a disposition, submit. That version breaks the moment you look at what actually has to happen underneath it.
Four disposition types, each of which can apply to a device in a warehouse or a device still with an employee, is already eight distinct backend order types. The platform has to pick the right one without asking the client to understand GroWrk's internal taxonomy. If a client's selected devices span more than one country, warehouse routing has to split that single request into multiple country-specific orders automatically, invisibly. Payment logic diverges by destination: Recycle and Destruction are priced and run through Stripe, Donation is free and skips Stripe entirely in A La Carte, Buyback is quoted and paid back to the client via credit note, and every Collect-for variant splits pricing between the pickup leg and the disposition leg. A parallel manual-entry path exists for devices outside the warehouse, which can't rely on inventory data and needs its own validation. And live pricing for all of it depends directly on the Service Catalog, keyed by device type, region, and order type.
On top of all of that sat a harder constraint than any technical one: whatever got built for A La Carte had to mirror the already-established EOL V3 rules for All In and Subscription, not invent parallel logic that would drift out of sync over time.
My Role
Owning the logic, not just the wizard
I owned the end-to-end design of the self-service EOL experience for A La Carte: the retirement hub, both wizard flows, the invisible order-routing rules underneath them, and the replacement-purchase upsell built directly into the same flow. I led research with Operations and Logistics, defined the business rules for how the platform decides which order type to generate and how country splitting works, and contributed to a wizard component pattern that later got reused across every A La Carte order type, not just this one.
Research
Learning how Operations actually did this
I went straight to the people who'd been doing this manually: Operations and Logistics. The finding that reshaped the whole project came out of that research, not out of a spec. GroWrk's existing order model, pick a product, then pick an order type, breaks down for retirement. What people actually needed was a single hub where every device eligible for EOL was visible at once, so they could act on many of them in one pass instead of one request at a time.
Defining the Model
A hub, not a per-device request
That reframe became the foundation. Instead of a client choosing a product and then an order type, the EOL hub surfaces every eligible device up front and lets them act on many at once. Bulk, multi-select processing replaced what had been a one-at-a-time, order-by-order request, which sounds like a small UI difference and is actually the entire point: it's the difference between a form and a workflow.
Key Decisions
1
Letting the platform decide the order type
2
Splitting orders by country automatically
Clients shouldn't need to understand GroWrk's internal order taxonomy to retire a device, so the platform infers it for them. If a selected device is already in a warehouse, choosing Destruction creates a plain Destruction order. If that same disposition is chosen for a device still with an employee, the platform generates a Collect for Destruction order instead, automatically, based on where the device currently is.
The trade-off is straightforward: clients lose direct visibility into how their request gets categorized internally, and gain a dramatically simpler decision. They pick a destination. The platform figures out the rest.
When a client selects devices that span more than one country, say, some in Mexico and some in Canada, the platform generates a separate order per country without ever asking the client to think in terms of "orders" at all. They see one bulk retirement request. Behind it, the platform is doing the routing work a human would otherwise have had to do by hand.
3
Building the upsell into the flow itself
Right after a client chooses a disposition, the flow asks a simple question: would you like to replace this? If they say yes, the platform pulls live pricing from GroWrk's purchase catalog and generates the corresponding purchase order automatically, to Inventory or to the Employee, depending on the context. This launched first for All In and later extended to A La Carte.
This is the decision that turns retirement from a cost center into a revenue moment, not by bolting a separate purchase flow onto the end of the process, but by asking the question at the exact moment it's most relevant: right after someone has decided to get rid of something.
4
Mirroring All In's logic instead of inventing ALC's own
Rather than building parallel EOL rules for A La Carte, I designed the backend logic to mirror the already-established EOL V3 rules for All In and Subscription companies. That's a smaller-sounding decision than it is. The alternative, a fully custom A La Carte flow, would have been faster to build in isolation and much more expensive to maintain the moment either business model's rules changed. Consistency here was the more senior call, even though it meant less flexibility to customize A La Carte's flow on its own terms.
Validation
What real usage showed, not a lab study
This validation didn't take the form of a dedicated usability study, the way Service Catalog's did. The real check here was architectural: does A La Carte's order-routing logic actually hold up against the already-validated EOL V3 rules for All In and Subscription? It did, per the documented parity requirement, and the manual-entry path's serial-number validation held up under its own review.
Outcome
What shipped, and what's still unproven
The EOL hub is live in both All In and A La Carte. It replaced manual, off-platform tracking with a bulk, self-service retirement flow, resolved order-type and country routing automatically and invisibly, and built the replacement-purchase offer directly into the same flow rather than treating it as a separate journey. It's been described as stable and low-maintenance since launch.
What I can't yet say with a number attached: exactly how much replacement-purchase revenue this has driven, or how often the offer gets accepted versus declined. Those numbers exist somewhere in Mixpanel and haven't been pulled. Until they are, the honest version of the impact is qualitative: this gave clients a self-service way to retire devices in bulk and created a direct path from retirement to replacement purchases where none existed before.
Reflection
What the platform had to absorb so the client didn't have to
The mostThe hardest part of this project was never the disposition logic on its own. It was deciding what the platform should figure out silently versus what should stay a visible choice for the client. Every one of the key decisions here, order-type routing, country splitting, the upsell placement, follows the same underlying instinct: push complexity into the system, not onto the person using it.
If I kept going, I'd want real adoption and conversion numbers before citing any figure publicly, and I'd want to run an actual usability study on the EOL hub itself, since the validation it's had so far has been architectural consistency, not direct observation of someone using it. I'd also want to know whether clients understand why some destinations are free and others are priced or quoted, since that's exactly the kind of thing that reads as confusing in a support ticket and invisible in a design review.