{"id":1537,"date":"2026-04-16T10:02:23","date_gmt":"2026-04-16T08:02:23","guid":{"rendered":"https:\/\/jsoncrew.com\/?p=1537"},"modified":"2026-04-17T19:07:29","modified_gmt":"2026-04-17T17:07:29","slug":"5-configuration-implementation-problems","status":"publish","type":"post","link":"https:\/\/jsoncrew.com\/en\/2026\/04\/16\/5-problemow-wdrozenia-konfiguratora\/","title":{"rendered":"5 most common problems when implementing a configurator and how to avoid them"},"content":{"rendered":"

60% custom configurators without domain knowledge end in failure.<\/strong> 95% system\u00f3w CPQ jest zaprojektowanych dla administrator\u00f3w RevOps, podczas gdy 95% realnych u\u017cytkownik\u00f3w to handlowcy. Wed\u0142ug Standish CHAOS Report tylko 31% projekt\u00f3w IT ko\u0144czy si\u0119 sukcesem \u2013 19% to totalna pora\u017cka.<\/em><\/p>\n

\n\"The
\n<\/figure>\n

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.<\/p>\n

<\/p>\n

\n

60% problem\u00f3w to procesy, nie technologia. Tw\u00f3j konfigurator nie padnie przez kod. Padnie przez to, co dzieje si\u0119 wok\u00f3\u0142 niego.<\/p>\n<\/div>\n

<\/p>\n\n\n
\n

Do you already have a configurator that doesn't work?<\/p>\n

Audit 1-2 days, free of charge. We'll tell you straight up if it can be saved.<\/p>\n<\/td>\n

\nOrder an audit<\/a>\n<\/td>\n<\/tr>\n<\/table>\n

Problem 1: Pricing rules live in the trader's head (not in the system).<\/h2>\n

<\/p>\n

\n
Configurator<\/div>\n

Check if the configurator makes sense on your end<\/h3>\n

Survey 15 questions (3 min). After filling it out, we'll both know if there's anything to talk about.<\/p>\n

Fill out the checklist \u2192<\/a>\n<\/div>\n

<\/p>\n

\n

PROBLEM 1 \u00b7 MOST COMMON REASON FOR DELAYS<\/p>\n

Price list in PDF, exclusion rules in the constructor's head, 15 years of sales experience \u2013 nowhere written down. Software house gets incomplete rules, codes what it has, tests flip the project.<\/p>\n<\/div>\n

This is the most common reason why configurator projects drag on for months without noticeable progress. A company approaches a software house and says: \u201eWe have a price list, we have variants, we want to automate this.\u201d<\/em>. At the first meeting, it turns out that the price list 136-page PDF<\/strong> (a real case from our implementation for Akpil), the variations are 16 base versions multiplied by 30+ additional options, and the exclusion rules (\u201etire roller requires a transport drawbar, but the transport drawbar is incompatible with hydraulic system X\u201d) live in the head of the designer who has been with the company for 15 years.<\/p>\n

Research Kickflip on custom configurator development<\/a> show implementations without domain knowledge have a 60%+ failure rate<\/strong>. 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.<\/p>\n

What's happening in the project:<\/strong> 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.<\/p>\n

In the meantime, the client-side project manager gets a call from the CTO: \u201eWhen will it be ready?\u201d<\/em>. The answer is: \u201eonce we get the full rules from the trader\u201d<\/em>. Two weeks later, the same question, the same answer. A month later, the same dialogue, but with a hint of frustration.<\/p>\n

<\/p>\n

\n

How to avoid this<\/p>\n

Discovery week BEFORE the first line of code.<\/strong> 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) \u2013 the client reads and corrects it themselves. Only after the document is approved do we touch the keyboard.<\/p>\n<\/div>\n

Problem 2: Scope creep \u2014 \u201eand let's add this...\u201d<\/h2>\n

<\/p>\n

\n

PROBLEM 2 \u00b7 \u201eFEW MONTHS\u201d \u2192 12-24 MONTHS<\/p>\n

The management sees the working configurator and wants more: a dealer panel, CRM, and a mobile app. Each \u201eone more thing\u201d means a new quote and a new deadline. A project initially estimated at $60k\/10 weeks ends up taking 9 months and costing $180k.<\/p>\n<\/div>\n

Your configurator is working. After three weeks, you show it to the board. The board says: \u201eGreat, 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.\u201d<\/em>.<\/p>\n

Congratulations, you've just doubled the project.<\/strong><\/p>\n

Research Kickflip<\/a> shows a typical scenario: founder assumes \u201ea few months of development,\u201d actual implementations stretch to 12-24 months<\/strong>. Not because the team can't. Because scope creep is real and almost unavoidable.<\/p>\n

What's happening in the project:<\/strong> Every \u201elet's add one more thing\u201d 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 \u2013 and no one remembers who decided it.<\/p>\n

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<\/strong> \u2013 plus months of wasted time on the competitive market.<\/p>\n

<\/p>\n

\n

How to avoid this<\/p>\n

Fixed-price MVP, Time & Materials only in phase 2.<\/strong> The MVP scope is defined in the contract before the first line of code is written. Anything outside of that scope is a \u201echange request\u201d with a separate quote. Does that sound rigid? That's the point.<\/p>\n

The MVP should be minimal and ready for production<\/strong> \u2013 not \u201ea part of the solution we'll add later.\u201d You validate the direction \u2013 only then do you invest in expansion. It doesn't work as intended \u2013 you don't do phase 2.<\/p>\n<\/div>\n

Problem 3: Integration with an ERP system from around 2011<\/h2>\n

<\/p>\n

\n

PROBLEM 3 \u00b7 EVERY INTEGRATION POINT = FAILURE MODE<\/p>\n

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.<\/p>\n<\/div>\n

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.<\/p>\n

Research DigiCommerce and B2B configurator implementation<\/a> identifies: Every integration point is a potential failure mode<\/strong>, 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 \u2013 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.<\/p>\n

<\/p>\n

\n

How to avoid this<\/p>\n

ERP audit before implementation.<\/strong> The first week of discussion is not about \u201ehow the configurator should look,\u201d but \u201ewhat your ERP looks like, where the pricing is stored, who updates it, and which fields are the source of truth.\u201d If the ERP has an API, we'll synchronize in real-time. If not, we'll write custom middleware.<\/p>\n

Alternative: we're building configurators with native integration with JSON Hub<\/a> \u2013 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.<\/p>\n<\/div>\n

Problem 4: Salespeople don't use it. They go back to Excel.<\/h2>\n

<\/p>\n

\n

PROBLEM 4 \u00b7 95% USAGE = REPS, DESIGN = ADMINS<\/p>\n

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 \u2013 a fundamental misalignment.<\/p>\n<\/div>\n

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?<\/p>\n

Vendor in the analysis \u201eWhy CPQ implementations fail\u201d<\/a> points out the key problem: \u201eCPQ is designed for RevOps admins, but 95% of daily usage comes from sales reps.\u201d<\/em>. 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.<\/strong><\/p>\n

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 \u2013 and Excel works. In their head: \u201eThis is an IT tool, not my sales tool.\u201d<\/em>. If no one on the board explains why we're changing and shows \u201ewhat's in it for me\u201d \u2013 the salesperson will ignore it.<\/p>\n

<\/p>\n

\n

How to avoid this<\/p>\n

Salespeople on the project team from day one.<\/strong> 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.<\/p>\n

Incentive alignment<\/strong> 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 \u2013 and their commission is based on the number of closed deals. This is then their tool, not IT's.<\/p>\n<\/div>\n

Problem 5: No one planned for maintenance. The configurator lives for 12 months and lies.<\/h2>\n

<\/p>\n

\n

PROBLEM 5 \u00b7 \u201eWE WILL BUILD AND WE ARE READY\u201d<\/p>\n

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.<\/p>\n<\/div>\n

The founder signs the implementation agreement. The configurator goes into production. Assumption in mind: \u201eWe built it and it's done, now it will work.\u201d<\/em>. A month later, you add a new product variant \u2013 the configurator doesn't recognize it. A quarter later, you update the price list \u2013 the configurator shows old prices. Six months later, the integration with the supplier's API stops working because that supplier changed the endpoint.<\/p>\n

Research Kickflip<\/a>: \u201eEvery hour spent maintaining custom configurator code is an hour you're not spending on growth initiatives.\u201d<\/em>. But this is only true if you DON'T have a maintenance plan. If you do \u2013 maintenance is a predictable cost like a CRM subscription.<\/p>\n

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<\/strong> \u2013 shows old prices, missing variants, non-working options. The salesperson stops trusting it. Returns to Excel (see: problem 4).<\/p>\n

Real-world example: a client returned to us 18 months after launch with a question \u201eThe configurator shows old prices, the sales reps don't use it, what now?\u201d<\/em>. 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.<\/p>\n

<\/p>\n

\n

How to avoid this<\/p>\n

Maintenance plan BEFORE signing the implementation agreement.<\/strong> Not after launch. Not \u201ewhen needed.\u201d Before. Typical annual cost: ~20% project values<\/strong>.<\/p>\n

You need this for that client-side owner<\/strong> \u2013 one person who aggregates feedback. Without this, the provider receives 15 email inboxes with \u201esomething isn't working here\u201d from 15 different salespeople. Details of maintenance costs in the article about configurator prices<\/a>.<\/p>\n<\/div>\n

Summary: 5 checkpoints before deployment<\/h2>\n

Before signing an agreement with a software house, check these five things:<\/p>\n

<\/p>\n\n\n\n\n\n\n\n
<\/td>\nCheckpoint<\/td>\nRed flag if...<\/td>\n<\/tr>\n
1<\/td>\nPricing Rules Document<\/strong><\/td>\nSH says \u201ewe'll figure it out later\u201d.\u201d<\/td>\n<\/tr>\n
2<\/td>\nFixed Price + Clear Scope in Contract<\/strong><\/td>\nScope in the \u201eguideline\u201d document\u201d<\/td>\n<\/tr>\n
3<\/td>\nERP audit in the first week<\/strong><\/td>\nSH assumes \u201ewe will manage the integration\u201d.\u201d<\/td>\n<\/tr>\n
4<\/td>\nSalesperson on the team since day 1<\/strong><\/td>\nSH only wants to talk to IT.<\/td>\n<\/tr>\n
5<\/td>\nMaintenance plan in the main agreement<\/strong><\/td>\nKeep \u201ewe'll figure it out post-launch\u201d<\/td>\n<\/tr>\n<\/table>\n

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.<\/p>\n

How do we do it at JSON Crew<\/h2>\n

Our configurator implementation process is based on these five checkpoints from day one.<\/p>\n