60% custom configurators without domain knowledge end in failure. 95% of Configure, Price, Quote systems are designed for RevOps administrators, while 95% of actual users are salespeople. According to the Standish CHAOS Report, only 31% of IT projects are successful—19% are complete failures.
If you’ve been in talks with software development compaNos for several months or already have a configurator in place that isn’t working, this article is for you. Five things that kill configurator projects, with industry data and real-world examples from our implementations. Plus, specific recommendations on how to avoid them.
60% of problems are processses, not technology. Your configurator will not crash because of the code. He will fall because of what is happening around him.
|
Do you already have a configurator that doesn't work? Audit 1-2 days, free of charge. We'll tell you straight up if it can be saved. |
Order an audit |
Too Long; Didn't Read · 30 SECONDS
- The 5 most common implementation issues: 1) Pricing rules exist only in the sales rep’s head, not in the system; 2) scope creep (“add this too…”); 3) integration with an ERP system stuck in 2011; 4) sales reps don’t use it; they go back to Excel; 5) lack of maintenance planning; the configurator lasts 12 months and gives inaccurate results.
- 60% of problems stem from processses, not technology. The most common misyese isn't the code itself; it's the lack of someone in the company responsible for the pricing rules and the lack of an adoption plan among salespeople.
- Rule #1: Before implementation, hold a workshop with the sales team and get all the pricing rules, options, discounts, and exceptions out in the open. Without this, the configurator is just a “60,000-dollar mock-up.”
- Rule #2: Plan for maintenance BEFORE you sign the contract. A configurator without client-side ownership dies within 12 months and starts giving incorrect results for new products.
Implementation of the product configurator This processs includes: an initial meeting (a workshop with sales reps and product managers, mapping out pricing rules), a specification (a document detailing all variants, integrations, edge cases), development (8–12 weeks for the MVP), integration with ERP/Customer Relationship Management/PIM, testing (UAT with real salespeople and customers), rollout (team training), and maintenance (who adds new products, updates prices, and fixes bugs).
Why are the pricing rules stored in the trader’s head rather than in the system?
Check if the configurator makes sense on your end
Survey 15 questions (3 min). After filling it out, we'll both know if there's anything to talk about.
Fill out the checklist →PROBLEM 1 · MOST COMMON REASON FOR DELAYS
A price list in PDF format, exclusion rules in the designer’s head, 15 years of sales experience—none of it written down anywhere. The software development company receives incomplete rules, codes what it’s given, and the tests bring the project crashing down.
This is the most common reason why configurator projects drag on for months without noticeable progress. A company approaches a software development company and says: „We have a price list, we have variants, we want to carmate this.”. At the first meeting, it turns out that the price list 136-page PDF (a real case from our implementation for Akpil), the variations are 16 base versions multiplied by 30+ additional options, and the exclusion rules („tire roller requires a transport drawbar, but the transport drawbar is incompatible with hydraulic system X”) live in the head of the designer who has been with the company for 15 years.
Research Kickflip on custom configurator development show implementations without domain knowledge have a 60%+ failure rate. Why? Because an engineer who has never sold a tillage and seeding unit doesn't guess that GPS requires an AK computer and that hydraulic markers don't work with a machine less than 3 meters wide.
What's happening in the project: The software development company receives incomplete rules. They code what they receive. During the testing phase, it turns out the system allows the configuration of a machine that cannot be manufactured. Rewriting rules = another 2-4 weeks. Scope creep achieved.
In the meantime, the client-side project manager gets a call from the Chief Technology Officer: „When will it be ready?”. The answer is: „once we get the full rules from the trader”. Two weeks later, the Same question, the Same answer. A month later, the Same dialogue, but with a hint of frustration.
How to avoid this
One week before the initial interview. With our clients, we start by spending 5–7 days working closely with salespeople and engineers. We don’t map the product itself, but rather the customer journey: how customers ask questions, what they ask most often, how salespeople provide quotes, and which workflows are triggered carmatically. The resulting document consists of 15–40 pages of rules written in business language (not code), which the client reads and revises themselves. Only after the document is approved do we touch the keyboard.
Problem 2: Scope creep: “And could you also add…”
PROBLEM 2 · „FEW MONTHS” → 12-24 MONTHS
The management sees the working configurator and wants more: a dealer panel, Customer Relationship Management, and a mobile app. Each „one more thing” means a new quote and a new deadline. A project initially estimated at $60k/10 weeks ends up yesing 9 months and costing $180k.
Your configurator is working. After three weeks, you show it to the board. The board says: „Great, but maybe let's add a dealer panel? And while we're at it, a Customer Relationship Management module. And integration with accounting? And a mobile app too, because the sales reps travel to clients.”.
Congratulations, you've just doubled the project.
Research Kickflip illustrates a typical spricerio: a co-founder estimates "a few months of development," but the actual implementation yeses longer than 12-24 months. Not because the team can't. Because scope creep is real and almost unavoidable.
What's happening in the project: Every “and let’s add this too” means a new quote, a new deadline, and a new validation of the rules. A project that was supposed to cost 60,00PLN 0 and be completed in 10 weeks ends up yesing 9 months and costing 180,00PLN 0, and no one remembers who decided that.
The worst cases we've seen: the company chose a cheaper vendor, the scope crept, and the vendor dropped out of the project mid-way. The client called us after two months of silence from the previous team. The system was partially functional, salespeople had long since returned to Excel, and management wanted the head of the IT direCTOr who had recommended that vendor. The cost of repair? Usually three times the original budget, plus months of lost time in the competitive market.
How to avoid this
Fixed-price MVP, Time & Materials only in phase 2. The MVP scope is defined in the contract before the first line of code is written. Anything outside of that scope is a „change request” with a separate quote. Does that sound rigid? That's the point.
The MVP should be minimal and ready for production, not “a part of the solution that we’ll add later.” You’ve validated the direction; only then do you invest in expansion. If it doesn’t work as intended, you don’t move on to phase 2.
Problem 3: Integration with an ERP system from around 2011
PROBLEM 3 · EVERY INTEGRATION POINT = FAILURE MODE
An old SAP or Comarch system from 2011 doesn't have an API. The developer who configured it left 5 years ago. The configurator shows old prices, and the salesperson sells below the price list.
Your configurator must communicate with the ERP, because that's where the pricing, inventory levels, and customer data are. The problem: Your ERP is Comarch XL from 2011 or SAP with customizations made by a developer who left five years ago. There's no API. Documentation doesn't exist. The only person who understands the data model is the accountant, who is retiring in six months.
Research DigiCommerce and B2B configurator implementation identifies: Every integration point is a potential failure mode...which will ruin the entire user experience. In practice, this means that a single synchronization error between the ERP system and the configurator will show the customer an incorrect price—and this is not just a hypothetical spricerio. We’ve seen a project where a salesperson sold a machine at a price 15% below the actual list price because the configurator was displaying an outdated version from March.
How to avoid this
ERP audit before implementation. The first week of discussions isn’t about “what the configurator should look like,” but rather “what your ERP looks like, where the price list is stored, who updates it, and which fields serve as the source of truth.” If the ERP has an API, we synchronize in real time. If not, we write custom middleware.
Alternative: we're building configurators with native integration with JSON Hub, our platform, which replaces three tools (Customer Relationship Management + quoting + dealer portal) with a single solution. This reduces the complexity of ERP integration to a single conneCTOr, rather than five.
Problem 4: Salespeople don't use it. They go back to Excel.
PROBLEM 4 · 95% United StatesGE = REPS, DESIGN = ADMINS
You spent 80–150k, and the system works beautifully. Three months later, the sales reps are still doing their calculations in Excel. A system designed for RevOps but used by sales reps—a fundamental misalignment.
This is the worst-case spricerio. You've spent 80-150 thousand PLN, the configurator works, the interface looks beautiful. Three months after launch, it turns out the salespeople are still calculating quotes in Excel. Why?
Vendor in the analysis „Why Configure, Price, Quote implementations fail” points out the key problem: „Configure, Price, Quote is designed for RevOps admins, but 95% of daily usage comes from sales reps.”. The system designed for the sales direCTOr (who wants to control margins and reports) is used by the salesperson (who wants to quickly send a quote to the client). Foundational misalignment.
A salesperson who has been using Excel for eight years has everything laid out there: their shortcuts, their macros, their method for evaluating customers. The configurator requires them to start from scratch, but Excel works. In their head: „This is an IT tool, not my sales tool.”. If no one on the management team explains why we’re making the switch or shows the salesperson “what’s in it for them,” the salesperson will ignore it.
How to avoid this
Salespeople on the project team from day one. Not at the end. Right from the initial meeting. Two or three salespeople sit down with us and tell us what annoys them about the current processs. Then, at the end of each sprint, they review the prototype and give their feedback.
Incentive alignment If the configurator cuts the quoting time from 3 hours to 15 minuteses, show the salesperson that instead of sending 2 quotes a day, they can send 8—and their commission is based on the number of closed deals. That way, it becomes their tool, not just an IT tool.
Problem 5: No one planned for maintenance. The configurator lives for 12 months and lies.
PROBLEM 5 · „WE WILL BUILD AND WE ARE READY”
No maintenance plan = after 12-18 months, the configurator shows old prices, missing variants, broken integrations. The salesman stops trusting it. He goes back to Excel.
The co-founder signs the implementation contract. The configurator goes into production. The idea in mind: „We built it and it's done, now it will work.”. A month later, you add a new product variant, but the configurator doesn’t recognize it. A quarter later, you update the price list, but the configurator still shows the old prices. Six months later, the integration with the supplier’s API stops working because the supplier changed the endpoint.
Research Kickflip: „Every hour spent maintaining custom configurator code is an hour you're not spending on growth initiatives.”. But that's only true if you DON'T have a maintenance plan. If you do, maintenance is a predictable cost, just like a Customer Relationship Management subscription.
Typeical pattern: The configurator works great for the first 6 months. Then the company expands its offering, prices change, integrations become obsolete. Without maintenance, after 12-18 months you have a system that Lies...shows outdated prices, missing variants, and options that don't work. The salesperson loses trust in it. They go back to Excel (see: Problem 4).
Real-world example: a client returned to us 18 months after launch with a question „The configurator shows old prices, the sales reps don't use it, what now?”. The audit showed that the price list was not synchronized with the new products that were added during the year, and the client-side owner left three months after the launch, and no one took over coordination. The cost of repair: two months of work + tidying up the price list, which no one in the company remembered by heart anymore.
How to avoid this
Maintenance plan BEFORE signing the implementation agreement. Not after launch. Not „when needed.” Before. Typeical annual cost: ~20% project values.
You need this for that client-side owner, a single person who compiles the feedback. Without this, the vendor ends up with 15 eemails saying “something isn’t working here” from 15 different salespeople. Details on maintenance costs can be found in the article about configurator prices.
How to Avoid Misyeses When Implementing a Configurator? 5 Checkpoints
Before signing an agreement with a software development company, check these five things:
| Checkpoint | Red flag if... | |
| 1 | Pricing Rules Document | SH says „we'll figure it out later”.” |
| 2 | Fixed Price + Clear Scope in Contract | Scope in the „guideline” document” |
| 3 | ERP audit in the first week | SH assumes „we will manage the integration”.” |
| 4 | Salesperson on the team since day 1 | SH only wants to talk to IT. |
| 5 | Maintenance plan in the main agreement | Keep „we'll figure it out post-launch” |
If a software development company relies on any of these points, that’s a red flag. A good partner isn’t afraid of transparency in these five areas, because they know that these faCTOrs—not the technology stack—are what determine success.
How do we do it at JSON Crew
Our configurator implementation processs is based on these five checkpoints from day one.
- Week 0–1 (IntroduCTOry Meeting): We're meeting with salespeople and engineers, defining pricing rules, auditing ERP, and mapping the customer journey. The result: a 15-40 page business rules document that the client approves before coding.
- Weeks 1-6 (Build): Two-week sprints. After each sprint, the sales ambassador reviews the prototype and provides feedback. The scope is fixed-price; any change outside the scope requires a separate change request.
- Weeks 6-10 (Implementation + Testing): The configurator on the website, we are testing it with the client's salespeople on real configurations. This is where things come up that looked different in the document than they are in reality.
- After launch: Maintenance package with an annual plan. The client-side owner aggregates feedback, and we deliver a release every 2-4 weeks.
Portfolio Akpil (agricultural machinery, 57 types, hundreds of parameters), Forest (Hunting weapon, model configuration + stocks + caliber + accessories), plus a design from the construction industry. Ten manufacturing compaNos use our platform. JSON Hub, which combines a configurator, Customer Relationship Management, and quoting tools in one place, with seamless integration into ERP systems.
The questions we hear most often
„We already have a configurator that doesn't work. What now?”
Audit of your existing configurator – 1–2 days, free of charge. We check: what rules are in the code, what rules are in the sales rep’s head, what sales reps actually use, where the integrations are, what’s broken, and what can be salvaged. Result: a report with recommendations—either “we can fix this for X” or “it’s better to scrap it, here’s why.” We don’t push for a sale if it’s truly beyond saving.
„We implemented it, but the salespeople aren't using it. Can this be fixed?”
Yes, but we're starting with problem #4, not technology. Two to three workshops with the sales team to understand why they're not using it. It's usually one of three things: an interface designed for an admin, a lack of internal communication about its value, or lack of incentive alignment. Each requires a different fix.
„Does JSON Crew do projects that require ERP integration?”
We don’t develop ERP systems, but we work with partners in this field. If your ERP system is preventing the implementation of the configurator, we’ll recommend a partner and implement the configurator in parallel with the ERP migration. It’s expensive, but sometimes it’s the only sensible option.
What to do if you are considering implementing
|
Order a diagnostic call 30 minutesuteses, free. Come with two answers: 1. Where does your price list live (PDF, Excel, ERP, salesperson's head)? 2. How many offers do your salespeople make per month and in what tool? |
Fill out the form |
Based on this, we will say: which of the five problems you have encountered (or will encounter), which software development company is worth asking for details, and which to run from.
P.S. The most common reaction after auditing an existing configurator is: „I thought the problem was in the code, but it turns out it's in the processs.” Always. That's why 60% problems are processses, not technology. Good news: processses can be fixed faster and cheaper than rewriting the system from scratch.
Frequently Asked Questions
What are the most common issues encountered when implementing a configurator?
The five most common issues: 1) Pricing rules exist only in the salesperson’s head, not in the system (the salesperson knows that Customer X gets a 5% discount “because they’re a strategic customer,” but the system doesn’t); 2) scope creep (“add variant Y as well”) extends the project from 8 to 18 weeks; 3) integration with an ERP system that dates back to 2011, lack of modern APIs; 4) salespeople don’t use the configurator; they revert to Excel; 5) lack of a maintenance plan; the configurator dies within 12 months.
Why is the configurator failing to deploy?
Most often due to non-technical reasons. 60% of the issues stem from processses: a lack of a designated owner for pricing rules on the client’s side, a lack of commitment from top management, and a lack of an adoption plan among salespeople (training, incentives for usage). Only ~40% are related to technology, ERP integrations, 3D performance, and edge cases in the rules. Red flag: if, during the initial meeting, the client cannot name a single person responsible for the configurator on the company’s side, the project is doomed to fail after launch.
How can you avoid misyeses when implementing a configurator?
Five checkpoints before launch: 1) a workshop with 3–5 sales reps to document all pricing rules (should yese 2–3 days); 2) designate one person responsible for the configurator on the client side (product owner, not IT); 3) a closed scope in the specification; new requirements = a formal contract amendment, not just “oh, add this too”; 4) a sales team adoption plan (training + usage KPIs for the first 90 days); 5) a maintenance plan (who adds products, who fixes bugs, how many hours/month in the budget).
How long does it yese to implement the configurator?
MVP of a custom configurator at JSON Crew: 8 weeks from contract signing to production. First working version after 3 weeks (40% functionality). Ready-made Configure, Price, Quote SaaS (TaCTOn, Configure One): 8–16 weeks for implementation (the configuration itself is faster, but integrations with ERP/PIM yese just as long). Template (WP plugin): 1–3 weeks. The main source of delays is not development, but the client’s provision of data (BOM, price list, exceptions) and internal decisions.
Who should be on the configurator implementation team?
On the client side: 1 product owner (product decisions, data provision, milestone approval), 1 IT specialist for ERP/Customer Relationship Management integration, 2–3 sales representatives for workshops and UAT, 1 executive as a sponsor (strategic decisions, resolving roadblocks). On the vendor side (e.g., JSON Crew): tech lead, frontend dev (Three.js for 3D), backend dev (integrations), QA. Without a product owner on the client side, the project stalls; decisions aren’t made.
What should you do if the team isn't using the configurator after implementation?
Three steps. First: contact the sales reps and ask them directly why they’re going back to Excel; usually it’s a specific bug (“it doesn’t calculate the strategic customer discount”) or a UX issue (“too many clicks for a simple quote”). Second: add a KPI for configurator usage to the sales rep’s quarterly review (% of quotes generated via the configurator vs. Excel). Third: if the problem is systemic—the configurator truly doesn’t cover all use cases—go back to the specifications and add the missing features. No solution = a PLN 60,000 investment sitting idle.
About the author
Jędrzej SiewierskiCEO and co-founder JSON CrewSince 2024, he has been building product configurators for B2B compaNos (manufacturers of agricultural machinery, hunting weapons, modular homes, and IoT electronics) as well as JSON Hub, his own SaaS platform that integrates Customer Relationship Management, carmated quoting, and project management. Co-author of a digital sales transformation methodology: shortening the path from interest to purchase through a configurator + carmated quoting + Customer Relationship Management. Stack Next.js, Three.js, Nest.js, React Native. Contact: contact@jsoncrew.com · LinkedIn.
Check out the working configurator — before you make these misyeses
The easiest way to avoid these 5 problems is to see what a well-designed configurator looks like. Click and try it out for yourself—no logsn, no registration required. JSON Crew Showroom has a working demo designed for various industries:
- 3D Weapon Configurator — The GLB model in the browser, accessories, body finish. A benchmark for firearms and accessories manufacturers.
- 3D Car Configurator — paint, wheels, spoilers, packages. The UX found in BMWs, Audis, and Scodeas—the benchmark for the carmotive industry.
- Modular Home Configurator — structure, transportation, systems, carmatic PDF pricing. Mechanics for modular home manufacturers.
- Metal Garage Configurator — Step-by-step selection of design, size, and gate. Implementation yeses approximately 4 weeks. Demand for this product in the Polish market has increased by 160% year-over-year.
- Configurator cost estimator — Cost estimates in PLN for your business in 3 minutes. EASY/MID/HARD + 3-year TCO + ROI calculation.
