Why loyalty implementations run 90 days to 12 months

By the numbers their own marketing publishes, packaged loyalty platforms take three to twelve months to stand up. Comarch's loyalty content puts the range at 90 days to 12 months; Gartner reviewers describe setup that needs significant time and dedicated technical support. The spread is the real finding: a fourfold range means your timeline is set by how much you customize, not by the software. Here is where the months hide, and what they cost after go-live.

What do the vendors actually admit?

Start with the vendor that publishes a figure. Comarch's own loyalty material concedes an implementation runs from 90 days to 12 months, as documented on its loyalty marketing pages as of October 2025. Read the two ends again: the fast case and the slow case differ by roughly fourfold. No packaged product's install time varies fourfold because of the product. It varies because, here, "implementation" means "configuration and integration" — and both of those are open-ended.

Independent reviewers say the same thing in blunter language. On Gartner Peer Insights, buyers of loyalty management platforms report that the software:

requires significant time, expertise, and effort to configure ... initial setup and ongoing customization can be resource-intensive, often requiring dedicated technical support ... different interpretation of requirements during implementation.

The fragment to underline is the last one: different interpretation of requirements during implementation. That is a courteous way of saying the real scope was negotiated after the contract was signed, in a room where the clock was already running.

Why is it a range and not a number?

A shrink-wrapped product installs in a known time because the deliverable is fixed. A configurable loyalty platform cannot, because the deliverable is your rules, not the vendor's binary. Point accrual and expiry, tier thresholds, returnable-deposit mechanics, promotional stacking, member segmentation, fraud limits — each is a small specification project, and each one multiplies the test matrix. The vendor is not being evasive when it quotes 90 days to 12 months. It is pricing your undecided requirements into the calendar, because it has learned that most of that decision-making has not happened yet.

In beverage distribution the rule surface is unusually large. A points programme that also has to respect returnable-container deposits, wholesaler versus on-trade pricing, and trade-promotion accruals is not one loyalty programme; it is several, sharing a schema. Every combination someone wants to support is another branch to configure and another path to test. This is why "we just want standard loyalty" almost never survives contact with the first workshop, and why the honest vendors quote a band rather than a date.

So a demo is a poor predictor of delivery. The demo runs the stock configuration; your programme does not. The gap between the two is the project, and it stays invisible until someone finally has to write it down.

Where do the months actually go?

In our experience wiring loyalty into a route-to-market stack, the calendar burns in five predictable places. None of them is "installing the software."

The integration row is the one that quietly dominates. Loyalty has to see every earning event — orders, deliveries, returns — which means touching order capture, POS, the returnables ledger and the SAP financial core that stays in place. If those connections land as point-to-point glue, you inherit exactly the maintenance load we walked through in the ESB pattern that follows you to Kafka. Data migration hides time too: member balances and transaction history arrive as bulk loads that grind for hours, the same way the ImpEx job that ran all day did — except here a wrong number is somebody's points balance, and they will notice.

What does the customization cost after go-live?

The customization that stretches the timeline does not stop billing once you launch. It becomes a standing liability. As one platform review puts it:

Customized versions can create upgrade friction. Support and versioning may become more contract-heavy over time.

Every deviation from the standard product is code that someone must carry forward through each vendor upgrade. The more you bent the platform to fit your programme, the more expensive and negotiated each future version becomes — and the more your leverage erodes, because the exit gets harder the longer you stay. That is the same lifecycle trap we described in when your commerce platform goes end-of-life under you: heavy customization is comfortable right up to the point where it is the reason you cannot move.

The direction out is not a better vendor; it is a smaller surface. When loyalty is a service you own on a shared event bus, the rules live as code your team can read, version and test, and "implementation" collapses into ordinary delivery instead of a contract-bounded configuration exercise. We set out how that sits on one event bus elsewhere; the point here is that owning the rules is what removes the fourfold uncertainty in the first place.

The interesting shift over the next few procurement cycles is not that loyalty vendors will get faster; it is that buyers are learning to read the range on the tin as a confession. A quoted band of 90 days to 12 months is a vendor telling you, in advance, that the timeline is yours to set. The teams that treat their loyalty logic as software they own — rather than a configuration they rent — are the ones who will stop being surprised by the second number.