BPM stands for "Business Process Management", i.e. life cycles. A BPM journey defines the states the contact can be in. The states are stored in a BPM list. For a global customer life cycle this can be "welcome, retention, loyalty, etc.". For a specific welcome scenario, this might be the different steps: "first touch, first reminder, don't miss out, etc.". The BPM list is always linked to an Audience list and contains the state a contact is in.
The BPM journey defines the different states with BPM State components, and it has one BPM In component that serves as an entry point for contacts to enter the BPM cycle.
The BPM Process component is used to push a selection of contacts in the BPM cycle. It is used in other journeys than the BPM (states) journey. It can be used for an entire selection, a journey with an Audience component and a BPM Process component. Usually in a data driven (scheduled) journey, to continuously push contacts in the BPM cycle depending on the selection in the Audience component. You can compare it to a data driven email journey, where you create emails for everyone entering the journey. Or it can be used somewhere in a journey, after the contact clicks, and push him in the BPM cycle. Compare it to an instant email.
Finally, the BPM Trigger component is used in journeys, other than the BPM (states) journey, to change the contact's state when they do something. For instance change the state from "Welcome" to "Retention" in a customer lifecycle, when they registered in the registration journey.
The BPM journey can also be used in combination with FrontOffice. If a BPM State component is set to an "interactive" state, all contacts in that state will be visible in FrontOffice. A FrontOffice agent can manually answer questions about the contact in that specific "interactive" state. A typical example would be a call center, where the FrontOffice agent calls the contact and based on his answers fills out the questions. FrontOffice can also be used independently from a BPM journey.
A BPM journey is continuously active. This implies that the journey should be data driven (scheduled). Every time it is executed it checks if the contact needs to change state, depending on the events (triggers) defined in each BPM State component.
Another important difference is that a BPM journey always start with a BPM In component and not with an audience component.
!
Note that BPM (states) journeys can be completed with other components (email, SMS, etc.). Each time the contact enters a state, the email will be send to him. So it is possible the contact receives the email multiple times, each time they enter the state again ('Entry' trigger).
Emails can also be personalized in a BPM journey:
- Scope= MASTER : to retrieve data from the BPM list
- Scope= PROFILE: to retrieve data from the audience list. E.g. ~PROFILE.FIRSTNAME~
To personalize emails in a regular journey (without a BPM in component) use
- Scope= MASTER to retrieve data from the audience list
- Scope= BPM_CID_XXX: to retrieve data from the BPM list, if the BPM list is linked 1-on-1 to the audience list, just like any other profile extension.
Following is an
example of a journey with a BPM Process component (second journey image
below) pointing to the BPM journey (third journey image below), adding
contacts to the BPM cycle:
The first journey runs daily, adding contacts that recently ordered. They
receive an invitation email to fill out the "Satisfaction survey".
Each time a contact ordered, they will receive the email. (note: an action
list is used to send the invitation email multiple times). A sensor in
the email points to the second journey's Input component, so when a contact
clicks the sensor, they will end up at the "After sales Satisfaction
Survey".
Once they have complete the survey, they will be added to the "After
sales" BPM journey.
Because the contact can fill out the survey multiple times (each time he
ordered), the contact can have many survey records (1-on-many linked survey
list). The Lookup component finds the most recent filled out survey record
and adds all that record's information temporary in memory ('Add
to context' with scope name "SURVEY.")
Once 'Found', and if the contact requested to be contacted in the survey,
the BPM Process component adds the contact to the BPM Process, passing
the survey values to the BPM journey. On the tab 'Data validation'
of the BPM Process component a constraint is added to check if he requested
to be contacted in the survey: SURVEY.REQUEST_CALL='yes' (remember, the
scope survey comes from the Lookup component 'Add to context')
The contact only enters the BPM "Contact after sales" journey
when he asked to be contacted in the survey (third BPM journey image).
The 'Fields' have been defined on the BPM In component and the values will
be stored on the new record, created for the contact in the BPM list.
The BPM In component's checkbox 'Unique users' is unchecked. Each time
the contact fills out the survey, a BPM record is added for him.
He enters in the interactive BPM State "Contact me". An interactive
state is used by FrontOffice agents. An employee can use this module to
call the contact. As a result of the communication, the FrontOffice agent
decides if the contact is "Unhappy" or happy ("Send voucher"
event). If they are unhappy, the contact enters a second interactive BPM
State "Unhappy" for a second FrontOffice contact moment.
When the contact enters the "Send voucher" BPM State component
an email is sent with a "Discount voucher". The "No Further
Contact Required" BPM State is an end state of the BPM cycle.
The current state of the contact is stored in the STATEID field on the
BPM list. This matches the BPM State component IDs.
