Diagnóstico inicial
Falomir Juegos
Informe elaborado por Edu Salado | Befocusy
Cliente: Falomir Juegos — empresa familiar de desarrollo y distribución de juegos de mesa (Valencia, 1945 · 3.ª generación)
Fecha de la última actualización: 8 de abril de 2026
Contexto
Perfil del negocio
Falomir Juegos es una empresa familiar fundada en 1945 en Valencia, actualmente en su tercera generación. Han protagonizado una transición estratégica relevante: han pasado de comercializar juegos genéricos fabricados en China a desarrollar producto propio con autores, ilustradores y docentes.
  • Canales: El Corte Inglés, Carrefour, tiendas especializadas y papelerías
  • Proceso de desarrollo largo, iterativo y con muchos agentes externos
Flujo actual
El flujo actual depende en exceso de intervención manual y carece de un sistema que conecte las 8 fases con visibilidad en tiempo real sobre el estado de cada producto.
Problemas detectados
Sin fuente de verdad única
Cada consulta sobre «¿en qué fase está este juego?» requiere buscar en Excel, preguntar a Rafa o revisar el correo. Varias horas perdidas por semana.
Diseño sin seguimiento estructurado
Más de 20 pasos entre el briefing inicial y el artwork final. Sin tablero de estado, los diseños se quedan «en espera» semanas sin que nadie lo detecte.
Fechas límite no vinculadas
Falomir tiene dos ventanas críticas al año (Navidad y vuelta al cole). Sin plazos por producto, es imposible garantizar que los juegos estén listos a tiempo.
Más fricciones operativas
Coordinación Fernando–Rafa sin visibilidad compartida
Trabajan en horarios diferentes sobre los mismos productos. Se producen duplicidades, malentendidos y lagunas de información.
Gestión de proveedores externos dispersa
Contactos, briefings y entregas de diseñadores y fábricas se gestionan por email sin estructura. Difícil saber quién está disponible o qué encargo está en curso.
Archivos de diseño desconectados del producto
Troqueles, bocetos, artes finales y archivos editables viven en carpetas sin conexión al registro del producto.
Sin onboarding documentado
El conocimiento de los procesos está en la cabeza de Fernando y Rafa. Cualquier incorporación requiere transmisión oral íntegra.

Fricciones críticas (bloquean casi todo): Sin fuente de verdad única · Proceso de diseño sin seguimiento (cuello de botella principal) · Fechas límite de campaña sin sistema de alerta.
Objetivos del proyecto
Vista completa cada mañana
Abrir Notion y ver el estado de todos los productos: qué fase, qué tareas requieren acción hoy.
Control de plazos por campaña
Cada producto tiene fecha límite vinculada y el sistema alerta cuando hay riesgo de retraso.
Seguimiento del diseño end-to-end
Desde el briefing hasta el artwork final, con visibilidad de en qué paso está cada producto y quién tiene la pelota.
CRM operativo
Todos los contactos externos (diseñadores, clientes, distribuidores, autores) organizados por tipo y estado.
Bandeja de entrada centralizada
Inbox que centralice peticiones y comunicaciones externas, preparado para automatización futura.
Sistema escalable
Estructura estable en Notion antes de automatizaciones. Diseñado para crecer a otras áreas sin reconstruirse.
Arquitectura propuesta en Notion
Productos
1 registro = 1 juego. Campos: nombre, campaña objetivo, fase actual, estado, responsable y fecha límite.
Fases
Las 8 fases del ciclo de producto por juego. Campos: nombre, estado, fecha objetivo y producto vinculado.
Tareas
Acciones concretas dentro de cada fase (basadas en el flujo de 96 tareas documentado). Campos: nombre, responsable, estado y fecha límite.
Encargos de Diseño
Cada encargo vinculado a un producto y un diseñador. Estado: bocetos → preliminares → maquetados → artwork final.
Contactos
Personas externas: tipo (Diseñador, Cliente, Autor, Proveedor…) y estado (Activo, En pausa, Prospecto…).
Empresas
Organizaciones que agrupan varios contactos (Carrefour, El Corte Inglés, agencias de diseño, fábricas…).
Inbox
Bandeja de entrada de peticiones y solicitudes. Preparado para automatización desde Outlook con Make/n8n.
Wiki / Procesos
Documentos de proceso y SOPs del equipo. Contexto para la IA de Notion y onboarding de nuevos miembros.
Front-end operativo (vistas de trabajo)
Panel diario
  • Tablero Kanban: todos los productos organizados por fase
  • «Mi trabajo hoy»: lista de tareas del día filtrada por responsable
  • Vista calendario: fechas límite de campaña y tareas críticas
  • Vista «Diseños en revisión»: encargos que esperan feedback
Panel de diseño
  • Tablero de diseño: bocetos → preliminares → maquetados → artwork final
  • Vista «Encargos activos» por diseñador
  • Vista Inbox: entradas sin procesar
Automatizaciones
  • Alta prioridad: Alerta si un producto lleva más de X días sin cambiar de fase
  • Alta prioridad: Cambio automático de fase al completar todas sus tareas
  • Media: Creación automática de tareas al iniciar una nueva fase
  • Media: Captura de emails de Outlook en el Inbox vía Make/n8n
Entidades: plan de implementación
Una Entidad es un módulo funcional completo del sistema: bases de datos, dashboards, plantillas/SOPs y criterio de «Listo» en uso real. Ciclo por entidad: Modelado (2 sem.) → Front-end (2 sem.) → Implementación (2–6 sem. según complejidad)
Productos
Fuente de verdad única. Tabla completa, vista por campaña y galería. Todos los productos activos cargados con estado y campaña. Complejidad: simple.
Seguimiento de Fases
Tablero Kanban por fase, «Mi trabajo hoy», calendario y dashboard semanal. Plantilla con 8 fases y tareas pre-creadas. Complejidad: alta.
Diseño y CRM
Encargos de diseño, contactos y empresas. Tablero bocetos→artwork final, vista por diseñador y CRM completo. Complejidad: alta.
Inbox
Bandeja centralizada de peticiones y comunicaciones. Entradas sin procesar, asignadas y vinculadas a productos. Preparado para automatización. Complejidad: intermedia.
Wiki de Procesos
Transversal a todo el proyecto. Se construye en paralelo documentando SOPs a medida que se implementan las demás entidades. Sin coste adicional.
Hoja de ruta y cadencia
Las sesiones son reuniones de trabajo de 1 hora. Por cada entidad: Sesión 1 al final del Modelado (semana 2), Sesión 2 al inicio de la Implantación (semana 5), y sesiones semanales de seguimiento durante la implantación. La Wiki de Procesos se construye en paralelo sin añadir semanas.
Checkpoint 1 — Semana 4
«Productos en Notion»: todos los productos activos cargados. Fuente de verdad única para el equipo.
Checkpoint 2 — Semana 14
«Seguimiento operativo»: Fernando y Rafa usan el tablero y la lista de tareas diariamente.
Checkpoint 3 — Semana 22
«Diseño y CRM activo»: encargos de diseño gestionados en Notion y CRM de contactos en uso.
Checkpoint 4 — Semana 26
«Inbox operativo»: todas las peticiones y comunicaciones externas se capturan y clasifican en Notion.
Próximos pasos
Confirmar diagnóstico y entidades
Fernando y Rafa revisan este diagnóstico y confirman si el desglose de entidades y el orden propuesto refleja bien sus prioridades.
Decidir alcance inicial
¿Empezamos solo con «Productos» o arrancamos «Productos» y «Seguimiento de Fases» en paralelo? Recomendación: empezar solo con la primera para no saturar el equipo.
Limpiar el workspace de Notion
Organizar espacios, corregir la importación del Excel (fechas mal tipadas) y definir la estructura de páginas principal antes de empezar.
Arrancar Entidad 1 — Productos
Edu prepara el modelado de la entidad «Productos» — plazo estimado: lunes-martes de la semana siguiente a la confirmación. El Excel del flujo completo ya ha sido compartido ✅