Skip to main content
Anjelika Tan
Back to selected systems

Client platform and live operations

Building and operating a multi-region brokerage loyalty programme

Led the product and integration workstream for a multi-region brokerage loyalty programme, translating client goals into embedded experiences, data contracts, campaign mechanics, operational tooling and automated fulfilment.

My role
Client-facing product and integration coordination across stakeholders, engineering, QA, portal, data and operations teams
Scope
Data integration, embedded experiences, automated fulfilment and programme operation
Team
Client stakeholders, product, engineering, QA, portal and data teams
Delivery
Live multi-region operation with ongoing incident recovery
Evidence type
Bounded operational check
Observed result
In one reconciliation window, 66 trading-credit orders had 66 matching success messages with no missing message or duplicate in that comparison. A later 19-order gap exposed the limit and triggered further investigation.

Case Study 01

How the work unfolded

This case shows account-level product work rather than a single feature. The programme only worked when client goals, platform rules, portal behaviour, source data, fulfilment automation and support operations stayed connected.

Problem

One client programme crossed data integration, identity, embedded widgets, Store fulfilment, campaigns, regional experiences and live support, with different teams owning each technical boundary.

Decision

Treat the account as one product lifecycle: make the data and business rules explicit, connect each team through testable contracts, and design monitoring and recovery into the operating model.

Observed result

The programme reached live multi-region operation across embedded reward experiences and automated trading-credit fulfilment, with reconciliation and incident evidence used to tighten the product after launch.

Sanitized product artifact

Account lifecycle

A sanitized view of the product boundaries that had to work as one programme.

  1. 1Data and identityField mapping, account matching and launch risks
  2. 2Member experienceAuthenticated regional reward surfaces
  3. 3FulfilmentEligibility, trading-credit automation and order states
  4. 4OperationMonitoring, reconciliation, support and recovery

My contribution: Connected client goals and incidents to product rules and testable team handoffs.

Observed result or limit: Live programme use is proven; the 66-to-66 check was bounded and a later 19-order outage remained visible.

Context

The client ran a brokerage loyalty programme across multiple regions. Members used embedded rewards, Store, milestones, campaigns and games, while client teams needed data integration, fulfilment, reporting, permissions and support controls behind those experiences.

What I owned

I was the practical client-facing Platform PM and product operator for the programme. I translated goals and incidents into product rules, coordinated client stakeholders with engineering, QA, portal, data and operations teams, and followed the work from discovery into launch and live recovery. I did not own the engineering implementation alone.

How the system evolved

Phase 1: Make the data and identity risks visible

The programme depended on client trading data, member identity and regional configuration. Before launch, field mapping and data-quality gaps had to be treated as product constraints rather than hidden integration details.

What changed

  • Snowflake approach validation and field mapping
  • Identity and duplicate-data risks surfaced before launch
  • Loyalty, redemption and outstanding-liability reporting needs
  • Client discovery on catalogue, permissions and support workflows

Important decision

Keep uncertain or incomplete source data visible in the launch plan instead of designing the member experience around an assumed clean feed.

What I shaped

I worked directly with client, data and engineering stakeholders to turn field-level questions into product rules, blockers and follow-up decisions.

Campaign and operational scope

The breadth matters because each surface depended on the same member identity, reward rules and operating evidence.

  • Defined campaign instrument scope, deposit eligibility, counting boundaries, timezone rules, privacy and widget permissions.
  • Supported weekly ranking and winner operations alongside refunds, status correction and entitlement restoration.
  • Used client discovery to clarify coin expiry, currency liability, catalogue APIs, permissions and support needs.
  • Kept regional and language differences visible instead of treating one portal configuration as universal.

Evidence and limits

Client and internal names are generalised. Any screenshots, direct quotes or identifiable operational records require permission and redaction before publication.

  • Authenticated Store, Milestone, Currency Overview, quest, rewards-log, leaderboard and mini-game experiences reached live multi-region use.
  • Trading-credit automation reached live launch and was reconciled through order and message evidence, but the 66-to-66 window was not full downstream broker proof.
  • A later 19-order failure and recurring fixture issues show that reliability was not yet repeatable.
  • The portfolio does not claim measured retention, revenue, conversion or sustained automation success.

What I would change now

A campaign handoff ran two days late, an early rule missed a demo-account exclusion, I confused two similarly named boosters before correcting them, and some fixture issues recurred. The lesson is not that broad ownership is heroic. It is that the operating model needed more repeatability and less dependence on personal recovery.

  • Set clearer work-in-progress limits and assign durable operational owners before launch.
  • Consolidate fragmented handoffs into one versioned programme contract and evidence dashboard.
  • Add earlier rule reviews for exclusions, naming and campaign fixtures.
  • Define outcome and reliability measures with the client before rollout.