The context: a regulated, subscription-based business scaling across Europe

Two Wombats runs Shopify for transactional emails and Klaviyo for their growth and marketing. That’s common. What is less common is the convergence of (1) subscription growth ambition, (2) multi-language expansion, and (3) regulated-market consequences when language errors carry real risk.

Meet Dave Walker: developer brain, marketer instincts, and unusually precise taste

Dave has a marketer’s instinct for leverage. He knows where the attention is, and he refuses to waste it.

He also knows the trap teams fall into once they realize that:

So Two Wombats uses transactional emails with restraint. They treat each one like a product moment: deliver the expected value first, then add one additional action that fits the moment and doesn’t feel like an ad.

Their transactional sequence is intentionally simple. Four emails, each with a specific objective. The first is designed to prevent customer support issues (a growth lever disguised as operations). The next emails introduce loyalty and referrals in ways that align to the shipment journey.

Dave’s model is subtle. His execution of it is not, it’s precise and decisive.

Why Dyspatch was the only option for Two Wombats

When Dave describes his workflow, he doesn’t describe “email creation.” He describes a modular build pipeline.

He can hand off the CSS layer of a block to one person, the dynamic logic to another, and recombine without losing structure. This matters more as the program grows: more blocks, more languages, more touchpoints, more experiments—without creating a giant, fragile HTML artifact nobody wants to touch.

Dyspatch, in Dave’s view, is valuable because it respects how modern teams ship work: specialized contributors, modular components, and controlled deployment.

That philosophy also shows up in their plan: they’re redesigning everything (“version two”), then adding countries and languages steadily afterwards. The redesign isn’t the hard part. The hard part is rolling change forward cleanly across everything that exists.

Without block-level localization and modular assembly, every experiment would require duplicating emails across languages, revalidating compliance, and coordinating fragile HTML changes. That kind of overhead would make most of these experiments impractical

The standout metric: 64% loyalty uptake (via the simplest incentive we’ve seen all year)

Two Wombats’ loyalty program isn’t points. It’s not “700 points = mystery reward.”. It’s intentionally transparent and easy to understand.

Their numbers prove that it’s working: 64% of users opt into the loyalty program.

And the most clicked element in their entire email program? A banner that tells you exactly what you have, in one glance:

How Dyspatch fits (and why this is not about features)

Here’s the part that surprised us: Dave barely cares about “emails” as finished artifacts. He cares about blocks as a system. And he likes Dyspatch because it mirrors how they already build software:

The workflow was described like a product organization: the CSS specialist works on the styling layer, the backend developer handles Liquid/dynamic logic (and Dyspatch’s DML + integrations), they assemble at the email level, and then ship changes broadly.

That’s not “email production", that's scalable iteration. Two Wombats isn’t just adding languages, they’re often doing a full redesign, and then rolling improvements out continuously:

This is the real story: Dyspatch is the infrastructure that lets them run faster subscription and lifecycle experiments without rebuilding the world each time.

Dark mode, real data, and “design that survives reality”

Dave doesn’t romanticize email design. He cares about what survives inbox rendering and real user settings.

For instance, Dark mode, for Two Wombats, isn’t a design trend, it's operational pain. They don’t have perfect tracking, so Dave did what pragmatic operators do: he surveyed customers.

Then he built accordingly: blocks designed to work in both light and dark mode, with design and logic developed in parallel and merged later. It’s also the kind of foresight that pays off as you’re scaling.

Actionable Takeaways: The kinds of experiments a “transactional-first” team can actually run

These are the experiments Two Wombats has successfully run:

1. First-order friction reduction (support-driven growth): They’re using order confirmation to proactively prevent issues.
   That’s growth. Fewer failed deliveries = fewer refunds = more retained subscribers.
2. Loyalty promoted at the moment of highest attention: Instead of burying loyalty in marketing flows, they attach it right after shipment: signing up gets you free rewards, instantly.
3. Referral prompts tied to shipment state: Not generic “tell your friends”, instead, there are contextual nudges, like offering a specific incentive to a friend. 
4. Localization scaling without duplicating 16 entire emails: The thing Dave refused to compromise on was Block-level localization, because in a regulated space, allowing variation across versions would be messy and risky.

This wasn’t just a customer interview. It was a preview of where lifecycle & subscription teams are going:

Dave and Two Wombats reflect what matters most to lifecycle and subscription teams now. Most brands treat transactional emails like plumbing: necessary, ignored, and never worth improving. Dave views them as a product opportunity. As he put it: “Everyone opens them… so you may as well stop sending s***.”

What we learned from Dave about transactional emails should be a checklist for growth teams:

• Treat transactional email as a high-attention growth surface
• Treat localization as an operating system, not a checkbox
• Build emails like software: modular, testable, composable
• Use metrics-driven incentives to fuel growth
• Maintaining experimentation velocity is a competitive advantage