Modèles de propriété communautaire

Je réfléchis à la propriété communautaire et aux modèles opérationnels, et je suis intéressé d’en savoir plus sur la place de la communauté au sein de votre organisation.

Il existait autrefois des écoles de pensée claires mais disparates : d’un côté, l’idée qu’une équipe communautaire devrait être une unité autonome et autogérée ; de l’autre, le fait qu’il soit plus logique de dépendre d’un autre département.

J’ai mon opinion, mais je n’ai jamais travaillé comme CM (Community Manager) au sein d’une grande entreprise. Je suis curieux de savoir ce que vous en pensez, vous qui le faites (ou l’avez fait).

Je pense que ma position actuelle est que dans les petites organisations, ou celles où la communauté ne sert qu’un seul département, il est logique de dépendre de ce département.

Par exemple :

Objectif communautaire Dépend de
Réduction des tickets de support Support
Acquisition, plaidoyer ou événements Marketing
Retours produit, tests, idées Produit

Alors que les communautés à l’échelle de l’entreprise, qui servent de nombreux départements, sont probablement mieux servies par un leadership autonome. À condition que le département ne devienne pas une tour d’ivoire et qu’il y ait une gouvernance transversale solide, cela semble être le moyen le plus efficace d’éviter trop de priorités concurrentes entre les parties prenantes.

Ces données du Community Roundtable semblent conclure que l’approche indépendante se développe parmi leurs répondants, dont environ 30 % proviennent d’organisations de plus de 1000 employés.

Quels avantages ou défis rencontrez-vous directement en raison de votre modèle de propriété et de gouvernance communautaire ?

9 « J'aime »

Je suppose que je vais commencer par la première réponse :zany_face:

Dans mon rôle actuel, l’équipe communauté est intégrée au service marketing, et je pense qu’il y a de réels avantages à cela. Cela nous permet d’avoir un lien fort avec le positionnement, les lancements, le contenu, l’advocacy et le récit plus large que l’entreprise cherche à transmettre.

Mais j’ai toujours eu le sentiment que la communauté n’est pas du marketing traditionnel. Il y a évidemment des recoupements, mais la logique de fonctionnement derrière chacun est différente. Par exemple, ce qui fonctionne dans un entonnoir d’acquisition ne fonctionne pas nécessairement au sein même de la communauté. Parfois, la bonne décision n’est pas celle qui génère le plus d’engagement immédiat ou de valeur pour la campagne. Parfois, il s’agit d’écouter, de ralentir, de créer de l’espace pour les retours, ou de protéger la confiance, même lorsque celle-ci est plus difficile à mesurer.

Pour moi, le plus grand défi de l’intégration au service marketing est de s’assurer que la communauté ne se résume pas à « un autre canal ». Parce que la communauté n’est pas simplement un autre public auquel diffuser des messages.

Je pense que ce modèle fonctionne le mieux lorsque l’équipe communauté a l’autonomie pour prendre des décisions centrées sur les membres, tout en restant étroitement connectée aux équipes qu’elle sert.

Dans l’ensemble, je ne suis pas sûr que la réponse soit « la communauté devrait être intégrée au service X ». Je pense que la question plus importante est de savoir si l’organisation donne à l’équipe communauté le mandat, l’accès et la confiance nécessaires pour opérer transversalement entre les départements. Cela dit, je n’ai travaillé que dans des communautés à l’échelle de grandes entreprises, mais je comprends que pour les petites communautés, il soit logique qu’elles soient rattachées au service auquel elles servent principalement. Mais dès lors que la communauté sert simultanément le marketing, le produit, le support, le succès client et la formation, je comprends pourquoi une direction de communauté plus indépendante devient précieuse.

Sinon, le risque est que la communauté soit façonnée par le service qui la « possède », plutôt que par les besoins réels de la communauté.

9 « J'aime »

Je suis d’accord. Au niveau le plus fondamental, les communautés fonctionnent comme un canal d’acquisition en haut de l’entonnoir, mais une relation de confiance plus complexe doit être gérée une fois que les membres y sont.

D’accord, c’est là que le modèle peut s’effriter.

Je comprends que vous avez une équipe communauté entièrement autonome qui rapporte fonctionnellement au marketing. Si c’est le cas, comment définissez-vous les limites ou résolvez-vous les conflits d’intérêts si l’équipe marketing souhaite faire quelque chose que vous ne considérez pas comme centré sur les membres ?

Et si votre communauté est conçue pour servir les objectifs marketing, rencontrez-vous des difficultés à gérer les demandes des parties prenantes de différents départements ?

6 « J'aime »

Votre hypothèse est en grande partie correcte, avec une petite réserve.

Nous sommes bien intégrés au service Marketing, donc je ne dirais pas que nous sommes entièrement autonomes au sens d’« unité commerciale indépendante ». Mais fonctionnellement, nous avons une bonne dose d’autonomie dans la façon dont nous gérons la communauté au quotidien, protégeons le ton de l’espace et décidons de ce qui convient ou non aux membres.

La limite, c’est que la communauté peut soutenir les objectifs commerciaux, mais elle ne peut pas simplement devenir un outil de livraison pour ceux-ci.

Lorsque des demandes arrivent, (qu’il s’agisse d’une campagne marketing, de conversations de recherche, etc.), ce n’est généralement pas un oui ou un non immédiat. C’est plutôt : quelle est la valeur pour les membres ici ? Est-ce l’espace approprié pour cela ? Le cadrage correspond-il à la relation que nous entretenons avec la communauté ? Souvent, les réponses sont « oui, mais pas sous ce format », « oui, mais nous devons aborder cela différemment », « pas sur ce canal » ou « pas avant d’avoir posé les bases ».

Lorsque les demandes ne sont pas « centrées sur les membres », c’est généralement parce que le cadrage n’est pas bon.

Beaucoup de nos équipes voient de la valeur dans la communauté, ce qui est une bonne chose, mais chaque « petite demande » de chaque équipe peut rapidement devenir une expérience bruyante ou extractive si elle n’est pas gérée avec soin.

De la même manière que nous faisons confiance à nos autres équipes pour connaître leur domaine d’expertise, elles comprennent aussi que nous connaissons le nôtre — si nous devons trouver des moyens créatifs de soutenir quelque chose, nous le ferons.

Mais la santé de la communauté doit rester ce qui lui donne de la valeur.

7 « J'aime »

Je suis tout à fait d’accord avec ces deux points. Un défi majeur qui en découle est la nécessité d’aligner autant de personnes aux intérêts si contradictoires, pour ne pas mettre votre propre carrière en péril :

  • Mécontenter votre responsable et les budgets/demandes deviennent compliqués
  • Mécontenter vos utilisateurs et les chiffres chutent, les plaintes atteignent votre responsable, donc vous avez maintenant mécontenté votre responsable, ce qui signifie que les budgets/demandes deviennent compliqués
  • Mécontenter les pairs de votre responsable et vous finissez dans des réunions avec des gens qui pensent comprendre le sujet et exigent que vous fassiez des choses qui n’ont aucun sens. Si votre responsable connaît les communautés, ce n’est pas trop grave. Si votre responsable ne connaît pas les communautés, alors vous allez devenir vraiment bon en PowerPoint en essayant d’éduquer ces gens-là
  • Mécontenter le supérieur de votre responsable et… eh bien, vous voyez l’idée

Alors, qui est le mieux placé pour gérer la Communauté au niveau de l’entreprise ?

À mon avis : le côté extérieur devrait être géré par le Service Client, et le côté intérieur devrait être géré par une équipe qui s’étend à travers l’entreprise sous une forme de rôle de soutien : DevOps, IT, ou Gestion de la Formation et des Connaissances. Et si votre communauté est à la fois intérieure et extérieure, je mettrais en place un Département Communauté spécifique qui serait essentiellement un mélange de représentants du Service Client, du Produit, etc. Cela offre le meilleur des deux mondes : un leadership autonome de la part du Responsable de la Communauté, et une gouvernance transversale provenant du creuset de représentants des départements.

Vous avez peut-être remarqué que j’ai omis le Marketing, le propriétaire le plus courant des communautés, de ma liste. Personnellement, je ne suis pas fan des communautés gérées par le marketing. Je ne ressens simplement pas que ces communautés soient dans mon meilleur intérêt. Je veux dire, comment pourraient-elles l’être ? L’objectif du Marketing est de trouver/attirer des personnes qui pourraient acheter le produit, et cela signifie régulièrement « convaincre les gens d’acheter notre produit même si ce n’est pas la meilleure option pour la personne ». Pas toujours, mais assez souvent pour que je les approche avec un niveau de scepticisme préjugé.

Le support client, en revanche, j’adore le voir comme une communauté : voici un lieu qui est géré par des personnes dont la raison d’être est d’améliorer mon expérience en tant qu’utilisateur/client. Si une communauté est tournée vers l’extérieur, je la mettrais entre les mains du Support Client – avec l’exigence qu’ils construisent également une relation vraiment bonne et étroite avec l’équipe produit.

3 « J'aime »

C’est un point de vue intéressant. Chez Discourse, Meta relève du Marketing.

Notre position en matière de « marketing » est que si nous utilisons cette communauté pour aider les gens à mieux réussir avec Discourse, elle devient un outil de rétention.

1 « J'aime »

Intéressant. Si l’objectif est la rétention (qui fait partie du Marketing), mais que l’activité réelle relève principalement du Support Client, quelle distinction fait que la responsabilité appartient au Marketing plutôt qu’au Support Client ? La responsabilité ne reviendrait-elle pas plus logiquement au Support Client, étant donné qu’il est plus actif, ou le Support Client relève-t-il du Marketing en termes hiérarchiques ?

Par exemple, est-ce que la hiérarchie typique qui attribue la responsabilité au Marketing ressemble à ceci ?

graph TD
    HOM[Directeur Marketing] --> MCE[Responsable Réussite Client/Support]
    HOM --> MM[Responsable Marketing]
    HOM --> MS_MGR[Responsable Ventes]
    HOM --> CONTENT[Responsable Contenu/SEO]
    MCE --> CSS[Équipe Support Client]
    MM --> MKT_STAFF[Équipe Marketing]
    MS_MGR --> SALES_STAFF[Équipe Ventes]

N’oubliez pas que nous ne sommes pas une organisation de type « Enterprise » et que notre effectif est assez réduit ; ce n’est donc pas nécessairement la manière dont je concevrais les choses si nous avions plus de personnel, mais je ne pense pas que la hiérarchie de reporting changerait beaucoup.

« Support » désigne Taylor et nos ambassadeurs techniques, qui opèrent principalement via les boîtes de réception des équipes sur Meta. « Customer Success » (Succès client) désigne Chau et son équipe, qui accompagnent nos clients Enterprise via leurs catégories privées. Le Marketing détient la stratégie, mais gère la charge de travail via d’autres départements.

Nous n’avons plus de personnel communautaire à temps plein depuis le départ de Tobias, donc cette structure concerne davantage la gouvernance et la prise de décision que tout autre aspect. Danielle (CS) est en charge, avec le soutien de Mae (Directrice Marketing) et de plusieurs autres personnes en interne (moi y compris).

Est-ce vraiment le cas ? Je dirais plutôt que ce que nous faisons sur Meta est un mélange de « Customer Success » (via les catégories privées) pour les acheteurs, et de support « DevRel » (principalement la communauté OS) pour les développeurs. Notre équipe support passe très peu de temps à accompagner la communauté sur Meta en dehors des boîtes de réception des équipes, de sorte que la communauté s’autosuffit dans une certaine mesure.

Meta n’est pas conçu comme un outil de déviation de tickets, car la majorité des personnes cherchant de l’assistance ne sont pas nos clients.

1 « J'aime »

Hmmm, je suppose que c’est un aspect assez clé et cela m’a donné une tout autre façon de voir les choses. Parce que Discourse est gratuit et open source, je considérais toujours les utilisateurs de Meta comme des clients. Mais d’un autre côté, la plupart ne paient pas, donc techniquement, ils ne sont pas des clients.

Et je suppose que cette définition trace une ligne assez efficace en termes de clarification des responsabilités : La majorité des utilisateurs paient-ils pour le produit ? Oui — Service client ; Non — Marketing.

2 « J'aime »

À mes yeux, notre stratégie s’est plutôt imposée au fil des ans.

Au début, elle était principalement alignée sur le produit : nous voulions à la fois :

  • tester notre propre produit en interne et
  • recueillir les premiers retours sur les fonctionnalités auprès des utilisateurs open source

En contrepartie, la valeur apportée aux utilisateurs (clients, au sens large) était :

  • le soutien de l’équipe et de la communauté
  • la possibilité d’influencer la direction du produit

Je pense que ces éléments constituent toujours le fondement de cette communauté.

(Nous utilisons également ce site pour communiquer avec les clients (payants), mais une grande partie de ces échanges se fait via des canaux privés (messages personnels ou catégories privées). Je vais laisser cela de côté pour l’instant (excusez les parenthèses imbriquées)).

Je pense qu’un autre cas d’usage qui est apparu de manière organique est la « rétention » et le « plaidoyer » (advocacy). Là encore, l’objectif initial était principalement de servir les clients non payants, mais en effet secondaire, la communauté apporte également cette valeur aux clients payants.

Plus récemment, nous avons mis l’accent sur la façon dont la communauté peut soutenir la viabilité et la croissance de l’entreprise. Indirectement bien sûr, cela profite aussi à la communauté open source.

Mais nous voulons nous assurer que la communauté sert bien les clients payants, ainsi que les clients potentiels qui cherchent à prendre la meilleure décision concernant le choix d’une plateforme. Je dirais que la rétention et le plaidoyer sont les objectifs les plus étroitement alignés avec cela.

Il y a beaucoup de chevauchement en termes d’alignement avec deux départements de l’entreprise : le Marketing et le Customer Success (Succès Client).

Sur l’organigramme actuel, la communauté relève du marketing, mais nous avons des personnes directement impliquées venant du Customer Success, du marketing, du produit et de notre équipe de direction.

Il est difficile pour moi de regarder ce que nous faisons et de le résumer par « la communauté relève du marketing ». C’est vrai, mais il y a bien plus que cela.

3 « J'aime »

Exemple : Je suis un utilisateur satisfait, mais pas un client payant. Mes contributions ici incluront des rapports de bugs, des suggestions de correctifs, des retours sur les propositions et décisions de conception, ainsi que des suggestions de fonctionnalités. Je ne sais pas où vous classez tout cela — cela dépend de votre vision de l’orientation future du produit. Peut-être s’agit-il de marketing.

1 « J'aime »

Je ne pense pas que cela relève du marketing.

Je pense que tout cela s’inscrit dans le « développement produit » — au sein de l’entreprise, cela comprend en pratique l’ingénierie, le design et la gestion de produit.

Je pense que cela reste le fondement de cette communauté :

Cela dit, bien sûr, le produit et le marketing collaborent également (et pas seulement dans le cadre de la communauté).

En pratique, bien que la communauté « relève du marketing », la responsabilité de notre communauté est partagée, et chacun y a un intérêt.

3 « J'aime »