> ## Documentation Index
> Fetch the complete documentation index at: https://docs.alcmeon.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Campaigns: build, schedule, and send WhatsApp flows
> Create one-off WhatsApp campaigns using the visual flow editor, template steps, audience targeting, delivery hours, tests, and API sends.
A campaign is a one-off message (or short sequence of messages) sent to a chosen group of contacts at a chosen time. Every campaign starts from an approved WhatsApp template and can optionally continue into a flow of follow-up steps triggered by how contacts respond. This page covers building, scheduling, sending, and monitoring campaigns.
## What a campaign is
Campaigns are built and edited in a visual flow editor: a canvas where you place message steps and connect them with arrows to describe what happens next. The first step is always the approved template message that actually gets sent to the audience. Everything after it (extra messages, conditions, tags, waits) only plays out for a given contact once they interact with that first message.
## Campaigns vs automations
Campaigns and [automations](/simio/platform/automations) use the exact same editor and the same underlying object. The only difference is how they start:
* A **campaign** is sent manually: you pick an audience, pick a time, and send. It runs once per scheduling action.
* An **automation** is triggered automatically by an event, and keeps firing every time that event happens, for as long as the automation is turned on. There is no audience to pick and no schedule; instead you configure a trigger.
## Creating a campaign
Creating a new campaign opens a small setup panel where you choose:
* **Channel**: the messaging channel to send on (for example, WhatsApp).
* **Connected account**: which of the company's connected accounts on that channel will send the messages.
* **Name**: an internal label for the campaign (editable later from the **Details** tab).
Once created, you land directly in the flow editor with a starter template step already in place, ready to configure. Channel and account cannot be changed later for a plain campaign once it leaves draft (see "Editing mid-flight" below).
## Campaign workspace
A saved campaign opens on three tabs at the top of the screen:
* **Scenario**: the visual flow editor (canvas).
* **Details**: the campaign's general settings (**Channel** and **Campaign name**).
* **Results**: aggregate delivery statistics for the send.
The toolbar on the right of the tab bar exposes **Save**, **Send a test**, **Schedule**, and a **⋯** overflow menu with **Duplicate scenario**. The Schedule button opens the recipients and sending-mode panel described below.
## Building the message flow
### The trigger/anchor step
Every campaign has one required first step: the template message that gets sent to the whole audience. This step must reference an approved message template. It cannot be deleted or converted into something else; it is locked in place as the entry point of the flow.
### Additional steps
After the initial template message, you can add further steps and connect them with arrows to build out what happens depending on how the contact reacts. The bottom toolbar of the Scenario tab offers these step types:
* **Message**: A follow-up message, either a simple text/media message, a template or a **List message** (see "Surveys" below). Unlike the anchor step, this does not need to be a pre-approved template; it can be free-form content, sent once the contact has an open conversation.
* **AI**: Hands the conversation to a configured AI assistant, which answers using company-provided context and instructions you set on the step. This option is only available once an AI connector has been fully set up for the company (context and data sources configured); otherwise it is disabled with a link to go set it up.
* **Wait**: Pauses the flow for a given contact until a condition is met (for example, a fixed duration, or until a reply/message-status event happens) before continuing.
* **Condition**: Splits the flow into two branches ("Yes"/"No") based on a check. Supported checks: whether the contact has a given tag, whether they are currently opted in or out, whether the contact was created within a given time window, or a random percentage split (useful for A/B-style branching). Each branch shows a live running count of how many contacts took it once the campaign has sent.
* **Action**: Applies a tag to the contact, or calls an external URL (API Call) with configurable method, headers, body, and query/path parameters. Webhook actions can be tested directly from the editor by sending a live test call and reading back the response; the response can be mapped into a contact's custom field.
* **Opt-in/out**: Marks the contact as opted in or opted out of marketing messages. You choose which of the two on the step itself.
* **Note**: A sticky-note-style annotation on the canvas for your own reference. It doesn't send anything and has no connections.
Steps other than the initial template step are optional; a campaign can be just the single template message with no follow-up flow at all.
For the full field-level reference of every step editor (Message, AI, Wait, Condition, Action, Opt-in/out, Note), see [Scenario builder](/simio/platform/scenario-builder).
### Content types on a Message step
A Message step can be switched between three content types directly from its edit panel:
* **Text & Media**: free text, with an optional image or video attached.
* **List message**: presents the contact with a selectable list of options (see "Surveys" below). Displayed on the canvas with a **LIST MESSAGE** tag on the step header.
* **Template**: converts the step into a full WhatsApp template message instead (useful when you want a later step to also be a pre-approved template, e.g. for outside-24-hour-window sending rules).
Switching a step's content type this way changes what the step is and how it behaves, without losing its position in the flow or requiring you to delete and recreate it.
### Buttons on a message
Message and template steps can include buttons. Four button types exist:
* **Reply button**: a quick-reply chip; clicking it routes the contact along whichever path is connected to that specific button.
* **URL button**: opens a link. Clicks on these are tracked.
* **Flow button**: launches a WhatsApp Flow.
* **Phone button**: lets the contact call a phone number directly.
Each button in a step can have its own outgoing connection to a different next step, letting you branch the conversation based on which button the contact tapped.
### Surveys / list messages
A "survey" is simply a Message step configured as a list message: instead of a body of free text, the contact is shown a selectable list of options. Each option can be individually connected to a different next step, letting the flow branch based on which option the contact picked. There's no separate "survey" feature; it's a display mode of the Message step.
### Personalizing the template message with contact fields
The initial template step (and any other template step) can map each `{{1}}`, `{{2}}`, etc. placeholder in the approved template body to a contact field: WhatsApp display name, first name, last name, or phone number, each with an optional fallback default value used if the contact's own value is empty.
### Coupon codes in messages
A Message step's body can include a coupon-code placeholder that gets replaced with a real code drawn from a coupon pool at send time. See [Coupon codes](/simio/platform/contacts/coupon-codes) for full detail on that feature.
## Scheduling a send
Clicking **Schedule** in the toolbar opens the scheduling panel, which shows three things:
### The sending WhatsApp number
A card at the top displays the WhatsApp number the campaign will send from, along with real-time health signals pulled from Meta:
* **Quality rating** (for example, High).
* **Messaging tier** (for example, 1k / 24h), which caps how many unique contacts you can initiate conversations with in a 24-hour window.
* A **systems healthy** indicator.
* A direct link out to **Meta Business Manager** for that number.
The template selected on the anchor step is previewed alongside, with its own status badge (for example, **APPROVED**) and category (for example, **MARKETING**).
### Recipients
The audience is chosen at scheduling time, not while building the flow. You pick the source with a toggle at the top:
* **Simio**: choose a **Simio segment** from the dropdown. The **Manage segments** link opens the segment editor.
* **Brevo**: choose a Brevo list, if the [Brevo integration](/simio/integrations/brevo) is connected.
The system snapshots the audience size at the moment you schedule, so the "audience" figure you see afterwards reflects who was targeted when the send was launched, not the segment's size right now.
By default, only contacts who are currently opted in to marketing messages are actually sent to; opted-out contacts in the segment are silently skipped unless the send is explicitly forced to bypass that check (an option only available through the external sending API, not the everyday scheduling UI).
### Sending mode
Two options:
* **Send now**: Campaign will be sent immediately.
* **Schedule for later**: Choose a date and time to send the campaign. A **Date & time** picker appears below when this option is selected.
## Delivery hours
Each company configures its own delivery hours: which days of the week messages may go out, and the allowed time window (with time zone) per day. Any day left unconfigured is treated as closed (no sending that day). If a company hasn't set delivery hours at all, the default is 8:00 AM to 10:00 PM, Europe/Paris time, every day.
If a scheduled send's time falls outside the allowed delivery window, it is not dropped: it is automatically deferred and picked back up at the start of the next open window. This check happens at actual send time, not at scheduling time, so a campaign scheduled for a valid time can still be pushed later if delivery-hour settings change in the meantime, or if the send takes long enough to spill into a closed window.
## Sending a test
Before scheduling a real send, click **Send a test** in the toolbar to send a copy of the current flow to one or more specific phone numbers. The **Send a test** modal offers:
* A text field to enter one or more phone numbers separated by commas, and a **Send a test** button.
* A **Company users** list below the field: clickable rows for each teammate on file (name and phone number), which populate the field when clicked.
* For automations: optional overrides for the image, video, and link-button destinations used in the test, plus a free-form area to supply custom values (useful for testing trigger variables without needing an external system).
* If the template being tested is a carousel-style template with link buttons whose destination hasn't been fixed yet, the test-send screen requires you to fill in a real destination for each of those before it will let you send the test.
While a test is in flight, the editor shows live delivery status updates (sent, delivered, read, failed) for a few seconds after sending, so you can immediately see whether the test message actually arrived. If no status update comes back within about 10 seconds, it's shown as timed out.
Test sends never affect the campaign's real status or its audience/sent-count figures; they are entirely separate from the real recipient list.
## The campaigns list
The Campaigns page lists every campaign in the workspace. Each row exposes four action icons on hover:
* **Edit scenario**: opens the visual flow editor (Scenario tab).
* **Edit details**: opens the Details tab (Channel and Campaign name).
* **View results**: opens the Results tab for delivery statistics.
* **Delete campaign**: removes the campaign.
## Editing mid-flight and locking
While a campaign is still in **Draft**, everything is fully editable: channel, connected account, audience, message content, everything.
Once a campaign has been scheduled (moved past Draft, i.e. Scheduled/Running/Stopped/Sent), it becomes locked from a save perspective: the Save and Schedule actions disappear from the toolbar entirely, so there is no way to persist further edits to that campaign going forward. Sending a further test, or using **Duplicate scenario** from the ⋯ menu to spin up a fresh draft for bigger changes, remain available. (Automations work differently: since they don't go through this schedule/lock lifecycle, their content and settings stay editable on the same ongoing basis, gated only by the active/inactive toggle.)
## Campaign status lifecycle
| Status | Meaning |
| - | - |
| Draft | Never scheduled or sent; fully editable |
| Scheduled | A send has been registered for a future or immediate time, but dispatch hasn't started yet |
| Running | The system has started dispatching messages to the audience |
| Sent | Every message that was going to be sent has reached a final outcome (sent, delivered, read, or failed) |
| Stopped | Sending has been paused by a user; not yet resumed |
A campaign only becomes "Sent" once every real (non-test) message tied to it has reached one of the terminal per-message states below; it isn't simply "we finished queuing everyone." If literally nobody in the resolved audience qualified for a message (for example, an empty segment), the campaign is marked Sent immediately with nothing to track.
Automations do not use this status field in a meaningful way (it stays fixed at Draft internally); their real-world state is the separate Draft/Active/Turned off status described on the [Automations page](/simio/platform/automations).
## What "sending" looks like from a business perspective
When a scheduled send's time arrives and the delivery window is open, the system:
Resolves the actual list of contacts to message (from the segment), filtering out anyone not currently opted in (unless the send is explicitly forced).
Queues one outbound message per contact. This is a background, asynchronous process, not a single blocking action; large audiences are processed contact-by-contact rather than as one giant blast.
If it's accepted, Simio records it as sent and starts tracking its delivery status; if it's rejected outright, it's recorded as failed immediately.
As channel delivery status updates arrive later (delivered, read, or failed), each individual message's tracked status is updated accordingly.
There is no visible "batch size" or manual pacing control exposed to campaign creators; pacing is an internal system detail. What you see is aggregate progress: how many contacts were targeted (audience), and how many messages have gone out so far (sent count), refreshed as the send progresses.
### Per-message delivery status
Every individual outbound message (per contact) moves through this lifecycle:
| Status | Meaning |
| - | - |
| Sent | Accepted by the sending platform and handed off toward the channel (for example, WhatsApp) |
| Delivered | Confirmed delivered to the contact's device |
| Read | Confirmed read by the contact |
| Failed | Could not be delivered, either rejected immediately at send time or failed later per a delivery-status update |
A message can go sent to delivered to read, or fail at any point along that path.
## Send failures and opt-outs
A message to a given contact is skipped (not sent, not counted as failed) when:
* The campaign has been stopped in the meantime (see Pause & Resume below).
* The contact is not currently opted in, and the send hasn't been forced to bypass that check, and it's not a test send.
* The contact has previously opted out.
A message is recorded as failed when:
* The sending platform rejects it outright (for example, invalid recipient, malformed content), recorded immediately as failed.
* A later delivery-status update reports it failed after having been accepted (for example, the number turned out to be invalid on WhatsApp's side, or the contact had opted out on WhatsApp's own systems). When this class of error comes back, the contact is also flagged internally as having an invalid WhatsApp number, which can inform future targeting.
* A required piece of dynamic content (see trigger variables on [Automations](/simio/platform/automations)) had no value for that specific contact, the message is deliberately not sent blank; it's recorded as failed with a clear reason instead.
There is currently no automatic retry/reconciliation for a message that simply never receives any delivery-status update at all (for example, due to a lost webhook); it can remain in a non-final "sent" state indefinitely rather than being resolved to a final outcome. This is a known limitation, not an intended state.
## Pausing and resuming
Setting a running campaign to **Stopped** does not cancel messages already in flight; instead, it prevents any further not-yet-dispatched messages in that batch from actually going out; the system remembers exactly which contacts in that batch hadn't been reached yet.
Setting the campaign back to **Running** resumes it: the remaining, previously-unsent contacts pick up from where they left off, and the sending eventually completes and marks itself finished the same way a normal send does. There's also a safety sweep that periodically re-checks for any running campaign with contacts still waiting to be resumed, in case the initial resume signal was somehow lost, so a resume should never get permanently stuck.
## Real-time delivery tracking during test sends
While the flow editor is open and a test send is running, a live connection pushes delivery-status updates (delivered, read, failed, or timed out) to your screen as they happen, so you get immediate feedback without needing to refresh or poll anything manually. Reopening or refreshing the editor doesn't replay old notifications from before you reconnected; only genuinely new status changes are pushed.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.