The $125M order system reps refused to use

In 2013, Avon halted the global rollout of a new order management system after a single pilot in Canada and took a pretax charge of $100–125 million. The software was not, strictly, broken — the vendor's line was that it ran as designed. But it modelled a process, not how a rep places an order, and an estimated 16,000 Canadian reps stopped selling rather than fight it. Order-capture usability is the adoption mechanism, and adoption is the business case.

What actually failed at Avon?

Two things that get collapsed into one. SAP's public position was that its part of the stack, the ERP and CRM behind the site, had been running as designed for months, and that was probably true. The order-taking front end, built on IBM WebSphere e-commerce software, was a different story: reps reported they often could not log in, that the site did not reliably save orders or reserve inventory, and that placing a routine campaign order now took more steps than the paper process it replaced. The honest diagnosis is not "the software was buggy" or "the UX was bad." It was both, and each made the other unforgivable.

The detail that makes Avon the canonical case is who the users were. Its salespeople are independent representatives, some 6 million of them worldwide, not employees who can be ordered to adopt a tool. A captive-staff ERP can ship rough and survive because the pain stays inside the building. When your primary user can walk away without asking anyone's permission, friction stops being a satisfaction score and becomes a churn rate. Under one Canadian sales leader, more than a third of her 300 reps quit; across the country the estimate reached around 16,000. The pilot did not surface a usability complaint. It surfaced a sales channel switching itself off.

Why did a passing pilot still destroy the business case?

Because the pilot was read as a go-live readiness gate rather than a behavioural experiment. A readiness gate asks: did it deploy, did the data flow, did the queue of tickets come down? Argued narrowly, the Canada pilot could be pushed toward a pass. A behavioural experiment asks something the gate never does: are reps completing more orders, faster, with less abandonment than on the channel they had before? On those questions the pilot was screaming, and the screaming was logged as launch noise. Avon's own chief executive later conceded that the direct-selling model struggled to absorb abrupt, big-bang field changes of this kind — the same finding the pilot had already delivered, arriving a write-off too late.

Every one of those signals had an innocent reading available on launch day, and that is precisely the trap. Rollout programs are engineered to absorb early friction and push through; the reflex is "reps will adjust." Sometimes they do. Sometimes the quantity that adjusts is the number of reps still ordering, and by the time that is undeniable the write-off is an accounting formality. The value was destroyed months earlier, at the moment the negative signal was re-labelled as noise.

Why do capable teams keep shipping order systems reps won't touch?

Rarely incompetence; usually structure. By the time a pilot reveals that the order flow fights the task, fixing it is no longer a bug fix — it is a change request against a frozen design. Because every discovered dependency generates an invoice, real financial gravity pulls the program toward "it works as designed, ship it." Reworking the core interaction late is the single most expensive thing you can ask a fixed-scope integrator to do, so the cheapest line on paper is to reclassify the friction as a training problem. Avon carried the software as a capital asset; the roughly $125 million invested since 2009 is exactly what a program protects by refusing to reopen the design.

The other half is that the people who knew how reps actually order were seldom in the room when the design froze. Field knowledge is tacit, seasonal and unglamorous, and it tends to evaporate on the way into a program — the same failure mode as when knowledge transfer decks become where context goes to die. A slide can capture the order schema. It cannot capture that a rep places twenty small orders a week on a weak connection, between other commitments, and abandons anything that takes more than a few taps.

What does this mean for a route-to-market platform?

Order capture is the highest-frequency, lowest-tolerance surface in the entire route-to-market stack. It is touched thousands of times a day by users optimising their own time, not yours, and every other module — stock, pricing, returnables, settlement — exists to serve that one interaction, not the reverse. Treating it as a thin form bolted onto the "real" back end inverts the priority, which is how a technically compliant system ends up with no one placing orders through it. It is also why a transformation is better judged on adoption evidence than on cutover theatre, the same lens we applied to reading a €1B, four-market transformation honestly.

The fix direction is narrow and unglamorous: instrument the pilot for behaviour rather than deployment. Track time-to-order, mid-flow abandonment and rep retention against the old channel, publish them beside the go-live checklist, and agree in advance which of those numbers are stop conditions rather than slides to be explained away. If a pilot cannot fail on a usability metric, it is not measuring the thing that actually sank Avon.

The reps who left in 2013 did not file a defect report; they made a rational call that the tool cost them more than it returned. As order capture moves onto phones held by people who never signed an employment contract — distributors, wholesalers, independent outlet owners — that calculation gets faster and less forgiving. The next order system written off will not fail because the software was wrong. It will fail because the abandonment numbers were sitting in a pilot, correctly measured, and someone shipped anyway.