Doing email marketing is doing eCRM! It's totally unlikely (unforgivable?) that you'll limit yourself to sending emails if you have a customer (or prospect) base. SMS, push notifications and even the good old paper mail should be part of your arsenal (and many others).
On the other hand, for a marketer, it is not always easy to know what the library of elements that are essential to the design of an eCRM scenario is composed of. Whether you use Adobe Campaign, Selligent, Salesforce Marketing Cloud, IBM tools, etc., there is a whole series of tools that your campaign managers will use to compose your actions. In our article, we will try to isolate the main elements in order to project you in the technical constraints and the questions that your technical services may ask you. Feel free to reuse the icons to draw your own workflows 😉
Introductory note
We'll keep this introduction short, as we'll have the opportunity to develop certain points in a dedicated article. The most important thing to remember is that any eCRM workflow always starts with a trigger. The most classic trigger is your finger pressing the button to manually trigger the eCRM scenario. In this case, we have a "one-shot" campaign in which all your contacts meeting certain conditions will enter the scenario.
Other types of triggers are based on the appearance of new data (a transaction, a new contact, etc.), on the updating of data or thresholds (change of address, number of points reached, etc.) or on the verification of execution conditions (anniversary day, etc.). In this case, either the scenario is triggered in real time, we are in "one-to-one", or it is evaluated every X (once a day, once a month, ...), we are in "one-to-few".
This trigger is necessarily the starting point of your scenario, all the other operations we will see below start from there.
In eCRM solutions, there is not necessarily an object that physically represents this starting point, but there is often a "Play" symbol that serves as a starting point. In some solutions, this starting point can also be assigned a URL to which it is possible to pass parameters to trigger the scenario.
As a reminder, we will try to talk about the most frequent and standard objects, which represent the technical constraints common to all eCRM solutions.
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.
Need help?
Reading content isn't everything. The best way is to talk to us.
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.
