Réponse directe
Avec un seul transporteur, une feuille ou le portail prestataire peut suffire. Dès que plusieurs prestataires coexistent (selon les intégrations configurées et disponibles pour le compte — ex. Truship, Coliaty, Siftly, Rushliv, Speedex), une interface unique évite les statuts éparpillés — à condition d’accepter que la mise à jour passe par polling / sync configurée, pas par webhook temps réel garanti pour tous. ERP-STOK centralise le suivi livraison sans être transporteur.
Modèle A — une feuille (ou onglet) par transporteur
Chaque prestataire exporte ses statuts ; l’équipe recolle manuellement ou via VLOOKUP.
Avantage : coût logiciel nul au départ. Inconvénient : retards, doublons tracking, aucune vue commande ↔ colis ↔ stock.
| Critère | Feuille par transporteur |
|---|---|
| Setup | Rapide si un seul prestataire |
| Multi-transporteurs | Friction croissante (N exports) |
| Lien confirmation | Absent — copier-coller manuel |
| Stock au ramassé | Non automatisé sans script maison |
| Fraîcheur statut | Dépend de la discipline humaine |
Modèle B — interface unique multi-transporteurs
Les commandes confirmées partent via l’API du prestataire choisi parmi les intégrations configurées et disponibles pour le compte ; les statuts remontent par jobs de polling selon la config du tenant.
Une seule file « En livraison » avec tracking, ville et statut normalisé côté ERP — pas côté Excel.
| Critère | UI ERP-STOK multi-transporteurs |
|---|---|
| Setup | Configurer chaque intégration + villes |
| Multi-transporteurs | Vue unifiée par commande |
| Lien confirmation | Enchaînement natif post-confirmer |
| Stock au ramassé | DeliverySaleService au pickup |
| Fraîcheur statut | Polling — pas temps réel universel |
Ce que « multi-transporteurs » n’implique pas
ERP-STOK n’expédie pas physiquement : il parle aux APIs configurées.
Pas de promesse que tous les transporteurs marocains sont disponibles : la liste dépend des intégrations activées sur votre compte.
Le suivi n’est pas instantané par défaut : comptez sur des synchronisations périodiques.
Quand passer du modèle A au modèle B
Deux transporteurs ou plus, plus de 30 envois/jour, ou besoin de relier suivi et déduction stock : la feuille unique devient un goulot.
Si vous devez aussi analyser taux livraison par ville (COD Insights), l’UI centralisée évite de re-saisir les statuts.
- Lister transporteurs actuels et volumes par ville.
- Vérifier quelles intégrations API existent dans l’outil candidat.
- Tester un envoi + sync statut + ramassage sur chaque prestataire.
- Comparer délai de fraîcheur polling vs votre SLA interne.
Exemple fictif illustratif — « Nour Express Shop »
« Nour Express Shop » (exemple fictif) utilisait un Google Sheet onglet « Truship » et un onglet « Coliaty ». Les agents SAV perdaient 45 minutes/jour à recoller les statuts « livré » avant de clôturer le COD. Après centralisation ERP-STOK, chaque commande affiche tracking et statut dans « En livraison » ; le ramassé du prestataire configuré déduit le stock sans ressaisie. Le polling met à jour les statuts selon la sync du compte — pas en push instantané — ce qui reste suffisant pour une équipe de 6 personnes dans cet exemple.
ERP-STOK pour le suivi multi-transporteurs
Envoi via les intégrations configurées et disponibles pour le compte (ex. Truship Delivery API selon activation), file livraison unifiée, sync statuts par polling, lien ramassage → vente stock.
COD Delivery Insights complète la vue performance ville/produit — sans transformer ERP-STOK en société de livraison.
Pour conclure
Le bon choix dépend du nombre de transporteurs et du lien souhaité avec confirmation et stock. Multi-prestataires sans interface unique = feuilles qui divergent ; avec ERP-STOK = une commande, N trackings, sync par polling.
Limites et points d’attention
- Disponibilité intégrations selon tenant et plan.
- Pas de webhook temps réel universel revendiqué.
- Libellés statut normalisés côté ERP, pas identiques au portail transporteur.