Diseñar recorridos de comunicación que escalen

There's a moment every growing company hits. Your communication system (the one you built when you had twelve clients and a Slack channel for urgent issues) starts groaning under the weight of actual scale. Messages arrive late. Templates break. Someone in accounts gets CC'd on everything because nobody remembers why that rule exists. You've hit the communication wall.

And here's the uncomfortable truth: most communication systems aren't designed to scale. They're designed to work right now, for the clients you have right now. Which is fine, until it isn't.

The ten-client illusion

When you have ten clients, communication is easy. You can remember preferences. You know that Sarah at Acme Corp prefers email summaries on Monday mornings, and that the team at Bracket Ltd gets irritated by anything before 10am. You hold it all in your head, or in a spreadsheet, or in a series of increasingly fragile automations.

At a hundred clients, you can't. At a thousand, you're drowning.

Twilio's 2023 State of Customer Engagement Report found that 56% of consumers said they'd become repeat buyers after a personalised experience^[1], but that number drops sharply when "personalisation" means getting the same generic template with your name mail-merged into the greeting. People can tell. They always can.

Templates vs. journeys: the restaurant analogy

Think of template-based communication like a fast food menu. You have a fixed set of items. Customers pick from what's available. It's efficient, predictable, and works at enormous scale. But nobody's writing home about the experience.

Journey-based communication is more like a good restaurant with a tasting menu. The kitchen has a framework (courses, pacing, flavour profiles) but the specific dishes adapt. The chef knows about allergies, preferences, the pace at which your table is eating. The structure scales; the details flex.

In practice, the difference looks like this:

• Template architecture: You define a message. You define who gets it. You define when. Each message is an independent unit. Adding a new client means adding them to the right distribution lists.
• Journey architecture: You define a series of communication steps triggered by events or conditions. Each step can branch, delay, or adapt based on recipient behaviour and context. Adding a new client means they enter the journey, and the system handles the rest.

The template approach works until it doesn't. And "doesn't" usually arrives at about 50 clients, when the combinatorial explosion of "who gets what, when, and through which channel" exceeds what any reasonable person can manage manually.

Personalisation beyond "Hi {firstName}"

Let's talk about what personalisation actually means at scale, because it's not what most people think.

Real personalisation isn't about inserting someone's name into a template. It's about contextual relevance. It's the difference between:

"Hi James, here's your monthly report."

and:

"Hi James, your usage was up 23% this month, mainly driven by the new team you onboarded in week two. Here are three things worth looking at before your quarterly review next Thursday."

The second message requires the system to know things: usage data, team changes, the recipient's calendar or business cycle. That's not a template problem. That's a data-pipeline-meets-communication-logic problem, and it's where journey architecture earns its keep.

Epsilon's research on consumer expectations found that 80% of consumers are more likely to make a purchase when brands offer personalised experiences^[2]. But most companies are still stuck at surface-level personalisation: names, basic segmentation, maybe some light behavioural triggers. The gap between "good enough" and "genuinely useful" is where scalable journey design lives.

Event-driven vs. batch: it depends (and that's okay)

There's a tendency in engineering circles to treat "event-driven" as inherently superior to "batch processing." As with most things in software, the honest answer is: it depends.

When event-driven makes sense

• Time-sensitive communications: A client completes an onboarding step, and you want to send the next instruction within minutes, not in tomorrow's batch.
• Behavioural triggers: A user hasn't logged in for seven days. The re-engagement message needs to go out based on their clock, not yours.
• Transactional messages: Confirmations, receipts, security alerts. Nobody wants to wait for the 6pm batch run to get their password reset email.

When batch still wins

• Digest communications: Weekly summaries, monthly reports, aggregated alerts. Sending these as individual events would be noisy and annoying.
• Cost-sensitive channels: If you're paying per-message (SMS, RCS), batching lets you consolidate and reduce costs without materially impacting the recipient experience.
• Regulatory reporting: Compliance communications often have specific timing requirements that align better with scheduled batch delivery.

The real answer is that most scalable systems need both. The architecture should support event-driven triggers that can feed into batch aggregation when appropriate. Think of it as a river with locks: water flows continuously, but sometimes you need to hold it and release it in a controlled way.

The details that actually matter

Architects love drawing boxes and arrows on whiteboards. But the difference between a communication system that works and one that infuriates people usually comes down to a handful of mundane-sounding details.

Timezone handling

This sounds simple. It isn't. If you have a client in London and another in Sydney, "send at 9am" means two completely different things. But timezone handling goes deeper than just offsets. Daylight saving transitions, clients with teams across multiple zones, and the question of whether "9am" means the recipient's 9am or your 9am. These are the things that break at scale.

Our advice: store everything in UTC, resolve to local time at the point of delivery, and always,always, let the recipient's timezone win when there's ambiguity.

Channel preferences

Some people live in email. Others haven't opened their inbox since 2019 and exist entirely in Slack and WhatsApp. A scalable communication journey needs to respect this, which means maintaining preference data per recipient and having fallback logic when a primary channel fails.

But preferences aren't static. They shift based on message type (urgent vs. informational), time of day, and even the recipient's current context. The best systems learn and adapt; the merely adequate ones set a preference once and forget about it.

Delivery windows

We've all received that marketing email at 3:17am. The one that makes you wonder if the sender's automation system gained sentience and chose violence. Delivery windows prevent this, but they're harder to implement well than you'd think.

What happens when a message misses its delivery window? Does it queue for the next window? Does it expire? If you're aggregating messages for a digest, does a delayed message join the next batch or get sent individually? These edge cases multiply at scale, and each one is a tiny paper cut in the recipient's experience if you get it wrong.

When it's done right, you don't notice

Good communication design has a peculiar quality: it's invisible. When it works, the recipient simply feels informed, supported, and respected. They don't think about the system behind it. They don't marvel at the timezone logic or the channel fallback routing.

Bad communication design, on the other hand, is extremely visible. It's the duplicate email. The SMS that arrives after the issue is already resolved. The notification that says "Dear {{customer_name}}." The weekly report that arrives on Saturday. Each one is a small erosion of trust.

According to Forrester's 2023 Customer Experience Index, 73% of consumers say that valuing their time is the most important thing a company can do^[3]. Every poorly timed, irrelevant, or broken communication is a signal that you don't value their time. And people notice, even if they can't always articulate what went wrong.

Practical starting points

If you're looking at your current communication system and feeling a growing sense of unease, here's where we'd suggest starting:

1. Map your journeys, not your messages. Before you touch any code, draw out the communication paths your clients actually experience. You'll almost certainly find overlaps, gaps, and sequences that made sense once but don't anymore.
2. Separate content from logic. Templates should define what you say. Journey logic should define when, to whom, and through which channel. Mixing these is how you end up with 400 template variants and no clear picture of the client experience.
3. Instrument before you optimise. You can't improve what you can't measure. Track delivery rates, open rates, response times, and (critically) negative signals like unsubscribes and complaints.
4. Design for the unhappy path. What happens when a message bounces? When a channel is down? When a client changes their preferred contact method mid-journey? These aren't edge cases at scale. They're Tuesday.
5. Start with one journey. Don't try to redesign everything at once. Pick your most important client communication flow, redesign it as a proper journey, and learn from the process.

Scalable communication isn't about sending more messages to more people faster. It's about building systems that treat every recipient as an individual, even when you're serving thousands of them. That requires thoughtful architecture, attention to the boring details, and a willingness to invest in the plumbing that nobody sees but everyone benefits from.

The plumbing, as it turns out, is where the magic lives.