We respect your privacy. Your information is safe.Introduction
The math was easy. One hundred sixty-plus events annually. Around twenty-five emails per event: registration confirmations, training plans, race logistics, volunteer briefings, results announcements. More than four thousand emails a year, each needing to be accurate, on-brand, and timed right. For the marketing team at a global endurance sports organization, "manual" was no longer a description of their process. It was a complaint about it.
When we came into the engagement, the existing setup was what grows naturally when email needs outpace infrastructure: duplicated templates across regional teams, sends triggered by someone checking a calendar, minor but persistent brand inconsistencies between race series, and no formal approval gate before anything went out. The team wasn't failing. They were running a process built for thirty events, not a hundred and sixty.
The Instinct We Had To Fight
The obvious fix, and the wrong one, is to clean up the templates. Better naming conventions, shared libraries, and cleaner handoffs. We see this proposal in almost every large-scale email program. It makes the problem more organized without actually solving it. The constraint isn't template management. It's that every email in the program is disconnected from the underlying event data, and someone has to manually bridge that gap at scale, every time.
We argued for a different starting point: the data model. Specifically, a Race Custom Object in HubSpot is the single source of truth for every event.
How The Architecture Works
The Race Custom Object holds everything that every email in a race's sequence needs to know: venue, date, series, athlete categories, cutoff times, course specifics, and emergency contacts.
When that record is created and populated, HubSpot enrollment logic fires automatically. The trigger generates around twenty-five email drafts for that event, each pulling its content fields directly from the Custom Object record.
The shift is architectural, and it's worth being precise about why it matters.
In the old model, twenty-five emails represent twenty-five manual tasks: creating, populating, QA-ing, and scheduling. In the new model, they represent one data entry and a downstream output.
The marketing team's job moves upstream to data quality, not downstream to email production.
This is what we mean when we call it HubDB-first. HubDB is the layer that makes event data addressable by HubSpot's automation engine. The Race Custom Object is the spine. The email drafts are a consequence of populating that spine correctly.
Approval Without Bottlenecks
Automation at this scale doesn't mean unsupervised sending. For a global sports organization, an error in an athlete's logistics email isn't a minor embarrassment; it affects race experience for thousands of people. So we built a two-stage approval workflow into the architecture.
- Stage one is content review: Does the email say the right things for this specific race?
- Stage two is compliance and brand sign-off: Does it meet the organization's standards for tone, legal accuracy, and visual consistency?
Both stages are triggered automatically when drafts are generated and assigned to the right reviewers based on race series. Nothing goes out until both stages are cleared.
The goal was approval without bottlenecks. By assigning reviewers at the point of draft generation, rather than after a marketer manually routes the email, we cut the coordination overhead that was adding days to every send cycle.
The Build
In this section, we're describing an architecture that will handle the full 160-plus event calendar from day one without adding headcount to the email program.
What Transfers
The principles behind this build aren't specific to sports events. Any high-volume, recurring-event email program, conference, training program, retail activation, or field marketing program eventually runs into the same constraint.
When the number of emails per cycle outgrows the team's capacity to manage them manually, the answer isn't more templates. It's:
- Where does the data live?
- How do you make it addressable?
- How do you generate email outputs from it automatically?
Get that architecture right, and the rest follows. Get it wrong or skip it and optimize templates instead, and you're solving the same problem again in two years, just with more complexity.
If your events program is growing faster than your team's bandwidth, we'd be glad to look at the architecture with you. Let’s connect.
Nathan Roach, Director of Marketing
Germany-based consumer of old world wine and the written word. Offline you can find him spending time with his wife and daughter at festivities in the Rhineland.
Leave us a comment