60% custom configurators without domain knowledge end in failure. 95% systemów CPQ jest zaprojektowanych dla administratorów RevOps, podczas gdy 95% realnych użytkowników to handlowcy. Według Standish CHAOS Report tylko 31% projektów IT kończy się sukcesem – 19% to totalna porażka.
If you've spent months talking to software houses or have a configurator already implemented that isn't working, this article is for you. Five things that kill configurator projects, with industry data and real examples from our implementations. And concrete recommendations on how to avoid them.
60% problemów to procesy, nie technologia. Twój konfigurator nie padnie przez kod. Padnie przez to, co dzieje się wokół niego.
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 |
Problem 1: Pricing rules live in the trader's head (not 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.
PROBLEM 1 · MOST COMMON REASON FOR DELAYS
Price list in PDF, exclusion rules in the constructor's head, 15 years of sales experience – nowhere written down. Software house gets incomplete rules, codes what it has, tests flip the project.
This is the most common reason why configurator projects drag on for months without noticeable progress. A company approaches a software house and says: „We have a price list, we have variants, we want to automate 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 house 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 CTO: „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
Discovery week BEFORE the first line of code. With our clients, we start with 5-7 days of sitting with sales representatives and engineers. We map not the product, but the customer journey: how the customer asks, what they ask most often, how the sales representative prices, what dependencies are triggered automatically. The output document is 15-40 pages of rules in business language (not code) – the client reads and corrects it themselves. Only after the document is approved do we touch the keyboard.
Problem 2: Scope creep — „and let's add this...”
PROBLEM 2 · „FEW MONTHS” → 12-24 MONTHS
The management sees the working configurator and wants more: a dealer panel, CRM, 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 taking 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 CRM 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 shows a typical scenario: founder assumes „a few months of development,” actual implementations stretch to 12-24 months. Not because the team can't. Because scope creep is real and almost unavoidable.
What's happening in the project: Every „let's add one more thing” means a new quote, a new deadline, a new rule validation. A project that was supposed to cost PLN 60,000 and finish in 10 weeks ends up after 9 months for PLN 180,000 – and no one remembers who decided it.
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 wasted time on 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 we'll add later.” You validate the direction – only then do you invest in expansion. It doesn't work as intended – you don't do 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 UX. In practice, this means that one broken price synchronization between the ERP and the configurator will show the customer an incorrect price – and this is not hypothetical. We saw a project where a salesperson sold a machine 15% below the real price list because the configurator showed an old version from March.
How to avoid this
ERP audit before implementation. The first week of discussion is not about „how the configurator should look,” but „what your ERP looks like, where the pricing is stored, who updates it, and which fields are the source of truth.” If the ERP has an API, we'll synchronize in real-time. If not, we'll write custom middleware.
Alternative: we're building configurators with native integration with JSON Hub – Our platform, which replaces three tools (CRM + quoting + dealer panel) with one. Then the problem of integration with ERP is reduced to one connector, not five.
Problem 4: Salespeople don't use it. They go back to Excel.
PROBLEM 4 · 95% USAGE = REPS, DESIGN = ADMINS
You spent 80-150k, the system works beautifully. After 3 months, salespeople are still calculating in Excel. A system designed for RevOps, used by salespeople – a fundamental misalignment.
This is the worst-case scenario. 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 CPQ implementations fail” points out the key problem: „CPQ 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). Fundamental misalignment.
A salesperson who has been using Excel for 8 years has everything laid out there: their shortcuts, their macros, their way of evaluating customers. The configurator requires them to learn all over again – and Excel works. In their head: „This is an IT tool, not my sales tool.”. If no one on the board explains why we're changing and shows „what's in it for me” – the salesperson will ignore it.
How to avoid this
Salespeople on the project team from day one. Not at the end. From the very discovery. Two or three salespeople sit with us and tell us what annoys them about the current process. Then, on every sprint, they look at the prototype and comment.
Incentive alignment If a configurator shortens the quoting time from 3 hours to 15 minutes, 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. This is then their tool, not IT's.
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 founder signs the implementation agreement. The configurator goes into production. Assumption in mind: „We built it and it's done, now it will work.”. A month later, you add a new product variant – the configurator doesn't recognize it. A quarter later, you update the price list – the configurator shows old prices. Six months later, the integration with the supplier's API stops working because that supplier changed the endpoint.
Research Kickflip: „Every hour spent maintaining custom configurator code is an hour you're not spending on growth initiatives.”. But this is only true if you DON'T have a maintenance plan. If you do – maintenance is a predictable cost like a CRM subscription.
Typical 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 old prices, missing variants, non-working options. The salesperson stops trusting it. Returns 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. Typical annual cost: ~20% project values.
You need this for that client-side owner – one person who aggregates feedback. Without this, the provider receives 15 email inboxes with „something isn't working here” from 15 different salespeople. Details of maintenance costs in the article about configurator prices.
Summary: 5 checkpoints before deployment
Before signing an agreement with a software house, 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 house is weak in any of these areas, it's a red flag. A good partner isn't afraid of transparency in these five areas because they know these are what determine success, not the tech stack.
How do we do it at JSON Crew
Our configurator implementation process is based on these five checkpoints from day one.
- Week 0-1 (Discovery): 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 merchant-ambassador reviews the prototype and provides feedback. The scope is Fixed Price - any change outside the scope is 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 companies use our platform. JSON Hub, which combines a configurator, CRM, and quoting in one place – without integration issues with ERP.
The questions we hear most often
„We already have a configurator that doesn't work. What now?”
Audit of the existing configurator – 1-2 days, free of charge. We will check: what rules are in the code, what rules are in the salesperson's head, what salespeople actually use, where integrations are, what is broken, what can be saved. Result: report with recommendation – either „we will save it for X” or „it's better to scrap it, here's why.” We do not pursue sales if it cannot realistically be saved.
„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 do ERP, but we cooperate with partners in this field. If your ERP is a bottleneck for implementing a configurator, we'll recommend a partner and implement the configurator in parallel with the ERP migration. It's expensive, but sometimes the only sensible way.
What to do if you are considering implementing
Order a diagnostic call 30 minutes, 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 house 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 process.” Always. That's why 60% problems are processes, not technology. Good news: processes can be fixed faster and cheaper than rewriting the system from scratch.
