module selecteur commandes origine marketplace / profils employés

[chounpyt]

Bonjour

j'ai l'idée d'un module qui nous serait très utile, et probablement aussi à d'autres boutiques qui travaillent avec les market place ou les marchés internationaux

 

contexte :

multiboutique PS 1.6 : une boutique = une langue = un domaine (catalogue partagé)

interfaçage marketplace : Amazon, et en prévision CDiscount, Boncoin, PriceMinister, Facebook business, Etsy

l'administration des marketplace se fait partie sur le module PS pour la gestion des flux, partie sur le BackOffice PS pour la gestion des commandes, partie sur le backoffice vendeur de la marketplace

un employé par langue pour la gestion commerciale

un employé par marketplace intéressé sur le CA

 

objectif :

QUOI

1- restreindre l'accès des employés au périmètre qui les concerne : soit une ou plusieurs Marketplace, soit une ou plusieurs boutique (la sélection boutique = sélection langue)

2- conserver confidentialité sur la gestion commerciale globale, et contrôler la responsabilité en 'écriture' sur le périmètre de chacun

 

COMMENT

un module de type 'sélecteur' qui prends en compte :

• statut de l'employé (admin, superadmin, préparateur, gestionnaire de clientèle, etc.)
• nom de l'employé
• origine des commandes :
  • Amazon
  • CDiscount
  • PriceMinister
  • Le Boncoin
  • Etsy
  • Facebook
  • autres MKT futures

Si vous êtes intéressé par ce développement, veuillez contacter Didier en MP

Merci de votre intérêt sur notre projet

Didier

site : www.aero-passion.fr

 

[Mediacom87]

Bonjour,

 

Je n'ai pas tout compris mais pour moi, tout se fait déjà.

 

Pour les places de marchés il existe des modules, pour le front en 1 langue = 1 boutique je propose moi même un module.

 

Après les droits de chaque boutique peut se gérer par profil d'employe.

 

Mais peut être que je me trompe et que je n'ai pas bien compris votre demande.

[chounpyt]

bonjour et merci pour avoir répondu, je reformule mon besoin :

- restreindre l'accès d'employés en télétravail gestionnaire de clientèle marketplace et clientèle étrangère (un employé par langue, résidant parfois dans le pays de l'idiome), au seul périmètre qui le concerne

 

il me semble qu'il faudrait 'tagger' les commandes provenant des différents canaux afin que PS puisse faire le tri via un sélecteur,

- commandes Amazon et Cdiscount via le module 'Market Place', on doit pouvoir les tagger lors de l'import

- commandes d'origine Facebook via le module 'Boutique Pro pour Facebook', tagger sur le lien entrant

- commandes d'origine Etsy, Ebay, PriceMinister, Boncoin, Google Shopping, etc.

 

un gestionnaire de profil employé 'avancé' avec un sélecteur à choix multiple sur l'origine des commandes, l'IP des pays d'origine des clients (= sélection sur la langue)

 

un tableau de bord affichant seulement les commandes, le business, les clients en lien, les paniers abandonnés, etc. sur le périmètre de l'employé

 

est-ce compréhensible ainsi

Merci de votre intérêt

Didier

[Mediacom87]

ok, donc en gros une boutique une langue un elmployé

 

donc quel est le soucis et que faut il développer de plus.

 

chaque boutique un un configuration unique et indépendante et donc chaque module, chhaque employé, chaque commandes, chaque panier, chaque client peuvent être attaché qu'une boutique.

 

donc merci de m'expliquer où se trouve le truc qui coince poiur votre projet.

[chounpyt]

je suis déjà en multiboutique : une boutique = une langue

mais

les commandes entrantes provenant des marketplace arrivent dans la boutique pivot (la française) et ne sont pas rattachées à une boutique, elles pourraient l'être sans doute...

mais

je ne souhaite pas déléguer aux employés la gestion commerciale des clients des boutiques PS, seulement les marketplace. Le business model est que ces employés sont rémunérés sur le business résultant de leur implication en veille concurrentielle, suivi des clients, etc. sur les market place.

Les boutiques PS ont leur propre dispositif de promotion,

ainsi

ces employés ne sont pas concernés par l'activité commerciale sur les boutiques PS

 

l'objectif c'est vraiment de définir un périmètre par employé, dont le seul lien avec PS est que les commandes sont importées dans le back-office PS, d'une part pour avoir une vision globale, une gestion globale comptable, une gestion globale des transporteurs,etc.

 

l'import des commandes dans PS permet de 'tagger' les commandes, et d'avoir un monitoring du réalisé via le tableau de bord, tant pour l'employé que pour le manager

[Mediacom87]

Ok je n'ai rien compris.

 

en gros qui vend quoi et fait quoi, car à vous lire les commerciaux ne font rien mais on va les payer sur la base de commandes en provenance de market place mais sur quelle base et qui vend quoi. En gros on tag quoi, sur quelle base et à quel moment ?

 

Prestashop n'est pas du tout un outil de gestion commercial, et donc il a ses lacunes et surtout ses limitation, mais il ne peux pas faire de miracle au moment de l'import des commandes des market place sur quel base faites vous la différence entre les commerciaux ????

[chounpyt]

OK, je vais vous expliquer mon dispositif à partir d'un exemple concret sur Facebook :

• le travail de l'employé c'est d'animer la page FB, de faire du Buzz en écrivant sur les murs des pages ayant un territoire commun, bref de générer de la visibilité puis du trafic vers notre page FB, puis vers notre boutique PS
• techniquement le module 'boutique Pro Facebook' affiche sur FB un clone des catégories et produits de la boutique PS, mais les transactions se font sur la boutique PS
• l'employé est intéressé en % sur les ventes additionnelles recrutées via son travail sur Facebook
• donc, il me faut pouvoir tracer, lister et gérer ces commandes dans le back-office PS
• l'employé n'est concerné QUE par les commandes d'origine la boutique Facebook
• l'employé ne doit voir QUE ces commandes dans l'onglet 'commandes' de PS, des stats elles aussi circoncises à son périmètre Facebook dans l'onglet 'tableau de Bord' lui permettront d'analyser, de se motiver, et d'être managé

bien entendu chaque MarketPlace ayant un back-office accès vendeur spécifique, l'employé y travaillera dessus (Amazon Seller Central par exemple), aussi les fichiers export de mise à jour des offres - stocks - prix

 

chaque MarketPlace ayant des flux entrant dans PS différents, ils seront importés par un module spécifique (vous en avez fait un, Business Tech aussi, etc.) ;

quelque soit le module qui les importe, nous avons bien des commandes importées dans PS, donc mises au format PS pour être gérées par PS, et exportées dans les modules transporteur (nous utilisons DPD par exemple), pour la gestion des expéditions.

 

donc, il doit être possible de 'tagger' ces commandes avec un ID source marketplace, ce qui permettrait avec un 'configurateur de profil employé avancé' de les sélectionner pour définir le périmètre de chaque employé et donc en 'display' de limiter ce qui sera affiché dans l'onglet 'commandes', l'onglet 'tableau de bord', etc.

 

si c'est toujours pas clair, il nous faut peut-être en parler au tél... pour plus de réactivité dans le débat

 

[Mediacom87]

ok, un module à 5 ou 10 mille euro au minimum.

 

mais franchement si vous arrivez à trouver quelqu'un pour vous le développer au prix d'un module à moins de 100€ chapeau, car le potentiel de revente est proche de 0,000000000000001% de chance.

[chounpyt]

Hum...

je ne suis sans doute pas le seul à aller sur les Marketplace, et à interfacer avec PS,

et sans doute pas le seul à envisager de recruter pour suivre le développement de l'entreprise.

 

qui dit recruter, dit 'employés' au sens PS, et donc de définir des droits et de mettre en place des outils de travail.

On est en plein dans dans le dev du commerce numérique et les besoins suggère la création de nouveaux outils.

 

si je ne suis pas seul à avoir ce besoin, c'est qu'il y a un 'marché' pour un module 'configurateur de profil employé avancé'

[Mediacom87]

Je ne dit pas que cela est impossible, juste que j'en doute.

 

Ce que vous souhaitez demande beaucoup de développement et donc pour être rentable sur le cas d'un module revendu il faudrait en vendre plsuieurs centaines pour rentrer dans ses frais et prendre le risque de ne jamais être rémunérer totalement pour cela.

 

Perso je développe souvent des modules pour des demandes clients et je fait le pari de la rentabilité et prend le risque à ma charge. J'ai souvent fait fausse route, non pas que je en connaisse pas le marché mais que les cas particulier d'utilisation particulière de PrestaShop sont rarement rentable.

 

Après, peut être que quelqu'un viendra ici pour satisfaire votre demande mais pour ma part je ne prendrez pas le risque à votre place.

[chounpyt]

Merci d'avoir pris le temps d'avoir donné cet angle développeur / potentiel marché sur ce post,

cette réflexion sera sans doute utile aux autres qui voudront bien y répondre et je l'espère s'investir après avoir fait leur propre opinion sur la pertinence de l'outil.

[Mediacom87]

Une idée comme cela.

 

Ce module ne pourrait il pas repondre à une partie de vos attentes et voir avec le dev si vous souhaitez le faire evoluer.

 

http://www.prestatoolbox.fr/publicite-marketing/380-fidelite-parrainage-affiliation-facebook-le-module-tout-en-un-prestashop.html

[BeComWeb]

Personnellement je dirais qu'avec la richesse et la complexité de vos besoins vous devriez peut-être envisager une embauche plutôt qu'un prestataire.

 

Vous auriez votre développeur, dont une grande partie du travail consisterait à concevoir le(s) module(s) qui réalise(nt) les opérations que vous avez cité, et qui en plus ferait office de "helpdesk".

 

Parce que là sinon vous allez vous retrouver avec des "employés" dispersés géographiquement, plus ou moins à l'aise avec l'outil informatique, qui vont vous remonter des "ça marche pas".

A partir de là (et en supposant que vous ayez trouvé votre module "couteau suisse avec option centrale nucléaire" à 200 € ... ce dont je doute fort) vous vous retrouverez face à un problème : personne ne sera en mesure de répondre à ces demandes.

Même si vous trouvez un freelance ou une agence qui fait le pari de passer des centaines d'heures à développer une telle usine à gaz,  il n'investira pas 3, 5 ou 10h /semaine en plus à expliquer aux gens que si ça ne fonctionne pas c'est parce qu'ils n'ont pas coché une case ou pas cliqué sur un bouton