Je dirige une organisation décentralisée où chaque département a toute autorité pour conclure des partenariats avec d’autres organisations. Nous avons cependant besoin d’un moyen de partager des informations sur nos relations avec les partenaires entre les différents départements, afin de garantir une approche cohérente envers chaque partenaire, même si celui-ci interagit avec plusieurs départements.
Habituellement, une organisation utilise un CRM et forme ses collaborateurs à toujours consigner les appels et les messages avec tout partenaire organisationnel. Cependant, je souhaite limiter au maximum le nombre de systèmes que nous devons utiliser. Quelqu’un a-t-il personnalisé Discourse pour en faire un CRM léger dédié aux partenaires organisationnels ? Et si oui, comment ?
Mon idée actuelle est de créer une catégorie « Partenaires » où chaque partenaire se voit attribuer un sujet. Cette catégorie disposera d’un modèle de sujet demandant des informations sur chaque partenaire, notamment les départements avec lesquels ils sont en relation. Ensuite, les personnes devront toujours rechercher un partenaire potentiel dans cette catégorie en premier et consulter notre historique avec ce partenaire avant de prendre contact si elles souhaitent établir une nouvelle relation.
Je peins à rendre ce comportement fluide et je me demande s’il existe d’autres solutions potentielles que je n’ai pas encore envisagées. Notre solution actuelle est un Google Sheet qui nous permet de suivre le statut de chaque partenaire dans notre processus de partenariat et de parcourir rapidement la liste pour nous assurer de ne rien oublier. Nous pouvons également filtrer par département, ce que je ne suis pas sûr de pouvoir faire si nous passons à ce nouveau système.
C’est à peu près ce à quoi je pensais. Vous pourriez demander au département d’enseignement d’étiqueter ses sujets avec le tag de son département, afin que vous puissiez effectuer des recherches par ces tags. Vous pouvez demander à Discourse d’imposer le choix d’un tag.
C’est un peu lourd, mais les systèmes CRM que j’ai (à peu près) vus semblent tous pires (dit le type qui gagne sa vie avec Discourse).
Comment systématiser la mise à jour des informations par les personnes ? Y a-t-il des pratiques que tout le monde suit ? Et quelles informations sont attendues dans le sujet, et lesquelles ne le sont pas ?
J’envisageais cette option, mais chaque département possède déjà sa propre catégorie, je suis donc très réticent à utiliser exactement les mêmes noms comme tags. Je me demande s’il existe un moyen de rechercher les noms des catégories de départements au sein de la catégorie partenaires et de générer une liste de sujets. Est-ce que je complique les choses inutilement ?
Peux-tu transformer « partenaire » en étiquette plutôt qu’en catégorie ? Dans ce cas, la principale différence entre les deux pourrait être que, avec les étiquettes, tu as moins de contrôle sur l’expérience de navigation ou d’atterrissage sur la page de catégorie/étiquette et dans les listes de catégories/étiquettes, mais dans ton cas, cela ne semble probablement pas important.
C’est toujours ainsi que cela s’est passé, donc tout le monde sait où trouver le sujet contenant les informations sur chaque client et doit également mettre à jour ce sujet si nécessaire. Il y a aussi la contrainte de devoir chercher à plusieurs endroits pour obtenir des informations ; vouloir éviter cette contrainte constitue une motivation.
En plus de ce qui précède, certains membres de l’équipe sont chargés des relations clients. En tant que gestionnaire de communauté, cela aiderait à réorganiser les publications de la communauté au bon endroit, et ils font de même.
En résumé, c’est une habitude déjà établie, il est donc facile de la maintenir.
Cela ne fonctionnerait pas pour nous, car le sujet des partenaires devrait alors être placé dans l’une de nos catégories de département, alors que tout l’intérêt est qu’un partenaire puisse travailler avec plusieurs départements simultanément. Je pense qu’il est vraiment plus logique d’avoir une catégorie « partenaires » distincte.
Quels étiquettes utilisez-vous ? J’ai surtout du mal avec l’idée d’avoir des étiquettes de département alors que nous avons déjà des catégories de département. J’envisage également d’utiliser nos étiquettes de statut de projet pour suivre les partenaires depuis la phase d’idée jusqu’à la phase de compréhension, etc.
Bonne idée. Quelles sont les directives spécifiques que vous appliquez ?
Deborah, en lisant votre idée, qui semble bonne, cela me conduit à suggérer de faire du premier message un « message wiki ». Pour moi, il serait plus logique de rassembler toutes les informations dont chacun a besoin, à jour, dans le premier message, plutôt que de devoir lire l’intégralité du sujet (qui peut devenir long avec le temps). Vous conservez le sujet pour la discussion et/ou l’ajout de détails, et vous rapportez tout ce qui est important dans le premier message. Il vous « suffit » de mettre en place les bonnes procédures pour que cela fonctionne.
Note : C’est ainsi que l’équipe de Discourse procède ici sur meta pour certains sujets. Cela semble être une bonne méthode.
Hum, je suppose que, fondamentalement, oui ! Cela s’appellerait… une recherche ;), non ?
(Recherchez le nom du département souhaité en restreignant cette recherche à la catégorie partenaires)
Peut-être que c’est cela qu’il faut céder. Si vous placez ces éléments dans un groupe d’étiquettes, vous pourriez peut-être les rendre inaccessibles en dehors de la catégorie des partenaires.
Nous utilisons une balise générale pour marquer les projets clients, et tout s’inscrit dans une catégorie commerciale plus large.
Nous n’imposons ni n’appliquons rien au sens habituel. Nous avons la chance de faire partie d’une équipe où nous partageons tous des valeurs similaires, comme une communication appropriée et une organisation claire de l’information. Ainsi, tout fonctionne naturellement.
Je crois que cela s’explique par le fait que chaque membre de l’équipe a déjà eu une expérience avec des communautés, et comprend donc la nécessité de tout maintenir correctement trié et structuré.
Je ne sais pas si cela aide, mais nous avons créé une ontologie qui pondérait les probabilités pour un ensemble donné de besoins ou de résultats spécifiques, ce qui nous a permis d’utiliser un système de balisage de métadonnées comme discuté par @JonathanShaw@pfaffman.
