Implementation Roadmap
This roadmap describes the typical sequence to launch a wallet program with The Wallet Crew. It starts at contract signature and ends at go‑live, with an agile delivery approach and small, testable increments.
Real-world examples
A retail Brand launches a loyalty card and focuses first on POS scanning, then adds CRM campaigns.
A venue integrates ticketing first to ensure entry works, then adds post-event engagement.
A Brand replaces plastic membership cards with a digital pass, using a phased rollout per region.
A Brand starts with a single “core” template, then adds seasonal or event-specific templates.
Roadmap overview
Most wallet projects succeed when operations lead the design. The pass must work at the point of sale or at the gate before it becomes a marketing channel. The Wallet Crew therefore prioritizes early validation of the end‑to‑end chain: source systems → pass data → distribution → wallet installation → redemption.
The sequence below is the default. Some steps can overlap. The “lotissement” approach stays the same: ship small increments, validate quickly on real devices, then expand scope.
Project phases (contract → go-live)
2) Requirements collection (atelier)
The Wallet Crew runs a dedicated atelier to capture Brand needs and constraints. It is a working session, not a presentation. The goal is to converge on a first “minimal viable” wallet experience.
The atelier usually covers pass use case, distribution channels, redemption/scanning constraints, required data fields, consent/GDPR expectations, and reporting needs.
3) Technical setup (tenant + wallets + custom domain)
This phase makes the platform ready for secure testing and future production issuance.
It typically includes:
Tenant provisioning (staging and, when relevant, production).
Apple Wallet configuration (certificates, push keys, signing identity).
Google Wallet configuration (issuer account access, service account / API credentials).
Custom domain setup for branded links and hosted pages, when required.
Related docs:
Wallet provider setup: Apple & Google wallet
Apple certificates: Apple Wallet certificates
Google issuer setup: Google Wallet account
Custom domain: Configuring Custom Domain
4) IT architecture definition (system-of-record and data ownership)
This phase defines where The Wallet Crew sits in the overall IT landscape. It also clarifies which systems remain the source of truth for each data element displayed on the pass.
The key decision is the data flow: what triggers pass creation, how updates are computed, and how identifiers link a pass to Brand systems over time.
Related docs:
Data model and identifiers: Structure
5) Project definition and lotissement (agile increments)
This phase turns the scope into shippable lots. Each lot should be testable without future work. This reduces go‑live risk and avoids “big bang” rollouts.
A common breakdown is:
Lot 1: one template + one distribution channel + one redemption path.
Lot 2: updates lifecycle (field refresh, status changes, deactivation rules).
Lot 3: segmentation, analytics, and operational tooling.
Lot 4: marketing automation, notifications, and personalization at scale.
6) User experience flow (install → present → update)
This phase defines the customer journey and the operational journey. It includes entry points (“Add to Wallet”), install screens, fallback flows (desktop → QR), and how the pass is retrieved later.
Distribution choices typically map to these docs:
7) Pass configuration (templates + fields + barcode)
This phase translates the UX and data model into a pass template configuration for Apple Wallet and Google Wallet. It covers branding assets, field layout, links, and barcode/QR payload.
Template configuration lives under:
Design reference: Card design (colors, images, and fields)
8) Connect core tools first (ticketing, POS, CRM/loyalty)
The Wallet Crew recommends connecting the core operational systems before adding marketing layers. Wallet is a credential. It must work reliably where the pass is used.
This phase usually delivers:
A working creation/update feed from core systems.
A stable identifier strategy (membership number, ticket ID, gift card code, …).
A validated redemption flow in real conditions (scanner, POS, entry gate).
Once this is stable, marketing automation can be added without risking operations.
9) Add marketing and engagement (optional, after core validation)
This phase adds lifecycle engagement such as wallet notifications, geolocation, and marketing automation connectors. It is easier to iterate once core issuance and redemption are stable.
Entry points:
Notifications: Push notifications
Location triggers: Geolocated Notifications
Marketing connectors: Marketing automation
10) Go-live and operations
This phase completes production readiness: monitoring, support runbooks, and controlled rollout. It also defines how changes are shipped after go‑live (template updates, field additions, new lots).
Typical validation includes a production pilot, real-device checks on iOS and Android, and scanning tests in representative environments.
Common deliverables (what “done” looks like)
At go‑live, the minimal expected package usually includes one pass template, one distribution flow, and one operational redemption flow. It also includes a clear update strategy, so the pass remains trustworthy after installation.
As the program scales, deliverables expand to additional templates, segmentation, reporting, and optional engagement features.
FAQ
Can the project start before Apple/Google accounts are fully approved?
Yes, in most cases. Requirements, UX definition, and template design can start immediately. Wallet provider approvals and credentials must be completed before production issuance.
Why does The Wallet Crew recommend connecting core systems before marketing tools?
Because wallet is used in operational moments. If POS or ticketing redemption is unstable, marketing amplification increases support load. Once core issuance, updates, and redemption are reliable, marketing automation and notifications can be added safely.
Can the scope be limited to a single template for the first release?
Yes. A single template is often the best first lot. It keeps the data model and governance simple, and it enables faster validation on devices and in stores/venues.
Last updated