Why you need a customer portal when your PIM already exports

Your PIM exports cleanly. And yet, three times a week, someone in product data opens a request that says "can you send me the current data sheet and the front image for these eleven articles, in French".

That gap is not an export problem. An export is a delivery mechanism; what your customers are asking for is an access model — the ability to find the right record themselves, at the moment they need it, without anyone deciding on their behalf what to attach to the mail.

An export answers a question nobody asked twice

A catalog export is a snapshot of a scope that someone defined once. It is correct at the moment it is produced and decays from then on. The practical failures are always the same three:

• Scope is coarse. You export the whole catalog, or a category, or a market. You almost never export "exactly what this reseller is allowed to see", because encoding that in an export job means maintaining one job per customer.
• Freshness is a scheduling problem. Between two export runs, the recipient holds data you know is wrong. You know which fields changed; they don't.
• Distribution is untracked. A ZIP in a mail, a link in a file-transfer service. Six months later, when a specification turns out to have been superseded, nobody can say which version left the building or where it went.

Meanwhile the effort does not scale with the catalog — it scales with the number of customers times the number of times each one asks. That is the line item that grows.

What changes when access is entitled instead of exported

A customer portal inverts the flow. Instead of pushing a scoped copy outward, you publish one governed catalog and let each user's entitlements decide what they resolve to when they look at it.

In practice, entitlement is a stack of filters applied to every request, in the portal and in the API alike:

• Tenant — which brand or country company the data belongs to.
• Portal — the customer portal sees a different surface than the sales or supplier portal.
• Market — market flags on attributes decide whether a Swiss reseller sees the same approval data as a German distributor.
• Category — a reseller who carries only pressure measurement never browses past it.
• Catalog selection — a manual list or a rule (lifecycle = active AND market IN [DE, AT, CH]), saved as a filter template and reused.

The important property is that this is one record with many views, not many copies. When a specification changes in the PIM, it changes for everyone who is entitled to see it, in the same publication run. There is no second catalog to keep in step and no per-customer export job to maintain.

Key accounts are the case that usually decides the business argument. An exclusive catalog view — the products agreed in a contract, nothing else — is a rule in the selection, not a separate dataset someone has to remember to update.

The three things a portal gives you that an export cannot

Self-service at the moment of need. Full-text search, a category tree, faceted filters with live counts, and a product page that shows attributes with units, the hierarchy, and every asset attached to the SKU. The person looking for the French data sheet finds it in the portal at 22:40, which is when they were actually working.

Language and market fallback. You configure the languages a portal offers and a fallback chain — for example de-CH → de-DE → en-GB. A missing Swiss translation resolves to the German one rather than showing an empty field. In an export, a missing translation is an empty column that somebody downstream fills with a guess.

A record. Every access happens against an identity in a scope. Which means the question "which version of that data sheet did this customer get" has an answer.

Every quarter a new catalog PDF goes out. By the time it arrives, the first specification in it is already out of date.

Where exports still belong

Nothing here argues against machine delivery. A distributor feeding their own shop should not be clicking through a portal — they should be pulling from a versioned REST API with the same entitlements applied, or receiving a signed webhook when something in their scope changes.

The useful distinction is by consumer, not by preference:

• People browse. Give them a portal.
• Systems pull. Give them an API with delta sync — field-level delta means about 95 % smaller payloads than shipping the full export every night, and the receiving system can apply changes instead of diffing a dump.
• The open web crawls. That is what an Open Data feed is for.

All three should read the same governed data. If your portal and your API can disagree about a measuring range, you have two sources of truth and the argument will surface in front of a customer.

What to do on Monday

You can test whether this applies to you without buying anything.

1. Count the requests. Pull one month of inbound mail to your product-data alias. Classify each as "could have self-served" or "genuinely needed a human". In our experience the first bucket is the large one, and it is concentrated in a handful of asks: current image, current data sheet, a specification in a second language.
2. Write down one customer's real scope. Take an actual reseller and express what they may see as a rule — categories, markets, lifecycle status. If you can write it in one line, it is a catalog selection. If you cannot, you have found an entitlement question your business has never answered, and that is worth knowing before any tool is involved.
3. Check your fallback policy. What should a portal show when the fr-FR short description is missing? If the answer today is "an empty field in a spreadsheet", decide the chain now.
4. Ask what is not tracked. Identify one asset that went to a customer in the last year whose recipient list you cannot reconstruct. That is your audit gap, stated concretely.

None of this requires replacing your PIM. The customer portal reads from it — via XML, REST or a scheduled SFTP drop — and your PIM stays the source of truth. The portal is the door; the PIM remains the warehouse.

Entitled browsing, search, filters and the product and asset views are live today and in daily production use at a DACH manufacturer with 20,000+ products. Collections, share links with expiry and download caps, bulk download with an audit trail, and white-label branding per portal are planned for 2026. Change notifications on a customer's entitled scope are on the roadmap. Worth knowing which is which before you plan around it — see what is live.

Key takeaways

• An export is a delivery mechanism with a fixed scope and a decay curve; a portal is an access model that resolves per user, per request.
• Entitlements applied as a stack — tenant, portal, market, category, catalog selection — give you one governed record with many views instead of one export job per customer.
• Configure a language fallback chain deliberately; a missing translation should degrade to a known language, not to an empty field.
• Split consumers by type: people get a portal, systems get an API with field-level delta sync, the open web gets a feed — all reading the same data.
• Start by classifying one month of inbound data requests, and by writing one real customer's scope as a rule. Both are free and both tell you whether you have an entitlement model or a habit.