Arc'teryx Transactional CRM Infrastructure
When a shipment email fails, customers do not blame the template. They blame the brand.
Strengthening transactional reliability
≈25%
fewer observed quality failures
Automated validation and clearer ownership improved messaging quality across a high-volume, multi-platform communications ecosystem.
Selected technical and operational details have been generalized.
Overview
A missing order confirmation is not a marketing problem. It is a trust problem, and at Arc'teryx scale, even rare failures reach a lot of inboxes.
Transactional messages were generated across Salesforce Marketing Cloud, Narvar, commerce systems, and Okta. I led the program to modernize priority journeys, clarify ownership, and improve reliability across an ecosystem sending more than 50 million customer emails a year.
Event-to-inbox architecture
Source events
- Commerce
- Fulfilment
- Inventory
- Identity
Platforms
- Narvar
- SFMC
- Okta CIAM
Customer messages
- Order & delivery
- Availability
- Account & security
Source events
- Commerce
- Fulfilment
- Inventory
- Identity
Platforms
- Narvar
- SFMC
- Okta CIAM
Customer messages
- Order & delivery
- Availability
- Account & security
Different communication types used different platform paths, not every event flowed through every system.
The challenge
Each email looked simple to the customer. Behind it sat events, field mapping, business rules, templates, and handoffs across several platforms, often with no single owner when something broke.
Fragmented ownership
CRM, commerce, engineering, guest services, security, and vendors all touched the journey. Defects bounced between teams while customers waited.
Zero tolerance for failure
A late promo email is annoying. A missing shipment or account message creates support volume and erodes confidence fast.
Scale and compliance
Changes shipped inside a high-volume production environment with strict privacy, security, accessibility, and brand requirements.
One email. Multiple systems.
- 01Source event
- 02Customer data
- 03Order or account data
- 04Business rules
- 05Event routing
- 06Template logic
- 07Localization
- 08Consent and classification
- 09Delivery platform
- 10Monitoring
- 11Production support
- Fragmented ownership
- Low tolerance for failure
- Cross-platform dependencies
- High production volume
- Security and compliance requirements
My approach
1.Prioritized moments where trust was on the line
I ranked journeys by the customer questions they answered (order status, delivery timing, inventory, account security), not by which template was easiest to ship.
2.Mapped event to inbox
For each communication we documented triggers, data requirements, suppression logic, failure handling, and production ownership. Dependencies surfaced before launch, not in production.
From customer action to dependable communication
- 01
Customer or system action
- 02
Source event
- 03
Data validation
Required fields · Customer matching · Order or product details
- 04
Routing and orchestration
- 05
Business-rule evaluation
Eligibility · Suppression · Timing · Duplicate prevention
- 06
Template rendering
Dynamic content · Localization · Accessibility · Links and actions
- 07
Quality controls
Expected-path testing · Edge cases · Failure states · Production readiness
- 08
Customer delivery
3.Matched each message to the right platform
Narvar owned priority post-purchase flows tied to fulfilment. SFMC remained central for orchestration, templates, and broader lifecycle messaging. Okta stayed authoritative for identity and account communications.
4.Standardized requirements and testing
A consistent requirements format covered triggers, fallbacks, localization, accessibility, and launch criteria. Automated validation helped cut observed messaging and quality failures by approximately 25% in a high-volume environment.
Reliability designed before launch
~25% reduction in observed messaging and quality failures
- 01
Trigger validation
Did the correct customer or system event occur?
- 02
Data validation
Are all required customer, order, product, and account attributes present and accurate?
- 03
Rule validation
Are eligibility, timing, suppression, and duplicate-prevention rules working correctly?
- 04
Content validation
Does dynamic content render correctly across templates, devices, and languages?
- 05
End-to-end testing
Does the complete journey work across every participating platform?
- 06
Production readiness
Are ownership, monitoring, rollback, escalation, and support processes defined?
More structured requirements and automated validation made testing more repeatable across a high-volume CRM environment.
The solution
The operating model connected upstream events to the right orchestration layer and production controls.
Post-purchase through Narvar
Five priority post-purchase triggers launched with coordination across commerce data, fulfilment events, templates, QA, and security readiness.
Launching five priority post-purchase triggers
Order confirmed
Source event
Required data
Platform handoff
Customer message
Processing
Source event
Required data
Platform handoff
Customer message
Fulfilment update
Source event
Required data
Platform handoff
Customer message
Shipment progress
Source event
Required data
Platform handoff
Customer message
Delivery outcome
Source event
Required data
Platform handoff
Customer message
The implementation was managed as part of the wider CRM and commerce ecosystem, not as an isolated vendor deployment.
Inventory and identity
Back-in-stock messaging moved to a clearer transactional model with explicit trigger and duplicate-prevention rules. Okta-backed account communications received the same rigour because they touched security-sensitive actions.
Clearer platform boundaries
SFMC, Narvar, Okta, and commerce systems each owned what they were best positioned to support, with shared governance instead of overlapping ambiguity.
Three transactional communication domains
Post-purchase
Primary platform
Narvar
Customer need
Understand what is happening after an order is placed.
Reliability concerns
- · Event timing
- · Order data accuracy
- · Duplicate prevention
- · Status sequencing
Product availability
Primary platform
Commerce, inventory, and CRM
Customer need
Know when a requested product becomes available.
Reliability concerns
- · Inventory accuracy
- · Timeliness
- · Duplicate notifications
- · Out-of-date availability
Identity and account
Primary platform
Okta CIAM
Customer need
Complete account and security-related actions safely.
Reliability concerns
- · Security
- · Expiration states
- · Identity accuracy
- · Failure recovery
Impact
Five Narvar post-purchase launches, broader modernization across inventory and identity journeys, roughly 25% fewer observed quality failures, and clearer ownership across 50M+ annual emails made the system more dependable at scale.
50M+
Annual customer communications in the CRM ecosystem
5
Priority Narvar post-purchase triggers launched
3
Major transactional communication domains modernized
~25%
Reduction in observed messaging and quality failures
Customer trust
More dependable communications during important order, availability, and account moments.
Platform clarity
Clearer responsibilities across Narvar, Salesforce Marketing Cloud, Okta, and source systems.
Delivery confidence
More repeatable requirements, testing, and production-readiness practices.
Risk reduction
Integration and failure dependencies identified earlier in the product lifecycle.
What I learned
Patterns that stuck with me after owning transactional CRM at scale:
Transactional messaging is a product surface
Customers experience email, web, and service as one product. Communications need the same product thinking as any other feature.
The trigger matters more than the template
A well-designed message fails if it is late, incomplete, misaddressed, or duplicated. The critical decisions happen upstream of the inbox.
Reliability depends on ownership
When several systems participate in one journey, each stage needs explicit ownership, or defects move between teams while customers wait.
Platform boundaries should follow the problem
Centralizing everything in one tool creates new problems. Assign each platform what it is best positioned to support.
Failure scenarios deserve first-class requirements
Suppressions, retries, fallbacks, and escalation paths should be designed from the beginning, not discovered in production.
Continue reading
01
Arc'teryx Membership & Customer Engagement Platform
Connecting guest relationships across retail, digital, and service without defaulting to another points program.
03
RBC Avion Rewards Platform & Payments
Opening Avion to non-bank members meant building money movement customers never had to think about.
04
Aeroplan Co-Brand Cards & Digital Growth
Co-brand card growth across three issuers: one customer journey, many partner handoffs.