Statuts de commande dans PrestaShop : personnalisation et automatisation

Voici la partie de PrestaShop qui fait tourner discrètement tout votre back-office, alors que presque personne ne la configure vraiment : le statut de commande. Chaque commande se trouve à tout moment dans un seul statut, et cette seule valeur décide de ce que le client voit dans son compte, si le stock a été déduit, si une facture existe, et quel e-mail vient d’arriver dans sa boîte de réception. Laissez les valeurs par défaut telles quelles, et une boutique très active finit par avancer à l’intuition. Adaptez les statuts à votre manière réelle de traiter les commandes, et le même back-office commence à indiquer à votre équipe quoi faire ensuite — tout en informant vos clients de ce qui se passe avant qu’ils n’aient besoin d’écrire au support. Ce guide explique comment y parvenir spécifiquement dans PrestaShop : ce que déclenche réellement chaque statut par défaut, comment créer les vôtres dans Paramètres de la boutique → Statuts, ce qui se trouve en dessous dans la table ps_order_state, et comment automatiser les transitions pour que les membres de votre équipe cessent de jouer les déclencheurs de base de données avec un pouls.

Dernière mise à jour : juin 2026.

Ce qu’est réellement un statut de commande dans PrestaShop

Dans PrestaShop, un statut de commande n’est pas seulement une étiquette. Chaque statut est une ligne de la table ps_order_state (avec son nom traduisible dans ps_order_state_lang), et cette ligne porte un ensemble de drapeaux booléens qui indiquent au cœur de PrestaShop quoi faire lorsqu’une commande entre dans cet état : générer ou non une facture, marquer la commande comme payée, la marquer comme expédiée, rendre le bon de livraison PDF disponible, envoyer un e-mail. (La déduction du stock ne fait pas partie de ces drapeaux — PrestaShop réduit le stock disponible lorsque la commande est validée/créée, pas lorsqu’un drapeau de statut se déclenche ; nous y revenons plus bas.) Le statut actuel de la commande est stocké dans ps_orders.current_state, et PrestaShop ajoute en plus une nouvelle ligne dans ps_order_history à chaque changement de statut, ce qui donne aussi à la commande un historique d’audit complet et horodaté de tous les états par lesquels elle est passée. Le « statut actuel » visible dans l’administration est la valeur de current_state, tandis que ps_order_history enregistre le chemin qui y a mené.

Conséquence concrète pour un propriétaire de boutique : la liste des statuts est l’endroit où vit votre logique opérationnelle. Configurez correctement les drapeaux une fois, et PrestaShop les applique à chaque commande, durablement — aucun membre de l’équipe n’a à se souvenir que « nous générons la facture quand le paiement est confirmé, pas avant ». Configurez-les mal, et vous pouvez générer en silence des factures pour des commandes que personne n’a payées. Nous revenons sur ce piège plus loin.

Les statuts de commande par défaut — et ce que chacun déclenche vraiment

PrestaShop est livré avec un ensemble prédéfini de statuts. La plupart des marchands les traitent comme de simples libellés ; en réalité, chacun déclenche de vraies actions dans la base de données dès qu’une commande y arrive. Voici ce qui se passe réellement sous le capot.

En attente de paiement par chèque

Appliqué lorsqu’un client choisit le paiement par chèque lors du passage de commande. La commande existe, mais aucun argent n’est encore arrivé. La commande est validée au moment où elle est passée, donc le stock disponible est traité à ce stade selon vos paramètres de stock — il n’est pas « réservé » séparément par ce statut — aucune facture n’est générée, et la commande reste ici jusqu’à ce que vous confirmiez manuellement l’encaissement du chèque. Rien ne bouge tout seul : c’est volontaire.

En attente de virement bancaire

L’équivalent pour le virement bancaire. Le client voit votre IBAN/BIC et une référence de commande, le stock disponible est traité à la validation de la commande selon vos paramètres de stock, puis la commande reste ici jusqu’à ce que vous la marquiez comme payée — généralement un à trois jours ouvrés plus tard, lorsque le virement arrive. C’est le statut qu’il vaut le plus la peine d’automatiser (nous y revenons dans la section sur l’automatisation), car confirmer les virements à la main est de l’administration répétitive à l’état pur.

Paiement accepté

C’est le statut pivot. Lorsqu’une commande atteint Paiement accepté, PrestaShop :

• Génère la facture (si le statut porte le drapeau de facturation — c’est le cas par défaut) ;
• Marque la commande comme payée dans la base de données ;
• Envoie l’e-mail de statut au client.

Notez ce que ce statut ne fait pas : il ne déduit pas le stock. Le stock disponible est réduit lorsque la commande est créée/validée lors du passage de commande — ce qui se produit même pour les commandes en Attente de paiement — si bien que le mouvement de stock a généralement déjà eu lieu avant que la commande n’atteigne Paiement accepté.

Pour les paiements par passerelle — PayPal, Stripe, Mollie — le module de paiement définit automatiquement ce statut dès que la passerelle confirme le débit. Vous n’y touchez pas. Cette transition automatique, pilotée par le code, est exactement le comportement à reproduire pour vos modes de paiement manuels.

Traitement en cours / Préparation en cours

Un statut intermédiaire facultatif qui signifie « l’entrepôt prépare et emballe la commande ». Il ne déclenche aucune action automatique : toute sa valeur tient à la coordination humaine. Certaines boutiques s’en passent ; les boutiques à fort volume le trouvent indispensable pour distinguer d’un coup d’œil la file de préparation de la file des commandes impayées.

Expédiée

Appliqué lorsque le colis quitte votre entrepôt. Il déclenche un e-mail de confirmation d’expédition (avec le numéro de suivi, s’il est renseigné) et rend le bon de livraison disponible. L’ordre des opérations compte : saisissez le numéro de suivi dans la section Transporteurs de la commande avant de basculer le statut sur Expédiée, sinon l’e-mail part sans lien de suivi et vous recevez quand même le message « où est mon colis ? ».

Livrée

Indique que le client a reçu les produits — statut défini manuellement ou par une intégration avec l’API du transporteur. Dans l’UE, c’est le moment qui déclenche le délai de rétractation de 14 jours pour la vente à distance ; des dates de livraison exactes ne sont donc pas cosmétiques, elles constituent l’horloge de votre politique de retour.

Annulée

L’annulation d’une commande peut réaugmenter le stock disponible des produits de la commande (via le comportement normal de gestion des stocks de PrestaShop, puisque le stock a déjà été décrémenté au passage de la commande), et le client reçoit un e-mail d’annulation. Deux choses que cela ne fait pas automatiquement : rembourser l’argent (vous le traitez séparément), ni supprimer une facture déjà générée. Si une facture existe, émettez un avoir plutôt que de faire comme si la facture n’avait jamais existé — votre comptable vous remerciera.

Remboursée

Appliqué une fois le remboursement traité. Un avoir n’est pas créé simplement parce que vous appliquez cette étiquette de statut : il est généré via le processus de remboursement (le panneau Remboursement standard / Remboursement partiel / Retour produits) lorsque vous cochez l’option correspondante. Le retour des articles en stock vendable dépend, lui aussi, de la manière dont vous avez traité le remboursement dans ce panneau.

Erreur de paiement

Défini lorsqu’une tentative de paiement échoue : carte refusée, fonds insuffisants, étape 3-D Secure échouée. Aucun stock n’est déduit, aucune facture n’est générée. Que le client en soit informé ou non dépend entièrement du module de paiement.

En réapprovisionnement (payée / non payée)

Pour les boutiques qui acceptent des commandes qu’elles ne peuvent pas encore expédier. La commande est enregistrée, mais l’exécution attend le réapprovisionnement. Les variantes « payée » et « non payée » vous permettent de garder l’état du paiement exact pendant que les produits sont en route vers vous.

Lire les statuts dans la base de données

Vous n’aurez jamais besoin de toucher au SQL pour gérer une boutique, mais connaître la forme des données rend les écrans d’administration beaucoup plus compréhensibles — et c’est ce sur quoi repose toute automatisation. Les trois tables importantes :

Comme chaque changement de statut ajoute une nouvelle ligne ps_order_history (tout en mettant à jour current_state sur la commande), l’historique n’est jamais un écrasement destructeur : c’est une piste d’audit. C’est pour cela que vous pouvez toujours voir par où une commande est passée, et qu’une mise à jour SQL en masse imprudente sur les états de commande est dangereuse : écrivez directement dans les tables et vous contournez tous les drapeaux, e-mails et mouvements de stock que le cœur déclencherait normalement. La manière prise en charge de déplacer une commande dans le code passe par l’objet commande, pas par des UPDATE bruts. Nous abordons les bons hooks dans la section développeur.

Créer des statuts de commande personnalisés

Allez dans Paramètres de la boutique → Statuts (dans PrestaShop 1.6, cet écran se trouvait sous Commandes → Statuts). Cliquez sur Ajouter un nouveau statut de commande et vous configurez l’une de ces lignes ps_order_state depuis l’interface. Les champs qui comptent :

• Nom du statut : ce que votre équipe lit dans la liste des commandes. « En attente fournisseur » sera toujours plus utile que « Statut 7 » — la clarté ici supprime toute une catégorie de questions du type « celui-ci veut dire quoi déjà ? ».
• Icône et couleur : le repère visuel dans la liste des commandes. Choisissez une convention et tenez-vous-y : vert pour ce qui va bien, orange pour l’attente, rouge pour les problèmes. Un marchand devrait pouvoir trier mentalement la liste des commandes par couleur depuis l’autre bout de la pièce.
• Drapeaux de comportement — c’est le véritable moteur :
  • Considérer la commande associée comme validée : compte la commande dans vos statistiques de ventes.
  • Autoriser le client à télécharger et consulter les versions PDF de ses factures : contrôle la visibilité des factures dans le compte client.
  • Définir la commande comme payée : indique au reste de PrestaShop que l’argent a été reçu.
  • Afficher le bon de livraison PDF / Définir la commande comme expédiée : marque les produits comme partis et rend le bon de livraison disponible.
  • Générer la facture : crée la facture PDF lors de cette transition.
  • Envoyer un e-mail au client lorsque le statut de la commande a changé : le déclencheur qui transforme un statut en notification client.
• Modèle d’e-mail : le message envoyé lorsque le drapeau e-mail est activé.

Le « et alors ? » de ces drapeaux : ils font la différence entre un statut qui n’est qu’une couleur et un statut qui fait discrètement votre comptabilité. Définissez-les volontairement, et PrestaShop fera ce qu’il faut sur toutes les prochaines commandes sans supervision humaine.

Les statuts personnalisés que nous voyons le plus souvent

À force de travailler au quotidien avec des boutiques PrestaShop, voici les statuts personnalisés qui méritent vraiment leur place :

• En attente fournisseur : payée, mais un article doit être commandé. Pas d’e-mail client : c’est un repère interne, pas une information dont le client a besoin.
• Prête pour le retrait : pour le retrait en magasin. E-mail activé, avec l’adresse, les horaires et ce que le client doit apporter.
• Partiellement expédiée : certains articles sont partis, d’autres arriveront plus tard. Indiquez au client par e-mail ce qui a été expédié et ce qui reste en attente.
• En cours de vérification : commandes à forte valeur ou signalées comme potentiellement frauduleuses, mises en pause pour un contrôle manuel. Pas d’e-mail client.
• En attente de réponse client : vous l’avez contacté (correction d’adresse, question produit) et la commande est en pause jusqu’à sa réponse.
• Retour demandé / Retour reçu : les deux moitiés d’un RMA — le client a fait la demande, puis le colis est revenu chez vous pour inspection.

Déclencheurs d’e-mails pour chaque statut

Lorsqu’un statut a son drapeau e-mail activé, PrestaShop envoie au client le modèle nommé pour ce statut. Les modèles se trouvent dans /mails/LANGUAGE_CODE/, sous forme de fichiers HTML et TXT associés (la version texte brut sert de solution de repli pour les clients qui bloquent le HTML, donc les deux doivent exister).

Brancher un e-mail de statut personnalisé

Activez l’e-mail pour un statut personnalisé, et vous êtes responsable du modèle ; sinon l’envoi échoue silencieusement dans les journaux. Pour le brancher correctement :

• Créez les fichiers HTML et TXT correspondants dans chaque dossier de langue sous /mails/ — le nom du modèle doit correspondre à ce que le statut attend.
• Réutilisez les variables que le cœur expose déjà : {firstname}, {lastname}, {order_name}, {id_order}, {shipping_number} pour le suivi, et les autres.
• Définissez l’apparence une fois dans Apparence → Thème d’e-mail plutôt que de modifier chaque fichier à la main.

Si vous préférez ne pas créer de modèles du tout, le cas vraiment courant consiste simplement à renvoyer un e-mail de commande qu’un client a perdu. PrestaShop peut renvoyer la confirmation existante directement depuis la page de commande — nous montrons précisément où se trouve ce bouton dans comment renvoyer un e-mail de confirmation de commande.

Envoyer les bons e-mails, pas tous les e-mails

• N’envoyez pas trop d’e-mails. Les clients ne veulent pas recevoir un message à chaque étape interne. « Préparation en cours » concerne votre équipe, pas leur boîte de réception. Réservez les e-mails aux moments qui les intéressent vraiment : paiement confirmé, expédition (avec suivi), livraison.
• Rendez chaque e-mail actionnable. L’e-mail d’expédition contient le numéro et le lien de suivi ; l’e-mail de retrait disponible contient l’adresse, les horaires et ce qu’il faut apporter. Un e-mail sans prochaine étape génère seulement une réponse.
• Cadrez les attentes. En cas de réapprovisionnement, annoncez le délai. Un vague « le statut de votre commande a changé » sans détail est un ticket support en attente d’ouverture.

Automatiser les changements de statut

Gérer les statuts à la main fonctionne à dix ou vingt commandes par jour. Au-delà, chaque transition manuelle vous coûte du temps et crée une occasion d’oublier une étape. Les opportunités, par ordre approximatif de retour :

Confirmation du paiement

Les passerelles de paiement par carte automatisent déjà cela : PayPal, Stripe et Mollie basculent la commande sur Paiement accepté après confirmation, sans intervention humaine. Le trou concerne les virements bancaires et les chèques, où il vous reste la confirmation manuelle, une intégration de flux bancaire qui rapproche les virements entrants des commandes par référence, ou une vérification planifiée via le webhook d’une passerelle. Combler ce trou est généralement le plus gros gain de temps de tout le flux de commande.

Expédition

Un module d’intégration transporteur (Colissimo, DHL, Mondial Relay, etc.) devrait basculer la commande sur Expédiée et écrire le numéro de suivi dès que vous imprimez l’étiquette. Si le vôtre ne le fait pas, le réglage pour l’activer existe presque toujours dans le module — il est simplement désactivé par défaut.

Confirmation de livraison

Les API des transporteurs peuvent signaler la livraison. Une tâche planifiée qui interroge l’API chaque jour et passe les colis confirmés en Livrée garde l’horloge du délai de retour européen exacte sans que personne ne surveille les pages de suivi. C’est le terrain classique d’une tâche cron : configurez-la une fois, laissez-la tourner pendant que vous dormez.

Automatisation basée sur des règles

Pour la logique « si ceci, alors cela » que le cœur ne couvre pas — si le mode de paiement est le virement bancaire et que le total dépasse 500 EUR, définir En cours de vérification et prévenir l’administrateur — il vaut mieux une automatisation de statut basée sur des règles qu’un code personnalisé qui cassera à la prochaine mise à niveau. C’est précisément le type de processus conditionnel pour lequel notre équipe développe des modules chez mypresta.rocks : définissez les conditions et les actions depuis le back-office, et PrestaShop envoie chaque commande sur le bon chemin tout seul. L’intérêt n’est pas le mot à la mode « automatisation » : c’est que le goulot d’étranglement cesse d’être une personne qui doit se trouver devant son bureau.

Hooks de statut de commande pour les développeurs

Si vous construisez l’automatisation vous-même, PrestaShop déclenche des hooks autour de chaque changement de statut, afin que vous n’ayez jamais à écrire directement dans les tables :

• actionOrderStatusUpdate : déclenché pendant qu’un changement de statut est appliqué. C’est un hook de type notification ; utilisez-le donc pour exécuter vos propres validations et la logique de votre module autour d’une transition, plutôt que comme un moyen garanti et officiellement pris en charge de bloquer proprement cette transition.
• actionOrderStatusPostUpdate : déclenché après validation du changement — l’endroit pour les traitements de suivi, comme synchroniser la commande avec un ERP ou une plateforme d’expédition.
• actionOrderHistoryAddAfter : déclenché après l’écriture d’une nouvelle ligne ps_order_history — pratique pour vos propres journaux et pistes d’audit.

Un schéma typique : lors du passage en Expédiée, publier un webhook vers l’API de votre partenaire logistique ; lors du passage en Livrée, mettre en file un e-mail de demande d’avis pour sept jours plus tard. Comme vous déplacez la commande via son objet et écoutez ces hooks, chaque drapeau, e-mail et mouvement de stock géré par le cœur se déclenche toujours correctement — c’est exactement pour cela qu’il faut utiliser des hooks plutôt qu’un UPDATE SQL brut sur ps_order_state.

Modifier et corriger les commandes en cours de route

Les statuts décrivent où une commande en est ; tout aussi souvent, vous devez changer ce qu’elle contient — corriger une quantité, remplacer une adresse, appliquer une remise après coup. PrestaShop vous permet de modifier une commande déjà passée depuis sa page de détail, avec de vraies limites dès qu’une facture existe. Le guide complet de ce qu’il est sûr de modifier, et à quel moment, se trouve dans comment modifier une commande après qu’elle a été passée, et le travail quotidien plus large sur la liste des commandes — filtrage, actions groupées, statuts en contexte — est couvert dans notre guide complet de gestion des commandes dans PrestaShop.

Gérer les expéditions partielles

Les expéditions partielles font partie des flux les plus difficiles que les valeurs par défaut de PrestaShop doivent gérer. Le cœur suppose discrètement qu’une commande équivaut à une expédition : la prise en charge native des expéditions partielles est limitée, et les bons de livraison sont des documents au niveau de la commande — PrestaShop ne modélise pas proprement les expéditions partielles au niveau des articles par défaut. Une approche manuelle viable ressemble à ceci :

• Créer un statut personnalisé Partiellement expédiée ;
• Enregistrer le numéro de suivi des articles qui partent maintenant ;
• Lorsque le reste est prêt, l’expédier sous un nouveau numéro de suivi ;
• Ne passer en Expédiée que lorsque tout est parti.

Le point de friction : la page de détail de commande par défaut ne suit pas nativement quels articles sont partis dans quel colis, et générer un document de livraison par expédition pour les seuls articles de ce colis n’est pas une opération native. Les boutiques qui fractionnent régulièrement les commandes ont besoin d’un processus personnalisé ou d’un module pour un vrai suivi des expéditions et des documents par article au-dessus du cœur — sinon l’historique de commande vous dit que quelque chose a été expédié, mais pas quoi.

Processus de commande B2B

Le traitement B2B ne suit pas le parcours B2C, et la liste des statuts est l’endroit où vous encodez cette différence :

• Devis et approbation : commandes qui nécessitent une validation avant paiement, modélisées comme « Devis envoyé » → « Devis approuvé » → « En attente de paiement » → « Paiement accepté ».
• Bons de commande : les conditions à 30/60/90 jours signifient que l’exécution et l’encaissement du paiement suivent deux horloges séparées ; vos statuts doivent suivre les deux sans les confondre.
• Expéditions partielles : les commandes B2B multi-articles avec des délais mélangés s’appuient sur la configuration d’expédition partielle ci-dessus comme une routine, pas comme une exception.
• Contrôle du minimum de commande : les commandes sous le seuil peuvent passer par « En cours de vérification » avant que quelqu’un ne les prépare.

Créer des rapports à partir de vos statuts

Parce que chaque transition est une ligne horodatée dans ps_order_history, vos données de statut sont votre reporting opérationnel — gratuitement, si vous les regardez :

• Temps passé dans chaque statut : la durée pendant laquelle les commandes restent en Paiement accepté avant Expédiée est, littéralement, votre vitesse de préparation.
• Répartition des statuts : une pile qui grossit dans « En attente fournisseur » révèle un problème d’approvisionnement avant même que votre fournisseur ne l’admette.
• Annulation par étape : si les commandes échouent disproportionnellement à un statut, cette étape de votre processus fuit.
• Cycle de vie complet : du passage de commande à la livraison, suivi dans le temps, il vous indique si vous accélérez ou si vous ralentissez discrètement.

Erreurs courantes à éviter

• Trop de statuts. Au-delà d’une douzaine environ, plus personne ne les retient et la liste cesse d’aider au tri. Si votre équipe ne peut pas les réciter, vous en avez trop.
• Des noms flous. « Statut A » et « Statut B » ne disent rien à personne. Nommez-les d’après ce qu’ils signifient.
• Un statut personnalisé avec l’e-mail activé mais sans modèle. C’est le cas d’échec silencieux : l’envoi meurt dans les journaux et le client n’entend rien.
• Une équipe non formée. Le processus le plus propre ne sert à rien si l’équipe ne sait pas quand appliquer chaque statut. Une fiche de référence d’une page se rentabilise toute seule.
• Le piège du drapeau de facturation. Activez Générer la facture pour un statut qui ne confirme pas le paiement, et vous commencerez à produire des factures pour des commandes que personne n’a payées — un vrai désordre comptable et fiscal à démêler. Vérifiez deux fois ce drapeau avant d’enregistrer.

Un mot sur les commandes de test

Pendant que vous mettez tout cela en place, vous passerez des commandes de test pour observer les statuts et les e-mails se déclencher — et chacune d’elles pollue vos statistiques, votre séquence de factures et votre ps_order_history si vous la laissez. Nettoyez-les avant la mise en production ; la méthode sûre pour les supprimer (et pourquoi il ne faut pas simplement DELETE les lignes) se trouve dans comment supprimer les commandes de test dans PrestaShop.

Questions fréquentes

Où ajouter un statut de commande personnalisé dans PrestaShop ?

Allez dans Paramètres de la boutique → Statuts, puis cliquez sur Ajouter un nouveau statut de commande. Dans PrestaShop 1.6, le même écran se trouvait sous Commandes → Statuts. Chaque statut que vous créez est une ligne de la table ps_order_state, et les cases à cocher de ce formulaire (payée, expédiée, générer la facture, envoyer un e-mail) sont les drapeaux de comportement que le cœur déclenche chaque fois qu’une commande arrive sur ce statut.

Passer une commande en « Paiement accepté » déduit-il le stock ?

Non. Le stock disponible est réduit lorsque la commande est validée/créée au passage de commande — ce qui se produit même tant que la commande est en « Attente de paiement » — pas lorsque le drapeau payé se déclenche. Lorsqu’une commande atteint Paiement accepté, le mouvement de stock a généralement déjà eu lieu. Le statut payé génère la facture, marque la commande comme payée et envoie l’e-mail de statut ; il ne touche pas au stock.

Pourquoi l’e-mail de mon statut personnalisé n’a-t-il jamais été envoyé ?

Presque toujours à cause d’un modèle manquant. Lorsque vous activez le drapeau e-mail pour un statut, PrestaShop cherche des fichiers HTML et TXT portant le nom correspondant sous /mails/LANGUAGE_CODE/ dans chaque dossier de langue. Si ces fichiers n’existent pas, l’envoi échoue silencieusement dans les journaux et le client n’entend rien. Créez les modèles HTML/TXT par paire pour chaque langue avant de vous appuyer sur l’e-mail.

Puis-je changer le statut d’une commande depuis le code sans écrire de SQL ?

Oui — et vous devriez. Déplacez la commande via son objet commande pour que chaque drapeau, e-mail et mouvement de stock continue à se déclencher, et écoutez les hooks fournis par PrestaShop : actionOrderStatusUpdate (pendant l’application du changement), actionOrderStatusPostUpdate (après validation — utile pour la synchronisation ERP/expédition), et actionOrderHistoryAddAfter (après l’écriture de la ligne d’historique). Un UPDATE brut sur ps_order_state contourne tout cela, et c’est comme cela qu’on se retrouve avec des factures et des e-mails désynchronisés.

Comment éviter de générer des factures pour des commandes impayées ?

Surveillez le drapeau Générer la facture. Si vous l’activez pour un statut qui ne confirme pas le paiement, PrestaShop produira des factures pour des commandes que personne n’a payées — un vrai désordre comptable et fiscal à démêler. Gardez la génération de factures liée uniquement à votre statut de paiement confirmé, et revérifiez cette case avant d’enregistrer un nouveau statut.

Puis-je automatiser les changements de statut pour les virements bancaires et les règles conditionnelles ?

Les passerelles de carte basculent déjà automatiquement les commandes sur Paiement accepté ; le trou concerne les virements bancaires, les chèques, et la logique conditionnelle comme « si virement bancaire et total supérieur à 500 EUR, définir En cours de vérification ». Ce type de processus basé sur des règles est exactement ce que notre module d’automatisation du processus de commande gère depuis le back-office, afin que le goulot d’étranglement cesse d’être une personne obligée d’être à son bureau pour basculer les statuts.

Un processus de statuts de commande bien conçu est la colonne vertébrale d’un back-office serein : l’équipe sait quoi faire ensuite, le client reçoit la bonne information au bon moment, et la comptabilité reste propre parce que ce sont les drapeaux — et non un humain fatigué à 18 h — qui décident quand une facture existe et quand le stock bouge. Planifiez le processus avant de le brancher, car une fois les commandes en circulation dans vos statuts, les modifier en plein flux est beaucoup plus perturbant que de les configurer correctement dès le départ. Lorsque les transitions manuelles deviennent trop lourdes, l’automatisation basée sur des règles de mypresta.rocks retire de l’assiette de votre équipe les changements de statut répétitifs, afin que chaque commande suive le même chemin du passage de commande à la livraison — à chaque fois, que quelqu’un surveille ou non.