Qué hace un community manager cada semana, qué tareas son mecánicas y automatizables, y cómo montar dry-run, validaciones y alertas que nombran el campo exacto.
Pregúntale a cualquier community manager en qué se le fue la semana y la respuesta suele ser una mezcla rara: pensó la campaña del mes, peleó con un video que no subía, volvió a subirlo, respondió comentarios y persiguió a alguien para que aprobara un caption. La mitad de esa lista requiere talento. La otra mitad es una fila mal diligenciada en un calendario.
En el primer artículo de esta serie explicamos cómo automatizar el community management con un sistema completo: calendario como fuente única, scripts que ejecutan, un agente que propone y una persona que aprueba. Aquí bajamos un nivel: qué hace un community manager exactamente, qué partes se automatizan y cómo se montan las tres piezas que hacen que el sistema no falle en silencio: el dry-run, las validaciones y las alertas.
Qué hace un community manager: el mapa completo
La descripción del cargo dice "gestionar las redes de la marca". La semana real se ve más así:
| Tipo de tarea | Ejemplos | ¿Se automatiza? |
|---|---|---|
| Creativa | Definir campañas, escribir el enfoque, elegir qué historia contar | No: es el corazón del rol |
| Editorial | Producir o adaptar piezas, escribir captions, revisar tono | Parcialmente: el agente propone, la persona aprueba |
| Mecánica | Subir cada pieza a cada red, programar horarios, verificar formatos | Sí, completa |
| De control | Revisar que todo salió, detectar errores, avisar | Sí: las alertas lo hacen mejor que una persona |
| Comunitaria | Responder comentarios y mensajes, conversar | No: ahí la marca se juega su relación |
La conclusión incómoda: un community manager que pasa la mayor parte de su tiempo en lo mecánico está haciendo el trabajo de un script. La automatización no viene a quitarle el cargo, sino a devolverle la mitad de la semana.
La prueba para decidir: ¿barata, frecuente y determinística?
Antes de automatizar cualquier tarea, hazle tres preguntas. ¿Ocurre seguido? ¿Es barata de ejecutar? ¿El resultado correcto siempre es el mismo? Si la respuesta es sí tres veces, es un script. Si la tarea requiere interpretar contexto ("¿este hook encaja con la marca?"), es un agente de IA con aprobación humana. Si requiere relación con personas, no se toca.
Dry-run: el ensayo general antes de publicar nada
Un dry-run es una ejecución del sistema que hace todo menos programar: lee el calendario, valida cada pieza y reporta qué haría. Así se ve una salida real:
[DRY-RUN] Instagram Reel | 2026-11-03 18:30 | OK → se programaría
[DRY-RUN] YouTube Short | 2026-11-04 12:00 | FALTA: título
[DRY-RUN] TikTok Video | 2026-11-04 19:00 | OK → se programaría
La regla: corre el dry-run contra tu calendario real durante 2-3 días antes de activar la programación. Si el dry-run coincide con lo que el equipo esperaba tres días seguidos, el sistema está listo. Si no, las diferencias te dicen qué regla falta.
Dos principios que no se negocian en esta etapa:
- Idempotencia: si el script corre dos veces, no programa dos veces. La referencia es el ID externo que devuelve el programador, nunca la hora.
- El estado cambia a "Programado" solo después de una respuesta exitosa de la API, nunca antes.
Validaciones: cada red tiene sus propias reglas
La mayoría de fallas de programación no son errores de la herramienta: son piezas que salieron incompletas. Por eso cada combinación red + formato necesita su propia validación antes de llamar a la API:
- YouTube: título obligatorio, máximo 100 caracteres; la miniatura personalizada se sube aparte.
- Instagram: las Stories no llevan caption; los carruseles necesitan todos los archivos accesibles con enlaces estables, no temporales que venzan antes de la publicación.
- TikTok: confirma el modo de publicación de tu herramienta (algunas integraciones envían el video como borrador o notificación) y define la privacidad de forma explícita.
- Todas: formato vertical 9:16 para Reels, Shorts y TikTok, y fecha en el futuro que no choque con tus reglas de choque.
Cuando una pieza no pasa la validación, el sistema la marca como Error con el motivo exacto. Nunca la programa "a ver qué pasa".
Alertas que nombran el campo exacto
Una alerta útil responde tres preguntas: qué pieza, qué falta y dónde lo arreglo.
| Mala alerta | Buena alerta |
|---|---|
| "Error al programar" | "Falta el título en el YouTube Short del mié 4 nov, 12:00. Arréglalo aquí: [link a la fila]" |
| "Falló el sync" | "El archivo de Drive no es accesible (permiso denegado). Pieza: Reel 'Errores MVP'. [link]" |
Tres reglas para que las alertas sirvan: un canal dedicado (no el general del equipo), un solo mensaje agrupado por ejecución en vez de quince sueltos, y la urgencia calculada según cuántas horas faltan para la publicación. La prueba de fuego: el community manager puede resolver cualquier alerta sin abrir los logs.
Las fallas que más rompen este sistema
- Zona horaria implícita: la pieza sale una hora antes o después. Guarda la zona horaria en cada fila y muéstrala en cada alerta.
- Links temporales: el enlace de Drive vence antes de la publicación y el carrusel falla. Usa enlaces estables.
- Equipo editando en el programador: alguien cambia algo en Metricool o Buffer y el script lo crea de nuevo. Todo cambio se hace en el calendario; el programador es de solo lectura.
- Token vencido: todo falla de golpe un lunes. Lleva un calendario de vencimientos.
- Falso "ya publicado": el script compara solo por hora y cree que otra pieza es la misma. ID externo, siempre.
Lo que sigue en la serie
En el siguiente artículo: qué es un community manager hoy y cómo está cambiando su rol cuando un agente de IA se suma al equipo, con la cadencia de operación semanal y las métricas para saber si la automatización está funcionando. Si quieres el sistema completo ya, el playbook de automatización para community managers tiene las plantillas y el brief listo para copiar en tu agente.