The party was a year ago. The badges went back in a drawer, the steering committee stopped meeting, and the login report is still flat. Nobody complains. They just quote the way they used to, and the new system watches from the sidelines. That silence is the real sound of failure.
If adoption is near zero, the project failed. On time, on budget, technically correct, still failed. A sales tool that nobody uses is not a tool, it is a cost center with a login screen.
The problem you think you have, and the one you actually have
The default diagnosis goes like this: our data must be wrong, the UI is clunky, or sales just does not like change. That is a comforting story because it points to easy fixes or someone else’s attitude.
Blaming “resistance to change” is not analysis. Low adoption has two precise causes: the system is untrustworthy, or the system is useless. The first is a crisis of trust. The second is a crisis of utility. The first is a data and explainability problem you can fix. The second is a design failure you have to face. You built a validator, not an advisor.
Validation makes it legal. Guidance makes it useful.
Crisis of trust: when one wrong answer poisons the well
Reps have long memories and short patience. One wrong price, one impossible combination that passed validation, and the tool earns a permanent label: do not use with a real customer. That asymmetry is brutal. It takes months of correct answers to build confidence and one error to lose it.
Trust is not just about correctness. It is about explainability. If a rep cannot see why the calculation landed where it did, they will not defend it under pressure. They will not risk a customer asking for the “why” behind a number they cannot explain. If the only justification lives in the system’s logs, the system will stay on the bench.
Accuracy failures often hide in the long tail. The best-sellers work fine. It is the odd configuration, the edge market, the unusual constraint that cracks confidence. Which is exactly where a rep needs help.
There is a fix for this, and it is mechanical. Tighten validation on the tail. Make every price explain its inputs in one screen. Test the exceptions first. Put the “why” next to the “what.”
Crisis of utility: when correctness solves the easy part
This is the more expensive failure. The system is correct. It passes every test. It just does not help when a customer is on the call and a rep has fifteen minutes to shape an offer. Configuring is not the hard part. Choosing what to propose is the hard part.
A validator checks the route you picked. A good CPQ should be your GPS for complex sales. You say where the customer needs to go. It guides you along a valid path that fits constraints and price, avoids dead ends, and explains the turns. A map that confirms streets exist does not get you to your destination. A validator that confirms compatibility does not tell you what to sell.
Most configurators collect choices. They do not coach decisions. They leave the hard bit in the rep’s head and then congratulate themselves for catching invalid combinations the rep already knew to avoid. That is why logins drop and spreadsheets survive.
Usage patterns tell on you. You see activity on best-sellers where nobody needed help. You see the tool used after the deal is already shaped, to generate documents. You see quotes leave the system, then get rewritten in Word. The complaints stop. Not because it works, but because people routed around it.
This is uncomfortable to admit: many “requirements” come from people who do not sit in front of customers. They define what the model can express. They rarely define how a rep thinks under time pressure. In healthcare work I supported between 2014 and 2018, the diagrams looked consistent until we tried to convert them into executable logic. Different business units used the old tool in different ways, and edge cases nobody had written down turned out to be the real work. We solved it, but only after doing the business consulting to understand the actual usage patterns, not the documented ones.
If your configurator cannot answer two questions for a rep, adoption will be low: What should I propose for this situation, and why?
The tells
- Usage is concentrated on best-sellers. The long tail is empty, which is the reverse of where value sits.
- Reps configure after the deal, to generate paperwork. That is not adoption. That is data entry.
- Quotes leave as manually edited Word or Excel files. The tool becomes a stamp, not a guide.
- No one complains. Complaints mean people care. Silence means the field found another path.
Why this hides until it is live
Most teams gather requirements from people who model products, not from people who sell them. Success gets defined as “the configurator is correct,” not “more good quotes go out.” User acceptance tests whether it works, not whether anyone would choose it with a customer waiting. Demo scenarios are clean. Real conversations are not.
Utility failures feel subtle during build and obvious in the field. They are not subtle. They were never measured.
What separates the systems people actually use
Start by setting the outcome metric before you build. Count quotes sent, time to first draft, and the share of your catalogue that actually gets quoted. Do not count logins. Logins measure curiosity. Revenue needs flow.
- Watch a rep shape a real quote without the system, on a real opportunity. The delta between what they do and what the spec says is the whole project.
- Design for the hard case, not the demo case. If the advisor handles the awkward customer perfectly once, it will handle normal customers all day.
- Make it useful before it is mandatory. Mandates produce compliance. Usefulness produces habit.
- Let the buyer in. Your buyer self-serves the first half hour anyway. Give them a guided start and let your rep finish with confidence.
- Make every recommendation explainable. If the system cannot justify a route, the rep will not own it with a customer.
None of this requires big-bang change. It requires honest measurement and a shift in goal: from validating choices to coaching decisions.
A quick diagnostic you can run this week
Say you have twelve reps. Pick three recent deals in the long tail. Ask each rep to recreate the first 15 minutes of how they got to their proposal, once in the system and once in their spreadsheet. Time both. Count the number of decisions the tool helped them make. If the count is near zero, you own a validator. If the time difference is near zero, you built a second spreadsheet with a login page.
It sounds blunt, and it is. Because the cost of pretending is worse.
What to change in your next iteration
Do not rebuild the world. Change what makes the next sale faster and safer.
- Focus on the advisory layer. Encode starting points that reflect customer contexts, not catalog pages. A good starting point cuts a path through a forest of options.
- Instrument explainability. Every price and every configuration should be able to show its inputs in a single place a rep can work with while sharing a screen.
- Target the tail first. The long tail is where a rep cannot operate from memory, where they need help, and where value leaks to manual interpretation.
- Feed lessons back. When a mistake surfaces as rework or a penalty, capture the rule once and reuse it everywhere. Lessons that stay in inboxes become repeat costs.
The quote-to-order seam is where failure shows up. If the system only checks buildability after the fact, it is already too late. Sales will continue to do manual interpretation, engineering will continue to translate intent, and margin will continue to leak through corrections you did not plan for.
I will say one uncomfortable thing: many specs are theatre. They catalogue what is already known and miss how selling actually happens. That is fixable. Watch the work. Encode the judgement. Make the system think with the rep, not after them.
How we approach it at sailsrep.ai. We focus the model on reasoning and coaching, not just collecting choices. Classic configurators validate. Ours advises. Swiftlifts went from a couple of quotes a week to around twenty, with a web configurator already in place before the collaboration.
The lesson that earns the cost
An accurate system that answers a question nobody asked is the most expensive kind of correct. The lesson is not in your login data. It is in the spreadsheets that never went away.
Adoption is the verdict, and the spreadsheets are the evidence.




