Scale the data, not the complexity.

# Factor Blue on the Success of K-Parts — #trstd connect Amsterdam

Jesper van den Bogaard: Thank you, Roy. I'm Jesper van den Bogaard. I'm from Nijmegen, I'm 35, and I run a company called Factor Blue. We mainly do e‑commerce development and have been doing that for about 15 years now.

What I'm going to talk about is what we did for K-Parts. As I said, I'm from Nijmegen, and Zandri was a customer that first came to us around eight years ago. I knew the owner quite well. I simply walked into his company on an industrial estate. I knew he was already working with another partner for development, but I thought the best thing I could do was just walk in. I was still quite young as an entrepreneur, so I thought: I'll go in and see whether I can do anything for them.

The answer was a very firm no. He basically told me, "Keep looking, because I already have a good partner I'm working with." A few years later, however, he came back to me and we were able to start working for him.

I can't even see what's on the screen myself.

Very briefly about who we are and what we do: we don't do marketing. That's one thing we definitely don't do. We mainly focus on technology. We're really the technical people behind webshops. We usually leave marketing and design to external partners, whether they're embedded with the customer or are external agencies supporting things like Google Ads, Meta ads and other marketing activities.

We work from Nijmegen and from Niš in Serbia. I went there about ten years ago to find staff. It was very simple: I had ten employees and needed to grow to twenty, and I couldn't make that happen locally. Then I got in touch with a company in Amsterdam that told me they had people in Serbia, Montenegro and Macedonia. So I went there to find people, and by now we're a team of about 25.

What did K-Parts do? Actually, I need to start with Zandri. Zandri is an online shop with around 300,000 scooter parts from all kinds of suppliers, ranging from original Piaggio and Peugeot parts and many other brands to Chinese imitation parts that they have manufactured themselves and that you can then fit to your scooter.

What made Zandri particularly strong, and what differentiated them in the market, was that they had all the technical drawings for virtually every scooter from 1970 to the present day in their system. So people working on their own scooters could sit at home with a laptop or phone next to the scooter and think, "Wait, I need this particular bolt." They could find it on the drawing, click on the component and buy that exact part, without even needing to know what the part was called.

That was something they were very strong at. K-Parts was, in a sense, a little jealous of that. K-Parts had around 30,000 products in its shop, mainly the fast-moving items, and was primarily positioned as a price competitor. Zandri was much more of a specialist shop, while K-Parts was more of the price fighter.

Then there was an acquisition, and that was fairly complex. Both companies happened to use the same webshop system, which was the one advantage: both were on Magento. But apart from that, they had all kinds of separate systems. They had two different ERP systems, different suppliers, and products that sometimes had different SKUs in the Zandri shop and the K-Parts shop.

I'll explain a little more about how we handled that. K-Parts acquired Zandri, then M2 Trading and City Parts. I've been told they're currently working on another two acquisitions. Their ambition is essentially to become the European market leader in scooter parts. In recent years they have already become one of the major players, and of course acquiring competitors makes you even larger.

So ultimately, we moved towards one foundation for the entire company, but we made some deliberate choices along the way.

What do you inherit in an acquisition? First of all, a lot of legacy code, because these were two different organisations. We had already been working for Zandri for eight years, while another development company had been working for K-Parts. Suddenly, we inherited another webshop containing a great deal of legacy code that required a lot of work.

We also inherited all the reviews. One business was using one review provider, another was using Klantenvertellen, another was on eTrusted, and one was even on Trustpilot. Those reviews were spread across all these different platforms, and bringing them together was one of the challenges we faced.

Then there was supplier data and stock. That was another major issue because we now had roughly 330,000 products. How do you make sure all those products are correct across both webshops? How do you make sure stock levels are correct? And how do you deal with multiple suppliers offering the same item under different product numbers?

For example, you could have one exhaust supplied by five different suppliers, each using a different item number. How do you combine that? We eventually built a data platform with integration interfaces that validate supplier information based on the data sheets and technical drawings provided by the suppliers.

The platform could then say, "This product appears to match this other product by a certain percentage." After that, we asked a person to verify whether the match was actually correct. K-Parts has people who can take a scooter apart with their eyes closed, so they were able to do that validation. In the end, they had to do this manually for just under 20,000 products, which was actually still manageable.

Every shop also had its own setup and its own domains, which created quite a few SEO challenges. We don't do SEO as such, as I said earlier, but we do deal with technical SEO. With all these different domains and SKUs, the same product could have different product pages in different shops, so we had to solve a number of technical issues together with the marketing partners.

One of the first questions they asked when they told me they were merging the two companies was: "Can't we just put both webshops into one environment?"

Technically, that's no problem at all. You can put millions of products into one environment. But the problem is that if you're both one of the largest parties in the Netherlands in a specialist segment and one of the biggest price competitors, and you merge everything into one webshop, you create an enormous risk. If that shop goes down, you have nothing.

What happened before was that if one shop had a problem and went offline, customers simply bought from the competitor — and in this case, the competitor happened to be another company they owned. So I ultimately said: "You can't put everything into one system because the risk is simply too high."

What we did choose was a shared foundation. That mainly meant stock and price synchronisation, while still allowing the price-fighter brand to stay just below Zandri's prices. Customers still choose where they prefer to buy and where they may already have been shopping for years.

So we consolidated the data rather than the shops.

We created one source of truth: one data platform where everything comes together. That wasn't only product data. At one point, we also planned to consolidate all the reviews into one data hub, standardise them and then distribute them to all the platforms.

We didn't end up building that review layer ourselves, but we did consolidate stock and product data and made sure that there were never two systems containing conflicting information.

One business was using Exact Online or Exact for Trade as its ERP, another was using Microsoft Business Central, and there were other systems as well, including a DAM and an old legacy ERP process that collected supplier data from CSV files every night. We brought all of that together into one layer.

Today, around 500,000 synchronisations take place every day between all those systems and the different webshops.

The two businesses they acquired, M2 Trading and City Parts, continued running for about a year under their existing domains, m2trading.nl and cityparts.nl. Eventually, they decided to redirect those domains into the K-Parts and Zandri environments. But of course, you still want to preserve the reviews, product data, order data and other information, so we made sure that was retained.

K-Parts then started growing very quickly. The Netherlands had originally been its only market, but the ambition was to expand across Europe. Zandri was already active in markets including the Netherlands, Spain, Italy, Portugal and the UK and was already receiving a fair number of orders there.

To give you an idea of the scale: K-Parts and Zandri together process around 5,000 orders per day across the countries in which they are currently active.

The cheapest integration we built is the integration we didn't build.

I've already talked a little about stock and supplier data. On the review side, we went from three different review platforms to one platform, eTrusted.

The biggest challenge was that they wanted to launch a new country almost every month. K-Parts wanted to go into Denmark, Germany, Spain and other markets. Technically, we could do that because we had built the architecture to scale quickly. The biggest problems were product information, particularly translations, and reviews. Those were the two main bottlenecks.

For reference, K-Parts has around 38,000 to 39,000 service reviews, and Zandri has roughly the same number.

Together with eTrusted, we looked at how we could bring all those reviews together across all the different domains. Our first idea was to build our own data layer. We would retrieve reviews from all the different platforms and all the different brands in eTrusted, put them into our data platform, standardise them there and then distribute them back out to all the webshops.

Instead, together with eTrusted we arrived at review syndication.

That means that when they launch a new country, they can reuse the reviews they already have. Expansion is currently a little slower because they're evaluating market acceptance in a few countries, but two new markets were launched this year and another four are planned for 2027. Review syndication makes that scaling much easier.

So this is the data layer we did not build.

The original idea was that we would write the code and build the data hub ourselves to bring all that information together. In the end, we didn't need to.

What does that consolidation give us? All reviews together, one profile that can be reused across markets, and one integration to manage.

These are some of the markets where K-Parts is now live: the Netherlands, Belgium, Germany, France, Austria, Denmark and Poland.

What we've seen is roughly 20% growth from international markets alone. The overall company growth is of course higher, but if we look specifically at the additional orders generated abroad after entering those markets with local domains and syndicated reviews, the increase is around 20%.

Previously, customers in those countries sometimes ordered through the Dutch K-Parts webshop and the products were shipped internationally. Then you start seeing ten, fifteen, twenty or thirty orders coming in from Poland, and at some point it makes sense to launch a dedicated Polish shop.

For translations, by the way, we used Elovate, which may be a familiar partner to some of you. They have a kind of PIM solution that makes AI-based translation relatively easy. You still need to tweak and tune the output, but it works well.

That may be a useful tip for anyone who wants to scale quickly into other countries, or has customers who do. We once tried to develop something similar ourselves, but that was just before the current AI era and we were doing it with machine learning. The output simply wasn't good enough.

In the end, we chose one way of working, one data flow and one review source for the complete platform we built for them.

Now I'd like to move on to agentic commerce, because Roy mentioned that earlier as well.

How does an AI agent understand that it is on the correct webshop and that the data it receives is the right information? That's fairly complex, especially if you look at the way K-Parts sells its products.

Customers often need to know exactly what they need. You may have, for example, a Piaggio Zip from 2020. Specific parts fit that particular model, while a 2025 model may require different parts. A scooter can contain around 1,500 to 2,000 components. Many parts are reused across models, but many aren't.

So how do you make sure all of that information is supplied to agents in the right way?

We've spent quite a lot of time thinking about that. We've now developed a model that connects to the webshop. At the moment, it is only available for Magento because we're a Magento agency.

The model combines all available attribute data from both the PIM and the webshop and turns it into information that an AI agent can read. We aren't simply exposing data layers on the frontend. We're working with an MCP through which an agent can communicate directly.

We're developing and testing this with a number of customers.

K-Parts also has many garages and workshops buying parts from them, and those are ideal customers to test this with initially. But as you know, ChatGPT, Claude and similar systems do not yet have full agent-based purchasing available here. In Europe, that is expected to arrive later.

So we're essentially simulating it. We're testing what that future experience might look like in a beta environment, and we're already seeing some very interesting results.

An AI agent doesn't go through a funnel. It looks at the data it has and the data that is available.

I think the solution from eTrusted will help us considerably in giving the agent the trust signals it needs and enabling it to determine: this is the correct webshop where I can order these products.

Reviews and Trustmarks therefore need to be readable by the model. As I understand it, today's developments are an important step in that direction.

You can be perfectly discoverable and optimise heavily for AI. GEO — optimisation for AI systems — is developing extremely quickly. But product data is also crucial.

Another important aspect is that when people use AI, they search based on intent. If I want to buy running shoes, I probably don't search for "running shoes size 46". I might say: "I want to run on hard surfaces," or "I want to run in the forest and need good shoes for that."

If that information isn't present in your product data, you're not discoverable for that use case. If every product only says, "We have this shoe in size 46," but doesn't say anything about cushioning, surface type or whether the shoe is suitable for trail running or road running, then all those products look the same to the model.

We're currently enriching product information in exactly that way.

The same applies to something like a rain cover for a scooter. Imagine I need a cover that won't deform or melt at 35 degrees Celsius. That information needs to be in the data if you want an agent to be able to identify the right product.

Three things I'd like you to take away from this.

First, we consolidated the data, not the shop. We started by inventorying all the information and data points and then bringing them together.

Second, reviews are a launch asset. When you launch a new shop for a customer, being able to take existing reviews with you is extremely valuable. It supports revenue growth, creates trust and helps customers buy instead of forcing the new shop to start from zero again.

Third, agent readiness is partly technical and partly about optimisation. But being discoverable by an AI model is extremely dependent on the quality and structure of your data.

A very short closing point: if you have a customer who is technically stuck with data, integrations or Magento development, come and talk to me. Thank you.

Roy Malaiaars: Thanks, Jesper. Are there any questions for Jesper about his presentation? Yes, Thomas.

Thomas: Hi, I'm Thomas. You talked about migrating from the different providers that were handling reviews. One thing we still hear quite regularly is that when you migrate, you may be able to take your data with you, but you still have to rebuild your actual review value or score in the new system.

How did you solve that? You might have 70,000 reviews, but if you effectively start at zero again and the first new review is negative, then your rating in the new system is still very low. How did you handle that when you already had so many reviews?

Roy Malaiaars: I think initially this was actually something you were planning to build yourselves, and that's when we started talking about it as well.

Originally, the philosophy at Trusted Shops was that the service you provide in market A doesn't necessarily have to be the same service you provide in market B, so those markets were treated separately.

But as we started working with larger and larger customers, and our partners were also increasingly working with larger customers, this kept coming back as one of the biggest obstacles. Whenever we checked in with customers operating across several markets, they almost always raised this issue.

At first, we looked at how customers could solve it themselves. For example, in May I gave a presentation with Vonroc. They had technically built something themselves with their partner. Jesper was considering the same approach.

We then decided to build the solution ourselves so that we could provide it directly.

In practice, it now works like this: the moment you enter a new market, you can immediately implement all your existing reviews, whether they are product reviews or service reviews.

So if you launch in Poland, for example, you can also display the shop reviews you have collected in the Netherlands, Germany or any other market.

It is always clearly indicated that a review came from another market. But this prevents the situation where you generate one review in a new country and immediately end up with a poor score simply because that one review happens to be negative.

Technically, the systems communicate through the APIs we provide.

Thomas: And just as a follow-up, because you migrated from several platforms — Trustpilot, Kiyoh and others — how do you deal with reviews from those platforms? If they're already Trusted Shops reviews from another country, I understand how that works. But if they come from Kiyoh or Trustpilot, can those reviews simply be migrated as well? There's quite a lot of discussion about that, I think.

Roy Malaiaars: Yes, there is. In fact, that's usually the first question companies ask us.

The answer is: yes, you can take them with you.

It is very important, though, to create an export before cancelling your contract with another review provider. Otherwise, you can sometimes end up in a discussion where the provider says that the reviews belong to them. Of course, they don't. It's your social proof; it just happens to be hosted on another platform.

Once you've made the export, the reviews can be migrated. We often work with partners who load the data for us. For our own infrastructure, the process usually takes around four weeks before everything has been imported correctly.

We generally work with reviews from the previous 365 days. So if you have 20,000 reviews dating back to 2010, those won't all be included. We want the review profile to remain current so that it continues to represent who you are and the service you provide today.

But yes, reviews from other platforms can certainly be migrated. It will always be indicated that they were originally generated via another platform.

Roy Malaiaars: Jesper, do you want to add anything to that?

Jesper van den Bogaard: One thing you see very clearly is the labels. If you're looking at a review that originated on another domain, it clearly says, for example, that the review was left on zandri.nl even though you're currently visiting zandri.pl.

You can therefore still see that it's about the same product. The review isn't worth less because it was written in another country or market.

The reviews are also translated automatically now. Something has been developed for that as well.

Roy Malaiaars: And that applies to both company reviews and product reviews.

Jesper van den Bogaard: Yes. For product reviews, the important thing is that you're using the same SKU codes because that's ultimately what triggers the API.

For service reviews, it's simpler because it's literally the same company.

Roy Malaiaars: A question for you, then. Suppose Trusted Shops structures it this way and you're happy because you no longer need to build that part yourself. If you have company reviews and product reviews spread across multiple review platforms, how much work is still left for you to do?

Jesper van den Bogaard: What we mainly did was communicate a lot with each other and make sure we had exports from all the different environments.

We also reviewed the age of the reviews. We didn't remove reviews arbitrarily, but we did decide that very old reviews didn't need to be imported again. The company has existed for a long time, so we looked at that carefully.

There actually wasn't a huge amount of work for us there.

The biggest task was making sure the SKUs were consistent across all environments. Otherwise, reviews would end up attached to the wrong products.

We also had situations where two completely different products happened to use the same item number in two different shops. If you didn't correct that, you could suddenly have an exhaust displaying a review that was actually about a rain cover.

So we had to spend quite a lot of time making sure all of that data was correct. It was checked extensively both by us and by the customer.

Roy Malaiaars: Andreas.

Andreas (Dexport): Hi, Andreas from Dexport. I found it interesting when you said that you need to prepare your shop technically so that agents can complete purchases.

That sounds very interesting. Can you explain exactly what you mean by that? Has an agent already technically completed a purchase with you, or can you test that even if it hasn't happened yet?

Jesper van den Bogaard: At the moment, we have a kind of beta environment.

The protocols themselves have already been published. Google has its own protocol, OpenAI has its own protocol, and you can already start developing based on those protocols.

What we've built on one side is a feed module that supplies all the relevant data to the agent as a data feed.

We've also built a negotiation endpoint. That's primarily relevant for wholesalers, but it allows an agent to negotiate with the webshop, for example about price.

That's very interesting because you can give an agent certain boundaries and say, for example: you're allowed to negotiate up to this maximum discount.

We're currently testing that in a simulated beta environment because there isn't yet an official production environment available here where we can test the complete process.

In the US, parts of the checkout functionality are already running, but we don't yet have an environment in which we can test everything in real time here.

We're preparing for that because we want to make sure that an agent can actually perform these actions when the capability becomes available.

What I notice is that people are still quite sceptical about this.

Someone recently said to me, "I'm not going to give Claude my credit card details."

I said, "Well, you already have, because you have a paid subscription."

Then she said, "But I'm not going to let it do things I don't want it to do," or someone else might get hold of my API key and start buying things with my credit card.

I gave someone a simple example. I said: "Take out your iPhone and press the side button three times. All your bank cards are already on there."

A few years ago, people would have said: "I'm never going to put my bank cards on my phone or watch. That's ridiculous."

And yet today, that's completely normal.

I think we'll go in the same direction with agents.

We'll tell an agent: "Buy me a pair of running shoes suitable for running outdoors on hard surfaces." The agent will know your size, the colours you like and your other preferences, and the shoes could simply arrive at your door the next day.

That's what we're preparing for. We're developing modules that make those kinds of interactions possible.

It's all still very much in its infancy, but I think next year we'll at least be able to take the first real steps.

Roy Malaiaars: Thank you. Jesper, I have this for you as a small thank-you. We'll take a photo together in a moment. Thanks again for doing this.

Given the time, I suggest we take a short break of five to ten minutes. The sound is a little worse here. Everyone can grab a drink, coffee or a biscuit inside, and then we'll continue with Marlijn, followed by the panel talk.