Transaction Modeling is an advanced Blueshift capability that allows you to connect and segment lifecycle events/behaviors through a common identifier. Certain transactions, like hotel bookings, have multiple events associated with the transaction. Blueshift’s Transactions capability allows you to link these related events by using a common identifier. You stream in multiple events with the same transaction identifier and Blueshift models the "state" of the transaction based on these events. You can use the transaction state to drive a consistent set of communications for a given transaction.

transactions_flow_diagram.png

Note

Contact support@blueshift.com to enable Transaction modeling for your account.

Use Cases

Some examples where transactions can be used to drive communications are as follows:

Hotel Bookings

In the hospitality industry, a hotel booking goes through multiple states like booked, canceled, checked_in, checked_out, and so on. You might want to send a series of emails, SMS or mobile notifications related to these transaction states.

For example,

  • An email after the customer completes the booking.
  • An email before the customer checks in.
  • A thank-you notification after they check out.

Blueshift's Transaction Modeling makes it easy for you to orchestrate these messages that are all related to the same transaction.

Unique identifier:

  • booking_id

Events (transaction states):

  • booked
  • checked_in
  • checked_out
  • cancelled

eCommerce orders

In the eCommerce industry, when a customer places an order, the states can be order_placed, confirmed, shipped, delivered, order_cancelled, and returned. You might want to send emails at different steps during this process.

For example,

  • An email and SMS when a customer places an order.
  • An email and SMS when the order is shipped.
  • An SMS when the order is delivered.

You can use Blueshift's transaction modeling to create a campaign journey that sends messages at various points in the process.

Unique identifier:

  • order_id

Events (transaction states):

  • order_placed
  • confirmed
  • shipped
  • delivered
  • order_cancelled
  • returned

Sales industry

A sales executive's interaction with a prospect may contain many steps.

For example, the first interaction of an executive with a prospect may be a lead. This can be followed by an in-person message to someone from the prospect's team, validating if the prospect can truly lead to revenue. Then you send an offer, negotiate on terms, and close the deal. In such a case, you can use transaction modeling to create a journey that optimizes to convert the prospect into a deal. Unique identifier:

  • prospect_id

Events (transaction states):

  • lead
  • first_contact
  • validating_prospect
  • offer
  • negotiation
  • deal

For more information on how to use transactions, see:

Was this article helpful?
1 out of 1 found this helpful

Comments

0 comments

Please sign in to leave a comment.