# One catalogue, different prices depending on the customer

> A B2B distributor sold the same SKUs to very different customer profiles, each with its own negotiated price grid.

- Source canonique : [https://allaux.fr/en/realisations/marges-configurables-par-client](https://allaux.fr/en/realisations/marges-configurables-par-client)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## The context

The shop served several categories of professional customers: resellers, purchasing groups, companies ordering on a one-off basis. Each had negotiated different terms, sometimes by product family, sometimes by annual purchase volume. PrestaShop natively offers customer groups with simple discounts, but this mechanism stopped being enough once the rules grew more complex: a different discount depending on the brand, a margin floor never to go below, negotiated exceptions product by product for certain accounts.

Managing this with manual discounts entered account by account would have become unmanageable as the number of professional customers grew.

## What I did

1. **Scoping the actual rules** — Gathering all the pricing rules actually applied, including exceptions documented nowhere but in the sales team's heads.
2. **Designing the rules engine** — Building a module that calculates the displayed price from a hierarchy of rules: base price, group discount, family discount, account exception, with a clear priority between levels.
3. **Dedicated admin interface** — A back-office screen letting the sales team create and edit a grid without technical involvement for every change in terms.
4. **Margin floor check** — Adding a safeguard preventing a combination of discounts from pushing a price below a minimum margin threshold defined per product.

## What needed the most care

- **Consistency with native promotions** — The engine had to coexist with PrestaShop's existing promotion rules, without double application or priority conflicts.
- **Performance at display time** — Price calculation runs on every product page and listing view: the logic was designed to stay fast even with a large number of active rules.
- **Traceability of the displayed price** — Being able to tell, for a given price, which rule was applied — useful when a customer questions their rate.

## Result

> The sales team was able to create and adjust price grids without going through a development request for every new account, while keeping a guaranteed margin floor.

## FAQ

### Does this system replace PrestaShop's native customer groups?

No, it builds on them and complements them. Native groups remain the basis for segmentation; the rules engine adds the priority levels and exceptions the native feature can't cover on its own.

### How many rules can coexist without slowing the shop down?

The number of rules matters less than their structure: a well-designed hierarchy with the right database indexes stays fast even with several hundred active rules.

### Can the sales team edit the grids on its own?

That's exactly the point of the admin interface: creating, editing or disabling a grid needs no technical involvement once the module is in place.

### What happens when rules contradict each other?

The priority hierarchy defined at design time settles it automatically. Ambiguous cases spotted in advance were discussed with the sales team before going live.