10 questions to ask before buying a product configurator

Why should you care?

If you skip the preparation, you are almost GUARANTEED to end up with a solution that is expensive to operate and irrelevant in practice. Here are 10 questions that ensure your product configurator actually fulfils its potential.

1. What do I want to achieve with a product configurator?

You should not get a product configurator “just to have one”. Let me emphasise it—they are not free.

Whatever solution you choose, it is an investment of time, money, and resources that could have been used on other initiatives.

So the solution must be part of a strategic initiative—how does this investment support your strategy?

Consider whether it should:

• Minimise manual work
• Streamline sales processes
• Generate more or better-qualified leads
• Increase conversion rates and sales
• Increase your competitiveness
• Support a marketing campaign
• or something else entirely.

If you do not know what you want to achieve, it will be difficult to measure whether the investment makes a difference—and it will also be difficult to define a solution that meets these “undefined goals”.

2. What is the alternative—and what are the consequences of doing nothing?

What happens if you do not build a configurator?

And what are your alternatives? All investments compete with one another. Based on what you want to achieve, you must weigh whether the product configurator is the solution that most effectively moves you closer to that goal.

It could be:

• Automation of other processes that would bring you closer to your goals.
• Integrations between systems that solve the same or other manual processes.
• Hiring more salespeople.
• Implementing a CRM system that can make sales smarter.
• Perhaps there are other digital tools?

And what are the consequences of not doing anything at all? It is often easier to justify an investment if you can weigh up what happens if you do nothing.

For example:

• Even if we receive more enquiries by email/phone, they take too long to handle, and we do not have the capacity—so we will need to hire an additional 1–2 FTEs.
• Sales happen slowly through human advice rather than automatically.
• We get too few leads, so sales does not have enough to work with.

3. What are the success criteria—and when will you measure?

How do you know whether the investment in a product configurator was a success?

Make sure you have clear KPIs and a timeframe for measurement.

Clear KPIs:

• X% fewer manual orders
• 1 month shorter sales cycle
• DKK 10,000 higher average order value
• 2 out of 3 leads are qualified

Remember that when you define KPIs, they must be specific—which means they must include something quantifiable (a number—either absolute or percentage-based).

Timeframe:

• Will you measure after 3, 6, or 12 months?
• Who will measure it?

That way, you know when expectations have been met—and whether adjustments are needed.

4. Is there any demand at all?

Who says it is even a good idea? Who is driving the demand?

• Is it sales?
• Administration?
• Suppliers?
• Customers?
• Students?

5. Who is the user of the future product configurator?

Is it the end customer or your salespeople? Do they understand the product, or are they consciously technically incompetent?

The answers determine who the solution should be designed for and communicated to. And yes, the solutions look VERY different depending on whether it is internal users, external users, technical experts, or digital beginners who will use the product configurator.

• What do they need to choose (ready-made packages vs. technical accessories)?
• How many steps can they manage?
• And what is “easy” for them—mobile vs. desktop, visual choices vs. technical specs?

6. What value does it provide to the user?

Trust us—if it only benefits you, it will never be a success. So you may well want more leads—but what value does the user get from using your future product configurator?

For example:

• Does it create less uncertainty and fewer errors?
• Does it help the user understand the product faster?
• Does it provide transparency in pricing and choices (dynamic pricing)?

7. Which features are must-haves for your MVP?

Sit down and think carefully about which functions are absolute must-haves in an MVP (the first version of the configurator). You can read more about how to identify and prioritise features in an MVP here.

Examples of what we frequently see as critical:

• Complex rule sets—i.e., some choices must exclude each other, while other choices should unlock new options.
• Integration with business-critical systems —pulling and sending data to and from existing IT systems you use to run the business, e.g. ERP, PIM, CRM, or Business Central.
• Mobile-first thinking—users of the configurator may primarily use a mobile device, so the design must support this.
• Differentiated user roles—some users have access to certain things, and others have access to something else.

8. What does the product configurator need to integrate with?

This is closely related to the above. It is about considering the context the product configurator must be part of—and the role it should play.

• Is there an integration with ERP, CMS, CRM, PIM, or others?
• Where does the data come from, and where should it be processed and stored?
• Is there an app or marketing channels that need to connect with the system?

9. Which tech stack should be used

You may not be a programmer—but you still need to consider the tech stack that will define your new central business tool (the product configurator).

Is it a common technology?

• That ensures others can take over or build on it if the vendor goes bankrupt.
• Common technologies are also better supported by other IT systems when they need to integrate, giving you more options later on.
• There is always a reason a system is widely used—remember that 😉

Is it well documented?

• If something is properly documented, it minimises risks and errors, and it makes it easier for a developer to work with.

Is there an API, or can an API be built for the solution?

• An API is a “port” that makes a system ready to send and receive data. If a system has a well-documented API, integration with other systems becomes significantly easier. In other words: cheaper.

Is the tech stack ‘best in breed’?

• Does the choice of each component and technology make sense? Are the technologies used where they are best and most commonly applied?

10. How are maintenance and scalability handled?

Is the system maintainable? And what are the costs? You can certainly end up with a patchwork solution of various configured plugins that then breaks as soon as it is stress-tested even slightly, or as your needs change over time.

If you choose to invest in a product configurator, the expectation is that it will serve as a strategic tool for around 5 years. This gives rise to a great deal of further development, bugs, and errors.

News, you actually wants to read

Join newsletter

Indlæg af

Thomas Østerkjerhuus

CEO & Partner

[email protected]