Manage ID change requests
This page provides you with information on how to modify identifiers through the Member Care page.
You can submit the following change requests:
- Goodwill requests (coupons and points)
- Change mobile number
- Change Email ID
- Change external ID
- Account merge
- Edit profile
- Delete member's account
Configure notifications, auto-approval, OTP settings , and set escalation flow
Note: This can be performed only from old Membercare
To configure Email, Mobile, External ID, or Account Merge settings, do the following:
- On Member Care, navigate to the Settings category and click ID Change Request Settings. You will see different change request types - Email, Mobile, External ID, Account, and Retro Transaction.
- Click on the option that you want to configure. You will see the corresponding options as shown below.
- Configure the following settings and then click Save.
Option | Description |
---|---|
Email these on arrival of request | Select the employees of your org (org POCs) that you want to notify through emails when identifier change or account merge requests are submitted - it could be through Member Care, InStore, or API. Use the Filter box to search users by name. In Allow Request, select any of the following options. Never: Select this if you do not want to send any alerts to org POCs. Always: Select this to always send alerts to org POCs whenever a new request is logged. - Only when: Select this to alert org POCs based on the transaction value of the customer. |
Auto Approve | Set Auto Approve to On if you want to automatically approve Email, Mobile, External ID, or Account Merge requests, without the requests having to be queued for approval. |
Communicate Change to | For Email or Mobile select whether to notify to the old identifier or new identifier and click Configure to set the notification message. Select Old ID to send a notification to the old email id or mobile number regarding the identifier change. Select New ID to send a notification to the new mobile number or email id. For External ID, you can notify through both SMS and email. Click the respective CONFIGURE button to set the message. |
Configure Email (not applicable for Mobile) | 1. Click the Configure button to configure the Email message. 2. In the Configure Email window, type the subject in the Subject box. In the message body, type the content and insert images. Add custom tags in the message body using the predefined tags wherever required. 3. Click Save Changes. |
Configure SMS (not applicable for Email) | 1. Click the Configure button to configure the SMS message. 2. In the Configure SMS window, type in the message and include predefined tags wherever required. |
OTP settings (Applicable to all identifiers) | Set the to OTP slider to On to enable OTP validation for the customer identifier. |
- Click Save to save the changes.
Update Identifiers Directly (One Step Change)
Org admins can update identifiers through one-step change without the need of sending for approval.
- Open the respective identifier change request page that you want to update - mobile, email or external id
- Click One Step Change.
- Enter the current identifier (email ID/mobile number/external ID) in the Existing box.
- Enter the new identifier (email ID, mobile number, or external ID) in the Requested To box.
- Click Proceed.
Download Identifier Change Requests
You can download ID change requests (Account Merge, Mobile Reallocation, Email, Mobile, or External ID) as a CSV file. To download the list of requests, do the following.
- On the respective identifier change requests page, click the Download drop-down that appears on the top-right
- Set the duration of the requests that you want to download in Start Date and End Date
- In Download, select the statuses that you want to download - Pending, Approved, and Declined
- Click Proceed
The list gets downloaded as a CSV file.
Delete member account
Navigate to the Membercare home page, then click the three-dots menu. From the ID change request dropdown, select Delete member's account and submit the request.
After a deletion request is raised for a customer, their status changes to Deletion Pending. The member account is deleted only after the deletion request is approved. For information on approving or rejecting a request, refer to Manage requests.
Merge Accounts
When duplicate accounts of a customer can exist. you can merge those accounts into one. One account will be survived and another account will be moved
*Surviving Account: The customer account that will remain to continue after merging accounts is the Surviving Account.
Deactivating Account: The customer account that will be removed after merging is a deactivating account. The account *once deactivated cannot be activated again and its data cannot be retrieved. However, the entire data will be validated and moved to the surviving account.
Settings for Account Merge Requests
You can configure to notify org POCs on merge requests, automatically approve merge requests without the need of the back-end team to approve it, and notify customers through SMS and email when their accounts are merged.
- On the Member Care navigation pane, click Settings > ID Change Request Settings > Account.
- In Email these on arrival of request, select the org POCs that you want to notify on new merge requests.
- Set Auto approve to On to automatically approve merge requests directly.
- In Communicate change to, select whom to notify in case of account merge.
- Check Requestor to notify the customer that requested for account merge.
- Check Survivor to notify the customer whose remains after merging.
- Check both Requestor and Survivor to notify both.
- To configure SMS notification, click the Configure button next to Configure SMS and create the message. Use predefined tags wherever required.
- To configure email, click the Configure button next to Configure Email.
- In Subject, enter the subject of the email.
- In the message body, set up the message body with content and insert images. You can add predefined tags in the message wherever required. To add tags, just click the tag from the list on the left.
- Click Save Changes.
- Click Save.
Merge Accounts Directly (One Step Change)
To merge duplicate accounts directly, you can use the One Step Change option. Only admin users of an org have access to this feature.
- In the Account Merge Change Request page, click One Step Change.
- In the Existing Box, type the email ID, mobile number, or external ID of the existing account that you want to merge.
- In the Requested To box, type the email ID, mobile number, or external ID of the account into which you want to merge - survivor account.
- Click Proceed.
Download Account Merge History
To download accounts merge history as a CSV file, do the following:
- On the Account Merge page, click the Download drop-down that appears on the top-right
- Set the duration of the requests that you want to download in Start Date and End Date
- In Download, select the statuses that you want to download - Pending, Approved, and Declined.
- Click Proceed
The list gets downloaded to your computer as a CSV file.
Effect of account merging on the customer data
After merging, the account that continues to remain is a survivor account and the account that is merged into the survivor account is a victim account.
* Registration date: The registration date will be the earlier date between the two accounts
- Transactions: All transactions of the victim will be merged into the survivor's account
- Points & Coupons: All points and coupons of the victim will be merged into the survivor's account
The following table provides a comprehensive list of changes that will occur when two accounts are merged.
Parameter | Victim | Survivor | Final Values after Merging |
---|---|---|---|
Mobile Number/Email ID/External ID | ID1 ID1 Null | ID2 Null ID2 | ID2 ID1 ID2 The customer identifier will be the unique id of the surviving account if the customer id is available in both accounts. If the customer id is not available in the surviving account, then the values will be picked from the deactivating account (if available in that account). |
Registered Date | D1 | D2 | D1 - If D1<D2 D2 - If D2<D1 The earlier date among the two accounts will be considered as the final registration date. |
Registered Till | Till1 | Till2 | Till1 - If D1<D2 Till2 - If D2<D1 Based on the final registered date considered, registered at till varies. The final registration at till will be the till of the registered date considered after merging in surviving account. |
Registered Store | Store 1 | Store 2 | Store1 - If D1<D2 Store2 - If D2<D1 Based on the final registered date considered, registered at store varies. The registered store will be the store of the earlier registered account among the two. For example, if the registered date of the deactivating account is earlier than the registered date of surviving account then the entire registration details such as the registered date and registered at store/till/base terminal will be considered from the deactivating account. |
Base Terminal | T1 | T2 | Terminal1 - If D1<D2 Terminal2 - If D2<D1 The final value will be the base terminal of the earlier registered account among the two. For example, if the registered date of the deactivating account is earlier than the registered date of surviving account then the entire registration details such as the registered date and registered at store/till/base terminal will be considered from the deactivated account. |
Customer Level Custom Fields | F1 F3 Null | F2 Null F4 | F2 F3 F4 The resultant custom fields after merging will be the custom fields of the surviving account if the custom field values are available in both accounts. If any custom field is not available in the surviving account then the custom field value will be taken from the deactivating account (if available in that account). |
Transactions | Tran1 | Tran2 | Tran1+Tran2 The final transaction amount after merging will be the sum of transactions of individual accounts. |
Return Transactions | RT1 | RT2 | RT1+RT2 After merging, the return transactions will be the sum of return transactions of individual accounts |
Lifetime Points | LP1 | LP2 | LP1+LP2 The lifetime points after merging will be the sum of the lifetime points of individual accounts. |
Current Points/Active Points | CP1 | CP2 | CP1+CP2 The current points or active points after merging will be the sum of the current points of individual accounts. |
Expired Points | EP1 | EP2 | EP1+EP2 The final expired points after merging will be the sum of the total number of points expired in each account. |
Redeemed Points | RP1 | RP2 | RP1+RP2 The final redeemed points after merging will be the sum of the total number of points redeemed in each account. |
Till ID | We retain till id as is in points tables. In CPS, we keep the till attribution for registration as the survivor's. The points award entry will remain connected to the till where it was originally generated. So you can achieve whatever you want. | ||
Promised points | PP1 | PP2 | PP1+PP2 The promised points after merging will be the sum of the promised points of individual accounts. When the transaction is returned, the return will be processed. |
Imported points | IP1 | IP2 | IP1+IP2 Imported points are PACP points (Points Awarded Customer Promotions table) and will follow all the rules as mentioned in this table. |
Opening points (points of third-party) | We don't store third party points. Hence, the opening points scenarios are invalid. | ||
Till ID of points issued | The points issued from each TILL is retained as is while merging. There will not be any change in the TILL ID associated with each set of points. | ||
Points Expiry (Expiry schedule) | Date1 | Date2 | Date1 and Date2. Points will get expired as per the expiry schedule for points earned each time, even after merging. For instance, if a customer has earned 300 points for purchase and assumes that the points will get expired on Aug 1, 2014, if not redeemed. Now, the customer account is merged with another account. Then, the 300 points that are transferred to the surviving account will still get expired on Aug 1, 2014, irrespective of the merge date or any other factor. |
Tracker Data | Tracker1 | Tracker2 | The trackers for both the accounts will be combined, and the tracker condition will be calculated on the final values (values in surviving account after merging). |
Tier | S1 | S2 | If S1>S2, then S1 will be the final tier. If S2>S1, then S2 will be the final tier. - If S1=S2, then no tier upgrade takes place. The new tier will be the highest of the two tiers. |
Tier Movement History | S1 | S2 | If S1>S2, then S1 will be the final tier, and a new record for upgrading from S2 to S1 will be created on the retaining account. If S2>S1, then S2 will be the final tier. As no tier upgrade happens in the continued account, no new record will be created in his/her account. - If S1=S2, then no tier upgrade takes place, and hence no additional record will be created. |
Active Coupons | AC1 | AC2 | AC1+AC2 The active coupons of the deactivating account will be transferred to the surviving account, enabling the customer to use all the active coupons of both accounts. |
Redeemed Coupons | RC1 | RC2 | RC1+RC2 All the redeemed coupons of the deactivating account will be transferred to the surviving account. This facilitates future tracking of all the redeemed coupons of the customer. |
Expired Coupons | EC1 | EC2 | EC1+EC2 All the expired coupons of the deactivating account will be transferred to the surviving account to keep track of all coupons that are issued to the customer and expired. |
Cluster Information | C1 | C2 | The final customer data after merging will be recomputed and the cluster will be categorized as per the new figure. For example, assume that the deactivating account is in cluster C1 and the surviving account is in cluster C2. After merging the accounts, based on the new data available cluster strategy is recalculated. Now, if the new result meets the strategy of the cluster C3 then the surviving account after merging will be moved to the C3 cluster. However, after merging the accounts there are chances for the customer to fall either in C1 or C2 based on the recomputed result. |
NDNC Status | Status1 | Status2 | Status1 - If the mobile number of the deactivating account retains after merging, Status2 - If the mobile number of the surviving account retains after merging. NDNC status is specific to a mobile number. So, the NDNC status of the merged account depends on the mobile number that will continue to remain after merging. For example, if the deactivating account's mobile number is retained after merging, the NDNC status will remain the same in the surviving account. |
NDNC Status (When the mobile number is a secondary identifier) | Registered/ Not Registered | Not Registered/ Registered | Depending on the final mobile number considered after merging, NDNC status varies. For example, if the NDNC status of the final mobile number is registered in NDNC then the same status will continue to remain. |
Opt-in Status | Whatever the communication services the surviving account has opted-in for the same will exist even after merging. | ||
Subscription Status | Whatever is the subscription status of the surviving account, same will continue to remain after merging. | ||
Messages | Set of Messages1 | Set of Messages2 | Set of Messages2 Messages or notifications will not be merged or transferred from the deactivating account to the surviving account. The only messages of the surviving account continue to exist even after merging. |
Fraud Status | Reconfirmed | Confirmed/ Marked as Fraud/ Not Fraud | Reconfirmed If the fraud status of the deactivating account is Reconfirmed then the Fraud Status of the surviving account will change to Reconfirmed. |
Fraud Status | Confirmed/ Marked as Fraud/ Not Fraud | Reconfirmed | Reconfirmed Even though the fraud status of the deactivating account is Confirmed/Marked as Fraud/ Not Fraud the surviving account's fraud status will remain Reconfirmed. |
Fraud Status | Confirmed | Marked as Fraud/ Not Fraud | Confirmed Even though the fraud status of surviving customer is Marked as Fraud/ Not Fraud the final status after merging will be changed Confirmed. |
Fraud Status | Marked as Fraud/ Not Fraud | Confirmed | Confirmed If both accounts are in confirmed status the final value after merging also remains Confirmed. |
Fraud Status | Marked as Fraud | Not Fraud | Marked as Fraud If in any one account, the customer is marked as fraud, then the final status after merging will also be Marked as Fraud. |
Fraud Status | Not Fraud | Marked as Fraud | Marked as Fraud If in any one account, the customer is marked as fraud then the final status after merging will also be Marked as Fraud. |
Fraud Status | Reconfirmed/ Confirmed/ Marked as Fraud | Internal | Internal If at least one account status is internal then the final account status will be Internal. |
Fraud Status | Internal | Confirmed/ Marked as Fraud | Internal If at least fraud status of merging accounts is internal then the final surviving account status will be Internal. |
Card details | C2 | C2 | C1 & C2. The cards of the victim are transferred to the survivor's account. |
Transaction requests | Transaction Request 1 | Transaction Request 2 | Transaction request 1 & 2. The pending transaction requests of the victim are transferred to the survivor. |
When merging cards with the survivor, the application may generate warnings in the following scenarios:
- If the total number of cards under the survivor exceeds the defined maximum number of active cards per customer for individual card types.
- If the total number of cards under the survivor exceeds the defined maximum number of active cards based on global card settings.
However, you can choose to ignore the warning and proceed with adding the cards to the survivor.
Excluding card merging during account merge
By default, when merging customer accounts, the cards associated with the victim account are transferred to the survivor account automatically. In case the customer exceeds the set threshold for the maximum number of cards they can hold, the transfer of cards from a victim to a survivor account will proceed with a warning.
However, if you want do not want to transfer the cards of the victim account to the survivor account during a customer merge, you can raise a ticket and disable the CONF_ALLOW_CARD_TRANSFER_TO_SURVIVOR
configuration. This ensures that the cards are not transferred along with the other existing parameters.
There is no UI to enable this configuration. You need to raise a JIRA ticket (sample ticket) to the sustenance team to enable these configurations. Turn around time is five days.
Updated 10 months ago