What prospects really ask us: six questions from every PIM evaluation

When an enquiry reaches us, it rarely looks like a feature wish list. It looks like a risk assessment.

The people writing to us are building infrastructure that will stay with them for the next five to ten years. They have a leading ERP system they do not want to touch. They have markets in twenty countries and a team that does not include twenty editors. And they have seen how a “fully automated synchronisation” turns into a folder full of Excel workarounds six months later.

The questions they ask repeat with remarkable precision. Here are the six most common ones – and the answers we give, including where they are uncomfortable.

1. “How mature is AI translation really – and how much manual editing is left?”

This is the most honest question on the list, because it arrives with the right expectation: that the answer is not “none”.

Our answer is not “none” either. It is this: review effort depends on the type of content, not on the language. Treating 25 languages as a single task guarantees a bad plan. We separate three classes.

Structured and technical attributes

Dimensions, connector types, materials, variant labels. Once terminology and attribute values are set up properly, this runs with virtually no review. The Translation Agent is not transferring sentences here, it is transferring controlled values – “Small” and “s” become “S”, various shades of blue become “blue”. That is normalisation, not creativity, and it is reliable accordingly.

Marketing and descriptive copy

What we internally call emotional data – titles, bullet points, descriptions meant to carry a purchase decision. Translation is not the point here; adaptation is. The Translation Agent does not transfer literally, it adapts to market and language. Even so: in your two or three highest-revenue languages, you should edit. In the remaining twenty, a sample check plus a terminology review is usually enough.

Regulatory information

Energy efficiency classes, statutory labelling, textile labelling. This content is added and converted automatically – but it belongs in a documented approval process. Not because the AI is weaker here, but because you may have to prove who signed off. That is what the Workflow Agent is for.

Then there is the part translation alone never solves: metric conversion. Centimetres to inches, EUR to USD, shoe sizes EU to UK. Anyone selling across EMEA and MENA loses time exactly here – not on language, but on units.

You are not replacing editorial review. You are moving it from “translate everything and check everything” to “translate nothing and check selectively”. That is the actual lever.

2. “Which translation engine do you use under the hood?”

We get this question often, and we understand why. We still think it is the wrong question.

Our CEO Lorenz Schneidmadel states his position on this publicly on a regular basis: the core competence lies in orchestration, not in the model. Orchestration differs by use case; which model runs where is an implementation decision that can and should change – otherwise, in eighteen months, you will have bought today’s state of the art.

The questions that actually determine your results are different ones:

• Terminology control. Can you mandate that your product term in Polish is always rendered one way and never another?
• Context. When translating, does the system see only the text snippet – or the product’s category, attributes and usage context?
• Traceability. Can you see where a value came from and how confident it is? In our Deep Research, every attribute carries a source and a confidence rating – precisely for this reason.
• Replaceability. Are you locked into one engine when a better one arrives?

Ask only for the engine name and you get an answer that is stale within a year. Ask about these four points and you get one that holds.

3. “Is the ERP integration a certified native app or a custom-built interface?”

This question is never technical curiosity. It is scar tissue. Translated, it reads: are you building me a one-off that breaks at the next upgrade and that nobody understands afterwards?

The answer is: neither – and that is deliberate.

Our Business Central integration is a productised standard connector with an API-based connection. It is not a project artefact written once for you: it is maintained, versioned and developed as a product. It is still configured – field mapping, sync direction, frequency, formats (XML, JSON, CSV). That is configuration, not custom development. The difference shows the moment you need support.

Deliberately avoiding an extension that runs inside the ERP has a reason: that code has to be retested with every Business Central upgrade. An API-based connection decouples the two systems. Your ERP stays standard. Your PIM stays standard. What sits between them is a contract, not an intervention.

So with any vendor, look less at the certificate and more at these three things: is the connector run as a product or as a project? Who carries maintenance at an ERP update? And is the field mapping visible to you – or does it sit in a black box?

4. “How are conflicts resolved in bidirectional synchronisation?”

This is technically the best question on the list – and the only one whose premise we reject.

Well-built bidirectional synchronisation does not resolve conflicts. It makes them impossible.

The mistake is almost always the assumption that “bidirectional” means “every field flows both ways”. It does not, and it should not. Bidirectional means: some fields flow from A to B, others from B to A. At field level, not at system level.

In practice the split almost always looks like this: the ERP owns SKU, prices, stock levels, logistics data and commercial master data. The PIM owns marketing copy, images, videos, technical documents, declarations of conformity, channel-specific content and translations.

A field has exactly one owner. In the other system it is read-only. That leaves nothing to “resolve” – a conflict cannot arise in the first place.

For the cases where several sources genuinely supply the same information – typically supplier data, not the ERP relationship – we use the Golden Record: all sources feed one central record per product, and you prioritise the sources. Higher-weighted information overwrites lower-weighted information, by rule rather than by accident.

The sentence we give every prospect: if a vendor presents you with elaborate conflict-resolution logic, first ask why the data model permits conflicts at all.

5. “How do assets, documents and print fit into the same system?”

These three almost always arrive as an afterthought – and they are the reason pure ERP extensions fail.

Assets

Images and videos do not sit next to the PIM here, they sit inside it. The DAM is fully integrated and media are linked to products automatically. Add versioning, licence management with automatic detection of expired usage rights, duplicate checking on import and channel-specific image adaptation. The Media Agent generates ALT texts and media metadata automatically – which by now is less an SEO requirement than an accessibility one.

Documents with many-to-many links

Declarations of conformity, data sheets and certificates rarely apply to exactly one product. A document is therefore maintained once and linked to any number of products – not copied. When a certificate expires, you swap one file, not three hundred links.

Print, leaflets and PDF catalogues

There are two routes. The PDF export produces brand-compliant product data sheets and range overviews at the push of a button, live from approved PIM data – for quotes, trade fairs, dealer onboarding and tenders, with no wait for the design team. For designed catalogues there is the Adobe InDesign integration. In both cases the decisive point is the same: there is no second source of truth for print. What is approved in the PIM is what appears in the catalogue.

6. “And what about EDI and our trading partners?”

Here we answer by drawing a boundary, because anything else would be disingenuous.

A PIM is not an EDI system. Classic EDI transactions – purchase orders, despatch advices, invoices – belong in the ERP or in your middleware, and that is where they should stay.

What a PIM takes over is the product content side of partner exchange: the catalogues, range data and classifications you provide to your trading partners. For that there are structured output channels – API, webhooks, FTP/SFTP, JSON, CSV, XML, PDF – and the industry standards BMEcat and ETIM, which are the real currency in wholesale and technical trade.

The clean division of labour: your ERP exchanges transactions. Your PIM supplies the content those transactions are about. Force both into one system and you end up doing neither properly.