Customer Loyalty

Returning customId field in activity API and showing within Interaction Report

In the Site Admin (Under Loyalty Dashboard → Advanced Dashboard Settings), we've included a flag to limit the operations depending on the custom id value. We can also set custom id value restrictions. We don't grant points to the user for any activities using the points API if the custom id limit is exceeded.

Calculation method information (currency/quantity) in the API Purchase Action

• To override the buy points type that we put up in the Product Catalog, we added the field to the purchase action (Action ID = 109).
  
• We have three options in the Purchase Points type:

1. Both Type
2. Only Ratio
3. Only Flat

Add usage limit and period to a coupon

Annex Cloud enhances the usage limit of the coupon for a particular period as an admin. You can set it as per the requirements. Once the user has redeemed the coupon, that coupon can be reused up to the setup limit. The duration will be days, week((Mon-Sun), month, year, anniversary year, lifetime, and calendar (set the date range from date to date).

Navigation: Options > Coupon Groups> Add New Coupon Group

• Example: If the usage limit is 2 times a day. It means that the coupon code can be used twice a day.

Points Undo for Partial Return

• Our points redemption is applied to the order total, not the line item.
• We have to add a flag in the Super Admin to enable this feature.
  

1. On a partial return, we need to update the Points Report and Order Report.
2. If we refund the points on a partial return, we should update the redeemed points.

Allow members to use a claimed reward code multiple times

• Members will only be able to claim a reward once, depending on their eligibility.
• Members can use the claimed reward code several times in order till the limit is reached on Annex Cloud.

Points Undo-Redemption for Partial Returns

Our current return mechanism does not restore any redeemed points to the user in the case of a partial refund. We need to offer a solution that allows us to "undo-redemption" of points used in the order in the event of incomplete returns. Individual clients should have the option of using or not using this functionality via a configurable solution in the site admin. There are a few factors to keep in mind when solving problems.

When calculating points redemption, the order total, not the line item, is used.

• Modifications to PCM entries can make proportionate undo-redemption logic for partial returns much more complicated.
• Any further discounts, coupons, or other offers that may have been added to the cart should be taken into account.

Looking Ahead

Coupon Code-Based Campaigns

• When the order is placed through the order API, it receives a coupon code, and that order matches a predefined segment condition, then applies a campaign benefit to the order (i.e., 2x points).
• We need to update our ADR segment to be able to define the conditions for the coupon codes under the order attributes section.
• This works in real-time.

To Accept orders from customers before opting into the loyalty for Explicit With Retrospective program

Every order from customers should flow to Annex Cloud irrespective of their opt-in status and points will be awarded to the customer in Annex. Once the user opts into the loyalty program, then he/she should see all accumulated points from the earlier orders on the dashboard.

If the customer opts out of the loyalty program and makes purchases in the meantime before joining the loyalty program again, then these orders should be reflected in their account with the points.

Manual Adjustments to Spend-Based Programs

• Admin interfaces for debit or credit spending for the member.
• For existing orders, if spending is manually adjusted, do we need to communicate this to the external client systems.
• Integration with service desk solutions.
• API enhancements.

Add secondary key identifier in Order API

We presently match product id and quantity in the order API to determine which products we need to return or cancel. This has worked for us till now, because the majority of our clients use product id as the primary key.

Product id, on the other hand, does not serve as a unique identity for Henry Schein. There could be numerous goods with the same product id in order, each with a distinct unit price and product attribute. When a product return is generated, we are unable to determine which line of product to update because both have the same product id.

To address this, we'll add a flag that allows the client to choose between using the main key and a composite key for order mapping.

Tier Rules - Spend based on quarters

• Tier Expiration: Tiers are based on spending and they will be evaluated every quarter (calendar).
• 90 days are based on the Calendar Year and Annual Quarters.

Integration Product Management

• Attentive: End-to-End integration has been done. Certification has been submitted.
• Gorgias: Integration has been done. Certification has been submitted.

Visual Commerce

No product development.

Ratings & Review

No product development.

Incentive Engine

No product development.

Refer A Friend

No product development.