Modelos de propiedad comunitaria

Comunidad Empresa
1

He estado pensando en la propiedad y los modelos operativos de la comunidad, y me interesa saber más sobre dónde se sitúa la comunidad dentro de su organización.

Antes existían escuelas de pensamiento claras pero dispersas: un bando afirmaba que el equipo de comunidad debería ser una unidad autónoma y autogestionada, mientras que el otro sugería que tenía más sentido depender de otro departamento.

Tengo mi propia opinión, pero nunca he trabajado como Community Manager (CM) dentro de una gran empresa. Me gustaría escuchar a quienes sí lo hacen (o han hecho).

Creo que mi postura actual es que, en organizaciones más pequeñas o en aquellas donde la comunidad solo sirve a un departamento, tiene sentido que dependa de ese departamento.

Por ejemplo:

Objetivo de la comunidad Depende de
Desvío de soporte Soporte
Adquisición, defensa o eventos Marketing
Retroalimentación del producto, pruebas, ideación Producto

Mientras que las comunidades a escala empresarial que sirven a muchos departamentos probablemente se benefician más de un liderazgo autónomo. Siempre que el departamento no se convierta en un silo y exista una fuerte gobernanza multifuncional, parece ser la forma más efectiva de evitar demasiadas prioridades de partes interesadas en conflicto.

Estos datos de Community Roundtable parecen concluir que el enfoque independiente está creciendo entre sus encuestados, de los cuales aproximadamente el 30 % provienen de organizaciones con más de 1000 empleados.

image
image788×798 89.2 KB

¿Qué beneficios o desafíos enfrenta como resultado directo de su modelo de propiedad y gobernanza de la comunidad?

9 Me gusta
2

Supongo que empezaré con la primera respuesta :zany_face:

En mi puesto actual, el equipo de comunidad forma parte del departamento de marketing, y creo que esto tiene ventajas reales. Nos permite mantener una conexión sólida con el posicionamiento, los lanzamientos, el contenido, la defensa de la marca y la narrativa general que la empresa intenta transmitir.

Sin embargo, siempre he sentido que la comunidad no es marketing tradicional. Obviamente hay superposición, pero la lógica operativa detrás de cada uno es diferente. Por ejemplo, lo que funciona en un embudo de adquisición no necesariamente funciona dentro de la comunidad en sí. A veces, la decisión correcta no es la que genera más interacción inmediata o valor para la campaña. A veces se trata de escuchar, ralentizar el ritmo y crear espacio para la retroalimentación, o proteger la confianza, incluso cuando eso es más difícil de medir.

Para mí, el mayor desafío de estar dentro del departamento de marketing es asegurarme de que la comunidad no se reduzca a “otro canal”. Porque la comunidad no es simplemente otra audiencia a la que transmitir mensajes.

Creo que este modelo funciona mejor cuando el equipo de comunidad tiene la autonomía para tomar decisiones centradas en los miembros, mientras mantiene una conexión estrecha con los equipos a los que sirve.

En general, no estoy seguro de que la respuesta sea “la comunidad debe pertenecer al departamento X”. Creo que la pregunta más importante es si la organización otorga al equipo de comunidad el mandato, el acceso y la confianza para operar transversalmente entre departamentos. Dicho esto, solo he trabajado en comunidades a escala empresarial, pero puedo ver que para comunidades más pequeñas tiene sentido que reporten al departamento que la comunidad sirve principalmente. Pero una vez que la comunidad atiende simultáneamente a marketing, producto, soporte, éxito del cliente y educación, entiendo por qué un liderazgo de comunidad más independiente se vuelve valioso.

De lo contrario, el riesgo es que la comunidad se moldee según el departamento que la posee, en lugar de según lo que la comunidad realmente necesita.

9 Me gusta
3

Estoy de acuerdo. En su nivel más básico, las comunidades funcionan como un canal de adquisición en la parte superior del embudo, pero una vez que los usuarios están dentro, hay una relación de confianza más compleja que gestionar.

De acuerdo, aquí es donde el modelo puede fallar.

Entiendo que dices que tienes un equipo de comunidad completamente autónomo que, funcionalmente, reporta a marketing. Si ese es el caso, ¿cómo estableces límites o resuelves conflictos de intereses si el equipo de marketing quiere hacer algo que tú no consideres centrado en los miembros?

Y si tu comunidad está diseñada para servir a los objetivos de marketing, ¿te enfrentas a desafíos para gestionar las demandas de las partes interesadas de diferentes departamentos?

6 Me gusta
4

Tu suposición es mayormente correcta, con una pequeña salvedad.

Efectivamente formamos parte de Marketing, así que no describiría a nuestro equipo como totalmente autónomo en el sentido de “unidad de negocio independiente”. Pero, en la práctica, sí tenemos un buen grado de autonomía en cómo gestionamos la comunidad día a día, protegemos el tono del espacio y decidimos qué se siente adecuado para los miembros y qué no.

El límite es que la comunidad puede apoyar los objetivos del negocio, pero no puede convertirse simplemente en un mecanismo de ejecución para ellos.

Cuando llegan solicitudes, (ya sea una campaña de marketing, conversaciones de investigación, etc.), la respuesta no suele ser un sí o no inmediato. Se trata más de preguntarse: ¿cuál es el valor para el miembro aquí? ¿Es este el espacio adecuado para ello? ¿Encaja el enfoque con la relación que tenemos con la comunidad? A menudo, las respuestas son “sí, pero no en ese formato”, “sí, pero necesitamos abordarlo de manera diferente”, “no en ese canal” o “no hasta que hayamos hecho el trabajo preliminar”.

Cuando las solicitudes no son “centradas en el miembro”, suele ser porque el enfoque no es el adecuado.

Muchos de nuestros equipos ven valor en la comunidad, lo cual es positivo, pero cada “pequeña solicitud” de cada equipo puede convertirse rápidamente en una experiencia ruidosa o extractiva si no se gestiona con cuidado.

Así como confiamos en que nuestros otros equipos conocen sus áreas de expertise, ellos también entienden que nosotros conocemos la nuestra: si necesitamos encontrar formas creativas de apoyar algo, lo haremos.

Pero la salud de la comunidad debe seguir siendo lo que le da valor.

7 Me gusta
5

Estoy completamente de acuerdo con ambos puntos. Un gran desafío que surge de esto es la necesidad de alinear a tantas personas con tantos intereses conflictivos para no arruinar tu propia carrera:

  • Enfadaste a tu jefe y los presupuestos/solicitudes se complican
  • Enfadaste a tus usuarios y las métricas bajan, las quejas llegan a tu jefe, así que ahora también has enfadado a tu jefe, lo que significa que los presupuestos/solicitudes se complican
  • Enfadaste a los pares de tu jefe y terminas en reuniones con personas que creen entender el tema y exigen que hagas cosas que no tienen sentido. Si tu jefe entiende de comunidad, esto no es demasiado grave. Si tu jefe no entiende de comunidad, entonces vas a volverte muy bueno haciendo presentaciones de PowerPoint mientras intentas educar a estos tipos
  • Enfadaste al jefe de tu jefe y… bueno, ya te haces una idea

Entonces, ¿quién está mejor posicionado para liderar la Comunidad a nivel empresarial?

En mi opinión: lo orientado al exterior debería estar bajo la responsabilidad del Servicio al Cliente, y lo orientado al interior debería estar bajo la responsabilidad de un equipo que se extienda por toda la empresa en algún tipo de rol de apoyo: DevOps, TI o Gestión del Conocimiento y Aprendizaje. Y si tu comunidad es tanto hacia el interior como hacia el exterior, entonces establecería un Departamento de Comunidad específico que sería básicamente una mezcla de representantes de cada área como Servicio al Cliente, Producto, etc. Esto ofrece lo mejor de ambos mundos: liderazgo autónomo por parte del Director de Comunidad, y gobernanza transversal gracias al crisol de representantes de los distintos departamentos.

Quizás hayas notado que omití a Marketing, el propietario más común de las comunidades, de mi lista. Personalmente, no soy fan de las comunidades gestionadas por marketing. Simplemente no siento que esas comunidades estén en mi mejor interés. Quiero decir, ¿cómo podrían estarlo? El objetivo del Marketing es encontrar/atraer personas que podrían comprar el producto, y esto significa regularmente “convencer a la gente para que compre nuestro producto aunque no sea la mejor opción para esa persona”. No siempre, pero con suficiente frecuencia como para que yo las aborde con un nivel prejuicioso de escepticismo.

Por otro lado, me encanta ver al soporte al cliente como una comunidad: aquí hay un lugar gestionado por personas cuya razón de ser es mejorar mi experiencia como usuario/cliente. Si una comunidad es orientada al exterior, la pondría en manos del Soporte al Cliente, con el requisito de que también construyan una relación muy buena y estrecha con el equipo de producto.

3 Me gusta
6

Esta es una perspectiva interesante. Meta depende del departamento de Marketing en Discourse.

Nuestra posición de «marketing» es que, si utilizamos esta comunidad para ayudar a las personas a tener más éxito con Discourse, se convierte en una herramienta de retención.

1 me gusta
7

Interesante. Si el objetivo es la retención (parte del Marketing), pero la actividad real es principalmente de Soporte al Cliente, ¿qué distinción hace que la responsabilidad pertenezca a Marketing en lugar de a Soporte al Cliente? ¿No sería más adecuado que la responsabilidad recaiga en Soporte al Cliente, dado que son quienes están más activos, o acaso Soporte al Cliente depende jerárquicamente de Marketing?

Por ejemplo, ¿es típica una jerarquía que asigne la responsabilidad a Marketing de la siguiente manera?

graph TD
    HOM[Director de Marketing] --> MCE[Gerente de Éxito/Soporte al Cliente]
    HOM --> MM[Gerente de Marketing]
    HOM --> MS_MGR[Gerente de Ventas]
    HOM --> CONTENT[Responsable de Contenido/SEO]
    MCE --> CSS[Personal de Soporte al Cliente]
    MM --> MKT_STAFF[Personal de Marketing]
    MS_MGR --> SALES_STAFF[Personal de Ventas]
8

Recuerda que no somos una organización empresarial y tenemos un número de empleados bastante reducido, por lo que esto no es necesariamente cómo diseñaría las cosas si tuviéramos más personas, pero no creo que la línea de reporte cambiara mucho.

“Soporte” son Taylor y nuestros defensores técnicos que operan principalmente a través de los buzones del equipo en Meta. “Customer Success” son Chau y su equipo, que apoyan a nuestros clientes empresariales a través de sus categorías privadas. Marketing posee la estrategia, pero gestiona la carga de trabajo a través de otros departamentos.

IMG_2125.HEIC
IMG_2125.HEIC1920×2560 533 KB

No tenemos ningún personal de comunidad a tiempo completo desde que se fue Tobias, por lo que esta estructura se trata más de gobernanza/toma de decisiones que de cualquier otra cosa. Danielle (CS) lidera con el apoyo de Mae (Directora de Marketing) y varias otras personas internas (incluyéndome a mí).

¿Es eso así? Yo diría que lo que hacemos en Meta es una mezcla de Customer Success (a través de categorías privadas) para los compradores y soporte de devrel (comunidad principal de código abierto) para los desarrolladores. Nuestro equipo de soporte dedica muy poco tiempo a apoyar a la comunidad en Meta fuera de los buzones del equipo, por lo que la comunidad se autosostiene hasta cierto punto.

Meta no está destinado a ser una herramienta de desvío de tickets porque la mayoría de las personas que buscan soporte no son nuestros clientes.

1 me gusta
9

Vaya, supongo que ese es un aspecto clave y me ha dado una perspectiva muy diferente sobre esto. Como Discourse es gratuito y de código abierto, siempre consideré a los usuarios de Meta como clientes. Pero, por otro lado, la mayoría no paga, por lo que técnicamente no son clientes.

Y supongo que esa definición establece una línea bastante efectiva para determinar la responsabilidad: ¿La mayoría de los usuarios pagan por el producto? Sí: soporte al cliente; No: marketing.

2 Me gusta
10

Por lo que veo, nuestra estrategia ha sido algo emergente a lo largo de los años.

En los primeros días, creo que estaba principalmente alineada con el producto: queríamos una forma de:

  • usar el producto internamente y
  • obtener comentarios tempranos sobre las funciones de los usuarios de código abierto

A cambio, el valor para los usuarios (clientes, en sentido amplio) era:

  • soporte del equipo y de la comunidad
  • influencia en la dirección del producto

Creo que estos aspectos siguen siendo la base de esta comunidad.

(También utilizamos este sitio para comunicarnos con clientes (de pago), pero gran parte de eso ocurre a través de canales privados (mensajes personales o categorías privadas). Voy a dejar eso de lado por ahora (disculpen los paréntesis anidados)).

Creo que otro caso de uso que surgió de forma orgánica fue la “retención” y el “defensorado”. Nuevamente, esto se centró inicialmente en atender a los clientes no pagadores, pero como efecto secundario, la comunidad también aporta ese valor a los clientes de pago.

Más recientemente, hemos puesto mayor énfasis en cómo la comunidad puede apoyar la viabilidad y el crecimiento del negocio. Indirectamente, por supuesto, eso también beneficia a la comunidad de código abierto.

Pero queremos asegurarnos de que la comunidad atienda bien a los clientes de pago y a los clientes potenciales que están tratando de tomar la mejor decisión sobre qué plataforma elegir. Diría que la retención y el defensorado son los objetivos más alineados con eso.

Hay mucha superposición en cuanto a la alineación con dos áreas de la organización: Marketing y Éxito del Cliente.

En el organigrama actual, la comunidad reporta a Marketing, pero tenemos personas involucradas directamente desde Éxito del Cliente, Marketing, Producto y nuestro equipo directivo.

Me resulta difícil mirar lo que estamos haciendo y reducirlo a “la comunidad depende de Marketing”. Es cierto, pero hay mucho más en ello.

3 Me gusta
11

Ejemplo: soy un usuario satisfecho, pero no un cliente que paga. Mi aportación aquí incluirá informes de errores, sugerencias de correcciones, comentarios sobre propuestas de diseño y decisiones de diseño, así como sugerencias de funciones. No estoy seguro de dónde encajaría todo esto; depende de cómo veas la dirección del futuro del producto. Quizás eso sea marketing.

1 me gusta
12

No creo que encaje en marketing.

Creo que todo eso encaja en «desarrollo de productos»: dentro de la empresa, en la práctica incluye ingeniería, diseño y gestión de productos.

Creo que eso sigue siendo la base de esta comunidad:

Dicho esto, por supuesto, producto y marketing también colaboran (y no solo en el contexto de la comunidad).

En la práctica, aunque la comunidad «depende del marketing», hay una propiedad compartida de nuestra comunidad y todos tienen interés en ella.

3 Me gusta