Customer Events

Customer Events are various actions performed by contacts that capture their financial and marketing interactions. Customer events are processed by CRM.COM and are consumed for segmenting and rewarding contacts based on their actions. They also provide valuable analytics, and can even help facilitate payment flows.

There are several ways to create Customer Events:

  • Via an external integration system using CRM.COM’s Web APIs.

  • Automatically, through CRM.COM’s Automations when an event is performed.

  • Manually, by a system user through the CRM.COM back-end system.


THE ESSENTIALS

CRM.COM supports three different types of customer events:

When submitting a customer event, it's necessary to provide a unique identifier for the contact involved. The recommended method of identification is the CRM.COM Wallet’s code, however, if this is not possible, then the contact ID, contact code, CIM, or OTP are also acceptable methods of identification.

Purchase Events

A Purchase Event is a sales transaction captured by a third-party system, like a POS terminal, and submitted to CRM.COM through a dedicated Web API. The purchase event includes detailed information on who, where, when and which items where purchased along with detailed amounts information. Optionally, the purchase includes the contact’s request to spend an amount of money from their CRM.COM Wallet for fully or partially pay-off the purchase.

Additionally, when an invoice financial transaction is posted, it can also result in the generation of a Purchase Event. To enable this, an Automation must be configured to automatically generate the purchase event based on the invoice contents.

Upon cancelling a Purchase Event, the awarded and spent amounts (if any) will be reverted.

Achievement Events

An Achievement Event signifies a specific action performed by a Contact, such as topping-up their wallet. Achievement Events can be used in conjunction with Reward Offers to award contacts for achieving a target.

For example, an automation can be configured to automatically generate an Achievement Event whenever a Contact makes a new top-up. Then, an Achievement Reward Offer can be created whereby contacts who top-up their wallet with at least EUR100 within the space of a month will be awarded an additional EUR5. Segmentation enables the business to identify contacts with such achievements and configure targeted Reward Offers.

Referral Events

A Referral Event is generated when an existing contact recommends the business to a potential new customer, which could result in new contacts registering with the business. It's a way to motivate existing contacts to endorse the business.

Additionally, a Referral Event can be combined with a Referral Reward Offer to reward contacts for referring new customers to the business.


Customer Events Settings

Navigate to Settings > Contacts & CRM > Customer Events to configure system settings relevant to Customer Events.

Customer Event Classifications

Group your customer events based on classifications relevant to your line of Business. E.G., Purchase classifications can be created to differentiate between delivery, take away and dine-in purchases. Reward Offers can then be configured to target a specific purchase classification, e.g. a Reward Offer is created to award only purchases of type delivery.

Purchased Products Matching Resolution

If this setting is enabled, when a purchase is received, the purchased products will first be verified as to whether they are owned by the merchant/service provider where the purchase was performed and then by the Business. If such a product does not exist, the merchant/service provider will automatically create and own it.

Example

A merchant/service provider has a product (name: "Tea", SKU: "001"), a business also has a product with the same SKU (name: "Sugar", SKU: "001"). A purchase is submitted against the merchant/service provider for a product with SKU "001". If the product resolution setting is not enabled, the product to be used (and awarded/redeemed) will be the one created by the business, alternatively, if the setting is enabled, the product to be used (and awarded/redeemed) will be the one created by the merchant.

Purchase Matching Resolutions

This setting determines whether incoming purchase events should be instantly created or whether they should wait to be matched with a self-service claim or with other back-end purchases. Two modes are supported - Normal and Transaction Processor modes.

Normal mode

The normal mode applies if the toggle is disabled.

The core behaviour of Normal mode covers three possible scenarios:

Back-End Purchase: An external system submits a purchase (with a contact identification, e.g. contact code) - a purchase is instantly created.

Claim Purchase: An external system submits a purchase (without a contact identification, e.g. contact code) - a purchase won't be created until a contact claims it within 48 hours. A Contact can claim a purchase by scanning a QR code/Barcode on a receipt using a front-end application (e.g. consumer mobile application).

Self-Submit Purchase: In cases where there is no POS integration, a contact self-submits a purchase from a front-end application (e.g. a mobile application) directly to CRM.COM, where a purchase is instantly created.

Transaction Processor mode

Transaction Processor mode applies when the toggle is enabled. Even in such cases, there is an option to apply the Transaction Processor mode only for selected organizations, and the Normal mode will apply to the rest.

If this setting is enabled, CRM.COM tries to match two purchases, one received from a POS and one from a transaction processor, using the same unique reference number. When the match is achieved, the Contact is awarded.

Example of Transaction Processor mode

The concept of this flow is that the POS system does not identify the Contact during checkout and submits a purchase without a contact identification but with a unique transaction reference number. The Payment Gateway also submits a purchase with the Contact's card and the same unique transaction reference number.

The two purchases are matched, the Contact is identified based on the card used, and the Contact is awarded.


Good to Know…

Purchase Estimates

Prior to submitting a Purchase Event, a Purchase Estimates API can be submitted to CRM.COM with the items intended to be purchased by the contact, along with the requested amount to be spent using the contact’s wallet. The response of this API includes the actual amount that the contact can spend using their wallet funds.

Transaction Processor Purchase Events

With the Transaction Processor, the Platform determines the routing paths for all events (e.g. purchase events) among the platform’s organisations (i.e. Service Owners, Businesses and Merchants/Service Providers). A transaction processor is responsible for verifying incoming purchase customer events, redirecting them to the relevant business, assessing event eligibility, and matching Purchase Events with transaction claims, if applicable.

Customer Event Utilities

Customer Event Utilities provide the ability for back-end system users to view and void Customer events, as well as process ad hoc returns where products are returned and the associated transactions are reversed.

A back-end system user can view purchase, achievement and referral customer events by navigating to Rewards > Reward Events from the sidebar menu.

To manage these events, navigate to the relevant contact screen and select the Activity Feed tab, select the event to see the allowed actions.


Reference Material

You may also find it useful to refer to the following manuals for further reading in relation to Customer Events.

Contacts

Contacts

Reward Offers

Reward Offers

Automations

Automations

 

Related pages