18 — Commandes

1. Objectif métier

Piloter la commande client de manière fiable du début à la fin, avec un suivi clair pour l’équipe et une communication propre pour le client.

Ce module vise à:

créer des commandes exactes,
suivre un cycle de statuts cohérent,
limiter les erreurs de traitement,
notifier le client aux moments utiles,
améliorer la performance opérationnelle (délai, annulation, satisfaction).

2. Qui utilise ce module (admin/operator)

admin: définit les règles de traitement (statuts, contrôle qualité, discipline opérationnelle).
operator: crée et met à jour les commandes, traite les exceptions, informe le client.

Répartition recommandée:

l’admin fixe les standards,
l’opérateur applique les standards sur chaque commande.

3. Prérequis

Checklist avant exploitation:

catalogue propre et à jour,
contacts valides,
politique on_site vs delivery clarifiée,
frais de livraison standard définis,
politique de notification client validée,
procédure d’annulation/incident partagée par l’équipe.

Contraintes métier à respecter:

une commande doit contenir au moins un item,
chaque item doit exister et être disponible,
le total doit être cohérent avec les quantités et frais,
le type de commande (on_site ou delivery) doit être correct,
les statuts doivent être mis à jour au fil du réel, pas en fin de journée.

4. Procédure pas-à-pas (orientée actions produit)

Préparer la prise de commande.

Identifier le contact.
Vérifier rapidement la disponibilité des items demandés.

Créer la commande.

Ajouter les items et les quantités.
Ajouter une note opérationnelle courte si utile.

Choisir le mode de commande.

on_site: pas d’adresse de livraison.
delivery: adresse obligatoire et frais cohérents.

Valider les montants.

Vérifier le sous-total items.
Vérifier les frais de livraison.
Vérifier le total final avant validation.

Démarrer le traitement.

Laisser pending tant que la commande n’est pas validée côté équipe.
Passer confirmed dès validation opérationnelle.

Suivre la production.

Passer preparing au démarrage réel de la préparation.
Mettre à jour sans retard pour garder une visibilité fiable.

Clôturer ou annuler.

Passer completed à la fin.
Passer cancelled avec motif en cas d’annulation.

Informer le client aux moments clés.

Confirmation.
Changement important.
Clôture ou annulation.

Traiter les exceptions.

Produit indisponible.
Adresse incorrecte.
Erreur de quantité.
Changement client en cours de traitement.

Revue opérationnelle hebdomadaire.

commandes annulées,
délais anormaux,
causes de retouches,
qualité des notifications.

5. Scénarios concrets (minimum 2)

Scénario A: commande livraison standard. Objectif: exécution fluide. Action: création delivery, validation des frais, passage confirmed puis preparing puis completed. Résultat attendu: commande livrée sans correction manuelle.
Scénario B: item indisponible après création. Objectif: éviter l’annulation totale. Action: contacter le client, proposer alternative, ajuster la commande, notifier le nouveau total. Résultat attendu: conversion maintenue malgré rupture.
Scénario C: annulation côté client. Objectif: préserver la traçabilité. Action: statut cancelled, motif documenté, notification envoyée. Résultat attendu: reporting fiable et cause d’annulation exploitable.

6. Erreurs fréquentes et résolution

Erreur: création impossible. Cause fréquente: panier vide, contact invalide, item inexistant. Résolution: valider prérequis contact + items avant création.
Erreur: total incohérent. Cause fréquente: quantité erronée ou frais mal appliqués. Résolution: recalcul complet avant confirmation.
Erreur: commande oubliée en pending. Cause fréquente: absence de rituel de suivi. Résolution: mettre une revue horaire des commandes en attente.
Erreur: client non informé d’un changement. Cause fréquente: statut mis à jour sans notification. Résolution: rendre obligatoire la notification sur changement significatif.
Erreur: trop d’annulations tardives. Cause fréquente: confirmation trop rapide sans validation réelle. Résolution: confirmer uniquement après contrôle de faisabilité.

7. Bonnes pratiques et limites

Bonnes pratiques:

adopter une séquence de statuts unique et partagée,
définir un délai maximal autorisé par statut,
standardiser les motifs d’annulation,
utiliser des notes courtes orientées action,
traiter les commandes sensibles en priorité (montant élevé, client VIP, délai court).

Limites à connaître:

le système ne remplace pas la discipline opérationnelle de l’équipe,
les notifications dépendent de la qualité des données contact,
un changement tardif sur une commande déjà en préparation reste coûteux,
des transitions de statut non homogènes faussent le pilotage.

8. Référence rapide (champs/statuts/modes)

Statuts commande:

pending: créée, en attente de validation.
confirmed: validée pour traitement.
preparing: en préparation.
completed: terminée.
cancelled: annulée.

Types de commande:

on_site: retrait/consommation sur place.
delivery: livraison avec adresse.

Champs clés:

contact,
type de commande,
items,
quantités,
note,
sous-total,
frais de livraison,
total,
statut.

Repère de gouvernance conseillé:

révision toutes les 2 heures des pending.
révision quotidienne des cancelled.