Modelli di proprietà comunitaria

Comunità Impresa
1

Ho riflettuto sulla proprietà della community e sui modelli operativi e sono interessato a saperne di più su dove si colloca la community all’interno della vostra organizzazione.

In passato esistevano scuole di pensiero distinte ma chiaramente separate: una sosteneva che un Team Community dovesse essere un’unità autonoma e autogovernata, mentre l’altra suggeriva che avesse più senso riferirsi a un altro dipartimento.

Ho una mia opinione, ma non ho mai lavorato come CM all’interno di una grande azienda. Sono curioso di ascoltare chi di voi lo fa (o ha fatto).

Penso che la mia posizione attuale sia che in organizzazioni più piccole o in quelle in cui la community serve solo un dipartimento, abbia più senso riferirsi a quel dipartimento.

Per esempio:

Obiettivo della community Si riferisce a
Deviazione del supporto Supporto
Acquisizione, advocacy o eventi Marketing
Feedback sul prodotto, test, ideazione Prodotto

Mentre le community su scala aziendale che servono molti dipartimenti sono probabilmente meglio servite da una leadership autonoma. A patto che il dipartimento non diventi un silo e che vi sia una forte governance trasversale, sembra il modo più efficace per evitare troppi obiettivi contrastanti degli stakeholder.

Questi dati del Community Roundtable sembrano concludere che l’approccio indipendente sta crescendo tra i loro rispondenti, di cui circa il 30% proviene da organizzazioni con 1000+ dipendenti.

image
image788×798 89.2 KB

Quali vantaggi o sfide affronti direttamente a causa del tuo modello di proprietà e governance della community?

9 Mi Piace
2

Immagino che inizierò con la prima risposta :zany_face:

Nel mio ruolo attuale, il team community fa parte del marketing, e penso che ci siano veri vantaggi in questo. Ci dà una forte connessione con il posizionamento, i lanci, i contenuti, l’advocacy e la storia più ampia che l’azienda sta cercando di raccontare.

Ma ho sempre sentito che la community non è marketing tradizionale. C’è ovviamente una sovrapposizione, ma la logica operativa alla base è diversa. Per esempio, ciò che funziona in un funnel di acquisizione non funziona necessariamente all’interno della community stessa. A volte la decisione giusta non è quella che crea il maggior coinvolgimento immediato o il maggior valore di campagna. A volte significa ascoltare, rallentare e creare spazio per i feedback, o proteggere la fiducia anche quando è più difficile da misurare.

Per me, la sfida più grande nel far parte del marketing è assicurarsi che la community non venga ridotta a “un altro canale”. Perché la community non è solo un altro pubblico a cui trasmettere messaggi.

Penso che questo modello funzioni meglio quando il team community ha l’autonomia per prendere decisioni incentrate sui membri, pur mantenendo una stretta connessione con i team che serve.

Tutto sommato, non sono sicuro che la risposta sia “la community dovrebbe essere inserita nel dipartimento X”. Penso che la domanda più importante sia se l’organizzazione conferisca al team community il mandato, l’accesso e la fiducia necessari per operare tra i vari dipartimenti. Detto questo, ho lavorato solo in community di scala enterprise, ma posso vedere che per community più piccole ha senso riferirsi al dipartimento che la community serve principalmente. Ma una volta che la community serve contemporaneamente marketing, prodotto, supporto, customer success e formazione, capisco perché una leadership community più indipendente diventi preziosa.

Altrimenti, il rischio è che la community venga plasmata dal dipartimento che la possiede, piuttosto che da ciò di cui la community ha realmente bisogno.

9 Mi Piace
3

Sono d’accordo. A un livello basilare, le comunità funzionano come un canale di acquisizione nella parte superiore del funnel, ma una volta che gli utenti vi entrano, bisogna gestire una relazione di fiducia più complessa.

D’accordo, è qui che il modello può fallire.

Credo tu stia dicendo che hai un team della comunità completamente autonomo che, di fatto, riferisce al marketing. In tal caso, come stabilisci i confini o risolvi i conflitti di interesse se il team di marketing vuole fare qualcosa che non consideri “member-first” (centrato sui membri)?

E se la tua comunità è progettata per servire gli obiettivi di marketing, hai delle difficoltà nel gestire le richieste degli stakeholder di diversi dipartimenti?

6 Mi Piace
4

La tua supposizione è per lo più corretta, con una piccola precisazione.

Sediamo all’interno del Marketing, quindi non ci descriverei come completamente autonomi nel senso di “unità aziendale indipendente”. Ma funzionalmente, abbiamo una buona dose di autonomia su come gestiamo la comunità giorno per giorno, proteggiamo il tono dello spazio e decidiamo cosa sembra giusto o meno per i membri.

Il confine è che la comunità può supportare gli obiettivi aziendali, ma non può semplicemente diventare un meccanismo di esecuzione per essi.

Quando arrivano richieste, (che si tratti di una campagna di marketing, conversazioni di ricerca, ecc.) non è di solito un sì o no immediato. È più: qual è il valore per il membro qui? Questo è lo spazio giusto per farlo? La cornice si adatta alla relazione che abbiamo con la comunità? Spesso, le risposte sono “sì, ma non in quel formato”, “sì, ma dobbiamo approcciarlo in modo diverso”, “non in quel canale”, o “non finché non abbiamo fatto i lavori preliminari”.

Quando le richieste non sono “member first”, di solito è perché la cornice non è giusta.

Molti dei nostri team vedono valore nella comunità, il che è una cosa positiva, ma ogni “piccola richiesta” di ogni team può rapidamente diventare un’esperienza rumorosa o estrattiva se non è gestita con cura.

Nello stesso modo in cui ci fidiamo che gli altri team conoscano le loro aree di competenza, loro capiscono anche che noi conosciamo le nostre - se abbiamo bisogno di trovare modi creativi per supportare qualcosa, lo faremo.

Ma la salute della comunità deve rimanere ciò che le dà valore.

7 Mi Piace
5

Concordo pienamente con entrambi i punti. Una sfida importante che ne deriva è la necessità di allineare così tante persone con interessi spesso conflittuali, per non rovinare la propria carriera:

  • Se fai arrabbiare il tuo capo, budget e richieste diventano complicati
  • Se fai arrabbiare i tuoi utenti, i numeri calano, i reclami arrivano al tuo capo, quindi ora hai anche arrabbiato il tuo capo, il che significa che budget e richieste diventano complicati
  • Se fai arrabbiare i colleghi del tuo capo, finisci in riunioni con persone che pensano di capire l’argomento e ti chiedono di fare cose che non hanno senso. Se il tuo capo conosce le comunità, non è troppo grave. Se il tuo capo non conosce le comunità, allora diventerai davvero bravo a fare PowerPoint mentre cerchi di istruire queste persone
  • Se fai arrabbiare il capo del tuo capo e… beh, hai capito il punto

Quindi, chi è nella posizione migliore per gestire la Community a livello aziendale?

Secondo me: la parte rivolta all’esterno dovrebbe essere gestita dal Servizio Clienti, mentre quella interna dovrebbe essere gestita da un team che si estende in tutta l’azienda in qualche ruolo di supporto: DevOps, IT o Gestione della Conoscenza e della Formazione. E se la tua comunità è sia interna che esterna, istituirei un Dipartimento Community specifico che sarebbe fondamentalmente un mix di rappresentanti di Servizio Clienti, Prodotto, ecc. Questo offre il meglio di entrambi i mondi: leadership autonoma da parte del Responsabile Community e governance cross-funzionale grazie alla fusione di rappresentanti dei vari dipartimenti.

Avrai notato che ho omesso il Marketing, il proprietario più comune delle comunità, dalla mia lista. Personalmente, non sono un fan delle comunità gestite dal marketing. Semplicemente, non sento che quelle comunità siano nel mio migliore interesse. Voglio dire, come potrebbero esserlo? L’obiettivo del Marketing è trovare/attrarre persone che potrebbero acquistare il prodotto, e questo significa regolarmente “convincere le persone ad acquistare il nostro prodotto anche se non è l’opzione migliore per loro”. Non sempre, ma spesso abbastanza da avvicinarmi a loro con un certo scetticismo pregiudizievole.

Il supporto clienti, d’altra parte, adoro vederlo come una community: ecco un posto gestito da persone la cui ragion d’essere è migliorare la mia esperienza come utente/cliente. Se una comunità è rivolta all’esterno, la metterei nelle mani del Servizio Clienti - con il requisito che costruiscano anche una relazione molto stretta e buona con il team prodotto.

3 Mi Piace
6

Questa è una prospettiva interessante. Meta rientra sotto il Marketing in Discourse.

La nostra posizione “marketing” è che se utilizziamo questa comunità per aiutare le persone ad avere più successo con Discourse, essa diventa uno strumento di fidelizzazione.

1 Mi Piace
7

Interessante. Se l’obiettivo è la fidelizzazione (parte del Marketing) ma l’attività effettiva è prevalentemente Assistenza Clienti, quale distinzione fa sì che la responsabilità appartenga al Marketing piuttosto che all’Assistenza Clienti? Non sarebbe più appropriato attribuire la responsabilità all’Assistenza Clienti, dato che è più attiva, o l’Assistenza Clienti rientra nel Marketing in termini gerarchici?

Ad esempio, la gerarchia tipica che porta alla responsabilità del Marketing è qualcosa di simile a questa?

graph TD
    HOM[Responsabile Marketing] --> MCE[Responsabile Customer Success/Support]
    HOM --> MM[Responsabile Marketing]
    HOM --> MS_MGR[Responsabile Vendite]
    HOM --> CONTENT[Responsabile Contenuti/SEO]
    MCE --> CSS[Personale Assistenza Clienti]
    MM --> MKT_STAFF[Personale Marketing]
    MS_MGR --> SALES_STAFF[Personale Vendite]
8

Ricorda che non siamo un’organizzazione Enterprise e abbiamo un numero di dipendenti piuttosto limitato, quindi questa non è necessariamente la struttura che adotterei se avessimo più persone, ma non credo che la linea di reporting cambierebbe molto.

Il team “Supporto” è composto da Taylor e dai nostri tecnici advocate, che operano principalmente attraverso le caselle di posta del team su Meta. Il team “Customer Success” è composto da Chau e dal suo gruppo, che supportano i nostri clienti Enterprise tramite le loro categorie private. Il Marketing possiede la strategia, ma gestisce il carico di lavoro attraverso altri dipartimenti.

IMG_2125.HEIC
IMG_2125.HEIC1920×2560 533 KB

Non abbiamo più personale a tempo pieno per la community da quando Tobias se n’è andato, quindi questa struttura riguarda più la governance e il processo decisionale che altro. Danielle (CS) è la responsabile, con il supporto di Mae (Direttrice del Marketing) e di diverse altre persone interne (incluso me).

Ma è davvero così? Direi che ciò che facciamo su Meta è un mix di Customer Success (tramite categorie private) per gli acquirenti e di supporto DevRel (principalmente per la community OS) per gli sviluppatori. Il nostro team di supporto dedica molto poco tempo ad assistere la community su Meta al di fuori delle caselle di posta del team, quindi la community si autosostiene in una certa misura.

Meta non è inteso come uno strumento di deflessione dei ticket, perché la maggior parte delle persone che cercano supporto non sono i nostri clienti.

1 Mi Piace
9

Beh, immagino che sia un aspetto piuttosto fondamentale e mi ha fatto vedere la questione in modo molto diverso. Poiché Discourse è gratuito e open source, ho sempre considerato gli utenti di Meta come clienti. D’altra parte, la maggior parte non paga, quindi tecnicamente non sono clienti.

E immagino che questa definizione crei una linea di demarcazione piuttosto efficace per determinare la responsabilità: la maggior parte degli utenti paga per il prodotto? Sì – Assistenza clienti; No – Marketing.

2 Mi Piace
10

Secondo il mio punto di vista, la nostra strategia si è evoluta in modo piuttosto spontaneo negli anni.

Nelle fasi iniziali, penso che fosse principalmente allineata al prodotto: volevamo un modo per:

  • utilizzare internamente il prodotto stesso e
  • ricevere feedback precoci sulle funzionalità dagli utenti open source

In cambio, il valore offerto agli utenti (intesi come clienti in senso ampio) consisteva in:

  • supporto da parte del team e della community
  • possibilità di influenzare la direzione del prodotto

Credo che questi elementi costituiscano ancora le fondamenta di questa community.

(Usiamo questo sito anche per comunicare con i clienti (a pagamento), ma gran parte di questa interazione avviene attraverso canali privati (messaggi diretti o categorie private). Per ora lascio da parte questo aspetto (scusate le parentesi annidate)).

Penso che un altro caso d’uso emerso in modo organico sia stato legato alla “retention” e all’“advocacy”. Anche in questo caso, l’attenzione iniziale era focalizzata principalmente sull’assistenza ai clienti non paganti, ma come effetto collaterale, la community fornisce tale valore anche ai clienti a pagamento.

Più recentemente, abbiamo posto maggiore enfasi su come la community possa supportare la sostenibilità e la crescita dell’attività. Indirettamente, questo aiuta anche la community open source.

Ma vogliamo assicurarci che la community serva bene i clienti a pagamento, nonché i potenziali clienti che stanno cercando di prendere la decisione migliore su quale piattaforma scegliere. Direi che la retention e l’advocacy sono gli obiettivi più strettamente allineati a questo scopo.

C’è una notevole sovrapposizione in termini di allineamento con due aree dell’organizzazione: Marketing e Customer Success.

Nell’organigramma attuale, la community riferisce al marketing, ma abbiamo persone direttamente coinvolte provenienti da customer success, marketing, prodotto e dal nostro team esecutivo.

Mi risulta difficile guardare ciò che facciamo e ridurlo semplicemente a “la community dipende dal marketing”. È vero, ma c’è molto di più.

3 Mi Piace
11

Esempio: sono un utente soddisfatto, ma non un cliente pagante. Il mio contributo qui includerà segnalazioni di bug, suggerimenti per le correzioni, feedback sulle proposte di design e sulle decisioni di design, suggerimenti sulle funzionalità. Non sono sicuro di dove inserirle tutte – dipende da come si vede la guida del futuro del prodotto. Forse è marketing.

1 Mi Piace
12

Non credo che rientri nel marketing.

Penso che tutto questo rientri nello “sviluppo del prodotto” – all’interno dell’azienda, nella pratica questo include ingegneria, design e product management.

Penso che questa sia ancora la base di questa comunità:

Detto questo, ovviamente, prodotto e marketing collaborano anche (e non solo nel contesto della comunità).

Nella pratica, anche se la comunità “rientra nel marketing”, c’è una proprietà condivisa della nostra comunità, e tutti hanno un interesse in essa.

3 Mi Piace