Rethinking persona-based email automation at Side House
A strategic look at why adding a new persona exposed the limits of our email automation model, and what a more scalable architecture should have looked like from the start.
Introduction
Adding one new persona to an existing email automation system should be an extension task. At Side House, it exposed a structural limit.
The original setup worked for the first phase of growth. Flows were live, journeys were running, and the system supported the personas we had initially planned for. The problem appeared when the audience model expanded. What looked reusable was in fact too closely tied to the assumptions of the first version of the business.
That is the real issue this article addresses. The question is not only how to support one more persona. It is how an automation system should be designed when growth depends on supporting more audience variation over time.
Technology strategy
The core architectural mistake was treating persona as flow logic instead of system logic.
That usually happens in early-stage products because it is efficient at first. Teams ship automations around specific campaigns, conditions, and journeys. The result is functional, but the intelligence of the system becomes scattered across cron jobs, event rules, filters, and messaging branches. Once that happens, adding a new persona stops being a modeling task and becomes a structural correction.
A stronger design would separate four concerns from the start: triggering, eligibility, orchestration, and delivery. Triggering should decide when the system evaluates users. Eligibility should decide who belongs to which journey and why. Orchestration should determine entry, pause, exit, and transition logic. Delivery should handle content execution through the email platform. That separation matters because it keeps business rules centralized instead of burying them inside individual flows.
In that model, persona becomes an explicit entity with durable meaning. It has a stable definition, clear eligibility rules, valid lifecycle journeys, exclusions, and business goals. Once persona is formalized this way, the system can absorb new audience types without rewriting the automation layer every time strategy evolves.
State is equally important. Automation systems need memory. They need to know what a user is, what they have already received, what journey they are in, and what changed. Without explicit state, teams end up approximating behavior through timestamps, tags, and fragmented dashboard logic. That works until variation increases. Then it becomes brittle, hard to debug, and expensive to trust.
The same is true for system ownership. Klaviyo is effective as a delivery and execution layer, but it should not become the place where the business model is implicitly defined. The application should own the event taxonomy, audience definition, and eligibility logic. The delivery platform should receive structured inputs, not compensate for missing architecture upstream.
The broader lesson is simple: scaling automation is not about sending more emails. It is about controlling variation without losing clarity. That requires explicit models, centralized rules, durable state, and clear boundaries between evaluation and execution.
Product strategy
This matters because persona is not a messaging preference. It is a growth reality.
When a new persona appears, it usually means the product is serving a broader market than the first version anticipated. If the automation model cannot support that change cleanly, growth slows in less visible ways. Messaging becomes too generic, timing becomes less relevant, and the product starts communicating as if every user were the same. That weakens activation, conversion, and retention.
A persona-aware system fixes that by allowing the company to scale audience diversity without flattening customer experience. Different personas rarely need the same proof points, the same onboarding sequence, or the same conversion path. A system that recognizes those differences can support more relevant journeys without creating operational chaos.
That becomes especially important when expansion is part of the business strategy. Growth is not only about reaching more users. It is about serving more variation well. If the communication layer cannot adapt to that variation, each new segment adds cost, manual work, and inconsistency.
There is also a clear execution advantage. Once persona is modeled properly, teams can launch and refine lifecycle journeys faster because they are no longer rebuilding segmentation logic from scratch. Product, growth, and engineering can operate from the same structure. That reduces coordination overhead and makes experimentation safer.
For users, the effect is straightforward. Better persona handling leads to clearer onboarding, more relevant lifecycle messaging, and fewer mismatched emails. Users may never see the architecture, but they experience the quality of its decisions directly.
The product value, then, is not simply better email automation. It is a more scalable growth system that can support broader audience coverage without sacrificing relevance.
Conclusion
Adding a new persona revealed that the original Side House automation setup was effective, but not extensible enough.
The issue was not the choice of Next.js cron jobs or Klaviyo. It was the absence of a system model where persona, eligibility, state, and journey logic were treated as first-class components. Without that foundation, each new audience creates more structural friction than it should.
The better design is clear: separate evaluation from delivery, define persona explicitly, make state durable, and keep journey logic reusable. That is what turns automation from a set of working flows into a scalable growth system.
Follow our journey at side.house.