Short answer
RaftLabs built OOHPOD Rewards in a 10-week fixed-price engagement. The CRM-connected rewards program software automatically reflected OOHPOD customer eligibility and gave customers a responsive web app for browsing rewards, claiming coupons, and entering competitions, while administrators managed users, campaigns, coupon inventory, banners, and reporting. From 7 October to 31 December 2024, the administration dashboard recorded 67 total users, 93 logins, 92 reward views, and 37 coupons claimed.
Engagement
The OOHPOD Rewards engagement
- End brand
- OOHPOD
- Sector
- Parcel delivery and logistics
- Initial timeline
- 10 weeks
- Engagement
- Fixed-price initial build
- Team
- Frontend, backend, PM, and QA
- Platform
- Responsive customer web app and administration platform
- Market
- Ireland
OOHPOD already had the customer relationship. What it did not have was a dedicated product for turning that relationship into useful, controlled rewards.
RaftLabs built OOHPOD Rewards as a focused customer benefit platform. Existing OOHPOD customers needed one place to browse offers, claim coupon codes, keep previously claimed rewards, and enter competitions. The operating team needed a separate administration surface for customer access, categories, rewards, coupon inventory, competitions, banners, notifications, and reporting.
The non-obvious requirement sat between those two experiences: rewards access had to follow the customer relationship held in the CRM. A new OOHPOD customer should be added to the rewards platform automatically. A departing customer should lose access automatically. The rewards product could not become a second, manually maintained customer register.
RaftLabs delivered the initial fixed-price build in 10 weeks. From 7 October to 31 December 2024, the platform recorded 67 total users, 93 logins, 92 reward views, and 37 coupon claims.
the starting point
From a rewards idea to an operable customer program
- OOHPOD had customers in its core systems but no dedicated rewards experience for them
- Reward access risked becoming a manually maintained list separate from the customer CRM
- Customers had no central place to browse available offers or retrieve coupons they had already claimed
- Operators needed a controlled way to publish rewards and competitions without turning every campaign change into development work
- Coupon inventory, claim rules, dates, categories, and campaign content had to remain understandable to the people running the program
- CRM-driven eligibility keeps rewards access aligned with the underlying OOHPOD customer relationship
- A responsive web app lets eligible customers browse rewards, claim coupons, review claimed offers, and enter competitions
- Unique and generic coupon models support different campaign rules without forcing one mechanic onto every partner offer
- An administration platform gives operators control of customers, rewards, competitions, categories, banners, notifications, and reporting
- The dashboard separates observable platform activity from activity that happens later on a partner's website or in a store
The product decisions an enterprise rewards buyer should examine
- 01
Keep the CRM as the authority for customer eligibility
The fastest way to create support problems in a customer-only rewards program is to maintain eligibility in two places. An OOHPOD account could change status in the CRM while the rewards platform continued to treat the person as active, or a new customer could wait for a manual import before seeing a promised benefit.
The delivered model treated eligibility as an integration concern rather than an admin preference. When the CRM identifies a new OOHPOD customer, the rewards platform adds that customer. When the customer leaves, access is removed. This keeps the loyalty experience downstream of the customer record instead of allowing it to become a competing source of truth.
- 02
Define a coupon claim separately from partner redemption
OOHPOD Rewards can record when a customer claims a coupon and receives its code. It cannot, without a partner integration, prove that the code was later used on the partner's website or at a store. The distinction changes what an operator can report and what a buyer should promise internally.
RaftLabs kept the observable event bounded to the platform: the customer opened a reward and claimed a coupon. The dated dashboard therefore reports coupon claims, not attributable partner sales. A future partner redemption integration would be a separate data contract with its own identifiers, status updates, reconciliation, and consent requirements.
- 03
Support different coupon rules without multiplying campaign workflows
Not every reward uses inventory in the same way. A generic coupon may expose the same value to multiple customers. A unique-coupon campaign needs an inventory of individual codes. Some rewards permit one claim per customer; others permit repeat claims.
The administration model separates coupon type from claim frequency. Operators can load unique codes, configure a generic code, set availability dates, publish or return a reward to draft, and let the platform apply the relevant claim rule. That is a more durable boundary than hard-coding a new customer flow for every partner campaign.
- 04
Give campaign operators control without giving up system rules
An admin panel is not useful merely because it has edit forms. Operators need to understand which rewards are live, how much coupon inventory remains, which customers have claimed an offer, and how a competition is configured. At the same time, the system must prevent an edit from bypassing eligibility or issuing a coupon outside the permitted rule.
The delivered administration surface covers customer management, reward and category configuration, coupon uploads, competitions, banners, notifications, FAQs, and reporting. The product owns validation and access rules; the operator owns campaign content and timing. That separation lets campaigns change without turning operating flexibility into uncontrolled behavior.
System flow
How CRM eligibility becomes a controlled rewards experience
The system keeps customer status, rewards operations, and measurable platform activity as separate responsibilities.
Source
Customer CRM
The CRM remains the authority on whether a person is an active OOHPOD customer.
Sync
Eligibility integration
Customer additions and removals are reflected automatically in rewards-platform access.
Experience
OOHPOD Rewards
Eligible customers browse offers, claim coupons, revisit claimed rewards, and enter competitions.
Operations
Admin and reporting
Operators manage campaigns and observe registrations, logins, reward views, coupon claims, and competition activity.
customer and operator workflows
What the 10-week initial build delivered
The initial release was deliberately focused on one operating loop: establish eligibility from the customer relationship, let the customer act on a reward, and give the operating team the controls and evidence needed to run the program.
CRM-driven eligibility kept membership current
The rewards platform does not ask an operator to decide manually who qualifies. Eligibility follows the CRM relationship. A customer who joins OOHPOD is added to the rewards platform; a customer who leaves is removed. This reduces the risk of stale access and avoids operating two competing customer lists.
For a comparable enterprise program, the acceptance criteria should also define retry behavior, delayed updates, reconciliation, and the support path when the CRM and rewards platform disagree. Those controls are integration requirements, not marketing features.
Customers could browse, claim, and retrieve rewards
Eligible customers can browse rewards by category, open the terms and redemption instructions, and claim a coupon. The claimed item remains available under My Rewards so the customer does not need to repeat the flow or recover the code from an email.
The platform supports generic and unique coupon models. That matters operationally: a generic code can support a broad offer, while unique inventory prevents the same issued value from being assigned to multiple customers when a campaign requires individual codes.
Operators could run rewards and competitions from one admin
The administration platform brings customers, categories, rewards, coupon inventory, competitions, banners, notifications, FAQs, and reporting into one operating surface. A reward can be drafted, scheduled through start and end dates, supplied with unique or generic coupons, and removed from customer view.
Competition management is kept distinct from coupon claims. Operators can create a competition, set participation rules, and review or shortlist entries without pretending that a competition entry is a reward redemption. The same separation makes reporting easier to interpret.
Proof
What the first dated dashboard window recorded
All four figures cover 7 October to 31 December 2024 and come from the OOHPOD Rewards administration dashboard.
| Result | What changed | Period or context | Evidence and limitation |
|---|---|---|---|
| 67 total users | The dashboard recorded 67 users during the selected window. | 7 October to 31 December 2024 | Measured in the administration dashboard. |
| 93 logins | The platform recorded 93 login events during the selected window. | 7 October to 31 December 2024 | Measured in the administration dashboard. |
| 92 reward views | Customers opened reward details 92 times during the selected window. | 7 October to 31 December 2024 | Measured in the administration dashboard. |
| 37 coupons claimed | Customers claimed 37 coupons inside OOHPOD Rewards during the selected window. | 7 October to 31 December 2024 | Measured in the administration dashboard. Claimed means the coupon was issued inside OOHPOD Rewards. |
Need rewards program software that follows your CRM and campaign rules?
The lesson
Eligibility and redemption are different system boundaries
A reliable rewards platform answers two separate questions. First: should this person have access? That answer belongs to the customer system of record. Second: what happened after the customer saw an offer? The rewards platform can measure views and coupon claims, but final partner usage requires another integration.
Keeping those boundaries explicit prevents three common mistakes: stale customer access, campaign reports that overstate what was measured, and a roadmap that assumes partner redemption data will appear without a data-sharing contract. Buyers should define both boundaries before choosing between configured loyalty software and a custom loyalty platform.
stack
Why this stack fit the operating model
- 01Next.jsNext.js powers the mobile-responsive customer experience, giving reward browsing, account access, and coupon retrieval a fast web delivery model without requiring separate native applications for the initial release.
- 02React and Ant DesignThe administration application uses React with Ant Design to support dense operating workflows such as customer search, reward configuration, coupon inventory, competitions, and reporting.
- 03Hasura GraphQLHasura supplies a consistent GraphQL access layer for customer eligibility, reward configuration, coupon inventory, claims, competition entries, and activity records.
- 04AWS LambdaServerless functions handle backend workflows and integration work without requiring the initial program to operate a permanently provisioned application server for every task.
- 05Vercel and MetabaseVercel delivers the customer-facing Next.js application, while Metabase gives operators reporting access to registrations, logins, reward activity, coupon claims, and competition participation.
Evidence and limitations
Reviewed 20 September 2026
- Engagement and scope: the initial fixed-price build took 10 weeks. Later feature work sits outside that delivery duration.
- Delivered workflows: based on retained delivery records, the product specification, and owner-confirmed details.
- Results: the four activity figures come from the OOHPOD Rewards administration dashboard for 7 October to 31 December 2024.
- Measurement boundary: a coupon claim is recorded inside OOHPOD Rewards. Confirming use with a reward partner would require a separate redemption integration.
Questions buyers ask before building rewards program software
RaftLabs built a mobile-responsive customer web app and a separate administration platform for OOHPOD Rewards in 10 weeks. Eligible OOHPOD customers can browse rewards, claim coupons, retrieve claimed offers, and enter competitions. Operators can manage customers, categories, rewards, coupon inventory, competitions, banners, notifications, FAQs, and reporting.
The CRM remains the source of truth for customer eligibility. When a new OOHPOD customer joins, the integration adds that person to the rewards platform. When the customer leaves, the integration removes access. This prevents the rewards admin from becoming a second customer database that operators must reconcile manually.
It measures a claim inside the rewards platform: the customer selected the reward and received or revealed its coupon code. It does not prove that the coupon was later used on a partner website or in a store. Measuring final use requires a partner redemption integration and a shared identifier that can reconcile the two events.
For 7 October to 31 December 2024, the administration dashboard recorded 67 total users, 93 logins, 92 reward views, and 37 coupons claimed.
The fixed-price initial build took 10 weeks. That duration covers the initial customer rewards web app, administration platform, core campaign controls, and CRM-connected eligibility described here. Later features are outside the initial timeline. Comparable timing depends on identity, CRM readiness, reward rules, partner data, and approval speed.
Define the customer system of record, eligibility events, synchronization timing, retries, reconciliation, coupon types, per-customer claim limits, inventory exhaustion, expiry, and the difference between a platform claim and partner redemption. Also define which campaign changes operators may make without engineering and which evidence the dashboard must retain.
Use configurable loyalty software when its identity, eligibility, reward, reporting, and partner models fit your operation. Consider custom development when CRM status controls access, coupon rules differ by campaign, operators need owned workflows, or partner and reporting boundaries cannot be configured safely. Review our loyalty program development approach and loyalty software cost guide before scoping.
Related work
