Feature Ideas

Milestone items are currently completed strictly in sequence, and only the active milestone item evaluates an incoming Data Bridge event. The next item is only handed out to the member after the previous one is marked as completed. As a result, when a single bill contains the eligible products for milestones 1, 2 and 3, only milestone 1 is completed. The member has to make two more separate purchases to complete milestones 2 and 3, even though they already bought the qualifying products. Spend-based milestones do not have this limitation, because every item tracks the same value (bill total). With “Transfer value” enabled, the overshoot carries into the next milestone and one large bill can complete several milestones. Item or category-based milestones track different products per item, so there is no shared value to carry over. Clients expect both milestone types to behave the same way and report the difference as unexpected behaviour. Proposed Solution Add an option on the milestone collection (for example a toggle: “Evaluate the same transaction for the next milestone item”). When it is enabled, after an item is completed and the next item is activated, the same Data Bridge event is re-evaluated against the newly active item, and so on down the chain. Current Workaround and Its Limits The steps can be built as separate regular campaigns running in parallel, each with its own product filter, so one bill completes all of them. This loses the milestone progress bar, does not enforce order, and needs extra helper set-up for a “complete all steps” bonus. It also adds configuration effort and risk of duplicate rewards if filters overlap.

The UI fails to distinguish between a member's total points balance and their tier-qualifying points, both of which are labeled simply as "points". This lack of distinction causes widespread confusion and frustration during review periods, as members experience tier downgrades while their overall point balance remains untouched. Furthermore, the existing tier progress bar only shows tier thresholds without displaying the member's exact position, gap to the next tier, retention threshold, or upcoming review date, leaving members unable to anticipate downgrades. To resolve these issues, the feature request proposes giving qualifying points a distinct, configurable name (such as "Tier points") with a strict rule that both values never share the same label on a single screen. Additionally, it recommends redesigning the tier progress bar to incorporate the member's current position, the gap to the next tier, a retention threshold marker, and the next review date. Finally, the points overview screen should be split into two clear blocks separating the total balance (suppressed for clients without redemption) from the qualifying tier points and their associated review window.

As the platform expands its Tiering service capabilities, there is an increasing need for a dedicated analytical framework to track performance across different levels. Currently, the lack of tier-specific reporting creates a gap in evaluating the success of these offerings. Reports such as A. Tier Liquidity & Funnel Velocity (Are customers getting stuck?) B. Revenue & Habit Validation (Does tiering actually make them spend more?). C. Campaign Attribution & "Laddering" (What actually drives upgrades?)

We would like to have Time-based One-Time Passwords (TOTP) via authenticator apps (e.g., Google Authenticator) for all backoffice logins. This adds a dynamic security layer that requires users to provide a time-sensitive, 6-digit code in addition to their standard credentials.

Currently, campaign configuration is a "one-way" process. When clients set up complex, state-dependent campaigns—such as an Advent Calendar—for testing purposes, they are unable to reset the campaign state once testing is complete (e.g., once "boxes" are opened). As a result, if a client needs to perform a clean test run or re-run a campaign, they are forced to manually delete or reconstruct the entire campaign configuration from scratch. This is time-consuming, prone to manual errors, and creates a significant barrier to effective quality assurance. Proposed Solution Implement a "Duplicate/Clone" button within the campaign overview. This functionality would allow a user to create an exact copy of an existing campaign’s configuration, rules, and settings, but with a "clean slate." Key requirement: The duplicated campaign should carry over all structural configurations (dates, reward triggers, UI elements) but exclude all historical test data, user interaction logs, and state-specific variables (e.g., "opened" box states). Expected Benefits Increased Efficiency: Drastically reduces the time required for clients to set up testing cycles or launch repeat campaigns. Error Reduction: Eliminates the risk of misconfiguration that comes with manually rebuilding complex campaigns from memory. Improved UX: Encourages clients to thoroughly test their configurations, knowing they can easily spin up a fresh environment without starting over.

We are seeking to enhance our segmentation to allow for age-based targeting. Currently, while we often capture a user's Date of Birth (DOB), we lack the logic to convert this data into a functional "Age" attribute for audience grouping. Use Case Targeted Demographic Campaigns: As a Backoffice User, I want to create segments for specific age ranges (e.g., 18–25, 30–45, or 65+) so that I can deliver age-appropriate rewards, content, and product recommendations. Requirements Dynamic DOB Condition: Implementation of a "Date of Birth" segment condition that calculates age in real-time based on the current date. Operator Support: The ability to use operators such as: Between (e.g., Age is between 18 and 30). Greater than / Less than (e.g., Age is > 50). Equals (e.g., =30) Data Validation: Logic to handle and exclude invalid date formats or "null" values to ensure segment accuracy.

Right now there is no way to push coupons directly to a specific group of users from the backoffice. If we want to reward or target a segment with a coupon offer, we have to work around the system. We need the ability to select one or more existing coupons, assign them to a segment, and optionally trigger a notification — all from the backoffice. On the user side, these coupons should appear in a dedicated "Personal offers" section, kept separate from coupons earned through campaigns, which stay under "Earned coupons". Example Epic Jurgen made: PUT-4238

La Place has observed an increase in potentially fraudulent behavior involving employees from La Place. Specifically, these users are executing a high volume of transactions within a very short timeframe. Our working assumption is that employees are having their personal apps scanned on behalf of guests, which violates the intended use case of the application. Currently, detecting and auditing these suspicious transactions is an entirely manual process, making it impossible for the team to review everything comprehensively. Proposed Solution / Requirements Implement an automated alert system that notifies the team when a user exhibits abnormal or potentially fraudulent transaction patterns. Example Criteria for Triggering Alerts: Multiple transactions occurring within a few hours. More than two (2) transactions executed in a single calendar day. Business Value / Acceptance Criteria Proactive Monitoring: Removes the reliance on manual, time-consuming audits to catch suspicious activity. Misuse Prevention: Helps prevent employees from sharing or using their app for guests outside intended policy terms. Acceptance Criteria: The system successfully flags and sends a notification when a user meets the defined threshold of high-frequency transactions within a given timeframe.

Why your idea is useful: It allows customer service teams to quickly fact-check a customer's loyalty status (e.g., verifying if a user is in the 'Gold' tier) when they reach out with questions or complaints.Who would benefit: Our clients' customer service departments and our own support/backend team, as it eliminates unnecessary internal support tickets.How should it work? When looking up a specific user account in the backoffice, the current loyalty tier should be clearly visible on their profile overview page.

add the following segmentation options: Optin Newsletter Yes / NoParticipation in X unique campaignsMade a purchase in a reward shopAgeNumber of participation is a single campaign (F.e, minimum of 5 participation)

When a customer's card needs to be linked, corrected, or removed from their account, I want to manage those cards myself from the backoffice user portal, So I can resolve the request immediately without depending on a developer.

To prevent Fraude it might be an idea to disable the functionality of creating screenshots from our app (like banking apps also have)

Tenure-Based Event Triggers and User Segmentation (e.g. 6-Month Anniversary) We are seeking to enhance our engagement capabilities by allowing the system to trigger automated actions based on a user’s Registration Date (tenure). This will enable "surprise and delight" workflows—such as sending vouchers or push notifications—at specific milestones (e.g., 180 days post-signup) without manual intervention. Proposed Functionality/Feature Time-Delayed Triggers: Ability to schedule an event trigger for a specific interval (days/months) following the registration_date. Tenure Segmentation: A new segmentation attribute that groups users by "Length of Membership" (e.g., Segment: Users registered exactly 180 days ago). Business Value Increased Retention: Automates the "Surprise and Delight" strategy to re-engage users at critical lifecycle milestones (e.g., the 6-month mark) to prevent churn. Operational Efficiency: Eliminates the need for manual CSV exports and recurring uploads to target users hitting specific membership anniversaries. Scalability: Allows for a "set and forget" loyalty strategy that scales automatically as the user base grows. Thank you!

We are requesting the inclusion of Average Value per Transaction (ATV) as a core metric within the Campaign Analytics dashboard. This metric is essential for measuring the direct impact of specific campaigns on customer spending behavior and determining if marketing efforts are successfully driving higher-value purchases. Metric Definition Metric Name: Average Value per Transaction (ATV) Source Data: This refers specifically to the total purchase value (gross spend) documented at the store/venue level. Currency Support: The metric should be able to reflect values in both loyalty currency (points) and flat currency (e.g., Euros), depending on the transaction type. Scope & Clarification To ensure data accuracy, this metric is defined as the actual amount spent by customers at the store/venues during a transaction. It is distinct from "points burned" and is intended to track the total checkout value from the POS system rather than just the redemption of loyalty rewards. Business Case & Objectives Performance Measurement: Allows the team to analyze whether a campaign is successfully increasing the "basket size" or average spend per visit. Impact Analysis: Provides a clear correlation between loyalty engagement and real-world revenue growth. Strategic Planning: Helps stakeholders identify which campaign mechanics (e.g., tiered rewards vs. flat discounts) are most effective at driving higher transaction amounts.

A proposal for a UI/UX enhancement for the Feedback Form management section in the Backoffice to improve organization and reduce operational clutter. Currently, there is no mechanism to remove or hide feedback forms once they have been configured in the backoffice. This presents a challenge for clients who: Test Configurations: Often create multiple test forms that become permanent fixtures in the overview. Manage Lifecycle: Have deprecated forms that are no longer in use but remain visible, creating an increasingly cluttered and unclear dashboard. Proposed Solution Add an "Actions" menu or dedicated buttons to the Feedback Form overview list, providing two options: Archive: Hides the form from the active list while maintaining historical data for reporting purposes. Delete: Permanently removes the form (this should ideally have a confirmation modal to prevent accidental deletion of active forms). Or can only remove feedback pages not in used. Expected Benefits Improved Interface Clarity: Allows clients to maintain a clean, relevant list of active forms. Reduced Human Error: Minimizes the risk of configuring or linking an incorrect/old test form by mistake. Streamlined Workflow: Simplifies form management, making it easier for clients to navigate and audit their existing feedback collection setup.