Earned today, visible tomorrow: loyalty's batch accrual lag

Because most packaged loyalty platforms accrue non-purchase points in batch, not in real time. In Salesforce's own reference build, purchase accrual runs instantly while engagement accrual — check-ins, challenges, surveys — runs in batch mode once every day. A customer who earns those points at 2pm sees them after the nightly job, up to 24 hours later. It is a design default, not a bug — and it quietly breaks every mechanic that depends on immediacy.

Why does the point vanish until tomorrow?

Loyalty engines split accrual by activity type. A transaction — an order, a delivery, a paid case of product — posts against a rule the moment it lands, because the money is already real. Everything else — scanning a code at an outlet, completing a survey, hitting a challenge target — is treated as an engagement activity, collected as transaction journals and drained by a scheduled batch job. The reference documentation is blunt about the split:

In Cloud Kicks, the accrual process for purchases runs in real time while the accrual process for engagement activities runs in batch mode once every day.

Once a day is the operative phrase. The journals sit in a pending state until the nightly run sweeps them, so the lag a member feels is not the few seconds a rule takes to evaluate — it is the distance to the next batch window. Land your check-in one minute after the job fires and you wait almost the full cycle.

What actually breaks at a 24-hour lag?

Every mechanic marketing bought the platform for. Streaks assume the member can watch a counter tick upward; if today's progress only lands tomorrow, the member opens the app, sees nothing, and assumes the scan failed. Instant-win challenges — "scan now, earn now" — are the worst offenders, because the entire emotional payload is the word now. Flash mechanics tied to a single delivery window are over before the batch has run. You have built a slot machine that pays out the next morning.

Then the tickets arrive. "Where are my points?" is one of the most common loyalty support contacts, and a 24-hour accrual window manufactures it at scale: every engagement action becomes a potential "did it work?" query for the day it takes to settle. Each one costs a human reply, and each unanswered one costs a little trust. Field teams feel a sharper version of the same gap — when the number a person is chasing shows up a day late, they stop believing the number, the way a rep stops trusting a system that can lose the evidence behind their pay. We wrote about that failure mode in when a dropped photo costs a rep their bonus.

Can't you just switch it to real time?

Rarely, and never as a free toggle. Real-time and batch accrual are not independent lanes — per the official limits page, if you run processes simultaneously in real time and in batches, the limits apply as combined for both types. Flip engagement accrual to real time and it now competes with order accrual for one shared processing budget. At beverage route-to-market scale — thousands of outlets, repeated deliveries, returnable movements, promotional scans — that budget is exactly what you were rationing by pushing engagement into the overnight window in the first place.

So the "just make it real time" request becomes a capacity conversation, an extendable-limit support case, and a queue item for whichever team owns the loyalty integration. That is a familiar shape: the change is small, the dependency chain is not, and it lands on the integration team everyone waits for. It is also the rigidity you accept with a suite whose processing model is fixed by the vendor — the same trade-off visible in enterprise loyalty reviews, where the platform is capable but the seams are precisely where you wanted to move.

Why does beverage route-to-market feel this worse than retail?

Because the loyalty member is usually a business, and the points map to money the business can see coming. An outlet owner who scans a case at delivery is not collecting a novelty badge; they are tracking a rebate, a volume target, a returnables credit against real stock in the cellar. When that ledger updates a day after the truck has gone, the reconciliation happens against yesterday, the rep fields the query at the next visit, and the reward arrives detached from the moment that earned it. Retail loyalty can absorb a sleepy overnight batch because the stakes per action are low. In trade, the action is the commercial relationship, and a day of latency reads as the system failing to keep up with the route.

Where does the fix actually live?

Not in tuning the batch schedule — in removing the batch. Model accrual as a consumer on the order and engagement event stream, so a point is calculated the instant its triggering event hits the bus and is visible before the driver leaves the yard. That is the shape we build toward in our event-driven architecture: one event, evaluated once, reflected everywhere, with no nightly window to miss. It is a different processing model, not a config flag — which is precisely why the packaged default stays batch.

The gap that matters is closing on its own. Members now compare their trade loyalty app against every real-time balance in their pocket, and "check back tomorrow" reads worse each year. The brewers who win the next round of route-to-market loyalty will be the ones for whom the overnight batch is already a story they tell about the old platform, not a window their customers are still waiting on.