Equipo · Aprobaciones
Cada visto bueno, en una sola bandeja
Las revisiones de la Biblioteca, los planes de campaña, las solicitudes de lanzamiento y los días libres esperan en un mismo sitio, y cada uno se decide con las reglas de la herramienta a la que pertenece. Crea un espacio de trabajo y envía tu primer plan a aprobación, o descubre cómo funciona.
¿Ya tienes un espacio de trabajo? Iniciar sesión
- Planes desde 99 $ al mes
- Pensado para agencias con varios clientes
- Tu marca en toda la consola
Equipo · Aprobaciones
Software de flujo de aprobación para agencias, con una sola bandeja para cada decisión
En la mayoría de las agencias, un visto bueno es un mensaje de chat que dice «perfecto, mándalo». No está vinculado a ninguna versión, nadie lo encuentra un mes después y el compañero que editó el archivo más tarde nunca lo vio. Aprobaciones, en AI Marketing Dashboard, es un software de flujo de aprobación que lo sustituye, construido en torno a una sola bandeja. Los recursos de la Biblioteca enviados a revisión, los planes de campaña enviados a aprobación, los lanzamientos que alguien ha pedido y las solicitudes de días libres esperan allí, y cada uno lo decide una persona autorizada a hacerlo, con las reglas de la herramienta a la que pertenece. Un plan editado después de aprobarse lo dice, y un lanzamiento no puede salir amparado en un sí antiguo.
Chat o bandeja
Dónde se guarda un sí decide si se puede confiar en él
Un visto bueno vale lo que valga el registro que deja. Compara un pulgar hacia arriba en un hilo con una decisión tomada donde las reglas pueden verla.
Visto bueno por mensaje
- Un sí en un hilo de chat, sin vínculo con ninguna versión
- Una aprobación por email que la siguiente persona nunca ve
- Un plan editado después del visto bueno, sin avisar a nadie
- Un lanzamiento pedido con un toque en el hombro
- Unos días libres decididos en el primer mensaje que llegó
Cada sí fue sincero, y ninguno se puede comprobar después.
Visto bueno en una sola bandeja
- Hasta cinco pestañas reúnen lo que espera a una persona
- La aprobación de un plan cubre el plan tal como se aprobó
- Un plan devuelto, o un lanzamiento o unos días libres rechazados, llevan un motivo por escrito
- Las solicitudes de lanzamiento esperan a alguien con el permiso «Publish»
- Las filas de planes, lanzamientos y Biblioteca abren el registro del que tratan
Cada decisión conserva las reglas de la herramienta a la que pertenece, así que la bandeja no añade ningún atajo.
La bandeja
Despeja las decisiones de la mañana de una pasada
Todo lo que espera a una persona aparece ordenado por lo que es y por quién tiene que mover ficha, así que los diez primeros minutos del día son un repaso a una sola página.
Decisiones de la Biblioteca, de lanzamientos y de días libres sin saltar de pestaña en pestaña
- Pestañas «All», «Library», «Plans», «Launches» y «Time off», y «Time off» solo para administradores
- Los planes aprobados siguen en la lista durante 14 días
- Un filtro de cliente que parte del cliente del selector de la cabecera
El camino de un plan
De un plan enviado a un lanzamiento al que se permite salir
Cuatro movimientos llevan un plan de la persona que lo construyó a la persona que lo publica, y cada uno deja un registro.
Envía con una persona que revise
Quien construye el plan lo envía a aprobación y puede nombrar a una persona que revise. Aparece una tarea de revisión en el proyecto «Marketing Plans» del cliente, con vencimiento en tres días y asignada a quien revisa si se ha nombrado a alguien, y la campana y un email avisan a quien tiene que decidir.Decide sobre el plan tal como está
Quien aprueba lo aprueba, o lo devuelve con una nota. Quien envía un plan no puede aprobar el suyo. Un administrador de la agencia sí puede, y el historial registra que lo hizo.Ábrelo en Lanzar
Un plan aprobado aparece en «Ready to launch» en la página de lanzamientos de su canal. Si editas antes el plan, se señala como cambiado y se rechaza el lanzamiento hasta que se apruebe de nuevo.Pídeselo a quien publica si tú no puedes
Un compañero sin el permiso «Publish» presenta en su lugar una solicitud de lanzamiento. Quien tiene permiso de publicación lee las comprobaciones, aprueba o rechaza con un motivo, y las comprobaciones se ejecutan de nuevo al aprobar.
Ver el recorrido
Mira cómo se decide un recurso de la Biblioteca, un plan y una solicitud de lanzamiento
El recorrido parte de lo que está esperando, abre un recurso tal como lo verá el cliente, lo devuelve con un motivo, aprueba un plan y termina en por qué una solicitud de lanzamiento es una decisión aparte.
- 0:00Mira todo lo que te espera
- 0:06Abre el recurso como lo verá el cliente
- 0:11Devuélvelo con un motivo claro
- 0:20Aprueba un plan tal como está
- 0:29Las solicitudes de lanzamiento son aparte
42 segundos
Leer la transcripción
0:00 Mira todo lo que te espera. Los recursos de la Biblioteca, los planes, los lanzamientos y los días libres llegan a una sola bandeja. Fíltrala por cliente.
0:06 Abre el recurso como lo hará el cliente. Las revisiones de la Biblioteca se abren a pantalla completa y muestran el recurso exactamente como lo ve el cliente.
0:11 Devuélvelo con un motivo claro. «Request changes» necesita una nota. Di qué corregir para que su autor pueda actuar.
0:20 Aprueba un plan tal como está. Alex Morgan, que tiene el rol de administrador de la agencia, aprueba el plan de Jordan Lee exactamente como está escrito.
0:29 Las solicitudes de lanzamiento son aparte. Un lanzamiento espera a alguien con «Publish». Aprobar uno manual solo crea una tarea.
Pon cada decisión donde las reglas puedan verla
Añade a tu equipo y a tus clientes a un espacio de trabajo nuevo, envía después un primer plan a aprobación y mira cómo llega a la bandeja.
Los planes empiezan en 99 $ al mes.
En esta página
Software de flujo de aprobación: una bandeja para revisiones de la Biblioteca, planes, lanzamientos y días libres
Hasta cinco pestañas, un recuento en cada una y un filtro de cliente que sigue al selector
Equipo > Aprobaciones abre una sola página con hasta cinco pestañas: «All», «Library», «Plans», «Launches» y «Time off» (todo, Biblioteca, planes, lanzamientos y días libres). La pestaña «Time off» aparece solo para los administradores de la agencia. Cada pestaña lleva el número de elementos que esperan a una persona, «All» muestra los cinco primeros elementos en espera de cada origen con un enlace «View all» (ver todo), y un filtro de cliente acota el trabajo de clientes a una sola cuenta. El filtro parte del cliente en el que esté el selector de la cabecera, cuando ese cliente tiene algo en la bandeja, y un clic lo amplía a todos los clientes. Los días libres no son trabajo de clientes, así que la pestaña «Time off» ignora el filtro y lo indica con una etiqueta «Workspace-wide» (de todo el espacio de trabajo).
No se copia nada a un segundo sistema. Una revisión de la Biblioteca se sigue decidiendo en su pantalla de revisión, un plan mediante su aprobación, un lanzamiento mediante su registro y los días libres mediante la solicitud correspondiente, así que la bandeja no añade ninguna regla propia ni ningún resquicio. Se actualiza cuando vuelves a la pestaña y cada minuto mientras sigue abierta, y un enlace desde una notificación de un plan o de un lanzamiento, o desde un aviso de la Biblioteca que espera tu decisión, abre la pestaña correcta sobre ese elemento, de modo que quien aprueba llega a aquello por lo que le preguntaron y no a una lista en la que buscar.
Una aprobación cubre el plan exactamente como se aprobó
Si cambias el plan después, aparece como «Changed since approval»
Un visto bueno solo vale algo si sigue describiendo lo que se entrega. Cuando se aprueba un plan de campaña, el servidor registra una huella de su contenido: el nombre, el canal, el tema, las plataformas, la audiencia y los ajustes, las plantillas de la Biblioteca que envía un plan de email y la audiencia guardada a la que apunta un plan de email, de SMS o de pago, es decir, su definición y, en una lista fija, sus miembros. A quién incluye ese día un segmento basado en reglas no forma parte de ella. Si cambias cualquiera de esas cosas más adelante, la huella deja de coincidir. El plan figura entonces como «Changed since approval» (cambiado desde la aprobación) allí donde se muestra su aprobación, y no puede lanzarse hasta que se envíe y se apruebe de nuevo.
La comparación la hace el servidor con el plan tal como está ahora, nunca la pantalla, y se repite donde importa: al crear un lanzamiento, al aprobar una solicitud de lanzamiento y justo antes de que actúe un lanzamiento programado. Un plan editado mientras espera en la cola tampoco puede aprobarse; la bandeja dice que hay que volver a enviarlo. Los recursos de la Biblioteca se revisan de otra manera: llevan un estado, y editar un recurso aprobado no lo restablece, así que quien revisa reabre la revisión cuando el trabajo cambia.
Devuelve el trabajo con un motivo sobre el que su autor pueda actuar
Devolver un plan, o rechazar un lanzamiento o unos días libres, exige un motivo por escrito
Aprobar un plan, un lanzamiento o una solicitud de días libres lleva un clic y una confirmación, con una nota opcional. Pedir cambios lleva un clic y una frase, y la frase es obligatoria: un plan no puede devolverse sin una nota que diga qué cambiar, un lanzamiento no puede rechazarse sin un motivo y una solicitud de días libres tampoco puede rechazarse sin uno. La pantalla de revisión de la Biblioteca también exige una nota cuando pides cambios. El plan vuelve a quien lo envió como «Changes requested» (cambios solicitados), la tarea de revisión regresa a su lista con la nota adjunta y el elemento sale del recuento de espera de quien aprueba.
Así el trabajo de corrección se queda fuera del chat. Quien escribió el trabajo lee el motivo en el sitio donde lo envió, edita y vuelve a enviar, y quien aprueba lo encuentra como un envío nuevo con una huella nueva que comprobar. En la Biblioteca, la pantalla de revisión muestra el recurso tal como lo verá el cliente, y los comentarios pueden fijarse en un punto de la vista previa y mantenerse internos, o compartirse con el cliente por alguien con el permiso «Publish», de modo que el comentario señala el punto exacto en lugar de describirlo de memoria.
La aprobación del cliente ocurre en el portal, sobre el propio recurso
Una solicitud de aprobación, una petición de cambios con pin y una tira de versiones para las creatividades
Una revisión del cliente solo empieza después de que tu equipo haya aprobado el recurso o haya registrado que se omite la aprobación. Alguien con el permiso «Publish» lo comparte en el portal del cliente y pide una respuesta, añadiendo una nota opcional que lee el cliente. En el panel de revisión, un encabezado nombra a tu agencia y dice que pide aprobación. Solo un administrador del portal ve «Approve». Cualquier miembro del portal puede elegir «Request changes», que pide una nota por escrito y puede llevar un pin en el punto exacto. Cuando se sustituyó la imagen de una creatividad durante la revisión, sus versiones anteriores aparecen en una tira, y cada pin recuerda la versión en la que se dejó.
Tu equipo ve la respuesta como «Client approved» (aprobado por el cliente) o «Client requested changes» (el cliente pidió cambios), y quien pidió la revisión y quien envió el recurso reciben un aviso al instante, según sus ajustes de notificación. Un administrador del portal puede retirar una aprobación durante una hora, lo que devuelve el recurso a «Awaiting client review» (a la espera de la revisión del cliente). Cuando vuelven los cambios, editas el recurso y vuelves a pedir la respuesta. Los comentarios internos y el historial de revisión se quedan de tu lado: el portal recibe la nota de la solicitud, la decisión del propio cliente y los comentarios marcados como compartidos. Los portales de cliente forman parte de los planes Scale y Enterprise, mientras que la aprobación interna funciona en todos los planes.
Nadie aprueba su propio plan, y la única excepción queda registrada
Un administrador de la agencia puede aprobar su propio trabajo, y el registro lo dice
Un plan enviado por una persona lo aprueba otra. Si quien lo envió lo intenta, el servidor lo rechaza con un mensaje claro, y la bandeja muestra una indicación donde estaría el botón «Approve» en lugar de ofrecerlo. La persona revisora nombrada en un envío es una orientación, no un cerrojo: cualquier compañero con el permiso de aprobar para ese cliente puede decidir, de modo que la ausencia de una persona no tiene por qué frenar una campaña mientras haya otra con permiso para aprobar cerca, y un envío que no nombra a nadie puede recogerlo cualquiera que apruebe.
Existe una excepción, y deja rastro. Un administrador de la agencia puede aprobar su propio envío, o un plan que nadie envió, y la aprobación se guarda como autoaprobada y así se etiqueta en la bandeja; cuando el plan se envió, su tarea de revisión también lo registra. Para una agencia pequeña en la que la persona propietaria es también quien define la estrategia, eso es contabilidad honesta y no un atajo: el historial muestra quién decidió y que ninguna segunda persona lo hizo.
Las solicitudes de lanzamiento esperan a alguien que pueda publicar
Las comprobaciones previas del servidor se ejecutan de nuevo en el momento de la aprobación
No todas las personas que montan una campaña pueden ponerla en vivo. Lanzar requiere el permiso «Publish» para el cliente, y un lanzamiento de email o de SMS requiere además acceso al CRM del cliente, tanto si lo lanzas como si lo apruebas o lo pides. Un compañero sin «Publish» puede pedirlo igualmente. La solicitud aparece en «Launches» como «Waiting for launch approval» (a la espera de la aprobación del lanzamiento). La fila muestra quién la pidió, su nota y las comprobaciones tal como estaban cuando se hizo la solicitud, avisos incluidos: una plantilla de la Biblioteca que aún no está aprobada, por ejemplo. Una solicitud que no supera una comprobación se rechaza al presentarse, así que una que espera ha superado las comprobaciones bloqueantes. Quien tiene permiso de publicación aprueba o rechaza, y un rechazo necesita un motivo que pueda leer quien hizo la solicitud.
Antes de aprobar, quien publica lee una breve línea de consecuencias: a quién llegará un email y si empieza de inmediato o programado, o que un lanzamiento manual solo crea una tarea para quien publique a mano. Después las comprobaciones se ejecutan de nuevo, porque las cosas cambian entre una solicitud y su aprobación, y una comprobación que falla se enumera en el cuadro de diálogo en lugar de darse por buena. Los lanzamientos de email se envían; los de pago, redes sociales y SMS se registran como hechos a mano, y la bandeja es clara sobre cuál es cuál.
Las decisiones sobre días libres van junto al trabajo de clientes, pero aparte de él
Aprobar o rechazar, y un rechazo siempre se explica
Las solicitudes de días libres no son trabajo de clientes, así que tienen una pestaña propia, visible solo para los administradores de la agencia y etiquetada «Workspace-wide». Cada fila nombra a la persona, el tipo de ausencia, las fechas, los días laborables contados y cualquier nota que dejó, y «Approve» o «Decline» abre el mismo cuadro de diálogo que usan las demás pestañas. Rechazar exige un motivo que leerá quien hizo la solicitud, de modo que una negativa nunca llega como silencio.
Las reglas son las que exigiría recursos humanos. Tus propias solicitudes nunca aparecen en tu bandeja, y nadie decide sobre sus propios días libres mientras exista otro administrador de la agencia activo. Solo en un espacio de trabajo con un único administrador puede alguien decidir sobre su propia solicitud, y el registro muestra entonces que fue una autodecisión. Quien hizo la solicitud conoce el resultado por email, el servidor calcula una sola vez el número de días para que la cifra aprobada coincida con la que esa persona vio, y el perfil del miembro queda a un clic para dar contexto. El permiso no puede delegarse en un responsable de equipo: se queda con los administradores.
«Also waiting»: recuentos del trabajo que se decide en otro sitio
Los partes de horas y los guiones de reserva se cuentan aquí y se revisan en sus propias herramientas
Algunas aprobaciones necesitan más espacio que una fila. Los partes de horas se revisan en el Registro de horas con una semana entera a la vista, y las revisiones de los guiones de reserva se revisan junto al guion. La bandeja los deja donde mejor funcionan y añade una tarjeta, «Also waiting», con un recuento y un enlace «Open» para cada uno, de modo que un administrador que empieza el día aquí sabe igualmente cuántas entradas esperan sin abrir una segunda herramienta para averiguarlo.
Los recuentos son honestos o no aparecen. Cada origen informa de su propio estado, y el que no llega a cargarse muestra una tarjeta de error con un reintento en lugar de un cero; un recuento que no pudo leerse se omite, nunca se muestra como ninguno. La misma regla vale para toda la página: una lectura rota de la Biblioteca no puede dejar en blanco la pestaña «Plans», y una cola larga dice cuándo se ha recortado en los elementos más recientes en lugar de dar a entender que eso es todo.
Una matriz de aprobación: quién decide qué y con qué permiso
Esto se acuerda una vez, antes del primer lanzamiento, y cada discusión posterior sobre quién debería haber aprobado algo se acorta. La tabla indica lo que la consola hace cumplir hoy, fila por fila.
| Qué está esperando | Quién lo envía | Quién lo decide | ¿Una segunda persona? | Qué hace la decisión |
|---|---|---|---|---|
| Un recurso de la Biblioteca: tema, lista de palabras clave, textos, creatividad, landing page, página de reservas, formulario o email | Cualquiera que pueda editar la Biblioteca | Cualquiera con el permiso «Approve» (aprobar) para ese cliente | No se exige: quien aprueba puede aprobar lo que envió | Un recurso aprobado, o uno cuya aprobación se omitió, puede compartirse con el cliente |
| La revisión de un cliente sobre un recurso compartido | La agencia lo pide, con el permiso «Publish» (publicar) | El cliente: un administrador del portal aprueba, y cualquier miembro del portal puede pedir cambios | El cliente es la otra parte | La respuesta queda registrada en la revisión, y una aprobación se puede deshacer en una hora |
| Un plan de campaña | Cualquiera que pueda editar la Biblioteca | Cualquiera con el permiso «Approve» para ese cliente | Sí, salvo un administrador de la agencia, y la excepción queda registrada | El plan puede lanzarse, siempre que nadie lo edite después |
| Una solicitud de lanzamiento | Cualquiera que pueda editar la Biblioteca, con acceso al CRM para email y SMS | Cualquiera con el permiso «Publish» para ese cliente, con acceso al CRM para email y SMS | Siempre: sin «Publish» no se puede lanzar, así que decide quien tiene permiso de publicación | Un lanzamiento de email empieza o se programa, y un lanzamiento manual crea una tarea |
| Una solicitud de días libres | Cualquier miembro del equipo, para sus propios días libres | Solo un administrador de la agencia | Sí, mientras exista otro administrador de la agencia activo | Registra aprobado o rechazado con el motivo, y envía un email a quien hizo la solicitud |
Por defecto, un miembro del equipo de la agencia puede ver, crear y editar recursos y planes de la Biblioteca, lo que significa que puede enviar planes a aprobación pero no aprobar ni publicar. Una solicitud para lanzar una campaña de email o de texto exige además que quien la hace tenga acceso al CRM, algo que los miembros del equipo no tienen por defecto. Los administradores de la agencia tienen todos los permisos. Un administrador puede conceder «Approve» o «Publish» a un responsable, de uno en uno o mediante una plantilla de permisos, y un compañero actúa solo sobre los clientes que tiene asignados. Las decisiones sobre días libres no se pueden delegar en absoluto.
Consejo
Escribe la matriz antes del primer lanzamiento
Para cada cliente, nombra quién aprueba los planes y quién publica, y haz que sean personas distintas siempre que puedas. Donde una misma persona tenga que hacer ambas cosas, la consola lo registra, que es la alternativa honesta a fingir que miró un segundo par de ojos.
Quien envía, quien revisa, quien aprueba, quien publica y quien solicita, en palabras sencillas
Las mismas cinco palabras aparecen en todas las pestañas. Cada una significa una sola cosa.
- Quien envía
- La persona que envía un plan a aprobación. Edita y envía, y no puede aprobar su propio plan salvo que sea administrador de la agencia.
- Quien revisa
- La persona que quien envía designa en un plan. El nombre es orientativo: elige a quién se avisa y quién es responsable de la tarea de revisión, y cualquier persona que apruebe puede decidir igualmente.
- Quien aprueba
- Cualquiera que tenga el permiso «Approve» para el cliente. Quienes aprueban deciden las revisiones de la Biblioteca y las aprobaciones de planes.
- Quien publica
- Cualquiera que tenga el permiso «Publish» para el cliente. Quienes publican lanzan planes aprobados, deciden las solicitudes de lanzamiento y piden a los clientes que revisen recursos de la Biblioteca.
- Quien solicita
- La persona que pidió un lanzamiento sin tener el permiso «Publish». Puede cancelar su propia solicitud mientras espera.
Sacar los vistos buenos del chat y del email en cuatro pasos
La gente sigue aprobando en el sitio donde ya habla. Una implantación funciona cuando la bandeja es más fácil que el mensaje, así que empieza con un cliente y un tipo de decisión.
Haz la lista de los síes que das hoy
Durante una semana, anota cada visto bueno que ocurra en el chat o en el email: una creatividad, una landing page, una campaña, un lanzamiento, un día libre. Ordénalos en las cuatro cosas que contiene la bandeja y deja el resto donde están.
Nombra a quienes aprueban por cliente
Elige quién aprueba los planes y quién publica para cada cliente, concede esos permisos y asigna a esas personas al cliente. Un compañero que no está asignado a un cliente no verá su trabajo en la bandeja.
Prueba con un cliente durante dos semanas
Pide a quienes envían que nombren a una persona que revise y que pongan el motivo en la nota. Cuando alguien pida un sí por chat, responde que está en la bandeja y decídelo allí. La tarea de revisión, la campana y un email ya avisan a quien revisa, así que la mayoría se entera sin que haga falta insistir.
Haz de la bandeja el único sí
Pasadas dos semanas, pasa al siguiente cliente. Di al equipo que la consola rechaza de todos modos un lanzamiento sin un plan aprobado, y empieza cada día en la pestaña «All», tratando un recuento por encima de cero como la primera tarea.
De qué te protege «Changed since approval» (cambiado desde la aprobación)
El aviso no es una insistencia. Marca el momento en que un plan dejó de ser aquel con el que alguien estuvo de acuerdo.
| Estado | Qué significa | Qué ocurre después |
|---|---|---|
| «Pending» (pendiente) | Enviado y a la espera de quien aprueba | Quien revisa decide: lo aprueba o lo devuelve con una nota |
| «Changes requested» (cambios solicitados) | Devuelto a la persona que lo envió | Esa persona edita el plan y lo envía de nuevo |
| «Approved» (aprobado) | Quien aprueba aceptó el plan tal como estaba | Puede lanzarse desde la página de lanzamientos de su canal |
| «Changed since approval» | El plan se editó después de aprobarse | Necesita una nueva aprobación antes de poder lanzarse |
La comparación lee tres cosas: el propio plan, las plantillas de email de la Biblioteca que envía un plan de email y cualquier audiencia guardada detrás de un plan de email, de SMS o de pago: la definición de la audiencia y, en una lista fija, quiénes la forman. Cuenta una edición de cualquiera de ellas, incluida una edición de una plantilla que comparten otras campañas. Un segmento definido por reglas puede coincidir con personas distintas el día del envío sin dejar obsoleta la aprobación. Un envío pendiente que se editó mientras esperaba no puede aprobarse, y su fila dice que hay que volver a enviarlo.
Conviene conocer dos límites. Si un plan se edita después de programarse un lanzamiento, el proceso que ejecuta los lanzamientos programados vuelve a comparar justo antes de actuar, y el lanzamiento falla entonces con una explicación clara y sin enviar nada. Y los recursos de la Biblioteca funcionan de otra manera: llevan un estado de revisión en lugar de una huella del contenido, así que una edición de un recurso aprobado deja su revisión como estaba. Reabre la revisión cuando el trabajo cambie.
Una pasada de diez minutos por la bandeja para quien aprueba
La bandeja está pensada para despejarse desde arriba. Este orden pone primero las decisiones que bloquean a otras personas.
Empieza por «All»
Lee los recuentos de las pestañas. Si el selector de la cabecera ha acotado el filtro de cliente a una cuenta, amplíalo primero, para que nada espere detrás de un filtro que habías olvidado.
Atiende primero las solicitudes de lanzamiento
Alguien está esperando para publicar. Lee las comprobaciones y la consecuencia en una línea, y después aprueba o rechaza con un motivo. Una comprobación que falla aparece en el cuadro de diálogo y retiene la aprobación.
Después los planes
Abre cada plan desde su fila. Una fila señalada como editada tras el envío no puede aprobarse, así que pide un nuevo envío en lugar de esperar. Pide cambios con una nota que diga qué cambiar.
Después la Biblioteca
Abre cada revisión tal como la verá el cliente. Aprueba, pide cambios u omite la aprobación, lo que registra que nadie revisó el recurso y no se muestra como aprobado. Fija un comentario en el punto que quieres señalar.
Termina con los días libres y «Also waiting»
Los administradores deciden los días libres al final, con un motivo en cada rechazo. Si la tarjeta «Also waiting» muestra entradas de partes de horas o revisiones de guiones de reserva, abre el Registro de horas o Guiones de reserva desde sus enlaces.
Tres hábitos mantienen corta la pasada: enviar con una nota, nombrar a quien revisa y decidir en la bandeja en lugar de en el chat. La bandeja vuelve a leerse cada vez que regresas a la pestaña y una vez por minuto mientras sigue abierta, así que puedes dejarla abierta y volver a un recuento al día.
Lo que la bandeja no hace, para que nadie dé por hecho que lo hace
Una cola de decisiones solo es fiable cuando sus límites están claros.
- La bandeja no envía recordatorios y no escala. El envío de un plan hace sonar la campana y envía un email a quien revisa, o a todas las personas que aprueban del cliente cuando no se nombra a nadie, y crea una tarea de revisión con vencimiento en tres días, así que la fecha de esa tarea en Proyectos es el recordatorio. El resumen de la mañana, enviado por defecto en los días laborables, también enumera las revisiones de la Biblioteca, las entradas de horas y los días libres que esperan tu decisión, pero no los planes ni las solicitudes de lanzamiento. Un envío a la Biblioteca avisa a quienes aprueban y no crea ninguna tarea. Un elemento espera hasta que una persona lo decide.
- Salvo el email, hoy no publica ni envía por ti. Un lanzamiento de pago, de redes sociales o de SMS se registra como hecho a mano: la aprobación crea una tarea y una exportación de la especificación congelada, y alguien lo marca como lanzado, publicado o enviado. Un lanzamiento de email es la excepción, y envía.
- No decide los partes de horas ni los guiones de reserva. Esos se cuentan en «Also waiting» y se deciden en sus propias herramientas.
- No muestra planes, lanzamientos ni la bandeja a los clientes. Un cliente ve en el portal los recursos de la Biblioteca que compartes con él, y revisa los que le pides que revise.
- Muestra a cada persona los clientes que puede ver. «Approve» y «Decline» aparecen solo donde se tiene el permiso, una fila de plan o de lanzamiento en espera que no se puede decidir dice quién puede, y la pestaña «Time off» aparece solo para los administradores.
- No vuelve a lanzar un plan cuyo lanzamiento ha terminado. Para enviarlo de nuevo, duplica el plan y aprueba la copia. Un lanzamiento fallido, cancelado o rechazado puede volver a intentarse.
Dónde encaja la aprobación propia del cliente
Los planes y los lanzamientos son decisiones internas. El visto bueno del cliente se aplica a los recursos de la Biblioteca que compartes con él.
Aprueba primero internamente
Un recurso puede compartirse con un cliente cuando quien aprueba por parte de la agencia lo ha aprobado o ha omitido la aprobación. Los recursos ya compartidos antes de que existieran las aprobaciones se etiquetan como compartidos y nunca se bloquean.
Comparte y pide la revisión
Alguien con el permiso «Publish» comparte el recurso y pide la revisión del cliente, con una nota opcional que el cliente ve junto con la solicitud. Los comentarios marcados como compartidos también los ve el cliente.
El cliente responde en el portal
Un administrador del portal aprueba, y cualquier miembro del portal puede pedir cambios. Ambas cosas ocurren sobre el recurso tal como lo ve el cliente, con comentarios que puede fijar en el punto que quiere señalar.
Deshacer, reabrir o volver a pedir
El cliente puede deshacer una aprobación en el plazo de una hora. Tras una petición de cambios, editas y vuelves a pedir. Puedes retirar la solicitud mientras está con el cliente, y reabrir la revisión una vez aprobada u omitida.
En la bandeja, estos recursos aparecen en «With the client» (con el cliente), en la pestaña «Library», hasta que el cliente los aprueba, y después en «Decided» (decididos). Si el cliente pide cambios, se quedan en «With the client» hasta que vuelves a pedir o retiras la solicitud. La revisión del cliente necesita el portal de cliente, que viene con los planes Scale y Enterprise. Las imágenes son un caso habitual, y la gestión de creatividades muestra cómo las versiones y la revisión viven en la propia creatividad.
Preguntas frecuentes
¿Qué debería cubrir el software de flujo de aprobación de una agencia?
Cuatro cosas suelen necesitar una decisión con responsable: la creatividad y los textos antes de llegar a un cliente, los planes de campaña antes de comprometer dinero, los lanzamientos antes de que nada salga en vivo y los días libres antes de prometerlos. Esta bandeja reúne las cuatro, con las reglas de cada herramienta intactas, de modo que el flujo es un conjunto de permisos y registros y no un documento que nadie abre.
¿Qué planes incluyen la bandeja de aprobaciones?
La bandeja está en todos los planes. Lo que llega a ella depende del plan: los planificadores y lanzamientos de pago y de redes sociales necesitan el plan Agency o superiores, los planificadores de email y de SMS vienen con todos los planes, y la revisión propia de un cliente sobre un recurso de la Biblioteca necesita el portal de cliente en Scale o Enterprise. Las decisiones sobre días libres están disponibles para los administradores de la agencia en cualquier plan.
¿Quién puede aprobar un plan o un recurso de la Biblioteca?
Cualquiera que tenga el permiso «Approve» para ese cliente. Los administradores de la agencia lo tienen automáticamente, y un administrador puede concedérselo a un responsable. Por defecto, un miembro del equipo puede editar y enviar, pero no aprobar ni publicar. Los miembros del equipo también actúan solo sobre los clientes que tienen asignados, así que quien aprueba ve la bandeja filtrada a sus propias cuentas.
¿Puedo aprobar mi propio trabajo en la bandeja de aprobaciones?
Depende del tipo de elemento. Un plan no puede aprobarlo quien lo envió salvo que sea administrador de la agencia, y entonces la aprobación se registra como autoaprobada. Las revisiones de la Biblioteca no exigen una segunda persona, así que quien aprueba puede aprobar lo que envió. Nadie decide sobre sus propios días libres mientras otro administrador pueda hacerlo.
¿Qué pasa si un plan se edita después de aprobarse?
Figura como «Changed since approval», en la bandeja para las aprobaciones de los últimos 14 días y en las páginas del plan y de lanzamientos, y no puede lanzarse hasta que se envíe y se apruebe de nuevo. El servidor compara el contenido aprobado con el plan tal como está cuando se crea o se aprueba un lanzamiento, y otra vez justo antes de que actúe un lanzamiento programado, de modo que el contenido aprobado no puede salir convertido en otro.
¿Aprobar un lanzamiento lo publica o lo envía automáticamente?
Los lanzamientos de email se envían. Hoy, aprobar un lanzamiento de pago, de redes sociales o de SMS crea una tarea y una especificación exportada para que una persona la ejecute, y después quien tiene permiso de publicación marca el lanzamiento como lanzado, publicado o enviado, con un enlace opcional. La consola no publica en redes sociales ni envía mensajes de texto.
¿Ven los clientes la bandeja de aprobaciones o sus planes?
No. La bandeja es interna, y los planes y los lanzamientos nunca se muestran en el portal. Un cliente ve los recursos de la Biblioteca que compartes con él, en su propio portal con su marca, y revisa los que le pides que revise: un administrador del portal puede aprobar, y cualquier miembro del portal puede pedir cambios. El portal viene con los planes Scale y Enterprise.
¿La bandeja recuerda a quienes aprueban o escala los elementos que llevan tiempo esperando?
La bandeja no envía emails de recordatorio ni escala. El envío de un plan hace sonar la campana y envía un email a quien revisa, o a todas las personas que aprueban del cliente cuando no se nombra a nadie, y crea una tarea de revisión con vencimiento en tres días. Un envío a la Biblioteca avisa a quienes aprueban y no crea ninguna tarea. El resumen matinal de los días laborables enumera las revisiones de la Biblioteca, las entradas de horas y los días libres que esperan tu decisión. Un elemento espera hasta que alguien lo decide, así que usa los recuentos y las fechas de las tareas para reclamarlo.
¿Y si una parte de la bandeja no llega a cargarse?
Cada origen informa de su propio estado. Una lectura fallida muestra una tarjeta de error con un reintento solo en esa pestaña, y las demás pestañas siguen funcionando. Un recuento que el servidor no pudo leer se omite en lugar de mostrarse como cero, y una lista cortada en su límite lo dice, de modo que una pestaña vacía nunca esconde trabajo sin leer.
¿En qué se diferencia la bandeja del Centro de actividad?
El Centro de actividad es un feed de lo ocurrido en toda la consola, con filtros y estado de lectura. La bandeja de aprobaciones es donde se toman las decisiones, con sus reglas: quién puede aprobar, qué cubre la aprobación y qué ocurre después. Muchos elementos aparecen en ambos, y una notificación sobre una aprobación abre su fila aquí.