A Retro Claim occurs when a member receives credit for a transaction they made prior to the creation of their membership. This transaction is known as a retro transaction. There are typically two scenarios for a retro claim.
- A recently enrolled member looking to get credit for a purchase they made prior to their loyalty program enrollment.
- A member who forgot to provide their loyalty ID during a transaction.
In order for the retro claim process to work, three changes must be implemented in both ALP SaaS and the way transactions are inputted.
- ALP SaaS Support must enable retro claiming in the ALP SaaS instance.
- Transactions must contain both member-related and non-member-related data.
- A set of Retro Claim Keys must be defined. These keys are stored with the transaction and are used in the retro claim process.
Without non-member-related data, as referenced in the second item above, ALP SaaS will not be able to store retro transactions.
Retro Claims can be submitted in three ways, as detailed in the Submitting Retro Claims section below. They can be submitted by a user through Clienteling Services in ALP SaaS, by a member through the Member Portal and through WS Calls.
Main Article: Retro Claim Keys
Upon initial setup, Retro Claim Keys must be defined in order to support the composite key structure required for retro claim submission.
Main Article: Retro Claim Settings
Various settings can be configured that manage retro claim submission limits, retro transaction expiration and related options.
From a customer service perspective, retro claims are managed within the "Retro Claims" subpage of Clienteling Services. Loyalty members can view and submit retro claims via the member portal. Furthermore, WS functionality is available for managing retro claims.
System Location: Tools / Retro Claim / Retro Claim Activity
Program-wide retro claims can be viewed at the system location above.
System Location: Clienteling Services
Once a member is retrieved, the "Retro Claims" link can be utilized to view previous retro claims.
Retro claims can be submitted by users, members or via web services.
- User - Clienteling Services (Retro Claims subpage)
- Member - Member Portal (Retro Claim submission module)
- Web Services - WS Calls (RetroClaim.asmx)
Upon submission of a retro claim, the platform will attempt to match the claim with a retro transaction by using the Retro Claim Keys. Typically, this process is near real-time in processing speed, though system delays may occur. Additionally, dependent on the Retro Claim Settings at the time of the initial match attempt, a once daily job will execute in an attempt to match previously unmatched claims with retro transactions that may have been inserted into the database after the claim was made. If multiple retro transactions match the retro claim when a match attempt is made, only the oldest retro transaction will be matched.
Once a retro claim submission attempt is made, the platform can be configured to send an on-demand message to the member, alerting them of the end result. They can also view previously submitted retro claims within the member portal.
- Outstanding - The retro claim has not been matched yet, but is still eligible to be matched with a retro transaction.
- Matched - The retro claim has been matched to an existing retro transaction and the member received the actual transaction.
- Transaction Failed - The retro claim has been matched to an existing retro transaction, but the actual transaction failed to generate.
- Already Claimed - The retro claim has been matched to an existing retro transaction, but the retro transaction had already been claimed.
- Not Matched - The retro claim has not been matched and is no longer eligible to be matched with a retro transaction.
If the reprocessing retro claim setting is enabled, an initial match will attempt to be made, then further matches will be attempted until the retro transaction is expired. If the reprocessing retro claim setting is disabled, the initial match attempt will be the only one attempted.