Démonstration d’un logiciel de livraison : du colis au règlement

1. Le Client crée ou importe le colis

Connectez-vous avec un compte Client de démonstration. Créez un colis avec une référence reconnaissable, une ville, un montant et des coordonnées fictives. Si l’import XLSX fait partie de votre usage, testez aussi un petit fichier comportant une ligne correcte, une ligne incomplète et un doublon.

Vérifiez le message obtenu, le nombre de lignes acceptées et la possibilité de retrouver le colis. Le Client ne doit pas voir les données d’un autre vendeur. Contrôlez enfin les demandes de ramassage et les documents accessibles depuis ce profil.

2. L’Admin reçoit, contrôle et affecte

Dans l’espace Admin, recherchez la même référence. Vérifiez les informations reçues, corrigez une donnée autorisée et observez si l’historique ou le contexte reste compréhensible. Simulez ensuite la réception en agence et l’affectation à un livreur de démonstration.

Le tableau de bord Admin regroupe les colis, bons, factures, réclamations et statistiques. Pendant l’essai, ne vous limitez pas aux compteurs : ouvrez le dossier qui compose l’indicateur et contrôlez les références. Un bon tableau de bord doit conduire aux opérations, pas seulement afficher des chiffres.

3. Le Livreur traite les colis confiés

Ouvrez l’espace Livreur avec le compte prévu. Le livreur doit retrouver les colis affectés, comprendre les actions permises et distinguer un colis livré d’un colis à relancer ou à retourner. Testez l’usage sur téléphone si c’est le support réel du terrain.

Changez le statut des trois colis fictifs selon le scénario. Vérifiez ce qui devient visible dans les autres espaces et comment une erreur de statut peut être signalée ou corrigée. Une réaffectation doit également être testée pour éviter qu’un dossier reste bloqué sur un compte indisponible.

4. L’équipe contrôle les bons, les retours et les réclamations

Pour le colis livré, retrouvez les documents associés. Pour l’absence, vérifiez la prochaine action et la personne responsable. Pour le retour, contrôlez la référence, le motif, la réception et les éventuels frais. Ouvrez aussi une réclamation fictive afin de voir comment elle reste reliée au colis.

Le test est réussi lorsque l’équipe peut expliquer le parcours sans reconstruire l’histoire depuis plusieurs fichiers. Les documents imprimés ou exportés doivent reprendre des informations cohérentes avec l’écran et rester lisibles sur le support prévu.

5. Le règlement COD est rapproché

Prenez le colis livré avec paiement à la livraison. Comparez le montant annoncé, le montant encaissé, les frais et le net attendu. Vérifiez les bons de paiement concernés et la séparation entre les sommes du livreur, celles du client et les montants propres à la société.

Testez un écart fictif avant validation. Le système doit permettre de comprendre la différence, son responsable et la prochaine action. Une statistique globale ne remplace pas ce rapprochement par référence lorsque vous préparez un règlement.

6. La démonstration se termine par une décision

Classez chaque point comme testé, observé ou à confirmer. Les fonctions testées ont été exécutées par votre équipe sur le scénario. Les fonctions observées ont seulement été montrées. Les adaptations, connexions API et documents absents restent à confirmer par écrit dans le devis.

Avant de choisir, relisez les livrables : personnalisation, site vitrine, code source, serveur, hébergement, sauvegarde, formation et support. Demandez une seconde démonstration uniquement sur les écarts importants. Cette discipline réduit les malentendus sans prétendre éliminer tout incident de mise en service.

Consignez enfin les questions restées ouvertes, le nom de la personne qui doit répondre et la date de décision. Une capture seule ne prouve pas qu’un parcours fonctionne ; gardez la référence testée et le résultat obtenu. Si plusieurs personnes participent au choix, faites valider la synthèse par les profils réellement concernés avant de comparer les offres.

À vérifier avant de valider

• Utiliser uniquement des comptes et des données fictives pendant les essais.
• Relier chaque besoin à une action, un profil et un résultat observable.
• Inscrire au devis les adaptations, l’API, les durées et les livrables qui ne sont pas déjà démontrés.

Questions fréquentes

Peut-on tester la démonstration avec de vraies données clients ?

Il vaut mieux utiliser des données fictives. Vous vérifiez les mêmes fonctions sans exposer de coordonnées, de montants ou d’accès réels.

Pourquoi tester les trois profils ?

Parce qu’un parcours réussi côté Admin peut rester incompréhensible côté Client ou Livreur. La même référence doit rester cohérente tout en respectant les droits de chaque profil.

Une démonstration suffit-elle avant l’achat ?

Non. Elle prépare la décision. Le devis, les conditions de l’offre et la recette de la version installée doivent ensuite confirmer le périmètre réellement livré.