Ένα πρόγραμμα loyalty φαίνεται απλό: ο πελάτης αγοράζει, κερδίζει πόντους και τους εξαργυρώνει σε έκπτωση. Στην πράξη, το υπόλοιπο πρέπει να παραμένει σωστό όταν μια πληρωμή αποτύχει, μια παραγγελία επιστραφεί μερικώς, ένας κωδικός reward δεν δημιουργηθεί ή δύο checkout προσπαθήσουν να χρησιμοποιήσουν τους ίδιους πόντους.
Η σωστή υλοποίηση δεν αποθηκεύει απλώς ένα μεταβλητό points_balance. Χρειάζεται ledger, σαφείς καταστάσεις και idempotent σύνδεση με orders, refunds και rewards.
Ledger αντί για απλό υπόλοιπο
Κάθε μεταβολή καταγράφεται ως ξεχωριστή εγγραφή:
- κέρδος από ολοκληρωμένη αγορά
- bonus από συγκεκριμένη καμπάνια
- εξαργύρωση για reward
- ακύρωση ή λήξη πόντων
- αντιλογισμός μετά από refund
- χειροκίνητη διόρθωση με reason και admin actor
Το διαθέσιμο υπόλοιπο προκύπτει από το άθροισμα ενεργών ledger entries. Έτσι η ομάδα μπορεί να εξηγήσει γιατί ένας πελάτης έχει 830 πόντους και να διορθώσει μία συγκεκριμένη κίνηση χωρίς να ξαναγράψει όλο το ιστορικό.
Κάθε entry έχει stable event ID. Αν το webhook παραγγελίας φτάσει δύο φορές, το δεύτερο δεν προσθέτει ξανά πόντους.
Pending πριν γίνουν διαθέσιμοι
Οι πόντοι μιας αγοράς δεν χρειάζεται να γίνονται αμέσως spendable. Μπορούν να μένουν pending μέχρι να επιβεβαιωθεί η πληρωμή ή να περάσει το βασικό παράθυρο επιστροφής. Η πολιτική πρέπει να είναι ορατή στον πελάτη.
Διαθέσιμοι πόντοι: 620
Πόντοι σε αναμονή: 180, διαθέσιμοι από 20/10
Αν η παραγγελία ακυρωθεί πριν ενεργοποιηθούν, τα pending entries ακυρώνονται. Αν έχει ήδη γίνει activation και ακολουθήσει refund, δημιουργείται reversal. Δεν διαγράφεται το αρχικό earning event, γιατί το audit trail πρέπει να παραμένει πλήρες.
Κανόνες earning
Ο κανόνας πρέπει να ορίζει βάση υπολογισμού: net προϊόντα, gross σύνολο, ποσό μετά τις εκπτώσεις ή χωρίς μεταφορικά. Χρειάζεται επίσης πολιτική rounding. Αν ο πελάτης κερδίζει 1 πόντο ανά ευρώ, αποφασίζεται αν 19,90 ευρώ δίνουν 19 ή 20 πόντους.
Bonus campaigns έχουν effective dates, επιλέξιμα προϊόντα και maximum limits. Το ίδιο order event δεν πρέπει να ενεργοποιεί δύο φορές την ίδια καμπάνια. Για referrals ή reviews χρειάζονται anti-fraud checks και delayed approval, γιατί η ενέργεια μπορεί να ακυρωθεί ή να είναι καταχρηστική.
Εξαργύρωση χωρίς race condition
Δύο tabs ή δύο συσκευές μπορούν να επιχειρήσουν να εξαργυρώσουν το ίδιο υπόλοιπο. Ο server πρέπει να ελέγχει και να δεσμεύει πόντους atomically. Η τιμή που εμφανίζει το browser δεν αποτελεί απόδειξη διαθέσιμου balance.
Μια redemption μπορεί να δημιουργεί fixed reward, όπως 5 ευρώ για 500 πόντους, ή incremental reward, όπως 1 ευρώ ανά 100 πόντους με ελάχιστο και μέγιστο όριο. Η τεκμηρίωση του Smile διαχωρίζει fixed και incremental rewards και προτείνει όρια για έλεγχο της εξαργύρωσης.
Το reward έχει δικό του lifecycle: pending, issued, failed, used ή canceled. Αν αποτύχει η δημιουργία coupon στην commerce platform, οι πόντοι δεν πρέπει να χαθούν. Επιστρέφουν ή παραμένουν reserved μέχρι να ολοκληρωθεί recovery.
Reward και checkout
Ο κωδικός reward συνδέεται με συγκεκριμένο customer και έχει expiration, usage limit και stacking policy. Δεν πρέπει να μπορεί να μοιραστεί δημόσια αν προορίζεται για έναν λογαριασμό.
Στο checkout ο server ελέγχει ότι το reward είναι issued, unused, δεν έχει λήξει και ταιριάζει σε currency, προϊόντα και ελάχιστη αξία. Μετά την επιτυχημένη order creation γίνεται used με order reference. Αν το payment αποτύχει πριν δημιουργηθεί παραγγελία, χρειάζεται release ώστε να μπορεί να ξαναχρησιμοποιηθεί.
Refunds και επιστροφές
Σε πλήρες refund, οι πόντοι που κερδήθηκαν αντιλογίζονται. Σε partial refund, ο αντιλογισμός βασίζεται στις επιστρεφόμενες γραμμές και στον αρχικό earning rule. Αν ο πελάτης είχε χρησιμοποιήσει reward, το refund υπολογίζεται πάνω στο ποσό που πραγματικά πλήρωσε.
Δύσκολη περίπτωση είναι όταν ο πελάτης έχει ήδη ξοδέψει τους πόντους που τώρα πρέπει να αφαιρεθούν. Η πολιτική μπορεί να επιτρέπει αρνητικό balance, να περιορίζει νέα εξαργύρωση μέχρι να καλυφθεί ή να ζητά manual review. Δεν πρέπει να τροποποιεί κρυφά άλλη παραγγελία.
Λήξη πόντων
Αν οι πόντοι λήγουν, κάθε earning entry έχει expiration ή ακολουθεί συγκεκριμένη πολιτική, όπως rolling inactivity. Η εφαρμογή καταναλώνει πρώτα τους παλαιότερους πόντους και μπορεί να ειδοποιεί πριν τη λήξη.
Η αλλαγή πολιτικής δεν εφαρμόζεται αυθαίρετα αναδρομικά. Αποθηκεύεται rule version ανά entry. Το customer portal δείχνει επόμενη ημερομηνία λήξης και ποσότητα, όχι μόνο συνολικό balance.
Admin και υποστήριξη
Η ομάδα χρειάζεται customer timeline με earnings, redemptions, reversals και rewards. Οι χειροκίνητες προσαρμογές απαιτούν permission, reason και audit log. Δεν επιτρέπεται απλή επεξεργασία του balance χωρίς κίνηση ledger.
Τα reports εξετάζουν issued και redeemed rewards, outstanding liability, expiration και failed issuance. Η αύξηση πόντων χωρίς εξαργύρωση μπορεί να σημαίνει ότι οι ανταμοιβές δεν είναι ελκυστικές ή ότι η εμπειρία χρήσης είναι δύσκολη.
Πώς το υλοποιεί η Ai Foundry
Στην Ai Foundry σχεδιάζουμε loyalty προγράμματα με immutable ledger, pending states και idempotent order events. Ορίζουμε earning και redemption rules με versions, atomic balance checks και reward lifecycle που συνδέεται με το checkout και τον provider εκπτώσεων.
Προσθέτουμε portal για διαθέσιμο, pending και expiring balance, καθώς και admin timeline για υποστήριξη και manual adjustments. Ελέγχουμε failed payment, duplicate webhook, partial refund και ταυτόχρονη εξαργύρωση. Έτσι η Ai Foundry υλοποιεί rewards που είναι κατανοητά για τον πελάτη και συμφωνούν με τα πραγματικά οικονομικά γεγονότα του e-shop.
Συμπέρασμα
Οι πόντοι είναι οικονομικό δικαίωμα με ιστορικό, όχι ένας απλός αριθμός. Ledger, statuses, atomic redemption και σαφείς κανόνες refunds κρατούν το πρόγραμμα δίκαιο και αποτρέπουν λάθη που καταστρέφουν την εμπιστοσύνη.