Overview

Generally, brands spend a lot of money to keep their customers happy. This could be in the form of giving incentives like points which encourage customers to purchase more with the brand. However, there should be a limit on the amount of liability that is burning from the brand’s pockets. Without proper control on this, brands might end up with a lot of liability on their end.

To help brands maintain control over their liability, at Capillary, we have a concept called capping (also called limits). Using this capability, brands can limit the points that they are giving to their customers. A controlled liability is a good liability for any brand.

Existing capping/limit capabilities we have

In order to configure capping in Capillary, follow the following steps:
Go to the respective org → Go to the respective loyalty program → Click on Edit → Go to Workflow → Click on Activity reward currency limit

Currently, for capping, we are supporting two types of cappings. They are

1. Cart Level Capping
2. Customer Level Capping.

Cart Level Capping: The cart level capping applies the limits at the Cart Level i.e. on every transaction or bill where this capping is applicable.

• For example: You have configured a cart level capping that on each transaction, a max 700 total points can be given ( 500 regular points and 200 promotional points limits) can be given to a customer. Now, let's say a customer made a transaction of 10,000 INR and the customer is supposed to get 700 regular points but because of Capping the customer will only be getting 500 regular points.

Customer Level Capping: Customer level cappings are the type of cappings (or limits) that will be applicable for all the customers in a loyalty program, and they will be valid for a certain “duration”.

• For example: You have configured a customer level capping that, in a month, a user can get a max of 700 total points ( 500 regular points and 200 promotional points limits). Now, let’s say, a user made a transaction and is supposed to get 400 regular points, and the user will get them. However, in the same duration (aka same month), the user has made another transaction and is supposed to get 200 regular points.
• This time, the user will get only 100 regular points even though the user is supposed to get 200 regular points. Because, the user’s regular points limit of 500 for the durations is being crossed here. This is how customer-level capping helps in capping for customers across a time duration.

📘

Note

With the existing capping capabilities, if a brand wants to create customer level capping, they first have to create a milestone of type “limit customer benefits”. Once they have configured that, then those Milestones will be available in the capping UI to select.It will be like as below:

It will be like as below:

Here, we can see that customer-level capping is configured via milestone (as the type of ‘limit benefit activity’). Once a milestone is created, it is available just like the above picture & then the brand can select that as the “customer level capping”.

Limitations with the existing capabilities of capping

Even though the existing capabilities of capping help brands in controlling their liability, there are several limitations it comes to solving different use cases. Additionally, there are a few computational challengeswhich upon solving them could greatly help in end user experience.

Following are some of the major challenges with the existing capabilities:

1. With the existing capping capabilities, capping can be applied only on points (regular, promotional * both of them).
2. If a brand wants to apply capping/limits from lineitem perspective, it cannot be done directly with the capping available right now. Brands are depending on “sets” inside the workflows to achieve these types of use cases.
3. When the brands are depending on the “sets” to achieve such use cases, the complexity of the sets is increasing & also the number of sets are getting increased. This in turn, increases the computational speed of the processing & there by causes bad end-user experience.

Detailed explanation of point 2:

For example, this is a brand ABC that has 3 product lines. Let's say X, Y and Z. Now the ABC brands want to apply a capping at the product level .i.e., if a customer buys X, the maximum points allocated should be 100. Similarly for 200 points for Y, and 50 points for Z.

With the existing capabilities, we cannot directly apply capping at the SKU level or product level. Thus to implement these use cases, brands are kind of doing the following steps:

1. In Set 1 (aka Main set), they are creating forward sets like Set 2, Set 3, and Set 4.
2. In Set 2, the rule is written on X and capping is applied.
3. In Set 3, the rule is written on Y and capping is applied.
4. In Set 4, the rule is written on Z and capping is applied.

Because of this huge & complex process, the computational time increases because With the increasing number of sets, the computational speed of the system decreases.

Also later, when a brand wants to know what kind of capping they have created for a particular product line, they have to go to each set manually and check them which is not a good user experience.

Latest enhancements of cappings

With our recent enhancements, we have greatly improved the capabilities of our capping such that all the above limitations are nullified. Along with that, these enhancements can help the brands in unlocking several other use cases.

Cart Level Capping

Currently, at the cart level, we can configure capping based on points only. (Regular points, Promotional points, and both). However, we cannot configure lineitem perspective OR transaction amount type of cappings directly from here.

To configure these in the new enhancements of cappings, open the “Activity currency reward limits” (the same capping page which exist right now.

Here are the steps:

1. To apply capping at the cart level click on Add limit of “Individual activity limits”.

2. At max 10 capping limits can be applied at Cart Level including the types of capping as points, line-item quantity, line-item amount, and transaction amount.

With the enhancement, brands can apply capping on KPIs such as:

• Points (Regular, Promotional, and regular+promotional)
• Line-item quantity
• Line-item amount
• Transaction amount

📘

Brands cannot configure “Line-item amount” & “Line-item quantity” capping at the same time across both “cart level capping” & “customer level capping”.

This is primarily because the line item amount & line item quantity on any transaction talk about the same end information on any bill. So, computing differently on them at the same item can lead to a lot of ambiguity & computational challenges while applying the capping.

KPI: Points

Use case: Brand ABC wants to achieve a use case where they want to give a max of 1000 regular points on each transaction. They want to achieve this to control their liabilities.

As per the above use case:

• KPI: Points → Regular points.

Explanation of the fields in the latest cart level capping for the use case:

1. Name: Name of the capping.
2. Points limit: Select the KPI over which we can apply capping, in the above use case the KPI selected will be Regular points.
3. Scope: While applying the capping choose the scope between “All transactions” or “Filter transactions”. If a brand wants to apply these cappings on specific filters, then the filters under the “filter transactions” (Brands, Categories, SKUs, Attributes, Stores & Zones) can be used.
4. Limit Value: Limit value is the placeholder to set the value of points to be limited at the Cart level.
5. Exclude Promotions : If a brand want to exclude a certain promotion from this capping check, they can configure that here.

KPI: Line-item amount

With this enhancement, brands can apply “amount” type of capping on lineitems directly from here instead of depending on any indirect methods. This capping means that, brands can control until what amount, the benefits associated can be given to the customer on each transaction.

Use Case: A retail brand called Purple wants to apply capping on the line item category “beverages”. The brand wants to give benefits associated with that category only upto amount 1000. As the use case specifies that the capping needs to be applied on the category called “beverages”, the scope will be of filter transactions (have to select the appropriate filter from the drop-down).

In this use case:

• KPI → Line item amount i.e. the Max Line item amount on which points can be earned by a user per transaction for this category.

Explanation of the fields in the latest cart level capping for the use case:

1. Name: Name of the capping configured.
2. Points Limit: Select the KPI as “Line-item amount,” to apply the capping of Max Line item amount on which points can be earned per transaction.
3. Scope: As the use case states the capping is to be applied on “beverages” category, select the “category” as the filter & select the appropriate option.
4. Limit Value: Limit value is the placeholder to set the value of an amount to be limited at the Line item level. In this use case, it will be 1000.
5. Exclude Promotions: If the brands wants to exclude a promotion from this capping, that promotions has to be selected here.

KPI: Line-item quantity

With this enhancement, brands can configure capping on a particular lineitem from the quantity perspectives. This capping helps the brands in configuring “upto how many quantities, the associated benefits can be given to a customer”. Often verticals like fuels, paints needs this kind of capping.

Use Case: A fuel brand called “Reno” wants to apply capping in such a way that they want to give benefits only upto 10 liters of “petrol”. If a user purchases more than 10 lites of “petrol”, the brand don’t want to give benefits for those extra quantities.

In this use case:

KPI → Line item quantity is the maximum line item quantity on which points can be earned per transaction.

1. Name: Name of the capping configured.
2. Points Limit: Select the KPI as “Line-item quantity,” to apply the capping of Max Line item quantity on which points can be earned per transaction.
3. Scope: As the use case states the capping is to be applied on “petrol” category, select the “category” as the filter & select the appropriate option from the dropdown.
4. Limit Value: Limit value is the placeholder to set the value of an quantity to be limited at the Line item level. In this use case, it will be 10.
5. Exclude Promotions: If the brands wants to exclude a promotion from this capping, that promotions has to be selected here.

KPI: Transaction amount

Use Case: A retail brand “Jion” wants to give benefits associated upto ONLY 5000 transaction amount on each bill. They wanted to control on the transaction level not on the lineitem level.

Use Case: A retail brand “Jion” wants to give benefits associated upto ONLY 5000 transaction amount on each bill. They wanted to control on the transaction level not on the lineitem level.

In this use case:

• KPI → Transaction amount is the maximum transaction amount on which points can be earned per transaction.

1. Name: Name of the capping configured.
2. Points Limit: Select the KPI as “Transaction amount,” to apply the capping of Max transaction amount on which points can be earned per transaction.
3. Scope: Select the scope as per the use case the brand wants to achieve. The important point to note here is, only “store/zone” are supported as the filters in “transaction amount” capping.
4. Limit Value: Limit value is the placeholder to set the value of an transaction amount to be limited on each transaction.
5. Exclude Promotions: If the brands wants to exclude a promotion from this capping, that promotions has to be selected here.

Customer Level Capping

Customer level capping will have ALL the capabilities of the cart level capping with following changes:

1. In customer level capping, brands can configure capping on one more KPI called “Transactions count”. With this brands can say, upto X transactions, they will give the benefits.
2. As the customer level capping applies for each customer across a duration, brands have to add mentioned about “duration”, “start date” & “ number of cycles.

KPI: Points

Use case: KPI as “Regular points”
A brand “Pata” wants to apply capping at Regular points i.e. at max customers can earn 1000 points in a month (can be any time duration), for 12 months i.e number of cycles is 12.

In the above case:

• KPI: Points -> Regular points.

Explanation of the fields in the latest cart level capping for the use case:

1. Name: Name of the capping.
2. Points limit: Select the KPI over which we can apply capping, in the above use case the KPI selected will be Regular points.
3. Scope: While applying the capping choose the scope between “All transactions” or “Filter transactions”. If a brand wants to apply these cappings on specific filters, then the filters under the “filter transactions” (Brands, Categories, SKUs, Attributes, Stores & Zones) can be used.
4. Limit Value: Limit value is the placeholder to set the value of points to be limited at the Cart level.
   Exclude Promotions : If a brand want to exclude a certain promotion from this capping check, they can configure that here.
5. Refreshes: For how much time, the capping will be validated for the user. For example, if this is selected as “month”, then the applied capping will be valid for a month.
6. Start date: From what date, the brand wants the capping to be started. Please note that the dates 29th, 30th, 31st are disabled as the start dates keeping in view of some user-experience challenges.

KPI: Line-item amount

This enhancement allows brands to apply capping at Line-item amount for each customer across a duration of time. This is very similar to “Lineitem” capping of cart-level, just that it will be applied for all the customers for the selected duration.

Use Case: A retail brand called “Bishal Mart” wants to apply capping on the lineitem category “Beauty” of 500 INR amount per customer for a month time duration and for a 12 number of cycle. As the use case specifies that the capping needs to be applied at category “Beauty” at customer level, the scope will be filter transactions.

The capping start date is : 2023-10-05

📘

If the first cycle start date is today, the Limit will begin as soon as it is saved. Any other date start time: 12:00:00 am & end time 11:59:59 pm.

KPI: Line item amount i.e. the Max Line item amount on which customer will earn points in a particular time duration.

Explanation of the fields in the latest cart level capping for the use case:

1. Name: Name of the capping configured.
2. Points Limit: Select the KPI as “Line-item amount,” to apply the capping of Max Line item amount on which points can be earned per transaction.
3. Scope: As the use case states the capping is to be applied on “foundations” category, select the “category” as the filter & select the appropriate option.
4. Limit Value: Limit value is the placeholder to set the value of an amount to be limited at the Line item level. In this use case, it will be 1000.
5. Exclude Promotions: If the brands wants to exclude a promotion from this capping, that promotions has to be selected here.
6. Refreshes every: Refreshes every is a placeholder that defines the duration of the capping i.e. after how much duration the capping will start again
7. 1st cycle starts on: A date on which the first cycle of customer capping will start.
8. Total number of cycles: placeholder to set the number of times the cycle will be repeated.

KPI: Line-item quantity

This enhancement allows brands to apply capping at Line-item quantity per customer for a specific time duration and for specific number of cycles.

Use Case: A fuel brand called “Bhell” wants to achieve the use case where they want to give benefits associated upto 10 liters of petrol for each customer in a specific duration. They also want this capping duration to be repeated for 5 number of times (aka 5 cycles).

KPI: Line item quantity is the maximum line item quantity on which points can be earned per customer.

1. Name: Name of the capping configured.
2. Points Limit: Select the KPI as “Line-item quantity,” to apply the capping of Max Line item quantity on which points can be earned per transaction.
3. Scope: As the use case states the capping is to be applied on “petrol” category, select the “category” as the filter & select the appropriate option.
4. Limit Value: Limit value is the placeholder to set the value of an quantity to be limited at the Line item level. In this use case, it will be 10.
5. Exclude Promotions: If the brands wants to exclude a promotion from this capping, that promotions has to be selected here.
6. Refreshes every: Refreshes every is a placeholder that defines the duration of the capping i.e. after how many days the capping will start again
7. 1st cycle starts on A date on which the first cycle of customer capping will start.
8. Total number of cycles: placeholder to set the number of times the cycle will be repeated.

KPI: Transaction amount

This enhancement allows brands to apply capping on the overall transaction amount per customer across a duration of time, and for ‘n’ number of durations/cycles.

Use Case: A retail brand “BugBiscuit” wants to give benefits associated upto only 5000 transaction amount for each customer in a duration, so that they can control their liability.

1. Name: Name of the capping configured.
2. Points Limit: Select the KPI as “Transaction amount,” to apply the capping of Max transaction amount on which points can be earned per transaction.
3. Scope: Select the scope as per the use case the brand wants to achieve.
4. Limit Value: Limit value is the placeholder to set the value of an transaction amount to be limited on each transaction.
5. Exclude Promotions: If the brands wants to exclude a promotion from this capping, that promotions has to be selected here.
6. Refreshes every: Refreshes every is a placeholder that defines the duration of the capping i.e. after how many days the capping will start again
7. 1st cycle starts on A date on which the first cycle of customer capping will start.
8. Total number of cycles: placeholder to set the number of times the cycle will be repeated.

KPI: Transaction count

With this enhancement, brands can control upto how many number of transactions, the benefits associated will be given to each customer across a duration of time, and for ‘n’ number of times.

Use Case:

A ecommerce brand “Blipbart” wants to give benefits to their customers upto 5 transactions in a month to control their liability. They also want this capping to be repeated for 5 number of months (aka 5 cycles).

Options to select to achieve the above use case:

1. Name: Name of the capping configured.
2. Points Limit: Select the KPI as “Transactions count,” to apply the capping of Max transaction counts until which points can be earned.
3. Scope: Select the scope as per the use case the brand wants to achieve.
4. Limit Value: Limit value is the placeholder to set the value of an transactions count.
5. Exclude Promotions: If the brands wants to exclude a promotion from this capping, that promotions has to be selected here.
6. Refreshes every: Refreshes every is a placeholder that defines the duration of the capping i.e. after how many days the capping will start again.
7. 1st cycle starts on A date on which the first cycle of customer capping will start.
8. Total number of cycles: placeholder to set the number of times the cycle will be repeated.

How capping works in MLP?

In case of MLP Orgs, there will be a default program as well as source programs. Let’s say, there is a brand ‘ABC’ which is of MLP type and they have configured 1 default program & 5 source programs.

Now, whenever a customer makes a transaction, the transaction of that customer will go through the appropriate source program as well as the default program in the same order.

In the case of capping, the same hierarchy will be followed. The capping which has been configured on the source program will be validated first, and then the default program.

For example: There is a capping configured on the source program (300 regular points) & default program (200 regular points). Now, let’s say a customer has made a transaction and is supposed to get 300 regular points from source and 250 regular points from the default program.

Now, as per the hierarchy, capping of source will be validated first and then the default program. So, the user will get 300 from the source program but ONLY 200 from the default program.

Frequently asked questions

1. Can I add qty and amount limits together?

   No, Line-item amount and Line-item quantity capping cannot be applied together. This is primarily because the line item amount & line item quantity on any transaction talk about the same end information on any bill. So, computing differently on them at the same item can lead to a lot of ambiguity & computational challenges while applying the capping.
   Also, most of the brands will have the usecases where they configure cappings either on amount or quantity basis, but not both at the same time. For example, fuel vertical mostly will have quantity based cappings whereas retail markets will mostly have the amount based cappings.

2. How does it work with set-level capping?

   Brands can still use set level capping for the use cases which are not possible even with this advance capping. The idea of this advanced capping is to reduce the heavy dependency on set-level cappings (which many brands are doing right now) so that the overall use experience increases & the computational speed of the workflow increases.
   However, brands can still use the set-level cappings whenever they needed. Just make sure that, you have fully understood this advanced capping before going ahead with set-level capping.

3. If have regular and promotional points what is applied first? So that users know what will be capped?

   The hierarchy here is regular points → promotional points. This means that regular points capping will be validated first, and then the promotional points capping will be validated.

4. How will I see if certain line item points were applied less due to capping?

   We are planning to bring the “customer level cappings” view on the member care very soon. From here, CSMs and CSRs can view the tracked capping value of a customer and can know why a certain customer got a certain number of points because of a capping.

5. Will I be able to see this data in member care?

   As of now, there is no membercare view present for capping. However, we are planning to bring this feature in the near future where the CS members can see this date in the membercare.

6. Will I see cappings applied in evaluation logs?

   Yes, capping details of a transactions will be available in the evaluation logs of them. Sustenance team can view those details for de-bugging purposes & all.

7. Can I pause cappings?

   As of now, there is no way to pause a capping. Users can configure a capping & delete it as per their need. However, please note that, we are planning to bring the ability to pause a “customer level capping” very soon in the future.

8. How do I exclude certain promotions from capping limits?

   There is an option called “Exclude Promotions” while configuring the capping. If a promotion is included in that list, then that promotion will be excluded from the capping.
   A useful hack: If you want to include ONLY a particular promotion in the capping: Just select all the capping in “Excluded promotions” and deselect the above promotions. This will make sure that the capping is being applied ONLY on that promotion.

9. Why only 10 cappings? Can this limit be increased?

   As of now, we are supporting 10 cappings at the cart level and 10 cappings at the customer level. This means that, on each transaction, all these cappings will be evaluated on a real-time basis which requires a huge computational power and can decrease the overall speed of the processing.
   To keep this in check, we are limiting the number of cappings to 10. However, If a brand wants to have more capping for their use cases, do let us know (Product Team).

10. Where do I see the capping tracked value for a customer for a limit?

    This will be available in the member in the future. We will let you know once it is available to use