Five patterns determine how well a recovery program works.
These five patterns didn't start as a framework. They started as mistakes: at a leading mobile OEM, at a major device protection insurance company, and across the trade-in and recovery programs built, run, and advised on along the way. The same failure modes kept showing up. These five principles are what fixed them. TICE Group is a managed recovery orchestration company: it designs and operates recovery systems instead of selling software to run them.
Every engagement TICE runs starts with the same diagnostic, the TICE Recovery Diagnostic. Which variable is the system actually solving for? Where does value leak between vendors? Where is the system brittle? The answers almost always trace back to one or more of five structural patterns: patterns that showed up consistently across OEM trade-in programs, carrier recovery operations, and retailer returns flows.
These principles govern how TICE diagnoses, designs, and operates recovery programs. They're the operational logic that determines whether a program creates value or quietly bleeds it. If you run reverse logistics, returns, trade-in, ITAD, or resale operations, at least one of these failure modes is likely present in your current flow.
One more thing: no partner is best at everything. The five principles below are how we decide which specialist gets which slice. Auditable decisions. Handoffs accountable to you. No black box on the economics.
Net Recovery as North Star
Key Principle
The constraint that determines whether a recovery system works isn't speed, cost, or control. It's time-adjusted, risk-adjusted net recovery value.
Where this goes wrong
At Samsung, the very beginning of the first OEM-led trade-in program, we had one rule: no inventory at month close. Finance was nervous. Competitors' phones on the balance sheet was a non-starter. So I resold fast: manual, messy, low recovery. But at the end of every month, the inventory was gone. Metric hit. Dashboards clean. Everyone moved on. The system was working exactly as designed. That was the problem. I was optimizing for optics. Finance wanted zero visible inventory risk. Operations wanted speed. Both were measurable, both felt safe, and neither reflected the variable that actually determined whether the program worked: net recovery value after all costs. Most brands running fragmented programs settle at 15 to 30 cents on the dollar without ever realizing it. The metrics they tracked never told them what they were leaving on the table.
What changed
The fix wasn't working harder. It was solving for a different variable. Once I reframed trade-in as marketing cost, compared against the BOGO promotions standard at the time, Finance became real partners. The North Star changed from clear fast to recover well. The system followed.
The physics of holding inventory:
Used inventory drops roughly 1% per week in mobility. A $300 device held six weeks is worth $282. Add storage, insurance, and a 12% cost of capital, and you need to sell for $304.50 just to break even: nearly 10% above market.
A 30-day flow at $270 beats a 90-day hold at $300 almost every time. The first recycles capital twelve times a year. The second, four. At 5% margin per turn, twelve turns yields 60% annualized return. Four turns would need 15% per transaction just to keep pace. Same inventory. Different physics.
If someone asked what variable your recovery system optimizes for, would the honest answer be net recovery value, or speed, cost, and dashboard optics?
Flow Integrity over Vendor Management
Key Principle
The enemy isn't bad vendors. It's broken seams. Everyone owns a piece. No one owns the flow.
What fragmentation actually looks like
What most teams call "vendor orchestration" is really patchwork: separate vendors for trade-in, grading, resale, and recycling, tied together with a thin reporting layer. Each vendor is optimized for its own slice. No one owns the whole flow. That isn't orchestration. It's fragmentation dressed up as strategy.
The champion and the challenger
At Samsung, we had two processing vendors. One was the champion: speed, consistency, trust. The other was the challenger, rough around the edges, but hungry. Over eighteen months, the champion started drifting. They tried to upsell repair services where the economics worked for them, not the system. Shipping performance slipped: nothing dramatic, just slower, more exceptions, more noise. Their executives said the right things in meetings but stayed in their offices. The orders never reached the people actually moving inventory. They were still hitting their internal targets. They just weren't performing on the axis that mattered to the system. Meanwhile, the challenger wasn't trying to expand scope. They were trying to get better. When something broke, they fixed it on the floor. Their leadership showed up in the warehouse. We shifted volume. The champion drifted. The challenger compounded.
Where value actually leaks:
In a fragmented flow, 5–7 handoffs typically produce 5–10% value loss at each transition. Vendors prioritize their own margins. Idle time, lag, and opacity compound the damage. A device that starts at 100% consumer price can exit the flow at 20% of original value: 56% lost to fragmentation, 24% to time decay.
The leak isn't at any single vendor. It's between them.
What flow integrity means in practice
Flow integrity means owning the integration points, the seams, not replacing the specialists. The best refurbisher working with the best reseller, coordinated through shared rules and aligned incentives, will outperform one vendor trying to do both. TICE's role is the layer that designs and operates that logic, so the flow holds when pressure hits.
If you traced one unit from intake to cash, how many handoffs does it cross? At each handoff, who explicitly owns the seam? If the answer is "nobody," that's where your margin is leaking.
Stability Before Speed
Key Principle
A system that absorbs noise beats a system that shatters under it. Design for reliable motion, not maximum velocity.
Where the lesson started
At BCG, we ran a mock production-line exercise building toy trucks. Each round we got faster: less motion, tighter timing, cleaner flow. Then one of us said, "let's go again, I bet we can shave another few seconds." We did. And the whole thing collapsed. We had eliminated every bit of slack. One small mistake, and the system had nowhere to go.
Where it showed up with real money
Most recovery programs default to 60 to 90-day cycles. With discipline, 30 to 45 is reachable. At Samsung, I pushed our vendors to cut cycle times from 45 days to about 30. One partner decided to keep tightening: fewer buffers, tighter batches, zero slack. It worked until something slipped. Then pick, pack, and ship went from a day to a week. Buyers started tracking which lots came from that vendor and discounting them. The other vendor's inventory? Buyers paid more for it because they knew it would ship faster. The market had figured out what we were starting to see: they'd pushed past the floor. What was left wasn't waste. It was the margin that keeps things from breaking when something goes sideways.
What stability design looks like
I later launched a trade-in program with a carrier where requirements shifted for eighteen months. Scope moved. Decisions that should have taken weeks stretched into months. On paper, exactly the kind of setup that collapses. It didn't. Not because everything went smoothly: some flows stayed manual, fixes accumulated. But when requirements changed, we didn't restart. When constraints surfaced, we didn't redesign everything upstream. When something failed, it failed locally. The seams were designed to tolerate uncertainty, not assume it away.
What happens to your system when something goes sideways? Does it absorb the shock, or does one disruption cascade across the entire flow?
Critical Path over Surface Area
Key Principle
80% of your system's results come from 20% of its components. Protect the load-bearing elements. Let the rest flex.
What happens when the wrong part breaks
At Samsung, the Note 7 battery was just one component: commodity on paper, almost an afterthought relative to the rest of the device. In practice, it turned out to be the critical constraint. When a manufacturing flaw surfaced, the failure didn't stay contained. Supply chains froze. Retail partners scrambled. Warehouses filled with unsellable inventory. Customer confidence evaporated. The lesson was clear: if you don't know which parts of your system are load-bearing, you're not just risking throughput. You could take the whole program down.
The overdesign trap
The trap is overdesigning the elegant parts: shiny dashboards, innovation moments, the pieces leadership talks about, while neglecting the unglamorous ones that quietly hold everything up. An underpaid warehouse team. A key API. A margin threshold buried in pricing logic. These carry the weight. When they hold, everything flows. When they crack, everything stops.
Assumption debt
We built a "perfect" integration once. Every edge case mapped, every exception planned for, every unlikely scenario accounted for. Then we turned it on. It took months to stabilize. The labor cost alone, just for my company, was easily $200K. The partner's side was similar. Break-even got pushed back by over a year. The system was too rigid to bend when reality showed up. We had accumulated what I now call assumption debt: a system that only works if every guess made upfront was right. Start simple. Protect the critical path. Let the non-critical components be good enough until proven otherwise.
Can you name the three components in your recovery flow that, if they broke, would stop everything? If you can't, you don't have a system. You have a collection of parts.
Structural Memory
Key Principle
Systems that encode lessons beat people who remember them. If it wouldn't run without you, it's not a system. It's a performance.
What structural amnesia looks like
"We fixed this already." Those four words should be a relief. Instead, they're usually a warning, because if you're hearing them now, something just broke the same way it did last year. Teams solve the same problem three times in eighteen months. Each time with urgency, creativity, and good thinking. The problem isn't the solution. The problem is that none of the solutions stick. No embedded reflex. Just people hoping they'll remember next time. That's not a knowledge gap. It's structural amnesia.
How lessons get lost
In one sales operation, we'd build trust with a prospect, tailor the pitch, respond to an RFP. On paper, polished. But mostly ad hoc. We reused decks without tracking what landed or what backfired. One case study slide kept getting questioned in meetings. We meant to revise it. We never did. The confusion repeated. The deal didn't close. Post-mortem, good insights, good intentions, then the same playbook, the same gaps, the same result.
What structural memory looks like when it works
Another team turned every major breakdown into a constraint. They updated onboarding to surface the trap early. Revised launch gates to force the missing decision. Shifted budget logic to match real ownership flow. They didn't just document lessons: they rewired how the system moved. Six months later, the same risk resurfaced and got caught mid-motion. The people were new. The system remembered. At Samsung, the trade-in program worked because we treated it like a product from day one. Recovery margin targets locked before launch. Grading logic embedded at intake. Real-time resale data shaping offer logic. It wasn't perfect. But it ran without me in the room. That's the only test that matters.
Where does memory currently live in your recovery operation: in people's heads, or in the system itself? What lesson have you solved for, but not yet embedded?