La mayoría de los procesos de aprobación fallan del mismo modo. Nadie discute la idea. Luego un revisor falta dos días, tres publicaciones pierden su hueco y alguien pregunta si puede publicarlas él mismo.
Por eso esta guía trata menos de activar las aprobaciones y más de llevarlas bien: quién revisa qué, cuánto debería tardar una revisión y qué pasa ese jueves por la mañana en que la aprobación llega después de la hora. Si solo quieres ver qué hace la función, tienes la página del flujo de aprobación. Aquí damos por hecho que ya has decidido usarla.
Una aclaración antes de empezar. Las aprobaciones son para personas de tu equipo, cada una con su puesto. Si quien revisa es un cliente sin cuenta, usa un enlace de revisión, que explicamos en cómo conseguir comentarios de clientes sobre las publicaciones.
Un ejemplo completo: tres personas, un cliente
Imagina una agencia pequeña en el plan Pro, que incluye tres puestos.
- Maya es la propietaria y lleva la facturación.
- Dev es el aprobador. Conoce las normas de marca del cliente y sus sensibilidades legales.
- Sam es colaborador. Escribe y programa la mayoría de las publicaciones del cliente.
El martes por la tarde Sam escribe una publicación que anuncia las rebajas de primavera del cliente y la programa para el jueves a las 9:00. Como es colaborador, el botón dice Submit for Approval en lugar de Schedule. La publicación se guarda con su hora del jueves, pero lleva la etiqueta Awaiting approval y no saldrá hasta que alguien la apruebe.
Dev recibe una notificación. El miércoles por la mañana abre la publicación y ve que las rebajas terminan el domingo, no el sábado. La rechaza y escribe el motivo: “Las rebajas terminan el domingo a las 23:59, no el sábado”. La publicación vuelve a borradores con la etiqueta Rejected, y Sam ve la nota de Dev en la parte superior del compositor cuando la abre.
Sam corrige la fecha y la programa de nuevo. Eso cuenta como un reenvío, así que vuelve a quedar pendiente y Dev recibe otra notificación. El jueves a las 9:20, veinte minutos después de la hora, Dev llega a ella. Este es el caso incómodo. Como la hora pasó hace más de 15 minutos, a Dev se le pide elegir: Approve and publish now o Approve and pick a new time. Dev sabe que el correo de las rebajas salió a las 9:00, así que publica ya.
Si la hubiera abierto a las 9:10, dentro de la ventana de 15 minutos, aprobar la habría publicado al instante sin preguntar nada.
Hay tres cosas de esta historia que merece la pena copiar: el rechazo llevaba un motivo, el revisor era una persona concreta y no “quien lo vea”, y la regla de las aprobaciones tardías se conocía de antemano.
Decide quién revisa qué
La pregunta no es “quién es más veterano”. Es “a quién le daría más vergüenza que esto saliera mal”.
| Si el riesgo es… | El revisor debería ser… | Por qué |
|---|---|---|
| La voz y el tono de la marca | Un aprobador del equipo de contenido | Lo juzga en segundos y publica directamente lo suyo |
| Afirmaciones legales, de precios o reguladas | Un administrador o el propietario | Alguien que responde de lo que se afirma |
| La exactitud de lo que ve el cliente | El responsable de la cuenta, como aprobador | Es quien más cerca está de los datos reales del cliente |
| Redactores nuevos | Tu compañero con más experiencia, como aprobador | Las revisiones sirven también de formación |
Los aprobadores pueden publicar directamente, así que quienes tienen ese rol no esperan a nadie. Solo los colaboradores pasan por la barrera, y los lectores no pueden crear publicaciones. La lista completa de roles está en cómo invitar al equipo y elegir roles.
Nombra al menos a dos personas que puedan aprobar. Con un solo revisor, una baja por enfermedad se convierte en una congelación del contenido.
Fija un plazo antes de montar el flujo
Elige un número y dilo en voz alta. “En un día laborable” basta para el contenido planificado.
Luego calcula hacia atrás. Si una revisión puede tardar un día, nada debería enviarse con menos de un día de margen sobre su hueco. Una convención sencilla: enviar antes de que acabe el día anterior. Lo que llegue más tarde es un favor que se pide, y todos deberían saberlo.
Cuando una revisión sí se retrasa, la regla de los 15 minutos es una red de seguridad, no un plan. Pasado ese punto alguien tiene que decidir entre publicar tarde o reprogramar, y es una decisión que un revisor no debería tomar a las 9:20 con el cliente esperando.
Escribe rechazos que cierren el círculo
La nota de rechazo es la única respuesta que recibe el autor en el momento en que importa. Puede tener hasta 2.000 caracteres y es opcional, así que es fácil dejarla en blanco. No lo hagas.
- Mal: “No es esto.”
- Mejor: “Demasiado comercial para esta cuenta. Empieza con la historia del cliente y deja el descuento para la última línea.”
- Lo mejor: lo anterior, más lo que haría falta para aprobarla, de modo que el siguiente envío sea el último.
Un rechazo tampoco es una sentencia. La publicación vuelve a borradores, el autor la edita y la programa de nuevo, y vuelve a revisión. Piénsalo como una ronda, no como una negativa.
Errores habituales
Poner barrera a todo. Si cada respuesta rápida y cada republicación esperan aprobación, los revisores empiezan a aprobar sin leer. Reserva la barrera para el contenido planificado, de cara al cliente o regulado. Deja que los aprobadores publiquen directamente lo reactivo.
Un solo aprobador y nadie de repuesto. Ya lo vimos, y es el motivo más común por el que un flujo se abandona sin hacer ruido.
Editar tras la aprobación sin darse cuenta. Si un colaborador cambia una publicación aprobada y la programa de nuevo, necesita aprobación otra vez. Es lo previsto. Avisa a la gente, o pensarán que la herramienta está rota.
Olvidarse de la automatización. Las programaciones recurrentes y los feeds RSS creados o editados por alguien sin permiso para publicar quedan con aprobación obligatoria, aunque intente desactivarla. Quien puede publicar puede volver a desactivarla. Si te preguntas por qué las publicaciones de un feed están esperando, empieza por ahí.
Usar las aprobaciones para clientes. Los clientes sin puesto no pueden ser aprobadores, y darles un puesto solo para aprobar gasta uno de tus tres o diez.
Dar por hecho que las notificaciones llegan igual a todos. Los avisos de aprobación siguen la configuración de notificaciones de cada persona: en la app, por correo o en el móvil. Un aprobador que ha silenciado el correo puede no ver nunca una solicitud. Pídele que lo compruebe una vez.
Agentes e integraciones
Si scripts o asistentes de IA crean publicaciones por ti a través de la API, se puede crear una publicación con requestApproval en true aunque el titular de la cuenta pudiera publicar directamente. Entonces espera como la de un colaborador, y decide una persona. Es la forma más sencilla de dejar que la automatización te prepare la semana sin que publique nada sin control.
Lista para ponerlo en marcha
- Cuenta tus puestos. Free tiene 1, Pro 3 y Business 10, y las invitaciones pendientes cuentan para el límite.
- Invita a las personas y dale a cada una el rol más bajo que le permita hacer su trabajo. Colaboradores para quien redacta, aprobadores para quien revisa.
- Nombra al menos a dos personas que puedan aprobar.
- Acordad un plazo de respuesta y una hora límite de envío.
- Decide qué contenido se salta la barrera y dile a los aprobadores que pueden publicarlo directamente.
- Haz una ronda de prueba: envía una publicación, recházala con un motivo, reenvíala y apruébala.
- Comprueba que cada aprobador recibe de verdad la notificación.
Los precios de Pro y Business están en la página de precios. El proceso de aprobación funciona igual sea cual sea la plataforma de destino.
Y ahora qué
Empieza con un cliente o un conjunto de canales, úsalo dos semanas y mira dónde se atascan las publicaciones. Ajusta el plazo o añade un segundo aprobador antes de ampliar la barrera. Cuando estés listo, empieza gratis y añade compañeros cuando pases a Pro.