E-commerce
September 3, 2026
Are you wondering how to manage the frequent discrepancies between the balance shown on a physical card and the one visible in the online customer area? The lack of perfect synchronization between your point of sale and your Shopify site is a major risk for omnichannel trust. When these gaps occur, the customer perceives their program as faulty, which immediately weakens their relationship with the brand.
The solution lies in rigorous management of identifiers and a clear data reconciliation procedure. By structuring your support around a precise synchronization matrix, you transform a technical incident into an opportunity to demonstrate your reliability.
So how can you effectively unify physical and digital loyalty cards to secure the customer relationship? On the agenda:
Why does a loyalty card systematically generate urgent support tickets?
What are the five main frictions between the in-store balance and the online account?
How do you classify customer requests according to the LCARD matrix for a tailored response?
What synchronization rules must be applied before any balance adjustment?
What procedure should be followed in case of loss or theft to ensure customer security?
Let's get started.
Summary
Why do loyalty cards generate support tickets?", "Section Title 1 Visible": true, "Section 1": "<div dir=\"auto\"><p>The multiplication of customer touchpoints in omnichannel creates significant operational complexity for loyalty program management. A loyalty card no longer exists in a single form but is deployed in three distinct formats: the tangible plastic present on store shelves, the digital account visible exclusively on the website or mobile app, and the virtual pass integrated into digital wallets such as Apple Wallet or Google Pay.</p><p>The customer, for their part, naturally assumes the existence of a single, universal balance. When technical reality diverges from this expectation, for example when the point of sale (POS) displays 120 points while the online account only shows 80, the breakdown of trust is immediate. This ticket becomes urgent because it affects the perceived value and fairness of the program.</p><p>According to a recent study by Antavo, 42% of omnichannel loyalty programs report friction related to synchronization between physical and digital cards as the primary cause of churn. Without a robust data matrix, agents risk merging accounts without verification or promising a balance that cannot be technically validated.</p><p>It is therefore crucial for the support agent to understand that the divergence is not an isolated human error but often the symptom of an uncommunicated batch synchronization delay. This understanding makes it possible to shift from a defensive posture to a factual and reassuring explanation.</p></div>", "Section Title 1 Visible": true, "Section Title 2": "What are the five main points of friction between the in-store balance and the online account?", "Section Title 2 Visible": true, "Section 2": "<div dir=\"auto\"><p>Five types of blockages characterize the majority of incidents reported by merchants. The first and most frequent relates to balance inconsistency: a visible numerical difference between the cash register receipt and the customer portal, creating a feeling of impossible arithmetic for the user. This case requires immediate cross-verification of both systems.</p><p>The second friction is the failure to link the physical card to the digital account. A customer has their plastic card but has never completed the registration step on the website, making the points accumulated in-store invisible to them when browsing online. This creates an impression of unfairness where real activity is not valued.</p><p>The loss or theft of the card is the third critical point. Here, the request is no longer about a balance but about security and quick replacement without losing accumulated points. The customer is anxious at the thought of someone else physically using their old card.</p><p>The fourth reason concerns invalid card numbers. Either the card has expired, or the customer made a typo when connecting to the checkout funnel. The system then rejects any operation, blocking the transaction and the final user experience.</p><p>Finally, the fifth problem is the synchronization delay after an in-store purchase. The customer has just bought products, received their card, but the points do not appear instantly on their web profile because data flows are not real-time. Explaining this technical delay is key to easing frustration.</p></div>"
The multiplication of customer touchpoints in omnichannel retailing creates significant operational complexity for managing loyalty programs. A loyalty card no longer exists in a single form but is deployed in three distinct formats: the tangible plastic present on store shelves, the digital account visible exclusively on the website or mobile application, and the virtual pass integrated into digital wallets like Apple Wallet or Google Pay.
The customer, for their part, naturally assumes the existence of a single, universal balance. When technical reality diverges from this expectation—for example, when the point of sale (POS) displays 120 points while the online account only shows 80—the breach of trust is immediate. This ticket becomes urgent because it affects the perceived value and fairness of the program.
According to a recent study by Antavo, 42% of omnichannel loyalty programs report frictions related to synchronization between physical and digital cards as the primary cause of churn. Without a solid data matrix, agents risk merging accounts without verification or promising a balance that cannot be technically validated.
It is therefore crucial for the support agent to understand that divergence is not an isolated human error but often the symptom of an uncommunicated batch synchronization delay. This understanding allows the agent to shift from a defensive posture to a factual and reassuring explanation.
",
"Section Title 1 Visible": true,
"Section Title 2": "What are the five main frictions between the in-store balance and the online account?",
"Section Title 2 Visible": true,
"Section 2": "
Five types of roadblocks characterize the majority of incidents reported by merchants. The first and most frequent relates to balance inconsistency: a visible numerical difference between the cash register statement and the customer portal, creating a sense of impossible arithmetic for the user. This case requires immediate cross-verification of both systems.
The second friction is the failure to link the physical card to the digital account. A customer has their plastic card but has never completed the registration step on the website, making points accumulated in-store invisible to them when browsing online. This creates an impression of unfairness where real activity is not valued.
The loss or theft of the card constitutes the third critical point. Here, the request is no longer about a balance, but about security and a quick replacement without losing accumulated points. The customer is anxious that someone else might use their old card physically.
The fourth issue concerns invalid card numbers. Either the card has expired, or the customer made a typo when connecting to the checkout funnel. The system then rejects any operation, blocking the transaction and the final user experience.
Finally, the fifth problem is the synchronization delay after an in-store purchase. The customer has just bought products, received their card, but the points do not appear instantly on their web profile because data flows are not real-time. Explaining this technical delay is the key to defusing frustration.
Convert over 2,000 customers on average per month with Qstomy.
The world’s 1st Shopify AI dedicated to customer conversion
Empowering 200+ e-commerce merchants
What are the five main frictions between the in-store balance and the online account?", "Section Title 2 Visible": true, "Section 2": "<div dir="auto"><p>Five types of blockages characterize the majority of incidents reported by merchants. The first and most frequent relates to balance inconsistency: a visible numerical difference between the checkout statement and the customer portal, creating a feeling of impossible arithmetic for the user. This case requires immediate cross-checking of both systems.</p><p>The second friction is the failure to link the physical card to the digital account. A customer has their plastic card but has never completed the registration step on the website, making points accumulated in-store invisible to them when browsing online. This creates an impression of unfairness where actual activity is not valued.</p><p>The loss or theft of the card is the third critical point. Here, the request is no longer about a balance but about security and quick replacement without losing accumulated points. The customer is anxious that someone else might use their old card physically.</p><p>The fourth reason concerns invalid card numbers. Either the card has expired, or the customer made a typo when logging in during the checkout process. The system then rejects any operation, blocking the transaction and the final user experience.</p><p>Finally, the fifth issue is the synchronization delay after an in-store purchase. The customer has just bought products, received their card, but the points do not appear instantly on their web profile because data flows are not in real time. Explaining this technical delay is key to easing frustration.</p></div>
Five types of blockages characterize the majority of incidents reported by merchants. The first and most frequent concerns balance inconsistency: a visible numerical difference between the cash register statement and the customer portal, creating a feeling of impossible arithmetic for the user. This case requires immediate cross-verification of both systems.
The second friction is the lack of connection between the physical card and the digital account. A customer has their plastic but has never completed the registration step on the website, making the points accumulated in-store invisible to them when they browse online. This creates an impression of injustice where actual activity is not valued.
The loss or theft of the card constitutes the third critical point. Here, the request is no longer about a balance but about security and a quick replacement without losing the accumulated points. The customer is anxious that someone else might physically use their old card.
The fourth reason concerns invalid card numbers. Either the card has expired, or the customer made a typo when logging into the checkout funnel. The system then rejects any operation, blocking the transaction and the final user experience.
Finally, the fifth issue is the synchronization delay after an in-store purchase. The customer has just bought products, received their card, but the points do not appear instantly on their web profile because the data flows are not real-time. Explaining this technical delay is the key to soothing frustration.
How to classify requests according to the LCARD matrix?", "Section Title 3 Visible": true, "Section 3": "<div dir="auto"><p>Accurate ticket classification is essential to route the request to the right agent and apply the correct policy without delay. The LCARD matrix identifies eight types of requests used to segment incidents. The first category is the balance mismatch (lcard_balance_mismatch), where data differs between the POS and the app.</p><p>The second category concerns unlinked cards (lcard_not_linked), where support must facilitate linking the physical object to the digital account. The third type deals with lost or stolen cards (lcard_lost_stolen), which triggers emergency blocking protocols before any replacement.</p><p>The fourth category covers invalid numbers (lcard_number_invalid), which require verifying the expiration date or correcting an entry error. The fifth concerns duplicate accounts (lcard_duplicate_account) where a customer exists twice in the system and must be merged to centralize their points.</p><p>The sixth category relates to wallet pass issues (lcard_wallet_pass), where digital integration fails. The seventh is the physical replacement request (lcard_replacement). Finally, the eighth category corresponds to synchronization delays (lcard_sync_delay), often mistaken for a loss of points but actually just a batch process issue.</p><p>These tags allow systems and agents to sort requests quickly. Main tags include lcard, loyalty_card, and omnichannel_sync to facilitate searching and reporting of recurring incidents.</p></div>
Accurate ticket classification is essential for routing to the right agent and applying the correct policy without delay. The LCARD matrix identifies eight types of requests that allow for incident segmentation. The first category is the balance mismatch (lcard_balance_mismatch), where data differs between the POS and the application.
The second category concerns unlinked cards (lcard_not_linked), where support must facilitate the link between the physical object and the digital account. The third typology deals with loss or theft (lcard_lost_stolen), triggering emergency blocking protocols before any replacement.
The fourth category covers invalid numbers (lcard_number_invalid), requiring expiration date verification or entry correction. The fifth concerns duplicate accounts (lcard_duplicate_account) where a customer exists twice in the system and must be merged to centralize their points.
The sixth category relates to wallet pass issues (lcard_wallet_pass), where digital integration fails. The seventh is the request for physical replacement (lcard_replacement). Finally, the eighth category corresponds to synchronization delay (lcard_sync_delay), often confused with a loss of points but simply stemming from a batch process.
These tags allow systems and agents to sort requests quickly. The main tags include lcard, loyalty_card, and omnichannel_sync to facilitate searching and reporting of recurring incidents.
Which LCARD-MAP matrix documents the identification rules?", "Section Title 4 Visible": true, "Section 4": "<div dir="auto"><p>The LCARD-MAP matrix is the reference document that standardizes card management for agents and future chatbots. It must contain precise information on program identification (program_id), whether for solutions like Smile or Yotpo.</p><p>It is imperative to list the supported card types: physical, digital, or via wallet pass. Verification methods (lookup_methods) must be clearly defined: email, card number, phone number, or barcode.</p><p>Synchronization rules (sync_rules) are critical and must specify the delay between an in-store purchase and the visibility of points online. This information must be accessible to all agents so they do not blame the customer unfairly.</p><p>The account merge policy (merge_account_policy) defines how to handle customers with multiple existing profiles. Finally, replacement procedures (replacement_policy) and associated fees must be documented to avoid any surprises during a claim.</p></div>
The LCARD-MAP matrix is the reference document that standardizes card management for agents and future chatbots. It must contain precise information on program identification (program_id), whether it concerns solutions like Smile or Yotpo.
It is imperative to list the supported card types: physical, digital, or via wallet pass. Verification methods (lookup_methods) must be clearly defined: email, card number, phone number, or barcode.
Synchronization rules (sync_rules) are critical and must specify the delay between an in-store purchase and the online visibility of points. This information must be accessible to all agents so they do not blame the customer unfairly.
The merge account policy (merge_account_policy) defines how to handle customers with multiple existing profiles. Finally, replacement procedures (replacement_policy) and associated fees must be documented to avoid any surprises during a claim.
What are the six fundamental rules of LCARD support?", "Section Title 5 Visible": true, "Section 5": "<div dir="auto"><p>When a ticket arises, the agent must apply a rigorous set of rules to ensure the consistency of actions. The first rule is to verify the balance on both channels (BALANCE-VERIFY-BOTH). You must consult the POS and the digital system before making any modifications or corrections.</p><p>The second rule prohibits merging accounts without prior verification (NO-MERGE-WITHOUT-VERIFY). Customer profiles cannot be merged if the balance and history have not been compared and authorized by the LCARD matrix.</p><p>The third rule requires citing synchronization rules (SYNC-DELAY-CITE) before blaming the customer or promising an immediate unblocking. Explaining the batch delay set out in the matrix is a mandatory step.</p><p>The fourth rule requires blocking a lost card immediately after validation (LOST-BLOCK-FIRST). Customer security comes before any replacement request in order to prevent potential fraud.</p><p>The fifth rule concerns missing points which, after verification and if the error is proven, must be escalated to specialized technical support (POINTS-ESCALATE) for investigation via a specific incident ticket.</p><p>The sixth rule points out that synchronization and replacement are only carried out according to the LCARD-MAP matrix. No manual or out-of-process adjustments are allowed, otherwise future inconsistencies in financial and customer data may be created.</p></div>
When a ticket arises, the agent must apply a rigorous set of rules to ensure consistency of actions. The first rule is the verification of the balance on both channels (BALANCE-VERIFY-BOTH). You must consult the POS and the digital system before making any changes or corrections.
The second prohibits merging accounts without prior verification (NO-MERGE-WITHOUT-VERIFY). Customer profiles cannot be merged unless balances and history have been compared and authorized by the LCARD matrix.
The third rule requires citing the synchronization rules (SYNC-DELAY-CITE) before accusing the customer or promising an immediate unblocking. Explaining the batch delay written in the matrix is a mandatory step.
The fourth rule requires blocking a lost card immediately after validation (LOST-BLOCK-FIRST). Customer security comes before any replacement request to prevent potential fraud.
The fifth rule concerns missing points which, after verification and if the error is proven, must be escalated to specialized technical support (POINTS-ESCALATE) for investigation via a specific incident ticket.
The sixth rule reminds that synchronization and replacement are only done according to the LCARD-MAP matrix. No manual or out-of-process adjustment is authorized, under penalty of creating future inconsistencies in financial and customer data.
What is the eight-step process for a loyalty card ticket?", "Section Title 6 Visible": true, "Section 6": "<div dir="auto"><p>The incident handling process follows a logical eight-step flow (LCARD Flow) to ensure complete resolution. Intake (step 1) consists of identifying the angle of the ticket and collecting essential information: email, card number, and order reference if available.</p><p>Step 2 is searching for the card via the LCARD matrix to identify the associated program and available lookup methods. Step 3 requires a balance check on both systems (POS and online) to understand the actual discrepancy.</p><p>Classification (step 4) directs the ticket to the correct incident type: discrepancy, unlinked, lost, or delay. Step 5 checks whether a normal synchronization delay can explain the situation before taking action.</p><p>The agent then responds (step 6) using pre-validated macros from the LCARD matrix to ensure consistency of speech. Execution (step 7) consists of linking accounts, blocking a lost card, replacing a card, or escalating the incident to operations.</p><p>Closure (step 8) involves tagging the ticket as resolved and recording the program identifier. The SLA (response time) requires that any synchronization delay be explained with LCARD rules in a single interaction if the case is standard.</p></div>
The incident handling process follows a logical eight-step flow (LCARD Flow) to ensure a complete resolution. Intake (step 1) consists of identifying the angle of the ticket and collecting essential information: email, card number, and order reference if available.
Step 2 is searching for the card via the LCARD matrix to identify the associated program and the available lookup methods. Step 3 requires a balance check on both systems (POS and online) to understand the actual discrepancy.
Classification (step 4) routes the ticket to the correct incident type: discrepancy, unlinked, lost, or delay. Step 5 checks whether a normal synchronization delay can explain the situation before taking action.
The agent then responds (step 6) using pre-validated macros taken from the LCARD matrix to ensure consistency of speech. Execution (step 7) consists of linking accounts, blocking a lost card, replacing a card, or escalating the incident to operations.
Closure (step 8) involves tagging the ticket as resolved and recording the program identifier. The SLA (response time) requires that any synchronization delay be explained using the LCARD rules in a single interaction if the case is standard.
What essential macros should be used to respond to agents?", "Section Title 7 Visible": true, "Section 7": "<div dir="auto"><p>Standardized macros speed up responses and ensure consistency in the messages sent to the customer. The first macro, LCARD-BAL-01, is used to handle balance discrepancies. It informs the customer of the balance observed online and in-store, explains the cause of the discrepancy (delay or duplicate), and indicates when the points will become visible.</p><p>The second macro, LCARD-LINK-01, manages account linking requests. It confirms whether the card is linked or not, and provides the link or procedure to complete this link in case of user oversight, as well as the steps to follow to merge duplicates.</p><p>The third macro, LCARD-LOST-01, handles reports of loss or theft. It immediately confirms the blocking of the card, details the replacement policy (fees and delivery times), and reassures that the balance remains intact for the new issued card.</p><p>Finally, the LCARD-WALLET-01 macro manages digital pass issues. It indicates whether the pass is active or expired, offers a regeneration procedure via a secure link, and confirms the balance synchronization between the pass and the associated physical card.</p></div>
Standardized macros accelerate responses and guarantee consistency in messages sent to customers. The first macro LCARD-BAL-01 is used to address balance discrepancies. It informs the customer of the balance observed online and in-store, explains the cause of the discrepancy (delay or duplication), and indicates when the points will become visible.
The second macro LCARD-LINK-01 handles account linking requests. It confirms whether the card is linked or not, and provides the link or procedure to perform this link if forgotten by the user, as well as the steps to merge duplicates.
The third macro LCARD-LOST-01 addresses reports of loss or theft. It immediately confirms the card has been blocked, details the replacement policy (fees and delivery times), and reassures that the balance remains intact for the newly issued card.
Finally, the LCARD-WALLET-01 macro handles digital pass issues. It indicates whether the pass is active or expired, offers a regeneration procedure via a secure link, and confirms the balance synchronization between the pass and the associated physical card.
How to handle edge cases outside the standard macro?", "Section Title 8 Visible": true, "Section 8": "<div dir="auto"><p>Some complex situations fall outside standard scenarios and require specific intervention. If a customer reports missing points after a thorough check, the ticket must be redirected to technical investigation (PTS-REC) for manual adjustment by the back-office team.</p><p>The distinction between a loyalty card and a gift card is crucial. A Euro balance on a gift card is a separate financial product from a loyalty points program. If a customer confuses the two, support must clarify this difference and redirect to the appropriate policy.</p><p>In-store orders with online pickup (BOPIS) also pose channel attribution challenges. The agent must ensure that the activity is correctly credited to the loyalty program corresponding to the customer's status at the time of purchase, and not simply to the pickup method.</p><p>Third-party member sales (MEMSALE) involve specific statuses that may differ from standard cards. Finally, the general rules of loyalty bot #375 apply to any questions regarding redemption or the use of points, but do not replace the technical management of the physical card.</p></div>
Certain complex situations fall outside standard scenarios and require specific intervention. If a customer reports missing points after a thorough check, the ticket must be redirected to technical investigation (PTS-REC) for manual adjustment by the back-office team.
The distinction between a loyalty card and a gift card is crucial. A euro balance on a gift card is a separate financial product from a loyalty points program. If a customer confuses the two, support must clarify this difference and redirect them to the appropriate policy.
In-store orders with online pickup (BOPIS) also pose channel attribution challenges. The agent must ensure that the activity is correctly credited to the loyalty program corresponding to the customer's status at the time of purchase, and not simply to the pickup method.
Third-party member sales (MEMSALE) involve specific statuses that may differ from standard cards. Finally, the general rules of loyalty bot #375 apply to any questions regarding redemption or point usage, but do not replace the technical management of the physical card.
What are the essential KPI metrics for managing this topic?", "Section Title 9 Visible": true, "Section 9": "<div dir="auto"><p>To evaluate the performance of support and infrastructure, five key indicators (KPIs) must be continuously monitored. The LCARD ticket rate (lcard_ticket_rate) measures the number of specific requests divided by the total number of active members with a card.</p><p>The synchronization success rate (lcard_sync_success_rate) indicates how many times a sync delay is resolved without escalation to technical teams, showing the reliability of the standard process. A low rate signals a major communication or technical issue.</p><p>The mean time to resolution (MTTR) for lost or stolen cases helps optimize blocking and delivery procedures for new cards. Reducing this time directly improves customer satisfaction.</p><p>The reopening rate of tickets related to balance inconsistency must be monitored. If a ticket classified as "resolved" returns shortly after, it indicates that the explanation of the delay did not satisfy the customer or that there is a genuine, persistent technical error.</p><p>Finally, the distribution of ticket reasons (classification by typology) helps identify weak points: if "lcard_sync_delay" is massive, pre-shipment messages on the site must be revised to better anticipate these questions.</p></div>
To evaluate support and infrastructure performance, five key indicators (KPIs) must be monitored continuously. The LCARD ticket rate (lcard_ticket_rate) measures the number of specific requests divided by the total number of active members holding a card.
The synchronization success rate (lcard_sync_success_rate) indicates how many times a sync delay is resolved without escalation to technical teams, showing the reliability of the standard process. A low rate signals a major communication or technical issue.
The mean time to resolution (MTTR) for lost or stolen cases helps optimize blocking and delivery procedures for new cards. A reduction in this time directly improves customer satisfaction.
The reopening rate of tickets related to balance inconsistency must be monitored. If a ticket classified as "resolved" returns shortly after, it indicates that the explanation of the delay did not convince the customer or that there is a genuine, persistent technical error.
Finally, the distribution of ticket reasons (classification by typology) helps identify weak points: if "lcard_sync_delay" is massive, the pre-dispatch messaging on the site must be reviewed to better anticipate these questions.
What is the difference with other loyalty programs?", "Section Title 10 Visible": true, "Section 10": "<div dir="auto"><p>It is essential to distinguish this specific technical support (LCARD) from general discussions about loyalty programs. Content #374 covers the investigation of missing points after purchase (post-transaction technical incident), while content #587 focuses on the identification and synchronization between physical and digital cards.</p><p>The general loyalty bot #375 deals with program rules such as terms of use, redemption, or reward levels. LCARD support does not replace these rules but ensures that access to the program (the card itself) works technically.</p><p>Another distinct area is the management of payments with gift cards (#2 and #3). A gift card is a monetary currency, while a loyalty card is a points system. Confusing the two can lead to processing errors or tax explanation issues.</p><p>Finally, content on in-store trials before online purchase (#4) and the management of packaging without products (#5) touches on the customer experience but not on the synchronization of loyalty data. The LCARD matrix filters out these topics to only handle incidents related to identifiers and card balances.</p></div>
It is essential to distinguish this specific technical support (LCARD) from general discussions on loyalty programs. Content #374 covers the investigation of missing points after purchase (post-transaction technical incident), while content #587 focuses on identification and synchronization between physical and digital cards.
The general loyalty bot #375 deals with program rules such as terms of use, redemption, or reward tiers. LCARD support does not replace these rules but ensures that access to the program (the card itself) functions technically.
Another distinct area is the management of payments with gift cards (#2 and #3). A gift card is a monetary currency, whereas a loyalty card is a points system. Confusing the two can lead to processing errors or tax explanation issues.
Finally, content on in-store trials before online purchase (#4) and the management of packaging without products (#5) touch on customer experience but not on loyalty data synchronization. The LCARD matrix filters out these topics to only address incidents related to identifiers and card balances.
How does Qstomy help unify physical and digital cards?", "Section Title 11 Visible": true, "Section 11": "<div dir="auto"><p>Qstomy acts as the expert Shopify AI agent capable of navigating this complexity to protect the customer relationship. Unlike generic tools, Qstomy integrates an understanding of POS flows and Shopify customer metadata to instantly diagnose balance discrepancies.</p><p>When a customer reports that their card does not display the correct number of points, Qstomy can query the POS API and the Shopify backend simultaneously to determine if it is a synchronization delay (batch processing) or a linking error. This allows for an immediate, accurate response.</p><p>Qstomy also manages identity verification processes for lost or stolen card requests, securing the transaction before any replacement action is taken. The AI can clearly explain reactivation delays according to the LCARD rule defined by the merchant without requiring human intervention.</p><p>In addition, Qstomy identifies duplicate accounts and suggests the necessary mergers after securing customer data. This reduces churn caused by frustration over fragmented data between online and offline, while guiding the user toward a unified experience.</p></div>
Qstomy acts as the expert Shopify AI agent capable of navigating this complexity to protect the customer relationship. Unlike generic tools, Qstomy integrates the understanding of POS flows and Shopify customer metadata to instantly diagnose balance discrepancies.
When a customer reports that their card is not displaying the correct number of points, Qstomy can query the POS API and the Shopify backend simultaneously to determine if it is a synchronization delay (batch processing) or a linking error. This allows for an immediate and accurate response.
Qstomy also manages identity verification processes for loss or theft requests, securing the transaction before any replacement action is taken. The AI can clearly explain reactivation delays according to the LCARD rule defined by the merchant without requiring human intervention.
Furthermore, Qstomy identifies duplicate accounts and proposes the necessary mergers after securing the customer's data. It thus reduces churn caused by frustration related to fragmented data between online and offline, while guiding the user towards a unified experience.
Quelle checklist avant de traiter un incident carte fidélité ?", "Section Title 12 Visible": true, "Section 12": "<div dir="auto"><p>What checklist is needed before handling a loyalty card incident?", "Section Title 12 Visible": true, "Section 12": "<div dir="auto"><p>Before handling a support request related to cards, the following checklist must be validated to ensure an efficient resolution. First, identify the intent of the ticket and collect the customer's email and card number to run the queries.</p><p>Next, check the active loyalty program (Smile, Yotpo, or other) in the LCARD-MAP matrix to find out the applicable synchronization times. Confirm whether the user has successfully activated their digital account via an onboarding process.</p><p>Then, check the history of in-store and online transactions to detect any duplicates or date inconsistencies. Ensure that the card has not been reported as stolen or lost recently to avoid providing outdated information.</p><p>Finally, prepare the response based on the corresponding LCARD macros and anticipate communication regarding delays if synchronization is in progress. This ensures a smooth and professional interaction that builds customer trust.</p></div>
Before responding to a support request related to cards, the following checklist must be validated to ensure an efficient resolution. First, identify the intent of the ticket and collect the customer's email and card number to run the queries.
Next, check the active loyalty program (Smile, Yotpo, or other) in the LCARD-MAP matrix to know the applicable synchronization delays. Confirm if the user has successfully activated their digital account via an onboarding procedure.
Then, check the history of in-store and online transactions to detect any duplicates or date inconsistencies. Ensure that the card has not been reported as stolen or lost recently to avoid providing outdated information.
Finally, prepare the response based on the corresponding LCARD macros and anticipate communication on delays if synchronization is in progress. This ensures a smooth and professional interaction that strengthens customer trust.
To go further: How to handle customer questions about physical and digital loyalty cards - Qstomy, How to handle customer questions about gift cards combined with card payment - Qstomy, How to handle customer questions about taxes applied to gift cards - Qstomy, How to handle customer questions about in-store trials before online purchase - Qstomy, How to handle customer questions about products sold without packaging - Qstomy, How to handle customer questions about sharing data with partners - Qstomy, Product photo not contractual: explaining discrepancies without denying disappointment - Qstomy.
Enzo
September 3, 2026
