Equipo de Facebook Ads: del lanzamiento del proyecto al traspaso

Del lanzamiento al traspaso: cómo organizar un espacio de trabajo para un equipo de Facebook Ads en 2026

Un proyecto de Facebook Ads rara vez consiste en una sola cuenta publicitaria. Un equipo también puede trabajar con Meta Business Portfolio, todavía comúnmente llamado Business Manager o BM, páginas de Facebook, Instagram, perfiles de navegador, proxies, métodos de pago, notas internas y distintos niveles de acceso para empleados.

Con solo dos o tres proyectos, estas relaciones son fáciles de recordar. Sin embargo, a medida que el equipo crece, la memoria deja de ser un sistema de gestión. Un especialista recuerda qué perfil pertenece a un cliente, otro sabe dónde se guarda la información de pago y un tercero puede ser la única persona que entiende la estructura actual del proyecto.

Esto se vuelve especialmente visible cuando se incorpora un nuevo empleado o cuando un proyecto debe transferirse a otro media buyer. Si empezar a trabajar requiere abrir varias hojas de cálculo, buscar conversaciones antiguas y hacer una docena de preguntas a los compañeros, el problema ya no es la cantidad de herramientas. El problema es cómo están organizadas esas herramientas.

Por eso, escalar debería empezar con un objetivo simple: cualquier miembro del equipo debería poder entender qué activos pertenecen a un proyecto, dónde se encuentra su entorno de trabajo, quién tiene acceso a él y quién es responsable de mantenerlo actualizado.

Ciclo de vida de un proyecto de Facebook Ads: Configuración → Trabajo → Acceso del equipo → Traspaso

Un proyecto de Facebook Ads es más que una cuenta publicitaria

Resulta más útil pensar en un proyecto como un único contexto de trabajo.

Puede incluir:

• activos comerciales de Meta;
• un entorno de navegador;
• una conexión de red;
• un método de pago;
• miembros del equipo y niveles de acceso;
• estado actual del proyecto;
• tareas abiertas;
• notas internas.

No todos los proyectos necesitan todos los componentes. Lo importante es que exista una relación clara entre los elementos que se utilizan.

Si un empleado puede ver una cuenta publicitaria pero no sabe qué página le corresponde, qué perfil de navegador se usa, quién gestiona los pagos o dónde encontrar el estado actual, el proyecto depende demasiado del conocimiento verbal.

Cuanto más grande se vuelve el equipo, más costosa es esa dependencia.

Empieza con un pasaporte del proyecto

Una de las formas más sencillas de conservar el contexto es crear un breve pasaporte del proyecto.

Puede ser una ficha en el CRM, una hoja de cálculo, un documento interno o un registro en una herramienta de gestión de tareas. El formato importa menos que tener un único lugar que el equipo reconozca como la fuente de información actual del proyecto.

Qué registrar

Un pasaporte del proyecto no debería convertirse en una base de datos con cien campos. Su propósito es proporcionar contexto rápidamente.

Hay una forma sencilla de probar la estructura: alguien que se incorpore al proyecto por primera vez debería poder entender en menos de un minuto qué componentes principales le pertenecen y dónde encontrar el entorno de trabajo.

Si eso requiere enviar mensajes a varios compañeros, la estructura necesita mejorar.

Asigna un responsable

Cada proyecto debería tener un responsable: alguien que entienda su estado actual y pueda explicar la configuración.

Un media buyer, un diseñador, un analista y un líder de equipo pueden trabajar todos en el mismo proyecto. Eso es normal. Pero alguien debe mantener actualizado el pasaporte, el estado y la información de acceso.

De lo contrario, un proyecto pasa gradualmente a estar “a cargo de todos” y, en la práctica, a no estar a cargo de nadie.

Construye el entorno de trabajo

Una vez definida la estructura básica, el equipo puede montar el stack de trabajo del proyecto.

Activos comerciales

Empieza documentando qué activos de Meta ya existen y quién los gestiona.

Si el proyecto utiliza Business Portfolio/BM, cuentas publicitarias, páginas de Facebook, Instagram u otros activos, la propiedad y el acceso deberían estar claros desde el principio.

Cuando Meta ofrece roles y permisos oficiales, por lo general son más fáciles de gestionar que compartir contraseñas repetidamente entre empleados.

Esto también facilita gestionar futuros cambios en el equipo.

Perfil de navegador

La siguiente capa es el entorno de navegador.

Cuando un especialista gestiona varios proyectos, los perfiles de navegador separados ayudan a mantener sesiones, cookies, ajustes, marcadores y otros datos asociados a cada flujo de trabajo.

Undetectable admite perfiles locales y en la nube.

Los perfiles locales se almacenan en un dispositivo específico. Los perfiles en la nube son útiles cuando un entorno de trabajo debe estar disponible desde distintos dispositivos o compartirse con otros miembros del equipo.

Los conjuntos más grandes de perfiles en la nube pueden organizarse en grupos, mientras que el acceso a esos grupos puede asignarse a usuarios específicos. Por ejemplo, los entornos pueden separarse por cliente, GEO o flujo de trabajo.

Esto convierte un perfil de navegador, de ser otra ventana de navegador más, en un componente claramente definido de un proyecto.

Proxies y conexiones

Si se utilizan proxies en el flujo de trabajo —por ejemplo, en equipos distribuidos, para pruebas u otros escenarios permitidos— la conexión también debería formar parte de la estructura del proyecto.

Un proxy guardado como una línea aislada sin contexto puede convertirse rápidamente en “la IP que probablemente usamos para este cliente”.

El pasaporte del proyecto solo necesita registrar el tipo de conexión o identificador relevante, mientras que el proxy en sí puede asociarse con el perfil de navegador adecuado.

Esto elimina la necesidad de que los empleados reconstruyan manualmente la relación cada vez.

Pagos

El método de pago también necesita una titularidad clara.

El equipo debería entender con qué proyecto y cuenta publicitaria se relaciona, qué moneda se utiliza, quién supervisa los gastos y quién es responsable de las cuestiones de facturación.

El acceso también debería seguir basado en roles: los empleados deberían recibir solo la información que realmente necesitan para realizar sus tareas.

Completar el stack del proyecto

Una vez documentadas las relaciones principales, resulta mucho más fácil ver qué recursos ya tiene el proyecto y qué componentes aún deben prepararse.

Por ejemplo, un cliente puede proporcionar un Business Portfolio, una cuenta publicitaria y una página, mientras que el equipo organiza de forma independiente el entorno de navegador y otras herramientas de trabajo.

Los perfiles de navegador y el acceso del equipo pueden organizarse con Undetectable. Si el flujo de trabajo elegido también requiere cuentas de Facebook, Business Manager/BM, Fan Pages, proxies móviles o soluciones de pago para publicidad, estas categorías están disponibles a través de tiendas especializadas como CrazyFB.shop.

La fuente de un componente específico no debería cambiar el principio organizativo general: todo lo que se añada al proyecto debe conectarse de inmediato con su pasaporte, su propósito y el miembro del equipo responsable.

Al utilizar servicios de terceros, los equipos también deberían revisar de forma independiente los términos del producto, los derechos sobre los activos, los requisitos de pago, las políticas de Meta y la legislación aplicable.

Un proyecto, un contexto claro

Una vez completada la configuración, el proyecto debería aparecer ante un empleado como un entorno de trabajo listo, no como una colección de información desconectada.

Un sistema de nombres coherente ayuda.

En lugar de:

Perfil 1 Nuevo perfil Prueba DE

usa algo como:

ClientA_DE_Main

o:

Brand_GEO_Project_Owner

No existe un único formato de nombres correcto. Lo importante es que todo el equipo siga la misma lógica.

El mismo principio puede aplicarse a grupos de perfiles, notas internas, carpetas y fichas de proyecto.

La regla es simple: un nombre debería ayudar a alguien a entender qué es un objeto sin tener que hacer otra pregunta en el chat.

Cliente A → Grupo de perfiles → Perfil de navegador → Activos comerciales → Responsable

Qué debería ver un media buyer antes de empezar a trabajar

Antes de abrir Ads Manager, el especialista ya debería saber:

• en qué proyecto está trabajando;
• qué activos comerciales le pertenecen;
• qué perfil de navegador debe usar;
• qué conexión pertenece al entorno, si es necesaria;
• qué permisos tiene;
• quién es responsable de los pagos;
• qué tareas están activas actualmente;
• con quién contactar cuando el acceso necesite cambiar.

Para un equipo pequeño, esto puede parecer administración extra. En la práctica, estas reglas básicas ahorran tiempo en cuanto varios empleados y proyectos están activos al mismo tiempo.

En lugar de preguntar “¿Qué perfil es el nuestro?” o “Envíame el BM correcto”, el especialista abre el pasaporte del proyecto y obtiene de inmediato el contexto esencial.

Qué cambia cuando se incorpora un segundo empleado

Esta suele ser la primera prueba real del sistema operativo.

Si todo el contexto del proyecto existe únicamente en el ordenador del primer media buyer y en notas personales, añadir otra persona se convierte en una migración manual.

Hay que transferir ajustes, explicar la estructura, encontrar la información actual y reconstruir decisiones anteriores.

En flujos de trabajo de equipo, algunos entornos pueden organizarse mediante perfiles en la nube de Undetectable.

Los perfiles pueden agruparse por proyecto o flujo de trabajo, mientras que el acceso a grupos específicos puede proporcionarse a los usuarios que realmente lo necesitan.

Como resultado, el entorno de trabajo se vuelve menos dependiente de un solo ordenador y de una sola persona.

El principio del mínimo acceso necesario sigue siendo útil en todo el stack: alguien asignado a un proyecto normalmente no necesita visibilidad sobre todos los entornos que posee el equipo.

Cómo traspasar un proyecto sin caos

Un traspaso es una prueba de estrés útil para cualquier sistema interno.

Si un proyecto está organizado correctamente, el especialista entrante no debería tener que empezar con:

“¿Dónde está todo?”

Un traspaso puede seguir una secuencia sencilla:

1. Actualizar el pasaporte del proyecto.
2. Revisar los activos comerciales y el acceso actual.
3. Transferir el perfil de navegador requerido o el acceso a su grupo.
4. Comprobar la conexión y los ajustes de trabajo.
5. Registrar las tareas actuales y el estado del proyecto.
6. Asignar el nuevo responsable o responsable de respaldo.
7. Revisar los permisos anteriores una vez completada la transferencia.

El objetivo de un traspaso es transferir contexto, no solo credenciales.

Si el especialista entrante recibe acceso pero aún no entiende la estructura del proyecto, el traspaso no está completo.

Traspaso: Responsable actual → Pasaporte del proyecto + Espacio de trabajo → Nuevo responsable

Qué comprobar después del traspaso

Algunos problemas aparecen solo después del traspaso.

Un exempleado conserva el acceso “por si acaso”, el pasaporte del proyecto nunca se actualiza o la información importante permanece dentro de una conversación privada.

Después de una transferencia, comprueba que:

• el nuevo responsable esté registrado en el pasaporte;
• se hayan revisado los permisos anteriores;
• los empleados correctos puedan acceder al entorno de trabajo;
• los estados y notas estén actualizados;
• las tareas abiertas se hayan transferido;
• la información crítica no esté almacenada únicamente en el dispositivo del empleado anterior;
• el equipo sepa quién es ahora responsable del proyecto.

Esto le da al traspaso un punto final claro, en lugar de dejar el proyecto en un estado intermedio incierto.

Checklist de un espacio de trabajo listo para trabajar

Antes de considerar que un proyecto está completamente listo, verifica que:

• el proyecto tenga un nombre y un responsable claros;
• los principales activos comerciales estén documentados en un solo lugar;
• los roles y permisos coincidan con las responsabilidades de los empleados;
• el perfil de navegador sea fácil de identificar;
• el proxy u otra conexión, si se utiliza, esté asociado con el entorno correcto;
• la estructura de pagos esté clara para los miembros del equipo responsables;
• el estado actual y las tareas abiertas estén documentados;
• la información crítica no exista únicamente en chats privados;
• exista un proceso claro para entregar el proyecto a otro especialista.

Si el equipo puede completar esta checklist sin buscar en conversaciones antiguas, el espacio de trabajo está mucho mejor preparado para crecer.

De una colección de herramientas a un sistema de trabajo

Un equipo de Facebook Ads puede utilizar docenas de servicios, pero la cantidad de herramientas dice poco sobre la calidad de sus procesos.

Lo que importa es que cada componente tenga un lugar claro: los activos comerciales estén conectados a un proyecto, el entorno de navegador esté conectado a flujos de trabajo específicos, el acceso esté conectado a miembros del equipo y los cambios importantes no existan solo en el historial del chat.

En esta estructura, Undetectable puede cubrir la capa del entorno de navegador mediante perfiles locales y en la nube, grupos de perfiles y gestión del acceso del equipo.

El propio equipo todavía necesita conectar esos elementos en un único sistema operativo.

Si un proyecto puede abrirse, entenderse, compartirse con un nuevo empleado, traspasarse a otro especialista y continuarse sin reconstruir el contexto a partir de mensajes antiguos, el proceso funciona como debería.

Eso es lo que permite a un equipo escalar no solo campañas de Facebook Ads, sino también el trabajo que las rodea.