Paraurelien

une holding, des commerciaux et pas de personnel

Pour la petite histoire, tout commence avec un entrepreneur, nous l’appellerons M, qui souhaite monter une société, qui commerciale des produit pour professionnel, mais qui souhaite ne pas assurer la partie commerciale, se décharger des livraisons vers les clients, et ne pas assurer la production…En gros, un gars qui souhaite gagner sa vie sur les flux, mais sans assurer un quelconque service ,suivi et/ou gestion.

Nous avons donc imaginé une solution, pour en arriver la…

Pour commencer, pour vendre, il est nécessaire d’avoir quelques choses a vendre. M conclu donc avec quelques fournisseurs (nous les appellerons F) un contrat, organisé comme suit. Lui vend à ces clients les produits de ces fournisseurs, et transmet aux fournisseur l’adresse de ces clients. C’est donc les fournisseurs qui livrerons les clients de M, avec un BL au nom de M.

Ensuite M ne souhaite pas non plus s’occuper de la vente, il organise donc le recrutement de commerciaux C qui travaillerons à leur compte, et qui auront un fournisseur unique M. Dans cette approche l’ensemble des commande client de C,  bascule automatiquement en commande fournisseur et remonte vers M avec bien sur une adresse de livraison qui est celle du client C.

Dans cette organisation, chaque commerciaux C à son propre dolibarr, l’ensemble de ces dolibarr font transiter en automatique les commande des C vers le dolibarr de M qui lui même fait transiter au automatique vers les fournisseur F. Les factures suivent le chemin inversent.

Dans ces maillage, le CRM de M ne fait donc qu’assurer la transition des échange entre les commerciaux C avec les fournisseur F.

La liaison avec les fournisseurs F

L’ensemble des liaisons avec les fournisseurs sera automatisé à travers plusieurs processus en fonction des choix technique propre à chaque fournisseur.

• F1 se connectera sur le dolibarr de M, avec ces identifiant, et obtiendra la liste (en CSV) de ces commandes  avec une petite évolution du module d’export
• F2 lui utilisera directement le dolibarr de M pour produire les BL (quelque peu modifié) des commandes en cours
• F3 obtiens un email via les notifications
• F4 reçois en flux EDI qui lui permet d’intégrer directement les commandes dans son propre système informatique

Lors d’une commande client passé sur le dolibarr de M, celle ci est ventilé chez l’ensemble des fournisseurs en fonction de leur produit avec comme adresse de livraison les coordonnées du client.

La Liaison avec les commerciaux C

La construction des liaisons  de l’environnement des commerciaux C consiste a produire ventiler en commande fournisseur la validation d’une commande client.  Et lors de la validation de la commande fournisseur, provoque la transmission en edi vers le dolibarr de M.

L’ensemble des plateformes de commerciaux sont donc connectés a la Plateforme de M , lui meme connecté au fournisseur  F.

La  plateforme de M

la plateforme de M est donc en place, est permet de suivre et d’apprecicé l’ensemble de l’activité, sans aucune activé réel en dehors de la gestion. Pas de vente, pas de stock, uniquement une gestion commercial avec les C et des negociations et gestion des prix d’achat avec F

Paraurelien

Un suivi des demandes de support, appel de M.Claude

Hier, quelques rayon de soleil, à la terrasse d’un café avec quelques amis, avec quand même une grosse écharpe (à 8h30, il ne fait pas encore bien chaud.. ) ; Et un coup de fil d’un client…!

Bonjour M.Claude, … Comment, un suivi de vos demande de support, bien sur, avec Dolibarr ? bien entendu  A ce moment de la conversation, bien sur, mes habitudes de développeur un peu parano m’amène à poser la question : Vous imaginer donc que en utilisant un service de ticket directement sur votre dolibarr serait la solution ? Mais dans ce cas, vous rendez vous compte que l’adresse de votre dolibarr devient public, et que dans ce cas, l’ensemble de votre outils prend le risque d’être en frontal sur internet.. .

M.Claude réfléchit quelques instant, puis me demande alors si il existe des outils de suivi; Bien sur M.Claude, ce type d’outils est pléthore, nous resterons bien entendu sur les même technologique que celle de votre ERP (donc LAMP php/sql) . Oui ?

La conversation s’oriente donc vers la mise en œuvre d’une solution de ticket, avec une partie public un peu sexy, afin de l’habiller simplement dans le même thème que le site de M.Claude. Et soudain, M.Claude me demande alors : Mais comment permettre de perdre moins de temps quant au réponse toujours identique et répétitive.. Et bien, plusieurs possibilité s’offre à vous, un premier mail détaillant certaine procédure, une FAQ sur votre site, ou une base de connaissance sur votre outils de ticket basé sur le retour de vos équipes et des questions  les plus courantes…

M.Claude décide alors de préférer la solution de base de connaissance, celle ci se construisant sur le terreau réel des questions/ réponse posées.

M.Claude s’interroge ensuite sur les procédures automatisé adossé à un outils de ce genre; envoi d’émail automatisé, réponse à l’émail, suivi des messages par les clients. L’ensemble de ces points affinant grandement le choix de l’outil.

Nous arrêtons donc le choix, après une bonne dizaine de minutes sur un helpdesk en php/sql, fournissant une base de connaissance, et assurant le suivi des tickets, et plusieurs fonctionnel d’automatisation.

M.Claude m’invite donc à revenir vers lui avec un chiffrage et un délai.

Resté seul en terrasse, après le troisième café pour ne pas geler sur place, je me dis que la terrasse n’était pas la meilleur idée du jour.. 6°.. . De retour au bureau, j’attaque la petite proposition. De notre coté, nous avons un petit faible pour osTicket. Ce sera donc lui… Pour le couplage avec dolibarr, nous utiliserons notre connecteur d’api maison à greffer sur osticket (celui d’origine n’étant pas assez abouti). le cahier des charge étant donc respecté, le dolibarr restant caché, le frontend sera donc l’outil de ticket.

Pour l’intégration coté dolibarr, nous faisons donc le choix de travailler uniquement sur le socle de l’api, et de ne rien stocker en base afin de limiter les probleme ( pas de synchronisation). Nous définissons donc la capacité de créer un ticket lors de l’appel d’un client avec un simple bouton depuis la fiche client ou celle du contact, et de lister les ticket déjà ouverts.

Enfin notre module fournira une liste triable, avec champ de recherche, et une boxe des ticket ouvert et/ou en retard.

Quelques jours plus tard, M.Claude reviens vers nous, satisfait de la réponse, qui prend en compte à la fois la sécurité de ces données, la conservation de technologie proche simplifiant les rapprochements, une interface public pour les clients un peu sexy..

La réalisation de ce dossier se passera sans heurt notable. le suivi du support apporte une réel valeur ajouté à M.Claude qui lui permet donc de quantifier le temps passé, le nombre de demande par client, et de facturer le cas échéant l’abus ou les services complémentaire. La base de connaissance lui permet de limiter 1/10 de ces appels intempestif.

Vous voulez installer un osTicket dans un Dolibarr : contactez-nous !