One brand. A world of loyalty.

The scenario

A consumer buys a qualifying Coca-Cola product at Merchant A and earns a reward. Later, they redeem it at Merchant B. The experience should be clear at checkout, economically viable for the brand and fair to both merchants.

Design a global vision and a deliberately small pilot in one market. Treat merchant, acquirer, terminal, payment application and market support as constraints to validate—not universal capabilities.

The data question you must answer

A payment amount and card fingerprint do not prove that a specific Coca-Cola product was purchased. Explain the item-level evidence or integration your design needs, how you validate eligibility, and what you would do when the required data is unavailable. Consider card changes and wallet tokens without assuming that a card identifier is a universal person identifier.

Show three connected perspectives

1. Customer: enrolment/consent, eligible purchase, reward earned, balance and cross-merchant redemption, with useful failure and refund states.
2. Merchant: eligibility, checkout flow, funding visibility, reconciliation, support and a disputed or reversed transaction.
3. Brand/programme operator: programme rules, funding caps, merchant participation, pilot performance, fraud and a stop/pause decision.

What to submit

1. Standalone HTML prototype: one file with embedded styles/scripts and synthetic data. Include clickable state changes; prioritise product clarity over visual polish. No production integrations or live payments.
2. Product thesis: users, problem, value exchange, pilot scope, non-goals, assumptions and discovery questions.
3. Three epics and six user stories: prioritisation, dependencies, and at least two testable Given/When/Then criteria per story. Include a reversal and a failure case.
4. Economics and measurement: reward liability, brand funding, merchant settlement, currencies/market differences, incrementality, fraud controls and success/guardrail metrics.
5. AI and test log: tools, representative prompts, what you changed or rejected, tests performed and known limitations. Building without AI is also acceptable.

Useful constraints

• Assume there is no universal SKU feed. Propose one or revise the reward model honestly.
• Handle duplicate events, refunds after redemption, intermittent connectivity and a programme budget that runs out.
• Minimise data collection. Do not include raw card numbers, real customer information or employer-confidential materials.
• List what you would investigate about consent, retention, currencies, tax and local programme rules with the relevant specialists.
• Use the tool guidance in your application. Explain how you would transfer epics and stories into Zeal’s working tools.

In the live defence

You will have 10 minutes to demonstrate, 20 minutes to defend the decisions, 15 minutes to respond to a changed constraint and revise a story, and 15 minutes for a two-way discussion. Be ready to change your mind when the evidence changes.