The trade-promo module only consultants can touch

Because Vistex keeps your trade-promotion logic inside a proprietary rules engine whose configuration skills barely exist outside the vendor's own consultants. Every price move, rebate tier or promo mechanic becomes a ticket to an outside firm. That is a commercial problem, not an IT one: trade promotion is the second-largest line on most CPG P&Ls, and you have gated its fastest-moving part behind the scarcest resource in the building.

Why does every promo change need a consultant?

Trade-promotion configuration is not a settings form. It is where commercial strategy actually lives: eligibility rules, tiered rebates, accrual logic, deduction matching and settlement terms, modelled as condition types and access sequences on top of SAP pricing. The people who can read and change that model are trained almost entirely inside one ecosystem, and reviewers on public sites describe the skill set as effectively closed.

hard to find the Vistex skills outside of the Vistex organization

Read that as a labour-market statement rather than a product gripe. You cannot realistically hire the capability onto your own team, so you rent it. And when something breaks or needs a change, there is little public material to work from, so your engineers cannot route around the scarcity. As a reviewer puts it in the pros-and-cons on G2:

You always need consultancy because you don't have much information out there to solve or fix yourself

Two failure modes stack. The skill is scarce, and the documentation that would let you compensate for the scarcity does not exist. Whatever knowledge does accumulate tends to leave when a project closes, or lives with the one internal analyst who happened to sit through the implementation. Neither is a foundation for a pricing team. So the module that encodes your promotional strategy is, in practice, owned by whoever can bill for it.

What does the dependency actually cost?

Start with the invoice, because reviewers on Gartner Peer Insights and G2 are blunt about it:

not cheap or easy to configure… much higher TCO

Licence and day rates are only the visible part. The real tax is latency on a line you cannot afford to run slowly. The Promotion Optimization Institute puts trade promotion at between 11% and 27% of gross CPG revenue, the second-largest line on the P&L after cost of goods sold. When the fastest-changing quarter of your top line can only move on a consultant's calendar, three separate costs appear: the invoice you can see, the queue you wait in, and the promotions you never attempt because the change is too slow or too dear to be worth requesting.

It is the toll-booth dynamic we described in paying to look at your own data — a standing charge to interact with logic you already own. A competitor's promotion goes live on Monday; your answer ships after a scoping call, a quote, a sprint and a regression pass, all metered by someone else's utilisation rate.

Why does it crawl at volume?

The performance complaints are not cosmetic. Reviewers describe the runtime at scale as:

UI feels outdated… performance also is very slow

This class of engine is configuration-heavy and batch-oriented. Condition records multiply across products, customers and time, and evaluation happens in scheduled runs rather than at event time. At brewer scale — millions of order lines, tens of thousands of outlets, promotions that change weekly — the record explosion lands exactly where the system is weakest. We have watched the same physics with heavy batch jobs elsewhere; it is the theme of the ImpEx job that ran all day. When a tool is both slow to run and gated to change, experimentation quietly stops, and the team settles for whatever mechanics were configured last.

How does the dependency compound?

Scarce skills plus a proprietary layer would be manageable if the layer stood still. It does not. Every major version brings a migration, and each migration is another engagement priced by the same scarce specialists — the platform treadmill we walk through in chasing the platform upgrade. You pay to run the module, pay to change it, pay to upgrade it, and pay again to reconcile it when it disagrees with the rest of your estate. The four complaints reviewers raise are not separate faults; they are one dependency seen from four sides.

The direction out is ownership, not a different vendor: move the fastest-changing promo logic — eligibility, tiers, mechanics — onto an owned, event-driven layer your engineers can read, test and change, while SAP stays the financial core of record. A rule change becomes a pull request rather than a purchase order, the knowledge stays in the building, and the specialists are reserved for the genuinely hard settlement edge cases.

The trade-spend line is only getting more contested. Retail-media measurement, dynamic net-revenue management and per-outlet personalisation all assume you can reshape a promotion in hours, not sprints. The operators who pull ahead over the next few years will not be the ones running the largest promotion suite; they will be the ones whose own engineers can change a rebate rule on a Tuesday afternoon without booking anybody — on exactly the 20%-plus of revenue they can least afford to run slowly.