Concevoir un programme de réductions complet et complexe

Vous êtes product owner, architecte, ou développeur. Vous disposez déjà d’un système de commandes relativement classique, et vous devez concevoir un système de réductions (ou promotions) par dessus.

Les spécifications sont floues ou incomplètes, mais on vous laisse carte blanche pour les définir vous-même. Vous n’avez jamais fait cela avant, votre expérience en réductions se limite à votre carte Carrefour, mais après tout vous vous dites, optimiste (ou naïf 😂) que vous êtes, qu’il n’y a rien de bien méchant à appliquer -10 % sur une commande !

Vous voilà donc devant la feuille blanche, gonflés à bloc. Mais au fur et à mesure que vous esquissez la solution, tout un tas de questions imbriquées les une aux autres, de cas ambigus, de problèmes potentiels, commencent à faire surface et se mélangent simultanément dans votre tête.🤯

Cette situation, je l’ai vécue. Et le but de cet article va être de vous éviter au maximum de vivre la même chose.

Pour cela, nous allons concevoir ensemble un programme de réductions complexe, pas à pas, en nous posant une liste de questions. Petit à petit, répondre à ces questions va nous permettre de dessiner les contours de notre programme. Pas de développement ici, on restera sur la phase conceptuelle (qui se rapprochera de ce à quoi pourraient ressembler des spécifications fonctionnelle, le formaliste en moins).

Partons d’un système de commandes existant

Avant de parler conception de réductions, nous devons partir d’un système de commandes existant, sur lequel viendra se “brancher” par-dessus ce système de réductions. Je vous propose le modèle le plus simple possible, relativement classique :

Un client passe des commandes contenant des articles, dans un magasin spécifique.

Si ce système de commandes diffère du vôtre, pas d’inquiétude, cela ne remet pas forcément en cause les questions que vous devrez vous poser pour concevoir votre système de réductions. Au contraire, certaines questions ne se poseront peut-être même plus.

Posons-nous toutes les questions nécessaires

Maintenant que nous avons notre système de commandes, plusieurs questions doivent être mises sur la table, pour bien définir notre besoin métier, afin ensuite de définir les contours de notre solution. Nous allons les poser une à une, et choisir une réponse à chaque fois.

Chacune de ces questions n’est pas toujours indépendante l’une de l’autre : certaines questions seront la conséquence directe des choix des réponses aux questions précédentes.

Bien-sûr, cette réponse choisie à chaque fois ne sera pas “la bonne”, car la bonne réponse dépends de votre besoin, qui diffère du mien. Mais rappelez-vous que le but de cet article, est de concevoir in fine une solution complète qui servira d’exemple. Charge à vous ensuite d’adapter cet exemple en vous servant des questions ci-dessous pour alimenter votre réflexion. Allez, on y va !

Q1 : Les réductions doivent-elles être spécifiques à chaque client ?

On peut imaginer un système dans lequel peu importe le client et ses caractéristiques, les réductions à disposition seront toujours les mêmes. On peut parler de réductions génériques.

A l’inverse, si l’on veut créer un programme plus puissant dans lequel chaque client pourra obtenir des réductions potentiellement différentes, on parlera de réductions spécifiques.

Notre choix : des réductions spécifiques.

Q2 : Comment définir les groupes de clients bénéficiant des réductions spécifiques ?

Puisqu’on vient de choisir à l’instant de proposer à nos clients des réductions spécifiques, il faut maintenant concevoir comment.

Evidemment, on ne va pas associer les différentes réductions à des clients un par un, ça serait beaucoup trop long et inefficace. Il faut donc trouver un moyen de regrouper nos clients, par des critères qui nous intéressent. C’est ce qu’on va appeler des groupes de clients. Ce sera notre couche d’abstraction pour définir qui a le droit de bénéficier des réductions qui sont définies.

Ces critères pourraient être très variés : la date de naissance du client, la date de sa dernière commande, son panier moyen, etc. Pour l’exemple, imaginons le groupe nommé “Gros consommateurs”, dont le seul critère serait d’avoir un panier moyen supérieur à 50€. Tout client ayant un panier supérieur à 50€ devra donc être considéré comme appartenant à ce groupe.

Désobéissons un petit peu pour sortir du cadre purement fonctionnel, et posons-nous cette question : comment va t-on pouvoir savoir, si un client appartient à un groupe de clients (et donc si un client pourrait bénéficier de la réduction liée à ce groupe de client) ?

Deux solutions possibles :

Soit, on lie les clients à ces groupes, de manière manuelle. Par exemple, tous les soirs à 0h00, on calcule quels clients ont un panier moyen supérieur à 50€, ce qui permet de mettre à jour les clients appartenant au groupe “Gros Consommateurs”. Au moment de la commande, il suffit de voir si le client est dans le groupe, ou pas. On peut parler d’appartenance manuelle.
Soit, les groupes de clients ne définissent que les critères, et ne sont pas liés directement aux clients. Dans ce cas, au moment de la commande, il faudra calculer à la volée le panier moyen de client, pour savoir s’il fait appartient au groupe “Gros Consommateurs” ou pas. On peut parler d’appartenance dynamique.

Les deux solutions ont leurs avantages et inconvénients. L’appartenance manuelle permet de ne pas ralentir le passage d’une commande, en ayant pré-calculé l’appartenance d’un client, tandis que l’appartenance dynamique sera plus longue à calculer. Ceci est d’autant plus flagrant que les critères en question demandent beaucoup de calculs.

Mais l’appartenance dynamique permet d’avoir des groupes tout le temps à jour, puisque la vérification de l’appartenance est faite à la volée, ce qui n’est pas le cas de l’appartenance manuelle, dont la mise à jour se fait de manière asynchrone, via une tâche planifiée. Elle rend aussi la solution plus simple, car ne nécessite pas de tâche planifiée, dont une erreur non détectée dans son exécution rendrait l’appartenance fausse pour potentiellement tous les clients !

Notre choix : l‘appartenance dynamique (et on s’assurera que nos critères restent rapides à calculer. Si ce n’est pas le cas, on envisagera la dénormalisation des données pour que cela le devienne).

Q3 : Doit-on proposer d’utiliser des codes promotionnels ?

Dans beaucoup de commerces, notamment en ligne, on rencontre des systèmes de code promotionnels à utiliser : “-10% sur votre commande avec le code CESTNOEL”.

En utilisant un système comme celui-ci, vous laissez potentiellement n’importe quel personne utiliser la même réduction, à condition bien sûr qu’il ait connaissance de ce code. La personne pourra aussi choisir quand appliquer cette réduction.

L’approche marketing est ici très différente. Plutôt que de fidéliser un client grâce aux commandes qu’il a déjà passées, ou toute autre action qu’il aurait déjà faite, on peut chercher à inciter une personne à devenir un client, en lui faisant miroiter un avantage exceptionnel : “-50% sur votre première commande avant le 12 mai avec le code FIRST”

Notre choix : pas de codes promotionnels, car pas compatible avec nos choix actuels où chaque client dispose de ses propres réductions.

Q4 : Quelles actions vont permettre de gagner ces réductions ?

Traditionnellement, la première action qui devrait permettre à un client de gagner et déclencher une réduction, devrait logiquement être le passage d’une commande. “Si vous achetez ceci, vous gagnerez cela”. On parle de réductions obtenues par les commandes.

Néanmoins, on peut imaginer à terme un système bien plus poussé dans lequel une multitude d’actions diverses et variées pourrait permettre à des clients de gagner des réductions. Par exemple, offrir à un client une réduction, s’il laisse un avis sur votre site après son achat, ou s’il parle de vous sur les réseaux sociaux. On pourrait aussi imaginer une distribution de réductions à des clients au cas par cas (par exemple pour compenser une plainte). On pourrait parler ici de réductions obtenues par tout le système.

Notre choix : réductions obtenues uniquement par les commandes dans un premier temps (tout en nous assurant que le modèle puisse évoluer dans le futur)

Q5 : Sous quelle forme le client doit-il tirer le bénéfice de la réduction ?

Il existe certains systèmes de commandes, dans lesquels nos clients disposent d’un solde (on parle aussi de cagnotte) lié à leur compte. Par exemple à Franprix, en donnant sa carte de fidélité à chaque passage en caisse, le client cumule des euros sur sa cagnotte. Au moment de régler une commande, en plus d’utiliser un moyen de paiement classique (CB, espèces, etc.) le client a alors la possibilité de régler sa commande, totalement ou en partie, en utilisant le solde de son compte.

Si vous disposez d’un système de la sorte, deux solutions (et sûrement d’autres) très différentes s’offrent à vous au moment de la conception de votre programme :

Soit, comme on vient de le voir, les réductions ne sont en fait plus des réductions à proprement parler, dans le sens où le montant de la commande reste le même, mais le solde client est crédité d’un certain montant. Exemple : une commande de 5 € crédite la cagnotte du client de 1 €. Le client règle bien 5 €, et pourra utiliser les 1 € à la prochaine commande. On parle de cagnotte créditée.
Soit les réductions s’appliquent sur les commandes elles-mêmes. Exemple, une commande à 5 € déclenchant une réduction de 1 €, ne coutera au client que 4 €. On parle de réduction sur une commande.

Une réduction sur une commande à l’inconvénient d’être limitée par le montant de la commande. Par exemple, une réduction de 5 € ne pourra pas s’appliquer sur une commande qui vaut 4 € (ou bien le client perdrait 1 € bêtement). Cette problématique n’a pas lieu avec une cagnotte dédiée.

Mais la cagnotte créditée a l’inconvénient de ne pas laisser la possibilité de restreindre la manière dont le client peut dépenser cet argent. En effet, une fois la cagnotte créditée, l’argent qui est dessus est utilisable comme le client le souhaite (vouloir faire l’inverse serait très compliqué). A l’inverse, un coupon de réduction gagné mais pas encore utilisé, pourrait avoir beaucoup plus de restrictions (“à utiliser avant telle date”, “valable sur tels ou tels articles”, etc.)

Dans les deux cas, et contrairement à ce qu’on pourrait croire, les solutions permettent d’inciter le client à revenir à posteriori. Mais l’une permet d’aller beaucoup plus loin dans les possibilités. On va le voir dans la question suivante.

Notre choix : les réductions sur une commande.

Q6 : Les réductions doivent-elles être immédiates ou différées ?

C’est une question majeure qui va impacter le coeur de notre solution et qui doit être traitée d’entrée.

Les réductions immédiates

Les réductions immédiates sont les plus simples à concevoir mais les plus limitantes. Elles permettent, lors d’une même commande de gagner et déclencher la même réduction. Autrement dit, les notions de gain d’une réduction et de son application, sont totalement confondues.

Les réductions différées (via un portefeuille de réductions 👛)

Les réductions différées nécessitent une conception plus complexe, mais offrent beaucoup plus de fonctionnalités. Elles permettent, lors d’une commande, de dissocier la phase de gain des réductions, de la phase d’utilisation des réductions. Le client disposera en permanence d’un portefeuille de réductions utilisables sur chaque commande.

Un cas d’usage simple pour mieux comprendre la différence

Si l’on veut définir des promotions simples telles que : “-50% sur le café”, alors la réduction immédiate est suffisante. Il suffit que la commande contienne du café, et le café sera à moitié prix.

Maintenant, et c’est là que ça devient intéressant, si l’on veut définir une réduction plus complexe telle que : “Pour un café acheté, -50% offert sur le croissant”, une réduction différée devient nécessaire. En effet, ici on définit d’une part : la condition du gain de la réduction : “un café acheté”, et la réduction elle-même : “-50% sur le croissant”. Puisque la 1ère commande donnant droit à la réduction n’impose pas de contenir un croissant, alors cette réduction doit absolument pouvoir être utilisée à posteriori dans une autre commande.

Ici, il y a bien 2 phases complètements indépendantes l’une de l’autre :

Le gain : si la commande contient un café, la réduction sera gagnée et transférée dans le portefeuille.
L’utilisation : si la commande contient un croissant et que le portefeuille contient une réduction concernant le croissant, alors la réduction sera retirée du portefeuille pour être utilisée, c’est à dire appliquée effectivement à la commande.

On voit alors au moins 3 cas de figure différents qui pourraient se produire lors d’une commande :

Le client passe une commande qui contient un café mais pas de croissant ➔ la réduction est gagnée, mais reste dans le portefeuille sans être utilisée. Le client pourra l’utiliser dans une autre commande future qui contiendra un croissant.
Le client passe une commande qui contient un café ET un croissant ➔ la réduction est gagnée et utilisée dans la foulée. Techniquement, elle transite bien par le portefeuille de réductions mais n’y reste pas.
Le client passe une commande qui ne contient pas de café, mais un croissant ➔ dans ce cas il ne gagnera aucune réduction. Ceci étant, si avant la commande, il disposait déjà dans son portefeuille d’une réduction sur les croissants, elle sera utilisée à ce moment là. Dans le cas contraire, rien ne se passera.

A noter : on peut “simuler” une réduction immédiate avec ce système de réduction différée. Il suffit de définir “Pour tout café acheté, -50% offert sur le café”. Dans ce cas là, la réduction sera forcément gagnée et utilisée dans la même commande, et le résultat côté client sera similaire à la réduction immédiate “-50% sur le café” donnée plus haut en exemple.

Le système de réduction différée peut devenir encore plus puissant, lorsque nous rajoutons des contraintes différentes à la fois sur le gain de la réduction, et sur l’utilisation de cette réduction : “Pour tout café acheté entre 12h et 14h, -50% offert sur le croissant, à valoir après 18h.” Dans ce cas, la réduction gagnée ne pourra jamais être déclenchée en même temps, puisque les plages horaires sont distinctes. Ici, nous guidons entièrement le comportement client pour l’inciter à venir une première fois entre 12h et 14h, et le forcer à revenir une seconde fois après 18h s’il veut pouvoir bénéficier de sa réduction. Puissant non ?

Notre choix : les réductions différées 😍

Q7 : Sur quels éléments d’une commande doivent s’appliquer les réductions ?

Maintenant que nos réductions s’appliquent sur des commandes passées, il faut déterminer sur quels éléments de la commande appliquer cette réduction.

Si l’on analyse comment est composé le ticket d’une commande classique, on pourrait dire qu’il y a une liste d’articles commandés. La somme de ces éléments nous donne un total articles. Dans de nombreux systèmes (pas forcément dans le retail), il existe des lignes supplémentaires qui vont ensuite modifier le montant de la commande, par exemple des montants d’admission ou de subvention dans de la restauration collective. Et enfin, il y a un reste à charge qui correspond au montant net à régler par le client. J’omets volontairement le concept de TVA qui ne nous intéresse pas du tout ici. Voici un exemple de ticket sans réduction appliquée :

Sachant cela, sur quels éléments pourrait-on vouloir appliquer nos réductions ?

Sur les articles commandés : dans ce cas, le montant de la commande ne nous intéresse pas vraiment, on veut récompenser le client d’avoir commandé un ou plusieurs articles spécifiques. Le montant de la réduction ne pourra pas excéder le montant de l’article lui-même.
Sur le total articles : dans ce cas, le montant des articles commandés nous intéresse, mais pas les lignes de coûts supplémentaires (donc notre exemple : l’admission et la subvention employeur). Le montant de la réduction ne pourra pas excéder le montant du total articles.
Sur le reste à charge : dans ce cas, le contenu de la commande ne nous intéresse pas. On veut ici que la réduction soit en rapport avec le montant que le client doit encore régler. Le montant de la réduction ne peut pas dépasser le reste à charge.

Notre choix : nous partirons sur une solution hybride gérant à la fois les réductions propres aux articles, et celles propres aux restes à charge. Spoiler alert : cela ne manquera pas de générer des difficultés supplémentaires, liées à la priorisation d’application des réductions dans une même commande.

Q8 : Utiliser des réductions par pourcentage ou par montant fixe ?

Les réductions par pourcentage

Les réductions par pourcentage sont intéressantes car leur montant est variable. De cette manière, pour une réduction sur un article, si le prix d’un article varie au fil du temps, il semble logique pour le client que la réduction associée soit proportionnelle au prix de cet article. Autrement dit, le prix initial influence le montant de la réduction. C’est d’ailleurs souvent de cette manière que vont être soldés par exemple les vêtements en magasin.

Mais lorsqu’une réduction par pourcentage concerne le reste à charge d’une commande, cela devient dangereux. Pourquoi ? Imaginez une réduction de -50% sur le reste à charge d’une commande. Si votre client passe une commande de 1000 €, êtes-vous vraiment prêts à lui offrir 500 € ? Si ce n’est pas le cas, vous devrez alors définir en plus des seuils d’application de la réduction (ex : -50% offert, dans le limite de x€), ce qui a pour inconvénient majeur de rendre plus complexe l’offre aux yeux du client. Et cela fonctionne aussi dans l’autre sens : si le client bénéficie de -50% sur sa commande, alors qu’il vient d’acheter une paire de chaussettes à 3 €, il risque d’être frustré car il aurait pu gagner plus de 1,50 € si la réduction avait été appliqué à une commande. Dans ce cas, il faudra soit définir un seuil d’application minimum (ex : -50% offert, à partir de x€), soit laisser le client choisir quand utiliser la réduction. Dans les deux cas, on s’accordera à dire que c’est plus complexe.

Malgré cela, la réduction par pourcentage a le bénéfice de pouvoir toujours s’appliquer, quelque soit le montant des articles ou du reste à charge.

Les réductions par montant fixe

Les réductions par montant fixe sont plus simples à gérer, car plus prévisibles. Comme leur nom l’indique, leur montant est connu d’avance.

Mais ici se pose une autre problématique (qui ne se pose pas avec les réductions par pourcentage) : que faire si la réduction n’est pas applicable entièrement ?

Exemple : 2,00 € de réduction sur un article qui vaut 1,50 €. Cela pourrait se produire si le prix de l’article a changé, mais qu’on n’a pas mis à jour la réduction correspondante. C’est pourquoi, lorsqu’elles concernent les articles, les réductions en pourcentage semblent plus pertinentes en général.

Notre choix : mélanger les deux types de réductions.

Pour les réductions par pourcentage, on mettra en place un système de seuil par le bas et par le haut pour éviter les réductions trop avantageuses ou trop désavantageuses.
Pour les réductions par montant fixe : dans le cas d’une réduction sur un article, si la réduction est supérieure, on appliquera le prix de l’article comme réduction. Dans le cas d’une réduction sur le reste à charge, on n’appliquera pas du tout la réduction (le client pourra toujours en bénéficier lors d’une autre commande).

Q9 : Les réductions doivent-elles être cumulables ?

Bien sûr, si vous n’autorisez qu’une seule réduction d’un coup par commande, et que le client choisit lui-même cette réduction, vous avez résolu le problème. Mais dans les faits, il est peut probable que vous souhaitiez avoir un système aussi limitant. A partir du moment où l’on veut gérer un cumul potentiel de réductions, on trouve plusieurs moyens pour y répondre :

Soit on gère les règles de cumul réduction par réduction : à chaque réduction créée, le responsable marketing définit si elle est cumulable ou pas. Soit avec un simple oui/non, auquel cas si une réduction est marquée “non cumulable”, elle ne pourra être que seule dans la commande. Soit en allant beaucoup plus loin, en listant pour chaque réduction, une “liste blanche” (liste des réductions cumulables) ou une “liste noire” (liste des réductions non cumulables). Cette dernière méthode, est beaucoup plus fastidieuse et sujette aux erreurs. Laisser la main sur ce sujet au responsable marketing lui laisse plus de flexibilité, mais lui créé une complexité potentiellement inutile.
Soit on impose des règles fixes qu’il convient de définir en amont. La complexité de ces règles va alors directement dépendre des choix qui ont été faits plus tôt. Notre choix : des réductions cumulables, avec des règles fixes (qu’on va définir plus bas)

Q10 : Comment définir des règles d’ordonnancement de plusieurs réductions cumulables, et donc applicables à une même commande ?

Plusieurs choix que nous avons fait depuis le début vont complexifier cette partie de la conception. En effet, rappelons que jusqu’ici, nous avons choisi :

de mélanger des réductions applicables sur des articles et sur le reste à charge d’une commande
de mélanger des réductions en pourcentage (montant variable) et en montant fixe
d’assurer un déclenchement automatique des réductions disponibles dans le portefeuille client (donc une gestion automatique du cumul et de l’ordre d’application des réductions).

Voici les quelques règles que nous allons mettre en place :

Notre choix de règles :

Nous sélectionnerons tant que possible les réductions en priorisant celles les plus bénéfiques au client. Pour cela, il faudra calculer le montant potentiel de ces réductions (pour les réductions en pourcentages qui ont un montant variable) et les ordonner en ordre décroissant.
Dans un soucis d’éviter une complexité supplémentaire, nous n’autoriserons qu’une seule réduction sur le reste à charge, mais autant de réductions sur les articles, qu’il y a d’articles commandés.
*Nous appliquerons d’abord les réductions sur les articles, avant d’appliquer celle sur la reste à charge (ce qui semble logique).

Attention ⚠️, ces règles fixes sont loin d’être parfaites pour tous les cas. Cet algorithme devra être peaufiné dans le temps en fonction des réductions disponibles et des usages réels des clients.

Q11 : Le client doit-il choisir quand appliquer ses réductions ?

On a en fait déjà en parti répondu à cette question. On peut distinguer au moins 3 cas différents :

Le déclenchement automatique : le client n’a jamais la main sur les réductions, qui seront déclenchées automatiquement lorsqu’il passe ses commandes. Dans ce cas, pour que le bénéfice soit maximal pour lui et éviter toute frustration, il faut être très attentif à la conception de l’algorithme qui va choisir quelles réductions déclencher, notamment quand plusieurs réductions sont disponibles simultanément (cf. Question : Dans quel ordre appliquer plusieurs réductions applicables à une même commande ?).
Le déclenchement manuel : c’est l’opposé du déclenchement automatique. Une réduction ne sera jamais déclenchée sans l’action du client. En général, on peut retrouver ce fonctionnement avec les codes promotionnel à renseigner au moment de la commande. Ici, il appartient au client de penser qu’il dispose d’un code lui donnant droit à une réduction. Un système comme celui-ci permet de faire venir des clients qui ne seraient pas venus sans la réduction, mais de ne pas proposer de réductions à ceux qui ne viennent pas pour ça. Cela maximise à priori la marge de l’enseigne.
Le déclenchement suggéré : ici on est dans un système à mi-chemin, où au moment de la commande, on va présenter aux clients ses réductions utilisables, et lui laisser choisir lesquelles utiliser. Cela peut être intéressant pour le client dans les cas où le montant des réductions est variable en fonction de la commande passée. Exemple : s’il dispose d’une réduction “-50% sur votre commande, dans la limite de 20€” mais qu’il passe une commande de 2€, il n’a pas envie que cette commande soit appliquée à ce moment-là car ce n’est pas assez bénéfique pour lui.

Notre choix : déclenchement automatique.

Q12 : Qu‘est-il censé se passer si une commande est modifiée ou annulée ?

Typiquement, si on a choisi un système de réduction immédiates, cela devrait être assez simple à gérer : il suffit de recalculer si la commande mise à jour donne toujours le droit à la réduction en question. Il faudra juste penser à l’historisation.

L’importance de l’historisation 🗒️

Dans n’importe quel système de commande, l‘article dans la commande est “historisé”. Par exemple, si le steak a été acheté 3€, et qu’ensuite le prix du steak est modifié à 3,50€, le montant de la commande, lui, ne bouge pas. Encore heureux ! Techniquement, on peut dire qu’au moment de la commande, on fait une photographie à l’instant T du steak et de ses caractéristiques, et qu’on gardera cette photo dans la commande, peu importe comment le steak évoluera ensuite.

On veut probablement faire la même chose avec les réductions. Par exemple, si le client a bénéficié d’une réduction “-10% sur le steak”, et qu’ensuite cette réduction est modifiée par les équipes marketing à “-5% sur le steak”, si on n’a pas historisé la réduction, et que la commande est modifiée avec un réduction toujours applicable, alors elle passerait à -5% au lieu de -10%. Ce serait incompréhensible pour le client, et pourrait peut-être même poser des problèmes légaux.

Et avec les réductions différées ?

Là, ça se complique ! Accrochez-vous. Pour rappel, dans le cas des réductions différées (notre choix), il y a deux phases distinctes : celles du gain des réductions, et celles de l’utilisation des réductions disponibles dans le portefeuille. Tout ce qui vient d’être expliqué sur l’historisation reste valable, mais partons d’un exemple pour mettre en lumière une nouvelle difficulté 🥴 :

Le client passe d’abord une commande C1, dans laquelle il gagne la réduction R, mais ne l’utilise pas.
Le client passe ensuite une autre commande C2, dans laquelle il utilise la réduction R.
Enfin, la commande C1 est annulée.

Puisque la commande C1 a été annulée, le client ne devrait plus pouvoir bénéficier de R. Néanmoins, cela forcerait donc à ce que l’annulation de C1, provoque une modification automatique de C2. On pourrait appeler ce mécanisme, une modification de commande par effet de bord.

Mais son implémentation est probablement complexe, difficilement compréhensible côté client, et ce cas pratique ne pourrait se produire que très rarement. L’alternative est donc de ne pas l’implémenter et d’accepter dans certains cas d’offrir une réduction à un client, dont il n’aurait pas du bénéficier en réalité.

Notre choix : historisation, mais pas de modification de commande par effet de bord

Qui va gérer en interne ces programmes de réductions ?

Vous êtes le concepteur de la solution. Mais vous n’êtes pas la personne qui sera ensuite en charge de créer les programmes de réductions, suivre leur performance, etc. Qui va donc le faire ?

Dans notre modèle actuel, il existe plusieurs magasins. On devine alors deux solutions bien distinctes :

Soit, chaque responsable de magasin est en charge de définir ses propres réductions. C’est le modèle le plus simple : chaque réduction sera liée à un magasin et ne pourra s’appliquer que dans ce dernier. On pourrait parler d’un modèle de réduction en silo.
Soit, on imagine par exemple qu‘il existe en central, une équipe marketing, responsable de gérer l’ensemble des réductions de tous les magasins. Dans ce cas, créer une réduction par magasin deviendrait vite ingérable dès lors que le nombre de magasins augmenterait ! C’est pourquoi ici, une même réduction pourra s’appliquer dans plusieurs magasins à la fois. On pourrait parler d’un modèle de réductions transverse.

Notre choix : le modèle de réductions transverse.

Résumé

C’était long, mais on vient de levé beaucoup d’interrogations 😅

Les choix effectués

Nous allons créer un programme qui permet à nos clients d’avoir des réductions spécifiques. Cette segmentation clients sera faite par des critères propres à ces clients.

Les commandes seront à la fois l’action qui permet de gagner des réductions, mais aussi des les utiliser. Car oui, cela se fera en 2 phases distinctes pour ouvrir le champ des possibles. Chaque client aura alors un portefeuille de réductions utilisables.

Chaque réduction s’appliquera sur une commande, sous forme d’un rabais, sous forme fixe ou en pourcentage, sur des articles ou sur le reste à charge d’une commande. Les règles de cumul et l’algorithme de priorisation d’utilisation seront fixés. Les réductions déclenchées le seront sans l’aval du client.

Notre système prendra en compte le recalcul d’une réduction dans le cadre d’une modification ou annulation de commande, tout en faisant l’impasse sur les cas trop compliqués à gérer.

Enfin, les programmes de réductions (qui définissent à la fois les conditions d’obtention, et les gains) seront définis en central, ce qui permettra de faire des réductions qui fonctionnent dans plusieurs magasins de notre enseigne à la fois.

La prochaine étape

On pourrait très bien formaliser ces réponses pour en faire des réelles spécifications fonctionnelles, ou bien partir directement sur des spécifications techniques, notamment la modélisation du système.

En attendant, bonne conception à tous 💪💪💪