Building Automations That Survive a New Channel

The automations a business builds in its first year encode assumptions nobody wrote down: that a message has a phone number, that reaching out means a template, that a service window exists. Add a channel where none of those hold and the workflows do not adapt — they fail, usually quietly. Our guide to planning past WhatsApp covers how to avoid building yourself into that corner.

Model the event, not the channel

The difference is visible in how you describe a trigger. "A WhatsApp message arrives containing the word booking" is channel-specific. "A customer message expresses an intent to book" is not, and it will still be true when the message comes from somewhere else.

The same applies to actions. "Send template appointment_reminder_v2" ties the workflow to one platform's mechanics; "send the appointment reminder, using whatever format this channel requires" survives. The system should resolve the format at send time, based on where the conversation is happening.

What genuinely differs per channel

Being channel-agnostic does not mean pretending channels are identical. Three things really are different, and they should be handled in one place rather than scattered through every workflow.

• The outbound rules: whether templates are required, whether a service window applies, and what it costs to reach out.
• The message formats available — buttons, media types, size limits, whether formatting survives.
• Tone and length expectations, which differ enough between a WhatsApp thread and an Instagram DM to be worth separate copy — and differ again by market, as choosing channels market by market sets out.

The first is the one that bites. A workflow that waits three days and then sends free text works on a channel without a window and fails on one with, which is exactly the trap described in the 24-hour window, explained properly.

“

Write the workflow around what the customer did, not around what the platform calls it.

— be digital ai team

Keep the content separate from the logic

The most portable automations separate the sequence — trigger, wait, condition, send — from the words being sent. The logic of "remind twenty-four hours before, then again two hours before, unless they have already confirmed" is universal. The exact message is not.

Structured that way, adding a channel means writing new copy for messages you already send, rather than rebuilding the sequence. That is an afternoon rather than a project, and it is the difference that decides whether a second channel ever actually launches.

Design for the customer's preference

Once someone can reach you on two channels, an automation has to decide where to reply. The default should be simple: answer where they wrote, and for outbound, use the channel they last used.

Where a customer has expressed a preference, record it on the contact and let automations respect it. This is a small field with a large effect — messaging someone on a channel they have told you they do not check is a failure that feels personal even when it is mechanical, and preventing it requires the identity work in matching one customer across channels.

Test the failure paths

The most common multi-channel bug is an automation that cannot send and does not say so. The window is closed, the format is unsupported, the customer blocked you on one channel but not the other — and the workflow marks the step complete anyway.

Every send step needs a defined behaviour when it fails: try the other channel, escalate to a person, or stop and flag. Decide it explicitly rather than discovering the default, and check the run log after adding any channel to see which steps are quietly failing.

Reporting has the same problem

Metrics written around one channel break in the same way workflows do. A response-time report that only counts WhatsApp threads will look excellent while Instagram messages sit unanswered for a day, and nobody will notice because the number is green.

Define the measures generically — first reply time on any customer message, conversations open beyond target on any channel — and then split by channel when you want to compare. The reverse order produces reports that quietly exclude your newest problem.

Start generic even with one channel

The case for doing this early is that it costs nothing. Writing "send the reminder" instead of naming a template, and "a customer message arrives" instead of naming a platform, is the same amount of work on the day you build it.

It only becomes expensive later, when there are forty workflows and each one has to be opened, understood and rewritten by someone who did not build it. Businesses that make this choice in their first month barely notice; those that make it in their third year usually schedule it as a project and then postpone it.

Audit what you already have

Before adding a channel, read your existing automations and mark every place a platform name appears. That list is your migration work, and it is almost always shorter than expected — usually a handful of send steps and one or two conditions written around message formats. Fixing them while you have one channel is straightforward; fixing them while two are live is not.