Business
5 min readYou planned the spring campaign eight weeks out, the creative ready, the inventory staged, and the calendar locked. But the promotion itself, a tiered discount that stacks with loyalty points and applies differently across three brands, still needed engineering. By the time that ticket worked its way through the backlog and onto a full sprint, you’d already missed two weeks of the selling window.
This is the promotion management problem that nobody puts on the vendor evaluation scorecard. It's not about whether a platform can run a BOGO. It's about whether your team can launch one on Tuesday without filing a Jira ticket on Monday.
Merchandising leaders spend months building promotional calendars. They model margin impact, coordinate with buying teams, and align across channels. The strategy is usually sound. The execution is where things break.
According to research from Yieldigo, retailers routinely fall into promotion planning pitfalls: copy-pasting last year's campaigns without analysis, choosing inappropriate promotion types, and forecasting the wrong product quantities. These are upstream problems. The downstream reality is worse: once you've decided what to promote, getting it live still requires filing a ticket and waiting.
That gap between promotional intent and promotional execution costs real revenue. As XCCommerce's analysis of retail promotions puts it, execution is "the only one of the three [pillars] that directly touches the customer." Every day a promotion sits in a dev queue is a day your competitor's offer is live and yours isn't.
1. Business users can't launch promotions independently.
If every new promotion type requires custom development, you don't have a promotion engine, you have a promotion request system. A request system means your merchandising team operates at the speed of your engineering backlog. A true engine means they operate at the speed of their own decisions.
The best promotion platforms let business users define complex rules, including tiered discounts, stackable offers, customer-segment targeting, and channel-specific pricing, without writing code or waiting on a deploy. That's not a nice-to-have. It's the difference between running 12 campaigns a quarter and running 50.
2. Your promotions live in a silo.
A promotion that works online but doesn't apply in-store isn't a promotion, it's a source of customer complaints. Omnichannel consistency sounds like a buzzword until a customer tries to redeem a coupon at pickup and your POS doesn't recognize it.
The underlying problem is architectural. Most legacy platforms bolt on promotions as a feature of the storefront, which means the logic is tied to a single channel. When you add a second channel, or a third brand, or a marketplace, you're either duplicating promo logic across systems or building custom integrations to keep them in sync.
A single promotion engine that serves every touchpoint (web, mobile, in-store, call center) eliminates that duplication. One set of rules. One source of truth. The customer doesn't care which system fired the discount. They just expect it to work everywhere.
3. You can't own your promotional roadmap.
Here's the question most vendors don't want you to ask: who decides what promotion types you can run next year?
If the answer is "our vendor's product team," you've traded one constraint for another. You left the legacy monolith because it was inflexible, and you landed on a SaaS platform where flexibility is gated behind feature requests.
The alternative is a promotion engine you can actually extend. Not "extend via a plugin marketplace," but extend at the rule level, the data model level, the API level. When your merchandising team dreams up a new offer structure, say a loyalty multiplier that varies by product category and customer tier, your engineering team should be able to build it on the platform, not around it.
What actually works
The merchandising teams that run promotions well share a few things in common.
They chose platforms they can customize deeply. They can change how promotion rules evaluate, how offers stack, and how eligibility is determined. When a new business need comes up, engineering extends the engine, not rebuilds around it.
Eighteen months of implementation is a bad sign, not a badge of honor. The fastest-moving teams picked platforms that fit into their existing architecture, their infrastructure, and their deployment model. They didn't force a wholesale change in how their teams operate.
They control their own roadmap. This is the underrated one. When your promo engine is deeply extensible, your roadmap isn't subject to someone else's prioritization. Your team decides what to build next based on what your customers need, not what the vendor's largest customer requested.
Omnichannel wasn't a project they tackled later. It was a constraint they designed around from the start. One engine. Every touchpoint. Every channel they add after that inherits the full promotion catalog automatically. No re-implementation, no sync jobs, no drift.
Before your next platform evaluation, ask these questions about promotions:
- Can a business user create and launch a new promotion type without engineering?
- How many promotion types work out of the box, and what does it take to add a new one?
- Does the promotion engine serve all channels from a single rule set?
- Can we self-host or choose our deployment model, or are we locked into the vendor's infrastructure?
- Is the promotional logic visible and extensible, or is it a black box?
- How long does a typical implementation take before we're running live promotions?
If a vendor can't answer these cleanly, that's your answer. A platform that scores well on features but poorly on flexibility will feel great in month one and frustrating by month six.
Your promotion strategy probably isn't the problem. Your ability to execute it is. Fix the tooling, and the strategy takes care of itself.