Feature Ideas

Every custom demo deck we build already contains a fully specified loyalty program. Campaign names, subtitles, descriptions, instruction text, mechanics, prize sets, product names, prices, point costs, tier names and benefits, start and end dates, the brand palette, and a complete set of images cropped to the exact dimensions the app uses. Proposed solution A single export from the demo kit shoud be able to produce a backoffice-ready campaign setup based on: A structured content file (JSON or CSV) with one record per campaign: mechanic type, title, subtitle, description, instruction text, start and end dates, prize labels, product names, prices, point costs, plus tier names and benefits. An image bundle with every asset exported at the dimensions the backoffice expects, named by campaign type, containing: campaign header, banner, prize 1 to n, reward shop item, punch card empty and full states, stamp icon, logo. The brand palette as hex values. Scope Internal tool only, not client-facing. Users are CSM/Developers, and whoever handles implementation and onboarding. Why now The rebrand side is already automated. Decks are now built end to end from the client's real brand assets, so the copy and imagery inside them is accurate and genuinely reusable rather than placeholder content. The export is the missing half of that pipeline. Value Cuts campaign setup time during implementationRemoves transcription errors between what was sold and what goes liveCould make the demo deck the single source of truth from pitch through go-live Open questions and dependencies Needs a definition of the backoffice's expected image dimensions and required fields per campaign typeBest case, the backoffice accepts a bulk import. If not, this is still an export a human pastes in, which saves most of the effortDecide whether to target the backoffice import format directly or a neutral intermediate format that survives backoffice changes

As a loyalty app user, I want to see a breakdown of my purchase in the app, including item descriptions and receipt/transaction numbers, so that I can verify my purchases and have a clear record of what I bought and earned points on. Current Behavior: After completing a purchase, the app only shows a general transaction summary. Item-level descriptions and receipt numbers are not visible to the end user. Expected Behavior: Users should be able to view: Receipt / Order Number (transaction reference), Item Descriptions (product name per line item), Quantity per item, Unit Price and Total Price per item

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.

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

Data Bridge triggers have no "Reason" field, unlike other campaign trigger and action (e.g Reward value..). This means transactions created via Data Bridge that give out point value show no description in the app or backoffice transaction history. Since Data Bridge is the direction we're moving toward for these integrations, this gap will keep recurring. REQUEST: Add a Reason/Description field to the Data Bridge trigger config (static text, optionally a JMES expression for dynamic values such as OrderID), store it on the resulting transaction, and show it in both the app's and backoffice's transaction history.

Allow users to save campaign/game configurations as drafts in the backoffice, so they can pause mid-setup and finish later without losing progress or accidentally publishing an incomplete configuration.

Job Story When I need to bring data from an external source into Neoday, I want to import a data file through the backoffice, So I can have that data available in the system without manual entry in the database by a developer High-level feature specs Phase 1: Backend capability to import data files Phase 2: Backoffice UI for self-service imports, including: Immediate format validation on uploadColumn mapping to system fieldsData preview before committingImport mode selection (add / update / replace)Post-import report (imported / skipped / failed) Privacy/Security considerations Files will not contain personal data (confirmed for current scope).

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.

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!