How to set up retailer-specific assortments and price tiers in a B2B portal
Which products a retailer sees, at which price and in which quantities: the building blocks and the traps.
KEY TAKEAWAYS Summary by the editors
- A B2B portal can show each retailer its own catalogue and price list by assigning products and prices to a company or customer group.
- Tiered pricing, minimum order quantities and case packs are the three quantity rules most wholesale setups need to model.
- Native portal features usually handle simple rules, while contract-specific or real-time pricing often needs ERP integration or custom development.
- Payment terms and credit limits belong on the customer record and should come from the finance system rather than be maintained by hand in the portal.
- Restrictions such as exclusive lines or regional limits should be designed as rules on the customer record before any product is loaded.
To set up retailer-specific assortments and price tiers, define customer segments first, then attach a catalogue (which products are visible) and a price list (what they cost) to each segment or account, and finally add quantity rules and payment terms. Most platforms support this natively for simple cases. The hard part is not the software but deciding the rules and keeping the underlying data clean.
What are assortments and price tiers in a B2B portal?
An assortment is the set of products a particular retailer is allowed to see and order, for example because of an exclusive line, a regional restriction or a distribution agreement. A price tier is the set of prices applied to that retailer, which may depend on the account, a customer group or the quantity ordered. Shopify's B2B documentation describes the same ideas as catalogues that set buyer-specific product availability and prices, and company profiles with their own payment terms and permissions. Other platforms use different vocabulary for the same concepts.
How do you structure the rules step by step?
- Segment your accounts: group retailers by channel, region, relationship or contract (for example key accounts, independents, department stores).
- Define one catalogue per segment, listing which products and variants are visible.
- Create price lists per segment or account, either as a percentage off a base wholesale price or as explicit prices per product.
- Add quantity rules: minimum order quantity, case packs and any volume breaks.
- Attach payment terms, credit limits and tax settings to the customer record, ideally synchronised from the finance system.
- Test with a real account: log in as a buyer and try to place an order that should be blocked, and one that should work.
| Rule | What it controls | Typical source of truth |
|---|---|---|
| Catalogue | Which products and variants a retailer can see | Sales and distribution agreements |
| Price list | Price per product for an account or group | Pricing policy, ERP |
| Volume tier | Price break by quantity (for example one price up to 50 units, a lower price from 51) | Pricing policy |
| Minimum order and case pack | Smallest order and pack size per style | Product master, logistics |
| Payment terms and credit limit | When and how much a retailer can owe | Finance, ERP |
What can native portal features handle, and what cannot they?
An agency guide to Shopify B2B reports that price lists can be assigned to companies or customer groups and that tiered pricing is supported, but also that native price lists may not cover complex rules based on contract length or real-time market conditions, which may need an ERP integration or custom app. The same guide notes that approval workflows and per-user spending limits are not native, and that combining multi-language, multi-currency, B2B prices and catalogue restrictions adds complexity. Other platforms differ, so check your own vendor's documented limits rather than assuming.
Where do these setups usually go wrong?
- Pricing logic lives in several places (spreadsheet, portal, ERP) and drifts apart.
- Catalogue rules are added product by product, so a new style is visible to the wrong retailers by default.
- Case packs and minimums are held in a document, not in the data, so the portal cannot enforce them.
- Currency and tax handling are bolted on after the price lists are built.
- Nobody owns the rules, so exceptions accumulate without review.
How should the data be prepared before loading?
Before building anything, make sure each style has a stable identifier, complete size and colour variants, a base wholesale price, a suggested retail price and a case pack. Then document the commercial rules in plain language: who sees what, at which price, with which minimum. Writing these down first exposes contradictions that would otherwise surface only when a buyer is blocked at checkout. Where AI features such as recommendations are planned later, the same clean data and segmentation are a prerequisite.
How do you test and maintain the setup?
Treat the rules as a product that needs testing and upkeep. Create a small set of test accounts, one for each segment, and a checklist of expected outcomes: which collections each should see, the price for a reference style, the minimum for a reference style and what happens when the credit limit is exceeded. Run the checklist whenever a collection is loaded or a rule changes.
Maintenance matters as much as the build. New styles, price changes, new retailers and ended agreements all require updates. Assign an owner for the rules, set a review date each season and log exceptions so that repeated exceptions can be turned into proper rules or removed.
| Test | Expected result |
|---|---|
| Log in as the segment's test buyer | Only the agreed collections appear |
| Open a reference style | Segment price and correct currency shown |
| Enter a quantity below the minimum | Order blocked or warned |
| Enter a quantity that crosses a volume tier | Tier price applied |
| Exceed the credit limit | Order held or flagged according to policy |
Where an AI feature is planned, such as recommended quantities or reorder suggestions, the segment definitions above become its basis. Poorly defined segments produce poor recommendations, which is a good reason to settle the structure first.
What should be decided with sales, finance and IT?
Portal rules sit across three functions, and the setup stalls if one of them is missing. Sales defines who may see what and why. Finance defines credit, tax and payment terms and owns the customer record. IT or the platform team decides where logic lives, which integrations are needed and what must be built. A short workshop with all three, using a handful of real retailers as examples, resolves most questions faster than a long specification.
Use real examples to expose edge cases: a retailer with several delivery locations, a group with separate legal entities, a store that buys under a licence agreement, or an account that receives different prices in different currencies. Each of these tests whether the rules are modelled at the right level, whether company, location or buyer.
- Which level carries the price list: company, location or individual buyer?
- How are changes in an agreement reflected, and who approves them?
- What happens to open orders when a price list changes?
- How are exclusives and embargoed collections hidden until release?
The answers become the documented rules that the portal implements, and the test plan that checks it.
Frequently asked questions
What is a customer-specific catalogue in B2B commerce?
It is a set of products and prices tied to a company or customer group, so that each buyer sees only the range and prices agreed for them.
How do tiered prices work in a wholesale portal?
The unit price falls as the quantity crosses defined thresholds, for example one price up to 50 units and a lower price from 51 units.
Should payment terms be set in the portal or the ERP?
Usually the finance system should own terms and credit limits, with the portal reading and enforcing them, so there is one source of truth.
Can a portal handle minimum order quantities and case packs?
Many can, either natively or through customisation, but only if the minimums and pack sizes exist as data on the product rather than in a separate document.
One edition every weekday morning. Read in five minutes. Free for industry professionals.
