Strategie di accesso e coinvolgimento

Comunità Impresa
1

Quanto vicini dovrebbero essere i clienti ai vostri team?

La settimana scorsa ho dedicato del tempo a riflettere su questo argomento, influenzato in parte dalle discussioni che stiamo avendo sul coinvolgere di più il nostro team qui su Meta.

Progettare confini sani tra clienti e team di prodotto

Il modo in cui i team di prodotto interagiscono con i clienti nella loro comunità varia notevolmente da organizzazione a organizzazione, quindi parlerò della nostra esperienza con Meta.

La nostra situazione è piuttosto unica nel senso che stiamo utilizzando il nostro prodotto in tempo reale insieme ai nostri clienti (dogfooding). Nei primi anni del progetto, tutti nella nostra organizzazione lavoravano direttamente sul prodotto, quindi fare parte della comunità era una parte necessaria del lavoro. Col tempo, questa situazione è cambiata e ora dobbiamo incoraggiare attivamente il coinvolgimento del personale al di fuori delle categorie di supporto.

Alcuni membri del nostro team ammettono di non dedicare tempo a Meta perché non sanno come interagire. Non ci sono domande che si sentano qualificati a rispondere e non ritengono di avere la profondità di conoscenza necessaria per guidare discussioni interessanti o pertinenti. Ecco alcune delle sfide che abbiamo identificato come ostacoli alla partecipazione più attiva del nostro team su Meta: sono sicuro che altre organizzazioni affrontino problemi simili.

Ostacoli al coinvolgimento nella comunità

  • Risposte inaccurate, obsolete o incoerenti alle domande. (Non conoscere la risposta giusta o la paura di dare quella sbagliata impedisce a molti di partecipare.)
  • I membri più loquaci possono esercitare un’influenza sproporzionata sul nostro team, potenzialmente a danno di altri membri. (Alcuni membri richiedono molta energia per essere gestiti con diplomazia e non tutti hanno la pazienza necessaria.)
  • La fiducia si erode se modifichiamo la roadmap senza una comunicazione sufficiente o se chiediamo feedback e sembriamo ignorarlo. (Alcune persone si sentono più al sicuro lavorando in privato per non creare aspettative che non possono soddisfare.)
  • Stancheità da notifiche dovuta al fatto di essere menzionati personalmente in argomenti non pertinenti perché le persone sono impazienti. (Alcuni membri trattano la presenza visibile come un invito a richiedere supporto personale quando sono sotto stress.)
  • Gestione della frustrazione quando i membri non sentono di essere ascoltati. (A volte la partecipazione può essere stressante a causa della sua natura conflittuale, anche quando nessuno è in colpa.)

Dove l’interazione diretta tra clienti e prodotto ha funzionato bene nella vostra organizzazione e dove è diventata difficile?

11 Mi Piace
2

È interessante. Penso che l’assunzione naturale sarebbe che le persone che progettano e costruiscono il software siano tra le migliori per affrontare questo tipo di domande e discussioni. Hai approfondito per scoprire cosa alimenta questa mancanza di fiducia?

5 Mi Piace
3

Non tutti i membri del team sono ingegneri o designer :slight_smile:

5 Mi Piace
4

Penso che lo stesso presupposto valga per i Product Manager, l’Assistenza Clienti, l’Assistenza Enterprise, il Marketing, le Vendite e ruoli simili. Sarebbe piuttosto difficile svolgere bene questi lavori senza le conoscenze necessarie. :person_shrugging:

3 Mi Piace
5

Penso che tutti noi ci sentiamo un po’ così, a volte. Credo che questo sia un vantaggio delle comunità basate su forum rispetto ai social media. Il ritmo più lento delle conversazioni e la longevità degli argomenti offrono agli utenti la possibilità di prendere una “confidenza” con gli altri utenti e, alla fine, di sentirsi più a loro agio nel partecipare.

Essere “qualificati” a rispondere dipende dalle domande poste. A volte chiunque abbia anche solo una conoscenza remota di Discourse può aiutare perché l’utente è completamente all’oscuro. All’altro estremo della scala c’è quando qualcuno fa una domanda molto specifica su qualcosa di molto tecnico. In questi casi, di solito mi limito a verificare che la domanda includa informazioni sufficienti in modo che, quando un membro qualificato entra nel thread, abbia ciò di cui ha bisogno per aiutare. (numero di versione, quel tipo di cose)

Ancora una volta, penso che questo sia in parte natura umana. E l’ironia è che le conversazioni interessanti spesso provengono da molti luoghi inaspettati.

5 Mi Piace
6

Non sono sicuro di poter rispondere direttamente all’argomento, ma ho alcune osservazioni legate a Discourse:

A volte ho incontrato membri del team che dicevano “Oh, non sapevo di [funzionalità o qualsiasi cosa riguardante Discourse]” nonostante fossero sviluppatori o ricoprissero qualsiasi altra posizione lavorativa sul software stesso.

All’inizio mi ha sorpreso, ma solo per poco tempo.

Gli appassionati come me che amano Discourse, lo promuovono e a volte sono persino amministratori di Discourse, tendono ad avere (o nel mio caso avevano) una buona conoscenza generale di Discourse e possono rispondere a molte domande sul software. In alcuni casi, in modo più accurato o dettagliato rispetto a un membro del team. Direi che questo può essere considerato una sorta di successo o realizzazione di CDCK :hugs:

Non mi aspetto che nemmeno uno sviluppatore di Discourse conosca qualcosa sulle funzionalità di Discourse. C’è semplicemente troppo da sapere, gran parte delle quali forse non è correlata a ciò per cui vengono pagati, e molte domande su Discourse possono essere al di fuori della loro competenza. Questo ovviamente non li rende meno preziosi. Sono esperti nel loro campo.

Certo, chiunque può a volte pensare di sapere, rispondere a una domanda e risultare sbagliato. Succede a tutti, siano membri del team o meno. È successo a me molte volte, e ammetto che a volte mi sono sentito un po’ imbarazzato, sia che fossi un utente comune o meno in quel momento.
E anche gli esperti possono sbagliare di tanto in tanto, ed è okay.

Ricordo una volta, quando ero a CDCK, saltai con sicurezza su un problema CSS di un cliente pensando di risolverlo facilmente e velocemente (non era nemmeno il mio lavoro). Ero completamente sbagliato. Il problema era molto più complesso di quanto mi aspettassi e lasciai che fossero gli esperti a risolverlo. :laughing: Sì, è stato imbarazzante, ma onestamente non era un grande affare e superai la cosa rapidamente.

Beh. Non sto nemmeno davvero affrontando ciò che ho citato, sto più che altro condividendo aneddoti a questo punto.

Vale per entrambi i lati. Penso che le interazioni conflittuali con alcuni membri del team siano state una delle poche cose che mi hanno sempre disturbato (solo un po’, niente di grave) su Meta; dal primo giorno fino ad oggi, occasionalmente.

Penso che dipenda semplicemente dalla personalità, dall’umore, dal temperamento e dalla cultura delle persone. La maggior parte delle volte non posso e non incolpo le persone che trovo a volte dure nelle loro interazioni.
Le vedo come le creste delle onde su un mare altrimenti calmo. L’espressione della natura umana.
L’obiettivo delle interazioni tra team/comunità non dovrebbe e non può essere “perfettamente privo di attrito” ma piuttosto “per lo più privo di attrito”. Penso che sia il caso su meta, anche se c’è sempre spazio per miglioramenti.

Ma beh, sì, non posso rispondere all’unica domanda dell’argomento, quindi, scusate se sono stato un po’ fuori tema :face_with_tongue:

7 Mi Piace
7

Sì, penso che sia importante tenerlo a mente! Per quanto possa essere frustrante o imbarazzante provare a fare qualcosa di sbagliato, è meglio che nessuno provi affatto. Non stiamo lavorando su qualcosa che esploderà, non ci sono molti casi in cui fare qualcosa di sbagliato causerebbe danni irreparabili.

Con un po’ di pazienza ce la faremo e impareremo qualcosa lungo la strada… per esperienza, il 99% delle persone che usano Discourse e sono venute qui per parlarne lo capisce.

4 Mi Piace
8

Sto lentamente scivolando più fuori tema, ma quello che dici mi ricorda una citazione di un noto streamer di Trackmania sui bambini, gli errori e l’apprendimento:

[I bambini] non hanno paura. I bambini non tendono a pensare troppo, […] non hanno paura di sbagliare. È il modo migliore per imparare, vedere cosa non funziona. Ma se inizi a imparare una nuova abilità da adulto, hai un po’ paura di sbagliare. I bambini sono molto più disposti a provare e sbagliare rispetto agli adulti. Come gridare con sicurezza la risposta sbagliata se l’insegnante chiede a qualcuno se ha un’idea. E questo tipo di mentalità plasma il modo in cui impari le cose.[1]

Qualcosa da tenere a mente, immagino :slight_smile:

(fine del fuori tema)

  1. https://youtu.be/Hr2nBfa-yaM?t=1970 ↩︎

4 Mi Piace
9

Ciao James. :slight_smile:

Sì, l’ho fatto! Penso sia una combinazione di comprensione dei costi nascosti del coinvolgimento e di avere un quadro di riferimento per la partecipazione.

Il costo interno del coinvolgimento del personale

Una partecipazione significativa richiede più del tempo e dello sforzo spesi per rispondere effettivamente alle domande. Le persone hanno bisogno di accesso alle informazioni, di supporto alla moderazione, di quadri di riferimento per il follow-up, di percorsi di escalation e di chiarezza su cosa possono discutere/quali esempi possono condividere/quali clienti possono nominare.

I team della comunità assorbono generalmente questo lavoro invisibile perché sanno a quali esperti di materia rivolgersi, hanno relazioni con i membri, hanno le competenze per mantenere le conversazioni produttive e hanno il tempo per assicurarsi che nulla venga trascurato. Questo garantisce che i livelli di fiducia siano mantenuti e che la comunità offra valore a tutti i partecipanti.

Il nostro team comprende il valore di questa fiducia e quanto tempo ci vuole per costruirla, quindi la paura di fare qualcosa che la eroda è sufficiente a dissuadere alcuni dal partecipare.

Costruire fiducia senza sovraccaricare i team interni

La fiducia deriva più da un comportamento prevedibile che da una disponibilità costante. I clienti/membri non hanno bisogno di un accesso continuo al tuo team se hanno fiducia nei tuoi processi. Hanno bisogno di sapere:

  • dove dare feedback
  • cosa ne succede
  • chi lo legge
  • quali discussioni ricevono risposte
  • come vengono prese le decisioni
  • quando faremo un report

È necessario qualche forma di ciclo di feedback continuo che sia affidabile: essere affidabili con dei confini è preferibile a essere altamente disponibili ma inaffidabili. Nessuno investirà tempo a dare feedback se sta urlando nel vuoto. Hai bisogno di abbastanza contatto diretto per comprendere le esigenze dei membri, con abbastanza struttura che tutti sappiano quale valore ottengono dall’interazione.

Questo mi interessa—chiamiamo @mae e chiediamole cosa ne pensa di rispondere a domande tecniche sui prodotti. Penso che potrebbe essere piuttosto illuminante.

Sono d’accordo con te Andrew, ci sono probabilmente sempre un po’ di domande che chiunque può rispondere, ma la discoverability può essere un problema in questi casi. Sono interessato a sentire come altri team gestiscono questo.

Non penso sia off-topic, penso che ci sia qualcosa di piuttosto utile che possiamo trarne. Abbiamo bisogno di una migliore comprensione del motivo per cui abbiamo paura di fallire.

4 Mi Piace
10

Ecco cosa faccio quando non sono sicuro di una risposta…

primo passo: guardo da quanto tempo la domanda è lì senza risposta.

se è passato solo un’ora o due, o è il weekend, la lascio stare per un po’ e aspetto di vedere se qualcuno più brillante di me risponde.

Se è una domanda molto specifica e sono passate 24 ore e silenzio radio :cricket: allora inizio davvero a sentirmi in colpa per questa persona. Cercherò di aiutare, anche se so molto poco sull’argomento della domanda. In questa situazione a volte faccio una ricerca veloce e vedo se c’è qualche documentazione a cui posso indirizzarli. Potrebbero farlo da soli, ma molte persone non leggono la documentazione (RTFM) non importa quanto siano disperate. O se è un bug, provo a riprodurlo.

Se penso di sapere la risposta ma non sono sicuro, dico “Penso che…”

Se penso di sapere la risposta ma non sono certo al 100%, dico “Sono quasi certo che…”

Se non ho la minima idea, dico “Sto solo indovinando…”

In molti casi, con un argomento che è rimasto lì per un po’, qualcuno che risponde in qualsiasi modo è meglio del silenzio. Almeno l’utente sa di non essere ignorato. E spesso la risposta porta in superficie l’argomento e altri si uniscono.

Questo penso sia importante. (e molto ben detto) Un team super reattivo che sembra una risposta automatica e poi non segue è inutile.

Ma penso che questo si colleghi anche a ciò che le persone stanno dicendo nell’altro argomento sul calo dell’impegno della comunità. Se un forum di supporto non risponde o impiega ore per rispondere, la tentazione di chiedere a un’IA e ottenere una risposta immediata è ancora maggiore.

A proposito, penso che Meta faccia davvero un ottimo lavoro nel trovare un buon equilibrio su questo

QUESTO è il punto in cui credo che un forum della comunità raggiunga la massa critica!

Come persona che sta cercando di far decollare un forum della comunità, questo è ciò che spero di raggiungere un giorno.

Quando un forum, specialmente un forum di supporto, guadagna abbastanza utenti veterani esperti che partecipano, al punto che quando un utente fa una domanda, c’è un intero gruppo di persone che si riunisce e risponde alle domande solo per divertimento, allora stiamo facendo sul serio. Se il pubblico è distribuito su fusi orari sufficienti da garantire che qualcuno sia sempre sveglio e risponda, stiamo davvero sfruttando il potere del ‘world wide web’.
E c’è qualcosa che l’IA non può darci ma che una comunità sì… una comunità

7 Mi Piace
11

Era una lettura interessante, ma non penso abbia coperto la cosa principale che mi incuriosiva. Ero più interessato a questo in particolare:

Questo sembra controintuitivo. Chi altro è meglio posizionato per saperne di più, e attraverso uno spettro così ampio di siti e casi d’uso? Certo, nessuno può sapere tutto, ma sicuramente una fetta decente in più rispetto alla media dei lurker.

Ci saranno dipartimenti piuttosto distanti dal prodotto (ad esempio finanza, legale), quindi se questo feedback proviene esclusivamente da loro è più comprensibile—ma se fosse spiegabile così facilmente presumo l’avresti detto prima.

Mi sembra una montatura… :slight_smile: Immaginavo che marketing e vendite avessero una specializzazione leggermente diversa rispetto alle domande tecniche, ma forse sto pensando troppo. Non pre-giudicherò. :slight_smile:

Anche se sono d’accordo su dove applicare al meglio il tuo tempo/risorse, ma è un problema separato dal non sentirsi in grado di contribuire se si volesse.

1 Mi Piace
12

Chiedereste a un allenatore di basket di insegnarvi il tennis? Sono entrambi sport, ma vorreste qualcuno che gioca effettivamente quel gioco. Stesso concetto qui: preferirei indirizzarvi verso l’esperto giusto piuttosto che balbettare una risposta per cui non sono qualificato.

Posso parlare tutto il giorno di posizionamento, messaging e di come raccontiamo la storia di Discourse, ma gli aspetti tecnici più approfonditi spettano alle persone che li costruiscono effettivamente.

Detto questo, penso che Marketing e Vendite dovrebbero svolgere un ruolo più importante su Meta e potrebbero essere i motori dietro contenuti meno tecnici. Questa è una priorità per il terzo e quarto trimestre per me.

Se qualcuno ha idee per contenuti meno tecnici che vorrebbe vedere su Meta, non esitate a contattarmi o a taggarmi negli argomenti. :slightly_smiling_face:

5 Mi Piace
13

Esatto, mi piace molto. Credo sia l’approccio perfetto.

Pensiero molto interessante, non dubito che abbia ragione. Ma secondo lei le persone si rivolgerebbero di default al bot qui (o su un altro forum), o andrebbero completamente altrove? Potrebbe essere interessante misurarlo.

La mia risposta era un po’ contorta, ma quello che intendevo era proprio questo:

E per chiarire, sì, è il lato business dell’organizzazione a sentire quella particolare barriera al coinvolgimento. Non ho menzionato le domande tecniche, quindi c’è stata una certa confusione. :slight_smile:

14

Vero. Se qualcuno si avvicinasse a me con una domanda di base su Discourse, direi di poter rispondere con una certa sicurezza. Ma quando si tratta di configurazioni molto avanzate o di errori di installazione che si rivelano bug nascosti in profondità, allora siamo ben oltre le mie conoscenze.

C’è stato un periodo, qualche mese fa, in cui ho pubblicato molto meno. Non perché semplicemente non fossi presente (lo ero; leggo ancora Meta ogni giorno), ma perché le domande diventavano molto più tecniche e, a causa dei fusi orari, le vedevo molto più tardi. Report di bug molto specifici o domande troppo specifiche da poter applicare alla mia istanza (o alle mie istanze).

È stato allora che mi sono reso conto che, in definitiva, ciò che so gratta appena la superficie rispetto agli sviluppatori che lavorano sul prodotto vero e proprio, o a persone come Moin e Lilly.

Il mio punto? Anche se ci si impegna regolarmente con Discourse, la configurabilità di Discourse garantisce che le informazioni siano quasi infinite. È troppo personalizzabile (non è una cosa negativa, però) e può essere modificata così profondamente da assomigliare a malapena a un forum standard. Quindi se lo staff non dovesse conoscere tutto sul software, va bene così: si specializzano in parti diverse e ciascuno può essere consultato come “esperto” per quella parte.

4 Mi Piace
15

Ah, lo sapevo che erano probabilità basse, ma dalla descrizione “illuminante” avevo iniziato a sperare che fossi entrato in ballo con qualche conoscenza esoterica sugli script di migrazione di Flarum o sulla configurazione di un tunnel Cloudflare. :slight_smile:

Anche se, come dici più avanti nel tuo post, ci sono sicuramente altre aree meno tecniche in cui stai valutando di applicare le tue conoscenze specialistiche su Discourse, quindi almeno non fai parte del feedback originale sulla “mancanza di fiducia”. :partying_face:

Credo che le aziende debbano essere realistiche riguardo ai dipartimenti e alle persone che si aspettano partecipino alla community. Una politica generalizzata o un’aspettativa standardizzata probabilmente non si adatta bene, anche nelle organizzazioni più piccole. Credo che chiedersi “quali sono i vantaggi per questo dipartimento/persona a partecipare” sia sicuramente una domanda chiave quando si valuta una strategia di inclusione.

Anch’io ho pensato che fosse un’aggiunta incongrua alla conversazione. :slight_smile: Qualche tipo di glitch dell’IA o qualcosa del genere?

7 Mi Piace
16

Mi chiedevo di cosa stessi parlando e ho dovuto rileggere tutta la conversazione per capire da dove era nato il discorso, perché per quanto ne so qui non c’è alcuna IA coinvolta. Ma poi ho visto…

Ho fatto confusione! Non ho idea del perché abbia aggiunto la parola “tecnico”. Rileggendo, posso solo supporre che abbia frainteso quello che stavi dicendo. Nessuno chiede mai domande di marketing qui, pensavo che stessi suggerendo che tutti abbiano conoscenze sul prodotto. Scusa, è stato un mio errore.

5 Mi Piace
17

Penso che la «conoscenza del prodotto» e la «conoscenza tecnica del prodotto» siano livelli diversi della cipolla. Dato per scontato che marketing e vendite abbiano una «conoscenza del prodotto», immagino che cercare di fare marketing e vendere un prodotto di cui si sa ben poco sarebbe piuttosto limitante. :slight_smile: Anche se ritengo che sia del tutto ragionevole per un’azienda valutare «qual è il vantaggio» e decidere che quei specifici dipartimenti non sono adatti per il loro spazio community (o che il loro tempo/risorse siano meglio impiegati altrove). Dal post sopra, Mae sembra pensare che ci sia un potenziale qui, e spesso la community rientra sotto l’ombrello del marketing nella struttura aziendale, quindi c’è anche quel collegamento esistente, ma non credo che ci sia necessariamente una risposta giusta e ogni azienda dovrebbe prendere queste decisioni per conto proprio.

Un altro aspetto pratico da considerare insieme a «quali dipartimenti» è quanti membri dello staff ci si aspetta partecipino, quanto attivamente, e se la propria community sia abbastanza grande da assorbirli in modo sano. Ogni cultura community è diversa, e ogni combinazione community-azienda avrà anche un sapore leggermente diverso, quindi questo dipenderà in gran parte dal contesto - ma penso che valga la pena riflettere su quale effetto potrebbe avere l’inserimento di 20/30/50 membri del team attivi nella propria community. Dominare lo spazio potrebbe essere l’intenzione, ma se non lo è, penso che essere consapevoli di questa potenziale conseguenza possa aiutare a mitigare qualsiasi impatto. Per esempio, delineando spazi/categorie dove si ritiene che il loro coinvolgimento sarebbe meglio indirizzato, o alcune linee guida su quando trattenersi e lasciare che la community abbia la priorità, ecc.

Impostare una categoria privata come sandbox per aiutare l’onboarding di questi membri del team nella community può anche aiutare a rendere più fluida la loro transizione. Solo un piccolo posto fuori mano dove possono discretamente familiarizzare con il mezzo prima di tuffarsi nelle aree pubbliche. Cose semplici come come citare, o creare sondaggi, o imparare l’etichetta esistente del forum, ecc., così possono costruire fiducia e non precipitarsi tutti sembrando principianti. :slight_smile:

Inoltre, la questione se rendere la partecipazione obbligatoria… personalmente sento che questo dovrebbe essere evitato se possibile. Le persone che si sentono costrette a partecipare spesso trasmettono la vibrazione sbagliata, e interazioni rigide/imbarazzanti/imperiose potrebbero fare più male che bene nel lungo periodo. Penso che convincere le persone dei vantaggi del coinvolgimento sia un motivatore molto più desiderabile. (Anche se, ancora una volta, molto dipende dalla tua community e cultura aziendale :slight_smile:)

2 Mi Piace