# How to create a CRM scenario Planning?

## A key document

The **CRM Scenario Planning** is a central document in your onboarding with Batch. It is not simply a tracking file, but a **structuring tool for your entire CRM strategy 🌟**

<figure><img src="/files/GHfzU0DV44QSKmjgQlIb" alt=""><figcaption></figcaption></figure>

It allows you to:

#### 1. Centralize all your use cases

This file becomes your **single source of truth**:

* A global view of your CRM strategy
* Tracking of existing and future scenarios in Batch
* Prioritization of activations

👉 *It ensures you cover all your use cases and maintain a consistent CRM strategy.*

#### 2. Build your data mapping (tagging plan)

Each scenario allows you to identify:

* Events to track
* Required data (attributes, events, properties)

👉 *The scenario planning defines what you want to run in Batch. The data mapping makes it possible.*

💡 **Note**: Batch provides a set of **native data** (events and attributes called [built-in data](https://doc.batch.com/guides-and-best-practices/message/push-notifications/how-to-use-batch-built-in-data-in-your-push-notifications-and-in-app-scenarios)) that allow you to orchestrate many scenarios without specific implementation.

{% hint style="info" %}
As an example, if you define an *abandoned cart reminder* scenario, you will need to track:

* A trigger event → add to cart
* An exit event → purchase
* Personalization → products, amount, date, etc.

👉 Without this data, the scenario cannot run.
{% endhint %}

For more details on creating your data mapping, check our [dedicated documentation](https://doc.batch.com/developer/technical-guides/how-to-guides/how-to-create-a-tagging-plan) 👈

#### 3. Structure your email strategy (warm-up)

For the email channel, this document is essential to:

* Estimate sending volumes
* Identify message types (marketing vs transactional)
* Assess expected user engagement

These elements allow you to plan a **progressive ramp-up (warm-up)**, a key step to ensure strong deliverability from the start.

👉 *An incomplete planning may lead to delays and deliverability risks.*

## File structure

The document is divided into 3 main sections: marketing automations, transactional automations and campaigns.

### Marketing automations

These are messages with a marketing purpose such as promotions, abandoned cart, product recommendations, welcome pack, etc.

👉 Marketing scenarios require **explicit user consent** and the user must be able to **unsubscribe easily** at any time (via a one-click unsubscribe link).

### Transactional automations

These are messages related to a transaction or an action performed by the user or a service such as password reset, purchase confirmation, shipping tracking, server maintenance, etc.

👉 Transactional scenarios **are critical**, not subject to specific consent and the user is not supposed to be able to unsubscribe.

{% hint style="info" %}
**Important**: choosing the right type (marketing or transactional) is critical, especially for email and SMS.

It has direct impact on:

* Email warm-up (volume ramp-up)
* Deliverability
* Orchestration setup in Batch

**This distinction is not defined by Batch. It is regulated (GDPR / local laws) and depends on the message’s purpose.**

* Transactional → expected, service-related
* Marketing → promotional

A transactional message containing promotional content may be reclassified as marketing.
{% endhint %}

### Campaigns

One-off messages (one-shot), such as promotions, newsletters, or key events.

👉 Make sure to include your key campaigns.

{% hint style="success" %}
Each section can include categories (Onboarding, Anti-churn, Account management, etc.)

These are **examples**. You can adapt or create your own categories to organize your scenarios clearly.
{% endhint %}

## Understanding the columns

The idea is simple: one row = **one step of your scenario 🚀**

### Status

This column refers to the current status of the scenario (active, to activate, under consideration)

💡 **Best practices**

* Update this column regularly to track progress
* Use it as a tool to manage your CRM strategy
* Avoid leaving outdated statuses (e.g. “to come” for several months)

### Journey Name

This column refers to the name of the complete scenario (the orchestration). It groups all the messages that make up a user journey, for example:

* An onboarding
* An abandoned cart reminder
* A reactivation scenario

💡 **Best practices**

* Think “complete user journey”, not “individual message”
* Give a name that is:
  * clear
  * stable over time
  * business-oriented

{% hint style="success" icon="hand-peace" %}
Examples:

* *New users onboarding*
* *Abandoned cart reminder*
* *Churn prevention - card expiration*

To avoid:

* *Email J+1*
* *Push reminder*
* *Message 1*

👉 These names describe steps, not a scenario.
{% endhint %}

### Step name

This column refers to a specific message within the scenario. Each row = one send (one step) in a journey.

💡 **Best practices**

* Think “individual message”
* The name should reflect:
  * the content
  * or the objective of the message
  * and ideally the timing

{% hint style="success" icon="hand-peace" %}
Examples (for the same onboarding journey):

* Welcome D+1
* Feature discovery D+2
* Activation reminder D+3
  {% endhint %}

### Priority

This column refers to the business priority of the scenario (1 or 2)

* **1 = Priority scenarios**

  * To be migrated/activated first during implementation and onboarding
  * Includes scenarios used for email warm-up

  👉 Example: high-impact scenarios, high-volume scenarios, onboarding, transactional…
* **2 = Secondary scenarios**
  * To be activated later once implementation is complete

💡 **Best practices**

* Prioritize based on:
  * business impact (revenue, activation, retention)
  * user volume
* Avoid setting everything as priority 1 → it makes prioritization ineffective

### New / existing scenarios

This column indicates whether the scenario already exists in your previous tool or needs to be created.

💡 **Best practices**

* Clearly identify existing scenarios to:
  * avoid duplicates
  * facilitate migration

### Channel

This column refers to the channel(s) used for the scenario (Email, Push App, Push Web, SMS, In-app)

💡 **Best practices**

* Choose the channel based on the objective: *“which channel is the most relevant to reach my user?”*
* Guidelines:
  * Push / SMS → fast messages requiring immediate action
  * Email → richer content, consumed later
  * In-app → product guidance
* Avoid over-solicitation: favor a sequenced approach (example: Push → then Email if no engagement)

### Scheduling mode

This column refers to how the message is triggered. There are two main types:

* **Trigger**

  Message sent following:

  * an event (for example: add to cart)
  * an attribute change (for example: from 0 to 100 loyalty points, from silver to gold)

  👉 Examples: onboarding, abandoned cart, etc.
* **Recurring**

  Message sent on a schedule (daily, weekly, monthly)

  👉 Examples: newsletter, periodic summary.

💡 **Best practices**

* Prefer trigger scenarios (more contextual and performant)
* Use recurring for regular marketing communications
* Ensure the scheduling mode matches the use case

{% hint style="info" icon="book" %}
If you want to better understand how trigger and recurring modes work, you can refer to:

* [Batch Academy](https://go.meltingspot.io/spot/60d29fcc-0957-41b4-bbe9-8c43b1fab19d/home)
* [Batch documentation](https://doc.batch.com/getting-started#:~:text=Ready%20to%20create%20your%20first%20communications%3F%20Let%E2%80%99s%20get%20started!%20%F0%9F%9A%80)

👉 This can help you structure your scenarios before completing the planning
{% endhint %}

### Targeting

This column refers to the target audience of the scenario (who receives the message).

💡 **Best practices**

* Be precise and actionable

✕ To avoid:

* “All users”
* “Active users”

✓ Prefer:

* “Users registered less than 7 days ago without purchase”
* “Users who added a product to cart without purchasing”

👉 A vague segmentation = a low-performing and hard-to-activate scenario

### Timing

This column refers to what triggers the message. It depends on the scheduling mode:

* **Trigger**

  The message is sent following:

  * an event → *add to cart, account creation, page visit*
  * an attribute change → *from 0 to 100 loyalty points* or *from silver to gold*
* **Recurring**

  The message is sent at a defined time:

  * a date or frequency → *every Monday, the 1st of the month*

💡 **Best practices**

* Define a clear, precise and measurable trigger
* Prefer easily trackable events or conditions
* Avoid vague wording

### Delay (trigger only)

This column refers to the time between the trigger and the message send.

The delay can take different forms:

* **A specific time (*****wait delay*****)** → *1 hour, 24 hours, 7 days or at 11am the next day*
* **An specific (*****wait event*****)** → *wait for the user to become premium within 7 days*

💡 **Best practices**

* Adapt the delay to the scenario context
* Give users time to act (avoid sending messages too quickly)
* Avoid delays that are too long (loss of relevance)
* Ensure consistency between steps (space messages properly within a journey)

{% hint style="info" %}
Once live, you will be able to test and adjust your delay over time (the best timing depends on your business and your users’ behavior).
{% endhint %}

### Exit events (trigger only)

This column refers to conditions that stop or prevent sending.

💡 **Best practices**

* Always define at least one exit condition (if relevant)
* Base it on the achievement of the scenario goal

{% hint style="success" icon="hand-peace" %}
**Example: abandoned cart scenario**

✓ Trigger event: add to cart or empty cart

✓ Cancellation event: purchase

👉 Without exit event, you risk sending irrelevant or inconsistent messages.

👉 Make sure your logic is consistent across the entire journey (a single action can cancel multiple steps).

👉 A good scenario also knows when not to send a message.
{% endhint %}

### Personalization

This column refers to the data used to adapt the message to the user. The more personalized a message is, the more performant it is.

You can personalize messages using different types of data:

**1. User-centric data (related to the user: from user attributes or tracked events)**

Examples: *first name, age, favorite category, number of orders or articles read, last action, etc.*

{% hint style="success" %}
“Hi *Nina*, you didn’t complete your order.”
{% endhint %}

**2. Catalog data (related to products or content: from Batch catalogs)**

Examples: *product catalog, price, image, recommended category, etc.*

{% hint style="success" %}
“*Thanks for your order Nina, you might also like: Running shoes and Sports jacket.*”
{% endhint %}

💡 **Best practices**

* Identify the data needed for your step (for example: *first name, product, amount, etc.*)
* Prioritize useful and contextual personalization (linked to user actions or behavior)
* Avoid over-personalization (too much information = the message is harder to understand)
* Adapt personalization to the channel (richer in email, more concise in push)
* Combine both types of data to maximize impact: "*It’s been a while, Nina! Discover this week’s new sneakers* ��*”*

### Conversion goal (campaigns only)

👉 This column refers to the main objectives you want to measure after sending your campaign, such as a *purchase*, a *sign-up*, or an *add to cart*. It represents the actions you expect from your users after your campaign.&#x20;

{% hint style="info" icon="book" %}
Documentation on [Conversion settings](https://doc.batch.com/getting-started/features/customer-engagement-platform/orchestration/campaigns#creating-a-campaign) and [Conversion analytics](https://doc.batch.com/getting-started/features/customer-engagement-platform/analytics/orchestration-analytics#conversion-goal-dedicated-insights).
{% endhint %}

💡 **Best practices**

* Define clear objectives per campaign
* Choose an objective aligned with your intent (examples: promotion → *purchase*, newsletter → *click*, free trial → *sign-up*)

### Estimated engagement (email only)

This column refers to an estimate of your email scenario performance (*open rate*, *click rate*, *conversion*).

💡 **Best practices**

* Base your estimate on your past performance (if available)
* Even an approximate estimate is useful (it helps prioritize scenarios and anticipate warm-up)

{% hint style="success" icon="hat-chef" %}
**How to estimate simply?**

Take your overall average open rate (from your current email campaigns), then position your scenario:

* Above average → high engagement (active+ users)
* Around average → medium engagement (active users)
* Below average → low engagement (inactive users)
  {% endhint %}

### Sending volume (email only)

This column refers to the daily volume of emails sent for this scenario. It is essential to properly prepare the warm-up.

💡 **Best practices**

* Provide realistic estimates
* Estimate on a daily basis
* Try not to underestimate volumes (direct impact on deliverability)

## Best practices

#### 1. Think “user jouney” before “tracking”

The campaign planning should not be a list of technical elements. Its goal is to structure a coherent experience for your users and define scenarios aligned with your business and marketing objectives.

{% hint style="success" icon="hand-peace" %}
To avoid:

* “Track checkout button”
* “Send product push”

To prioritize:

* “Remind users who did not complete their purchase”
* “Encourage new users to complete their first action”

👉 Always ask yourself: *“What user behavior do I want to trigger or influence?”*
{% endhint %}

#### 2. Think “data”

For each row, ask yourself:

* What data is required?
* Can I clearly identify:
  * a trigger?
  * a target?
  * an exit condition (for trigger scenarios only)?

👉 If these elements are not clearly defined, the data mapping may be incomplete and the scenario difficult to activate.

#### 3. Be exhaustive

Even if some use cases are not a priority, it is recommended to include them in your CRM scenario planning. This allows you to:

* anticipate tagging
* have a complete view of your strategy
* avoid additional developments later

{% hint style="info" %}
Priorities help you break down scenarios into multiple batches and plan their rollout progressively over time.
{% endhint %}

#### 4. Challenge the value of each scenario

Before adding a scenario, ask yourself: *“What is its business value?”*

* Does it generate revenue?
* Does it improve retention?
* Does it meet a user need?

👉 This exercise will help you prioritize your scenarios more effectively.

#### 5. Align your teams

This document should ideally be built with:

* marketing
* product

To ensure:

* consistency across scenarios
* feasibility
* better quality of the information provided

## What happens next?

Once your planning is completed, two paths are possible depending on your level of support:

### 1. Advanced Onboarding

Your planning is reviewed with your Onboarding Manager during the use case workshop.

👉 The goal:

* Review each scenario
* Validate use cases
* Ensure all information is complete and actionable

{% hint style="warning" %}
**Important**: The document must be fully completed beforehand to ensure the quality of the workshop.
{% endhint %}

👉 Once the planning is validated:

* The Implementation Manager in charge of your setup builds the data mapping
* Technical implementation can then start

### 2. Standard Onboarding (self-service)

You complete the planning independently, without a validation workshop.

👉 Once your planning is finalized:

* You can directly move on to creating your data mapping by following our [dedicated documentation](https://doc.batch.com/developer/technical-guides/how-to-guides/how-to-create-a-tagging-plan?q=conversion+goal).

{% hint style="success" %}
**In both cases:** the **CRM Scenario Planning** remains the foundation of your Batch setup:

* It structures your CRM strategy
* It guides the creation of your data mapping
* It determines the success of your scenarios
  {% endhint %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://doc.batch.com/getting-started/how-to-create-a-crm-scenario-planning.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.