Aprende a planificar y construir una app web para agencias de marketing que gestione campañas, activos y aprobaciones de clientes, con roles, flujos de trabajo e historial listo para auditoría.
Antes de dibujar pantallas o elegir una pila tecnológica, aclara el problema central: las campañas de marketing y las aprobaciones están dispersas entre correo, chat y unidades compartidas. Una app web de campañas debe centralizar briefs, activos, feedback y firmas en un solo lugar para que todos vean qué sigue, sin perseguir hilos.
La mayoría de los flujos de aprobación en agencias involucran cuatro grupos, cada uno con necesidades distintas:
Las aprobaciones por correo crean problemas previsibles: plazos perdidos porque nadie ve la última solicitud, feedback poco claro como “hazlo más potente” sin especificaciones, múltiples versiones circulando y ciclos de rework por entradas tardías o contradictorias.
Define resultados medibles para juzgar si el producto funciona:
Para la v1, céntrate en el conjunto mínimo que mantenga juntas campañas y aprobaciones:
Guarda para después los extras agradables: informes avanzados, integraciones profundas, reglas de automatización y caminos de aprobación personalizados.
Antes de pensar en pantallas o tecnología, describe cómo se mueve realmente el trabajo en tu agencia. Un flujo claro convierte “¿Dónde está esto?” en un conjunto predecible de pasos que tu app puede imponer, automatizar e informar.
La mayoría de las apps de aprobación de campañas se describen con unos pocos bloques:
Documenta las relaciones: una campaña contiene proyectos; los proyectos contienen tareas; las tareas generan activos; los activos pasan por aprobaciones.
Un flujo simple y amigable para una agencia es:
Borrador → Revisión interna → Revisión cliente → Aprobado
Haz que cada estado signifique algo operacionalmente. Por ejemplo, “Revisión interna” podría requerir la firma del lead creativo y del account manager antes de que el cliente lo vea.
Decide cómo será el feedback en tu producto:
La clave es vincular el feedback a una versión del activo, para que no haya discusiones sobre qué archivo revisó el cliente.
Atrasos comunes: esperar a revisores, pasos siguientes poco claros y configuraciones repetidas. La automatización que más ayuda:
Las aprobaciones reales no siempre son limpias. Planifica para:
Si puedes describir estas reglas en lenguaje claro, estarás listo para convertirlas en pantallas y modelos de datos.
Una UX excelente comienza con una jerarquía de información simple que refleje cómo ya piensan las agencias: Cliente → Campaña → Entregables (activos). Si los usuarios siempre pueden responder “¿Dónde estoy?” y “¿Qué sigue?”, las aprobaciones avanzan más rápido y menos cosas se pierden.
Usa el cliente como ancla de nivel superior, luego muestra las campañas y finalmente los entregables (anuncios, emails, landing pages, publicaciones sociales). Mantén la misma estructura en la navegación, migas de pan y búsqueda para que las personas no tengan que reaprender la app en cada pantalla.
Una regla práctica: cada entregable debe mostrar siempre su cliente, campaña, fecha de entrega, estado y responsable de un vistazo.
Dashboard: La base de operaciones de la agencia. Enfócate en lo que necesita atención hoy: fechas próximas, ítems esperando revisión interna y items esperando aprobación del cliente.
Cronograma de campaña: Una vista tipo calendario o por fases que haga evidentes las dependencias (p. ej., “Copy aprobado” antes de “Diseño final”). Manténlo legible: la gente debe entender el progreso en segundos.
Vista de revisión de activos: Aquí se gana o se pierde tiempo. Haz la previsualización grande, los comentarios fáciles de encontrar y la próxima acción clara.
Bandeja de entrada: Un lugar único para “cosas que debo responder” (nuevo feedback, solicitudes de aprobación, menciones). Esto reduce el ping-pong entre correo y chat.
Los filtros rápidos deben responder consultas habituales:
La llamada a la acción principal debe ser obvia: Aprobar / Solicitar cambios. Mantenla fija en la vista de revisión (footer/header adhesivo) para que los clientes no la busquen tras desplazarse por los comentarios.
Los clientes revisan entre reuniones. Prioriza la legibilidad móvil: previsualización limpia, botones grandes y formularios breves para feedback. Si un toque abre el activo y otro aprueba, verás tiempos de respuesta más rápidos.
Una app de aprobación de campañas vive o muere por la confianza: los clientes deben sentirse seguros de ver solo lo que deben, y tu equipo necesita límites claros para que el trabajo no se sobrescriba o apruebe por la persona equivocada.
La mayoría de agencias cubren sus necesidades con cinco roles:
En lugar de solo permisos globales, define acciones por tipo de objeto (campaña, entregable, activo, comentario). Acciones típicas: ver, comentar, subir, aprobar, editar y eliminar.
Un valor por defecto práctico es “mínimos privilegios”: los colaboradores pueden subir y editar sus propios activos, pero borrar o cambiar ajustes de campaña está restringido a managers/admins.
Los clientes deben ver solo sus campañas, activos y conversaciones. Evita carpetas compartidas que puedan exponer cuentas ajenas. Lo más sencillo es que cada campaña esté ligada a una cuenta de cliente y que los checks de acceso se apliquen en todas las páginas, descargas y notificaciones.
Soporta dos modos por entregable:
Ofrece enlaces para compartir por conveniencia, pero mantenlos privados por defecto: tokens con tiempo limitado, contraseña opcional y capacidad de revocación.
Una buena regla: compartir no debe eludir el límite del cliente; solo debe conceder acceso a ítems que ese usuario ya podría ver.
Una funcionalidad de aprobaciones vive o muere por la claridad. Si tu equipo y tus clientes no pueden saber qué está esperando a quién, las aprobaciones se atascan y “aprobado” deja de ser incontestable.
Empieza con pocos estados que todos reconozcan:
Evita añadir un estado por cada caso límite. Si necesitas más matices, usa etiquetas (p. ej., “revisión legal”) en lugar de explotar el workflow.
Trata cada subida como una nueva versión inmóvil. No reemplaces archivos en el sitio: crea v1, v2, v3… vinculadas al mismo activo.
Esto soporta conversaciones limpias (“Por favor, actualiza v3”) y previene pérdidas accidentales. En la UI, deja claro cuál es la versión actual y permite abrir versiones previas para comparar.
Los comentarios libres son caóticos. Añade estructura:
Si admites timecodes (vídeo) o pins por página/región (PDF/imagenes), el feedback será mucho más accionable.
Cuando alguien aprueba, registra:
Tras la aprobación, define reglas: típicamente bloquea ediciones en la versión aprobada, pero permite crear una revisión menor como nueva versión (que restablece el estado a En revisión). Esto mantiene las aprobaciones defendibles sin impedir ajustes de última hora.
Las aprobaciones creativas dependen de que las personas accedan al archivo correcto en el momento adecuado. La gestión de activos es donde muchas apps de campaña se vuelven frustrantes: descargas lentas, nombres de archivo confusos y bucles de “¿qué versión es la final?”.
Un patrón limpio es: almacenamiento de objetos para los archivos binarios (rápido, escalable, económico) y una base de datos para los metadatos (buscable y estructurado).
Tu BD debe rastrear nombre del activo, tipo, campaña, versión actual, quién lo subió, timestamps, estado de aprobación y URLs de previsualización. La capa de almacenamiento contiene el binario y opcionalmente items derivados como miniaturas.
Apunta a un conjunto pequeño que cubra la mayoría de flujos:
Sé explícito en la UI sobre qué puede subirse vs. qué es solo enlace. Eso reduce fallos de subida y tickets de soporte.
Las previsualizaciones aceleran la revisión. Genera:
Esto permite que los stakeholders hojeen un dashboard de entregables sin bajar archivos en alta resolución.
Define límites de archivo desde el inicio (tamaño máximo, cantidad por campaña, extensiones soportadas). Valida tipo y contenido (no confíes solo en la extensión). Si trabajas con clientes enterprise o aceptas archivos grandes, considera escaneo antivirus/malware en el pipeline de subida.
Las aprobaciones suelen necesitar trazabilidad. Decide qué significa “eliminar”:
Combínalo con políticas de retención (p. ej., mantener activos 12–24 meses después del fin de campaña) para que los costes de almacenamiento no crezcan sin control.
Una app de campañas con aprobaciones no necesita infraestructura exótica. Necesita límites claros: una interfaz amigable, una API que haga cumplir reglas, almacenamiento para datos y archivos, y workers para trabajos temporizados como recordatorios.
Empieza con lo que tu equipo pueda construir y operar con confianza. Si ya dominan React + Node, o Rails, o Django, esa suele ser la elección correcta para la v1. Las preferencias de hosting importan: si quieres “push to deploy” sencillo, elige una plataforma que soporte bien tu stack y facilite logs, escalado y gestión de secretos.
Si quieres avanzar más rápido sin un ciclo pesado de construir desde cero, una plataforma de prototipado como Koder.ai puede ayudar a iterar el flujo (campañas, activos, aprobaciones, roles) mediante una interfaz guiada—y luego exportar el código cuando quieras tomar control.
Frontend (app web): Dashboards, cronogramas y pantallas de revisión. Habla con la API y maneja detalles UX en tiempo real (estados de carga, progreso de subida, hilos de comentarios).
API Backend: Fuente de verdad para reglas de negocio—quién puede aprobar, cuándo se bloquea un activo, qué transiciones de estado están permitidas. Mantén esto sencillo y predecible.
Base de datos: Guarda campañas, tareas, aprobaciones, comentarios y eventos de auditoría.
Almacenamiento de archivos + previsualización: Guarda subidas en almacenamiento de objetos (p. ej., S3-compatible). Genera miniaturas/previews para que clientes revisen sin descargar archivos pesados.
Trabajos en segundo plano: Cualquier cosa que no deba bloquear al usuario: envío de emails, generación de previews, recordatorios programados, informes nocturnos.
Para la mayoría de agencias, un monolito modular es ideal: una base de código backend con módulos bien separados (activos, aprobaciones, notificaciones). Puedes añadir servicios donde ayuden realmente (p. ej., un proceso worker dedicado) sin fragmentar el despliegue.
Trata las notificaciones como característica principal: en-app + email, con opt-outs y threading claro. Una cola de jobs (BullMQ, Sidekiq, Celery, etc.) te permite enviar recordatorios de forma fiable, reintentar fallos y evitar ralentizar subidas y aprobaciones.
Planifica tres entornos desde el inicio:
Si quieres profundizar en la parte de datos, continúa con /blog/data-model-and-database-design.
Un modelo de datos limpio mantiene la app sencilla incluso al crecer. La meta es que las pantallas comunes—listas de campañas, colas de activos, páginas de aprobación—sean rápidas y predecibles, mientras capturas la historia que necesitarás más adelante.
Empieza con un conjunto pequeño que refleje cómo trabaja una agencia:
Mantén IDs consistentes (UUIDs o IDs numéricos). Lo importante es que cada registro hijo tenga organization_id para aplicar aislamiento de datos.
Los estados por sí solos no explican qué pasó. Añade tablas como:
Esto facilita trazas de auditoría y responsabilidad sin inflar las tablas centrales.
La mayoría de pantallas filtran por cliente, estado y fecha de entrega. Añade índices como:
Considera también un índice compuesto para “qué necesita revisión ahora”, p. ej. (organization_id, status, updated_at).
Trata tu esquema como código producto: usa migraciones para cada cambio. Siembra plantillas de campaña (etapas por defecto, estados de muestra, pasos estándar de aprobación) para que nuevas agencias empiecen rápido y tus entornos de prueba tengan datos realistas.
Una app de aprobaciones vive o muere por la confianza: los clientes necesitan un login sencillo y tu equipo debe estar seguro de que solo las personas correctas ven el trabajo adecuado. Comienza con el conjunto mínimo de funciones de autenticación que sigan pareciendo profesionales.
Si tus usuarios son principalmente clientes que entran ocasionalmente, email + contraseña suele ser la vía más suave. Para organizaciones grandes, considera SSO (Google/Microsoft) para que usen cuentas corporativas. Puedes soportar ambos más adelante: evita hacer SSO obligatorio a menos que tu audiencia lo espere.
Las invitaciones deben ser rápidas, conscientes del rol y tolerantes:
Un patrón útil es un magic link para establecer contraseña y evitar que los nuevos usuarios memoricen datos al inicio.
Usa manejo de sesiones seguro (tokens de acceso de corta vida, refresh tokens rotativos, cookies httpOnly donde sea posible). Añade un flujo estándar de recuperación con tokens de un solo uso y vencimiento, y pantallas de confirmación claras.
La autenticación responde “¿quién eres?” La autorización responde “¿qué puedes hacer?” Protege cada endpoint con checks de permisos—especialmente para activos, comentarios y aprobaciones. No confíes solo en ocultar elementos en la interfaz.
Mantén logs amigables para auditoría (intentos de login, aceptación de invitaciones, cambios de rol, actividad sospechosa), pero evita almacenar secretos. Logea identificadores, timestamps, pistas de IP/dispositivo y resultados—nunca contraseñas, contenidos completos de archivos o notas privadas del cliente.
Las notificaciones hacen que una app de campañas sea útil o agotadora. La meta es sencilla: mantener el trabajo en movimiento sin convertir cada comentario en un incendio en la bandeja de entrada.
Empieza con un conjunto pequeño y de alta señal, y mantenlo consistente entre email y en-app:
Incluye en cada notificación el “qué” y la próxima acción con un enlace directo a la vista correcta (p. ej., la página de revisión del activo o la bandeja de aprobaciones).
Distintos roles quieren distinto detalle. Da control a nivel de usuario:
Usa valores por defecto inteligentes: los clientes suelen querer menos emails que los equipos internos y, por lo general, solo les interesan items que esperan su decisión.
Agrupa actualizaciones similares (p. ej., “3 nuevos comentarios en Banner Home”) en lugar de enviar un email por comentario. Añade reglas:
Una Bandeja de Aprobaciones dedicada reduce idas y venidas mostrando solo lo que el cliente debe hacer: items “Esperando por ti”, fechas de vencimiento y acceso en un clic a la vista de revisión. Manténla limpia y accesible, y enlázala desde cada email de revisión (p. ej., /approvals).
El email no está garantizado. Guarda estados de entrega (enviado, rebotado, fallido) y reintenta con lógica. Si un email falla, muéstralo a admins en una vista de actividad y recurre a notificaciones en-app para que el flujo no se estanque en silencio.
Cuando los clientes aprueban creativos, no es solo un clic: asumen responsabilidad por una decisión. Tu app debe hacer esa traza fácil de encontrar, entender y difícil de disputar.
Implementa un feed de actividad en dos niveles:
Haz las entradas legibles para usuarios no técnicos con formato consistente: Quién hizo qué, cuándo y dónde. Por ejemplo: “Jordan (Agencia) subió Homepage Hero v3 — 12 Dic, 14:14” y “Sam (Cliente) aprobó Homepage Hero v3 — 13 Dic, 09:03”.
Para responsabilidad, guarda una traza de auditoría de:
Una regla práctica: si un evento afecta entregables, tiempos o firma del cliente, debe estar en la traza de auditoría.
Los eventos de auditoría deben ser generalmente inmutables. Si algo necesita corrección, registra un nuevo evento (p. ej., “Aprobación reabierta por Agencia”) en lugar de reescribir la historia. Permite editar campos solo para presentación (como corregir una errata en el título) pero registra que la edición ocurrió.
Soporta exportar un resumen simple (PDF o CSV) para la entrega final: versiones aprobadas, timestamps de aprobación, feedback clave y enlaces a activos. Esto es útil al cerrar un proyecto o cuando el cliente cambia de equipo.
Bien hecho, esto reduce confusión, protege a ambas partes y hace que tu software de gestión de campañas parezca fiable, no complicado.
Los informes y las integraciones pueden inflar fácilmente el alcance. El truco es lanzar lo mínimo que ayude a los equipos a trabajar día a día y ampliar según el uso real.
Comienza con una vista sencilla (o widgets de dashboard) para chequeos semanales y triaje diario:
Luego añade indicadores de salud de campaña fáciles de entender:
No necesitan predicción perfecta: solo señales claras y reglas consistentes.
Las integraciones deben reducir trabajo manual, no crear fallos nuevos. Prioriza según hábitos diarios:
Aunque no publiques una API inmediatamente, define una estrategia de extensión:
Phase 1: dashboards centrales + listas de pendientes/vencidos.
Phase 2: indicadores de salud + tendencias de tiempo de ciclo.
Phase 3: 1–2 integraciones de alto impacto (normalmente email + Slack).
Phase 4: webhooks y una API apta para partners.
Si piensas en planes con niveles por informes e integraciones, mantenlo simple y transparente (ver /pricing). Si quieres un camino más rápido al MVP, Koder.ai puede ser útil: itera el flujo en “planning mode”, despliega una build hospedada para feedback y revierte con snapshots mientras afinas requisitos.
Para patrones de flujo más profundos, también puedes enlazar guías relacionadas desde /blog.
Comienza definiendo el problema central: las aprobaciones y el feedback están dispersos entre correo/charla/archivos. Tu v1 debe centralizar briefs, activos, feedback y firmas para que cualquier interesado pueda responder rápidamente:
Usa resultados medibles como el tiempo de respuesta de aprobación y los ciclos de revisión para mantener el alcance realista.
Diseña pensando en cuatro grupos comunes:
Si optimizas solo para usuarios internos, la adopción por parte del cliente (y la velocidad de aprobación) suele verse afectada.
Elige un pequeño conjunto de métricas relacionadas con fricciones reales del flujo de trabajo:
Mide estas métricas desde el inicio para validar mejoras tras lanzar la v1.
Un v1 práctico incluye:
Deja para después informes avanzados, integraciones profundas, reglas de automatización y rutas de aprobación personalizadas hasta comprobar el uso consistente.
Modela el flujo con unos pocos objetos centrales:
Define un ciclo de aprobación (p. ej., Borrador → Revisión interna → Revisión cliente → Aprobado) donde cada estado tenga un significado operativo (quién puede moverlo, qué debe ser cierto, qué sucede después).
Siempre vincula el feedback a una versión del activo para evitar disputas de “¿qué archivo revisaron?”. Buenas opciones:
La estructura reduce retrabajo al hacer el feedback accionable y responsable.
Mantén la navegación consistente alrededor de una jerarquía simple: Cliente → Campaña → Entregables (activos). Pantallas “de uso diario” clave:
Añade filtros que respondan preguntas reales: cliente, fecha de vencimiento, estado, responsable.
Empieza simple con los roles que la mayoría de agencias necesita:
Luego define permisos por objeto (campaña, activo, comentario, aprobación) como ver/comentar/subir/aprobar/editar/eliminar. Aplica el principio de “mínimos privilegios” y haz las comprobaciones en el backend, no solo ocultando elementos en la interfaz.
Trata cada subida como una nueva versión inmutable (v1, v2, v3…). No sobrescribas archivos en el lugar.
Registra metadatos de aprobación:
Normalmente, bloquea la versión aprobada pero permite crear una nueva versión (que resetea el estado a En Revisión) cuando se necesiten cambios.
Una arquitectura directa es suficiente:
Para la v1, un con un worker de jobs suele ser más fácil de desplegar y operar que muchos servicios separados.
