J'ai conçu et construit un outil de commande B2B pour Delicorner, avec Airtable. J'ai suivi le projet depuis la phase de discovery jusqu'à celle de delivery.
Une commande, quatre saisies
Delicorner est une entreprise parisienne fondée en 2015. Elle livre des fruits et des snacks aux entreprises.
Le projet couvrait les commandes de Meta, Salesforce et Datadog. Plus de 300 références par semaine, environ 100 000 € par mois. Chaque client avait sa liste de produits négociée, son budget et ses règles de livraison.
Une commande traversait quatre saisies manuelles. Le client remplissait un Google Sheet. Le suivi client recopiait les données dans un second fichier et les ressaisissait dans le CRM interne. À la préparation, l'entrepôt notait les ruptures dans un quatrième fichier, que le suivi client reprenait.
Venait ensuite la comparaison. Le suivi client confrontait à la main les quantités commandées et les quantités livrées, ligne par ligne, pour préparer le reporting.
Chaque saisie ajoutait un risque d'erreur de facturation. Entre sa commande et le reporting, le client ne voyait rien. Et tout le processus reposait sur une seule personne.
Le terrain a tranché
J'ai repris le parcours complet d'une commande (suivi client, achats, logistique). J'ai aussi interrogé le client.
À l'entrepôt, j'ai identifié le décalage principal. Le client commandait à l'unité. L'entrepôt préparait par pack.
Un exemple. Le client commande 55 canettes de soda. Les canettes arrivent par packs de 12. Le préparateur sort 4 packs, soit 48 canettes, ou 5 packs, soit 60. Dans les deux cas, le client ne reçoit pas ce qu'il a commandé. L'écart repart en reporting, et il faut le justifier à la main.
J'ai prototypé l'interface avec Figma Make. Trois règles ont cadré la première version.
- Commander par pack complet. Un conditionnement de 12 se commande par 12 et ses multiples.
- Ne jamais écraser la quantité commandée. La facturation porte sur le livré ; l'écart doit rester vérifiable.
- Une seule base pour les 3 clients, avec des interfaces distinctes. Je l'ai conçue pour qu'elle soit scalable et que d'autres clients sur le même modèle puissent être ajoutés facilement. J'ai écarté des demandes spécifiques pour garder cette portabilité.
De la commande au reporting
Le client commande dans un portail. Le montant évolue en direct. Après livraison, il retrouve l'écart entre commandé et livré.
Il peut aussi activer la récurrence. Sa commande se reconduit à l'identique chaque semaine ; il n'a plus besoin de ressaisir les quantités.
Une fois la commande validée, l'outil génère l'export logistique et les lignes de préparation. Il génère la commande suivante et bascule le portail sur la nouvelle semaine.
Les préparateurs signalent les manquants dans l'outil. Les achats y renseignent la date de réapprovisionnement. Le suivi client reçoit une alerte si cette date dépasse la date de livraison.
Après import des données de livraison, l'outil calcule les écarts avec la commande d'origine. Le reporting est prêt sans travail manuel.
J'ai accompagné le lancement : démo, guide client, point à J+7. J'ai documenté les procédures par rôle pour que les équipes travaillent sans moi.
Cinq à huit heures rendues
Les 3 clients et le suivi client utilisent l'outil au quotidien.
Avant, le suivi client passait 1 à 2 heures par client à préparer le reporting. Ce travail a disparu. Le point hebdomadaire durait 1 heure par client ; il dure maintenant 15 à 20 minutes.
Sur 3 clients, cela rend 5 à 8 heures par semaine au suivi client.
Côté client, la commande se passe seule, le budget se consulte à tout moment et le reporting n'apprend plus rien de nouveau. Moins d'erreurs, plus d'autonomie.