eCRM scenarios, what are the elements to compose them?

Faire de l’email marketing, c’est faire de l’eCRM ! Il est totalement improbable (impardonnable ?) que vous vous cantonniez à l’envoi d’emails si vous disposez d’une base client (ou prospect). Les sms, les notifications push et même le bon vieux courrier papier doivent faire partie de votre arsenal (et de nombreux autres). Par contre, pour un marketeur, il n’est pas toujours simple de savoir de quoi sont composées les bibliothèque d’éléments indispensables à la conception d’un scénario eCRM, que vous utilisiez Adobe Campaign, Selligent, Salesforce Marketing Cloud, les outils d’IBM, … il existe toute une série d’outils que vos responsables de campagnes vont utiliser pour composer vos actions. Dans notre article, nous allons tenter d’isoler les principaux éléments afin de vous projeter dans les contraintes techniques et les questions que pourront vous poser vos services techniques. N’hésitez pas à réutiliser les icônes pour dessiner vos propres worflows 😉

Introductory note

On va faire court pour cette note d’intro, nous aurions l’occasion de développer certains points dans un article dédié. Le plus important à rappeler, c’est que tout workflow eCRM commence toujours par un déclencher (trigger en anglais). Le déclencher le plus classique, c’est votre doigt appuyant sur le bouton pour déclencher manuellement le scénario eCRM. Dans ce cas, on a une campagne « one-shot » dans laquelle tous vos contacts répondant à certaines conditions vont entrer dans le scénario. Les autres types de trigger sont basés sur l’apparition de nouvelles données (une transaction, un nouveau contact, …), sur la mise à jour de données ou de seuils (changement d’adresse, nombre de points atteints, …) ou sur la vérification de conditions d’exécution (jour anniversaire, …). Dans ce cas, soit le scénario se déclenche en temps réel, on est dans du « one-to-one », soit il est évalué tous les X (une fois par jour, une fois par mois, …), on est dans du « one-to-few ». Ce déclencheur est forcément le point de départ de votre scénario, toutes les autres opérations que nous allons voir ci-dessous partent de là. Dans les solutions eCRM, il n’y a pas forcément d’objet représentant physiquement ce point de départ, mais on trouve souvent un sigle « Play » qui en fait office. Dans certaines solutions, ce point de départ peut d’ailleurs se voir attribuer une URL à laquelle il sera possible de passer des paramètre pour déclencher le scénario. Pour rappel, on va essayer de parler des objets les plus fréquents, les plus standards, qui représentent les contraintes techniques communes à toutes les solutions eCRM.

The data

That's certainly the basis, processing data. Data processing is not necessarily done at the scripting level in all eCRM solutions. But at the theoretical design stage of your eCRM workflows, it's important to get these steps down on paper anyway.

User list

In most cases, this is the second step in an eCRM scenario, where you select the list (table) in which the contacts you are interested in are located. In some cases, we may even decide to use several lists (or several segments if this concept is present at this level) in parallel.  

Data update

Your eCRM scenario may be asked to update some data. This is the case if you use forms or surveys, if you retrieve data from elsewhere... or even if you generate behavioral data.

Union

It is simply a matter of gathering data from several segments or several lists. We then continue the workflow by using the different lists gathered.    

Exclusion

In the same vein as the previous point, this is about rejecting one audience from another. For example, you might want to reject customers who have already purchased a certain product category from your overall customer base.  

Intersection

Here, as for the two previous objects, we mix several segments in order to keep only those present in both. For example, if you want to know the buyers of both Johnny Hallyday and Véronique Sanson CDs, this is the object you will use.  

Data export

eCRM solutions can in some cases export files containing contact lists (whether all profile information or only identifiers) in order to place them on an FTP server, to send them by email, ... in order to hand them over to another system, whether for analysis purposes or for channels that require data in "batch" mode.

Deduplication

If we use several lists, or if our lists do not contain only unique individuals, it may be important to deduplicate. The key used for deduplication can be selected on a case-by-case basis, whether it is the email address, the phone number, a customer ID, a family ID, ...  

Import of data

It can be interesting to import data directly into an eCRM workflow. Either simply to perform processing on this data (some eCRM platforms allow this), or if you decide to use this data to communicate on new leads or to add richness to your personalization (there are many other things you can do.

Profile search (Lookup)

In some scenarios, the entry point may be an unidentified individual. If following an identification (enrichment, form, ...) you want to match his existing profile (or simply check if he is already known), you will need an object of this type.  

Complex query (query engine)

Sometimes this module is found directly in the "user list" object, sometimes it is not integrated into the scenario at all, but this object can represent a query method on the database. Any eCRM solution has a graphical tool that allows you to perform queries without using SQL.  

SQL query

In some eCRM tools, it is possible to address the database directly by using SQL code or by pointing to stored procedures. This is necessarily very technical, but it sometimes allows you to bypass the limitations of graphical query engines and go one step further.

The actions

Processing data is important, but in the scripting process you have to create branches, make decisions, multiply the communication points... and to carry out these actions, it is essential to have a whole series of tools at hand.

Decision making

This is an essential block in your scripting, you need to make decisions against certain criteria. Most of the time, we check here a tie, is the number of points on the loyalty card greater than 1000. If it is, we will take one path, if not, we will take another.  

Split

We join here the previous block (sometimes they are represented by a single object), it is an object that will allow us to take several paths, most often, it is based on variables or fields present in the database. For example, if we do a split on the region, we will be able to take as many options as there are regions represented in the database.  

Timing

In an eCRM scenario, you don't always want all the tasks to be done one after the other. If you send reminders about abandoned carts, you won't necessarily send an email or a push notification in the next few seconds. The timing object therefore allows you to define a wait in the scenario, a few minutes, a few hours, a few days, etc.

AB Test

Testing is one of the foundations of eCRM, no scenario is perfect from the start. It is essential to test them. An AB Test object allows you to define the number of versions you want to test, the sample that will be used for the test and the decision mode concerning the winner of the test.  

Send by wave

It is an object that is mainly used to distribute the email sendings of a one-shot campaign, but it could also be the case for other channels. The objective is to send a message little by little, for example 1000 per hour in order not to produce technical problems, to relieve a customer service, ...  

Viral object / Sponsorship

We could probably have put this object in the channels category below, but it is an action tool. It allows you to change the person to whom the message is addressed. For example, while it is the sponsor who is identified and who carries out the actions in the eCRM scenario, we will switch to the sponsored person in order to send him a message.

CRM or other system connector

It is more and more important, you must be able to communicate with your other systems, whether it is a CRM platform, an ecommerce CMS, ... In many eCRM solutions, connectors are ready to use.  

Connection to a web service or an API

More rare, but very useful, is the possibility to connect to a web service or an API, again to communicate with an external system (send or receive information). It's close to the connector object, but here you can adapt to an API not provided by the eCRM solution.  

Redirection to another eCRM scenario

It is not necessarily relevant to put all your eCRM scenarios in a single workflow (in fact it is impossible in most cases) and it can be useful to move a lead into another eCRM scenario. For example, after a scenario dedicated to after-sales, you might want to direct your leads to a scenario dedicated to measuring customer satisfaction.  

End of scenario

Not present everywhere, it is sometimes essential to declare when your scenario stops or else you will not be allowed to put it into production or it will crash. In other eCRM tools, there is no need for this object, if there is no follow-up, the scenario stops by itself.  

Report

In some tools, it is possible to place report points at certain places in the scenario. Depending on the object you are going to link it to, this report can have different forms: email marketing report, segmentation report, purely technical report, ...  

Control point

This is again specific to each tool, but this object can in some cases allow you to delineate the different stages of your funnel. This is so that the global reporting can display the volume of leads according to the stage they arrived at.

The canals

It goes without saying that each channel will be represented by a different object, and as soon as we place this object in our scenario, we will have to specify the message to be sent. We won't comment them one by one, that will be the subject of a future article.