An offer in Insider One is managed as a single configuration object that carries its own lifecycle state, eligibility rules, priority, and consumption caps together. Toggling the state controls whether the offer is eligible to be shown; the same configuration enforces spend, redemption, and stock limits in real time as each customer is evaluated, with role-based control over who can create or change it.
Enterprise offer programs need more than an on/off switch: an offer has to move through defined states, be governed by who is allowed to change it, and stop showing itself the moment its budget, redemption, or stock limit is reached, without a customer ever being served an offer the business can no longer honor. Insider One models each offer as a configuration object that combines its lifecycle state, targeting and stacking rules, priority relative to other offers, and consumption caps. Because all of this sits in one place, toggling the offer’s state is what controls its eligibility everywhere it could otherwise be shown, rather than requiring separate systems to stay in sync.
This article covers the answers to the questions below:
Lifecycle states
An offer configuration carries an explicit state that determines whether it’s currently eligible to be evaluated for a customer:
State | Behavior |
|---|---|
Draft | Configuration is being built; not eligible to serve. Design updates continue to apply freely. |
Scheduled | Configured and queued to activate at a future date/time; still editable. |
Active | Eligible to be shown; evaluated against targeting rules, priority, and caps for every customer. |
Paused | Temporarily withdrawn from eligibility without losing configuration, history, or accumulated consumption counts. |
Expired | Permanently past its eligibility window; retained for reporting and audit but no longer evaluated. |
Because state sits within the same configuration object as the offer’s rules, priority, and caps, changing state controls eligibility across every channel and journey that could reference the offer. There is no separate system to update in parallel.
Externally-defined offers
Where an offer’s lifecycle is owned in an external loyalty or offer-management system rather than directly in Insider One, that system governs the state transitions, and Insider One reflects the current state via API, so targeting and messaging stay consistent with the system of record.
Approver gating & role-based control
Control over who can create, edit, or remove an offer configuration is governed by Insider One’s role-based permission model. Roles can be scoped so that, for example, a user can view an offer’s configuration and performance without changing its rules, caps, or state; the same pattern is used elsewhere in the platform to separate visibility from edit rights.
Changes to an offer’s configuration are versioned and timestamped, giving a record of what changed, when, and by whom.
A formal multi-stage approver-gating step ahead of specific state transitions (for example, requiring senior sign-off before an offer moves from Draft to Active) can be scoped as part of implementation, layered on top of this existing role and versioning foundation. It isn’t a native, out-of-the-box workflow today.
Budget & inventory guardrails
Spend, redemption, and inventory limits are configured as part of the same offer configuration, for example, the total number of times an offer can be shown or the number of times it can be redeemed. As each customer is evaluated for eligibility, Insider One checks the current count against the configured cap and suppresses the offer once that cap is reached; the count updates immediately, so the cap is respected for the next customer evaluated, with no batch delay.
Where redemption or stock truth lives in an external offer or loyalty platform, that ground truth is kept current in Insider One via a near-real-time feed, so caps reflect what has actually been redeemed or consumed rather than a stale snapshot.
Guardrail | How it works |
|---|---|
Spend / redemption cap | Configured limit on total offer usage; checked against the current count at each customer evaluation. |
Stock cap | Limit tied to available inventory; sourced from a near-real-time feed where stock truth sits in an external system. |
Real-time consumption visibility | Current count updates as the offer is shown or redeemed, so the next evaluation reflects the latest state. |
Auto-suppression | Once a cap is reached, the offer is automatically excluded from further eligibility checks — no manual step required. |
Consumption approaching a configured cap can be surfaced as an alert ahead of the hard cutoff, giving the offer owner visibility before the offer auto-suppresses, rather than only finding out once it stops serving.
Override & audit trail
Every change to an offer’s configuration, its state, rules, priority, or caps is versioned and timestamped, including manual overrides such as raising a cap or reactivating a paused offer. This gives a defensible record of what was changed, when, and by whom, which can be reviewed independently of the live configuration.