AMA — Membership Servicing Rebuild

Case study · Alberta Motor Association · 2022–Present

AMA agents service memberships all day: creating them, changing coverage, transferring, cancelling, reinstating. That work was spread across fragmented legacy systems. I rebuilt core servicing flows into one guided experience, and built the features that let staff act on both new and migrated records safely, while years of historical data were moved into the new platform.

This case study focuses on membership servicing: staff workflows, migrated-record compatibility, and the reliability layer behind enrollment, coverage changes, cancellations, and reinstatements.

customer + membership domains · 5 servicing flows · ~6K household sales/month

The problem

Servicing a membership meant jumping between separate customer, membership, and billing systems and leaning on legacy identifiers. The records themselves lived in an older platform. So the rebuild had a hard constraint: it had to keep working while those records were still being moved over, without losing history or breaking continuity for staff mid-migration.

What I built

My work covered the UI, APIs, data model, event workflows, and reliability handling.

Enrollment and checkout, including payment-provider integration and transaction confirmation.
Cancellation and refund flows with invoice previews, so staff see the financial outcome before committing a change.
Coverage-change flows with household context, associate members, and prorated pricing.
Much of the reinstatement experience: multiple paths, previous-membership validation, billing, and fulfilment.
The reliability layer beneath all of it: an event-driven workflow with validation, idempotency, retries, duplicate suppression, and a failure queue.
Compatibility for migrated records: lookup by legacy identifiers and preserved membership-number lineage, so old memberships stayed searchable and correct.

Architecture

Historical records are validated, linked, and moved into dedicated customer and membership domains. A unified API gives staff one consistent experience across migrated and newly created memberships, while billing stays synchronized through lifecycle events.

Why it's built this way. Rebuilding during a live migration changes how you build. Every operation had to be safe to retry and impossible to double-apply, because the same record might be mid-move. That's why the workflows lean on idempotency, retries, and a failure queue instead of assuming the happy path. And migrated records had to stay first-class, so I built the legacy-lookup and lineage compatibility to match.

Impact

Two domains, customer profiles and household memberships, brought into one servicing experience, with billing integrated as a supporting platform.
Staff moved from fragmented legacy workflows to one guided experience with transparent pricing and traceable lifecycle events.
Migrated and newly created records work through the same experience.
The rebuilt membership flows support a current run rate of roughly 6,000 new household membership sales/month.
Scope: work spanned the micro-frontend, serverless backend, database migrations, CI, and infrastructure, with heavy end-to-end coverage.

This membership app lives inside AMA's internal POS platform.

Read the platform case study → Back to Projects →

[M]Minesweeper

[P]Paint