The short answer. Test every onboarding tool on the same three to five real supplier files and a slice of your real data model. Before the trial, write an answer key: the values a careful person would enter for a sample of products. Then count, per tool, the values that were correct, the values sent to review and, above all, the wrong values that passed without a flag. Check sources, units, codes and what gets written to your PIM.
Why your own files matter
Every onboarding tool looks good on its own sample files. Those files were chosen to show the tool working. Your suppliers send something else: a data sheet with the table split across two pages, a spreadsheet where “Gewicht” means weight in grams, an email with three products in one paragraph.
A trial on your own files answers a narrower and more useful question: how much of your real work does this tool take off your team, and how much new checking does it add? This method works for any tool, including openProd, and needs no vendor’s cooperation beyond letting you upload files.
Pick the test set
Choose three to five files that represent your daily work. A good set covers:
- A PDF data sheet, ideally one with a table across pages or several products on one sheet. Our guide to supplier PDF data sheets explains what makes them hard.
- A messy spreadsheet with the supplier’s own column names, merged cells or units in the headers.
- A product email or pasted text, the kind of description a sales contact sends.
- A price list update for products already in your catalogue, so you can see how the tool handles updates.
- A file in another language than your catalogue, if your suppliers send them.
Then pick a slice of your real model: two or three product families with their real attributes, units and option lists. Do not simplify it for the trial. If your “Material” attribute has forty options with codes, the tool should face those forty options. Our guide to units and option lists covers why this is where most errors hide.
Prepare an answer key
The answer key is what makes the trial fair. For a sample of products from each file (for example ten), write down the values a careful person would enter, in your attributes, units and codes. If the PDF says 0.09 kg and your attribute expects grams, the answer key says 90. If the supplier writes “Stainless steel” and your dictionary code is stainless_steel, the key says stainless_steel.
Two rules:
- Prepare it before the trial, so no tool’s output shapes what you consider correct.
- Note the values that have no place in your model. A good tool should list them, not force them into the nearest attribute.
Preparing the key takes time. It is also the part you reuse for every tool you test.
What to measure
Measure outcomes per value, not impressions. A screen full of filled fields says nothing until you compare it with the key.
| Outcome | What it means | How to treat it |
|---|---|---|
| Correct | Matches the answer key | Good |
| Sent to review | Tool asked a person | Acceptable; note the effort |
| Wrong, flagged | Wrong, but marked uncertain | Acceptable if the flag is clear |
| Wrong, passed silently | Wrong, shown as certain | The most serious result |
| Missing | In the file, not found | Note it; check why |
Wrong values that passed silently matter most. A value sent to review costs a few seconds. A wrong value that looks certain goes into your PIM, then to your shop or marketplace, and someone outside your team finds it.
Beyond the counts, check:
- Units and option codes. Is 0.09 kg saved as 90 g when the attribute expects grams? Does “Stainless steel” become your code, or a new free-text value? Can you see the value as read next to the value after conversion?
- Values without a place. Where do features go that your model has no attribute for? Listed separately, dropped, or forced into another field?
- New versus update. For the price list update, does the tool recognise existing products, and does it show which values change?
- What is written, and when. Does anything reach your catalogue or PIM before a person approves it? Can you see a preview of every change first?
- Source per value. Can you open the file at the place a value was read, not just see the file name?
- History and rollback. Is every saved change recorded? Can you restore an earlier version of a product?
- Permissions. Who may approve, who may send data to the PIM, and who may change the model? Are these separate?
- Cost visibility. Do you know what a run will cost before it starts, or only after?
How to run the trial
- Same files in every tool. Do not let a vendor swap in an easier file.
- A timebox. Give each tool the same amount of working time, for example two days, including setup of your model slice.
- The right reviewer. The person who reviews the output should be the one who does the work today: a catalogue manager or product data specialist, not the buyer of the software alone.
- Record time spent. Note how long the review took, not just the extraction. A tool that sends everything to review may be correct and still save little.
- A simple results sheet. One row per value checked, with these columns:
- Tool
- File
- Product (SKU or name)
- Attribute
- Answer key value
- Tool value (after conversion)
- Value as read (if shown)
- Outcome (correct, sent to review, wrong flagged, wrong passed silently, missing, no place)
- Source link works (yes or no)
- Notes
Sort by outcome at the end. The rows marked “wrong passed silently” are your first conversation with the vendor.
Red flags in a trial
- The vendor wants to use its own files or to clean yours before the run.
- No way to see where a value came from. If you cannot check a value against the file, you will end up checking all of them by hand.
- Your model is replaced by a template. Values land on generic fields that you then map again.
- Units converted without showing the original. A wrong conversion becomes invisible.
- Unknown features disappear, or are pushed into a free-text field without asking.
- Data reaches the PIM before approval, or the preview does not show what changes.
- No change history or no way to restore an earlier version.
- Cost is known only afterwards.
- Accuracy claims you cannot check against your own answer key.
Reading the results
Put the tools side by side and read them in this order: wrong values that passed silently, then values missing, then the review effort, then everything else. A tool that flags more for review but never passes a wrong value silently is usually safer than one that fills every field with confidence.
Then add the setup work: connecting to your PIM, setting up your model, permissions and training. If you need a business case, the onboarding cost calculator estimates what manual onboarding costs today. For the tools on the market and what each states publicly, see our comparison of product data onboarding tools, and if you are weighing a portal against reading suppliers’ own files, supplier portal or AI onboarding.
How to run this trial with openProd
openProd is an AI onboarding layer in front of your PIM, and you can run the method above on it.
- Bring one of your files to a demo. In a demo, one of your supplier files goes through reading, mapping and review. openProd reads PDFs (product names and specification tables), spreadsheets such as price lists and update files, and pasted text.
- See the cost before the run. Before the AI analysis starts, openProd shows a credit estimate based on similar imports, with the expected time, and runs after you accept it. The analysis proposes data; the catalogue is not touched.
- Check values against your key. Values land on your attributes, units and dictionary codes. Clear values go straight through; conversions and values without an attribute wait for a decision in Data review, where you can compare the value as read with the value after conversion. Values your model has no attribute for are listed separately.
- Check the source. Show in source opens the file at the place a value was read.
- Check what would be written. The preview separates new products from updates and shows each changed value, now and after import. Nothing is written until someone clicks Save to catalog, and after saving openProd confirms the saved data matches the checked result.
- Check the history. Every product change is recorded, and you can restore an earlier version.
For the connection to your PIM, see Pimcore, Ergonode or Akeneo, and the tutorials for the steps in the app.
Sources and updates
This guide describes a trial method and makes no statements about other vendors’ products, so it has no external sources. For what each onboarding tool states on its own pages, with links, see our comparison of product data onboarding tools.
Checked on 13 October 2026. If something has changed, tell us and we will update this page.
