Sites Web et commerce
Structurez les files, les états, les responsabilités et les communications nécessaires lorsqu’une commande ne peut pas suivre le parcours normal d’exécution.
Comment le flux de travail s’articule
La plupart des diagrammes de commerce électronique se terminent par un paiement et une expédition réussies. Les opérations réelles comprennent également des écarts de stock, des paiements à vérifier, des adresses invalides, un traitement fractionné, des remboursements partiels et des défaillances du transporteur. Un flux de travail d'exception maintient ces cas visibles et assigne une action suivante avant qu'ils ne deviennent des demandes de soutien.
Commencez par les événements qui arrêtent ou modifient l'ordre: l'autorisation de paiement doit être revue, l'inventaire n'est pas disponible, l'adresse ne peut être validée, un article doit être expédié séparément ou le transporteur rejette une étiquette. Consigner où chaque condition provient et si elle peut être effacée automatiquement.
Évitez un statut d'exception de capture-tout. Une pénurie d'entrepôts et un paiement incertain exigent différents choix d'accès, d'information et de résolution.
Chaque élément de file d'attente doit indiquer ce qui s'est passé, quel système l'a signalé, ce qui a déjà été tenté, qui possède la prochaine action, et quelles actions sont autorisées. L'exploitant peut remplacer le stock, demander une adresse corrigée, annuler une ligne, réessayer une étiquette ou intensifier un examen de paiement.
Une mise à jour d'entrepôt retardée peut arriver après qu'un opérateur modifie la commande. Conservez les informations de version ou d'horodatage et rejetez les transitions qui ne s'appliquent plus. Les mesures de résolution devraient être idempotentes de sorte qu'une réessayer ne délivre pas un deuxième remboursement ou crée une autre expédition.
Conservez la réponse de la source à côté du statut normalisé. Ce registre permet de procéder à un rapprochement lorsqu'un système externe utilise une terminologie différente ou modifie ultérieurement son résultat.
Les messages devraient être déclenchés par des décisions confirmées, et non par tous les avertissements internes. Définir les événements qui nécessitent un préavis immédiat, qui nécessitent un examen par l'opérateur et qui peuvent demeurer internes. La vue du soutien devrait montrer ce qu'on a dit au client afin que la prochaine conversation commence à partir du même enregistrement.
Un client passe une commande pour le dernier article disponible. Le fournisseur de paiement autorise les frais, mais le système d'inventaire signale qu'un autre canal a réservé l'unité quelques instants plus tôt. L'ordre ne doit pas sauter directement à l'échec ou à l'accomplissement. Il entre dans un état d'examen de l'inventaire tout en préservant le délai d'autorisation de paiement et la solution de rechange ou d'annulation choisie par le client.
Un fonctionnaire peut libérer une autre réservation, remplacer une variante approuvée par l'accord du client ou annuler avant la saisie. Le flux de travail enregistre la décision et envoie ensuite la commande appropriée au paiement et à l'exécution. La communication avec le client est basée sur le résultat confirmé, pas sur la première réponse du système qui est arrivée.
Repère visuel
L'enregistrement de l'ordre coordonne plusieurs systèmes alors qu'une file d'attente d'examen possède des décisions qui ne peuvent être prises en toute sécurité par règlement.
Ordre reçu
Créez une commande stable et conservez les articles et conditions demandés par le client.
Paiement vérifié
Consigner l'autorisation, le déclin, l'expiration ou l'examen sans s'attendre à ce qu'il soit saisi.
Inventaire réservé
Confirmer le fait de stock de son système faisant autorité.
Examen des exceptions
Attribuer des conflits avec les options de décision et les délais.
Résultat appliqué
Mettre à jour l'exécution, le paiement et la communication client une fois.
Les API de paiement et de traitement peuvent atteindre leur délai d’attente après avoir accepté une demande. Conservez une clé d’idempotence pour chaque action prévue et interrogez le fournisseur avant de répéter une commande incertaine. Un client rafraîchissant la page de confirmation ne doit pas créer une autre commande, et un webhook répété ne doit pas déclencher une autre expédition ou courriel.
Donnez au personnel des actions sûres qui reflètent l'état actuel: réessayer une synchronisation temporaire, corriger une adresse avant l'expédition, demander la confirmation du client, libérer une réservation, annuler une autorisation non saisie, ou intensifier un examen de fraude. Consigner qui a agi, quels faits ils ont vus et quelles opérations externes ont été confirmées par la suite.
| Exception | Propriétaire | Action suivante sûre | Confirmation |
|---|---|---|---|
| Résultat du paiement inconnu | File des paiements | Demande par clé d’idempotence | État de la transaction avec le fournisseur |
| Conflit de stocks | Équipe d’inventaire | Révision de la réserve ou autre | Réserve pour stocks |
| Adresse non valide | Service à la clientèle | Demande de correction avant expédition | Adresse de livraison validée |
| Délai d'exécution | Opérations | Vérifier l'expédition avant de réessayer | Registre d'entrepôt ou de transporteur |
Questions pratiques
Non. Les cas connus récupérables peuvent réessayer ou résoudre automatiquement dans des limites claires. L'examen manuel est approprié lorsque l'argent, le choix du client, l'état incertain ou le jugement de politique sont impliqués.
Il peut vivre dans la plateforme commerciale, un tableau de bord des opérations, ou un système d'exécution connecté. La partie importante est un propriétaire faisant autorité et un historique complet de l'événement.
Poursuivre l’exploration
Collaborer avec Sun Cluster
Sun Cluster développe des expériences commerciales et les intégrations opérationnelles nécessaires pour gérer les commandes au-delà du paiement.
