Calendario Z
Herramienta de gestión de disponibilidad operativa para una empresa de telecomunicaciones. Discovery completo con múltiples áreas, prototipado con IA y design system en desarrollo.
Rol
Product Designer
Empresa
Strong Systems
Equipo
PO · Devs · Tech Lead
Estado
MVP en desarrollo
El problema que nadie había documentado
Qué estaba pasando
Una empresa de telecomunicaciones gestionaba el seguimiento de cuadrillas técnicas y órdenes de trabajo con un calendario heredado que generaba reprogramaciones constantes, falta de visibilidad y decisiones tomadas sin datos del campo. El sistema existía, pero nadie lo había auditado desde la perspectiva de quienes lo usaban todos los días.
Objetivo
Documentar el problema real antes de diseñar cualquier solución, entender cómo trabajaban los equipos, dónde fallaba el sistema y qué necesitaba cada rol para tomar mejores decisiones.
Solución
Trabajé con Operaciones y el Contact Center para mapear flujos, fricciones y documentos de uso real. Usé IA para acelerar el análisis sin perder profundidad. El resultado fue una herramienta de gestión de disponibilidad operativa construida con la lógica del campo, no desde supuestos.
Dos reuniones, tres sistemas y un caos de información
Conduje sesiones de discovery con Operaciones y Contact Center por separado. Usé NotebookLM para centralizar las grabaciones, transcripciones y documentos de cada reunión en un único espacio de análisis, esto me permitió cruzar información entre áreas y detectar contradicciones que de otra forma hubieran pasado desapercibidas.
Pain points
Operaciones
Pérdida de trazabilidad
El historial de reprogramaciones desaparecía después del segundo movimiento. Los supervisores no podían priorizar casos críticos sin contexto.
Operaciones
Desconexión técnica FO/RF
Sin validación automática entre la tecnología del ticket y la capacidad de la cuadrilla. Las visitas fallidas se detectaban recién en el domicilio del cliente.
Contact Center
Turnos mal configurados
El sistema bloqueaba la carga de tareas entre 12:00 y 13:00 por un convenio laboral anterior. La jornada real de 6 horas no estaba reflejada en ningún lado.
Contact Center
Excel paralelo como sistema
CC mantenía un Excel nocturno para controlar instalaciones pendientes. Un proceso manual que existía porque el calendario no daba visibilidad suficiente.
Ambas Áreas
Ceguera entre segmentos
Masivo, Pyme y Corporativo no eran visibles en el calendario. Generaba una percepción falsa de baja productividad en cuadrillas que sí estaban trabajando.
Ambas Áreas
Error humano sistémico
Duración de tareas con selector manual, coordenadas validadas a mano en Google Maps, asignación sin alertas de horario. El sistema invitaba al error.
"La historia de las reprogramaciones desaparece después del segundo movimiento, dejando a los supervisores sin datos para priorizar clientes críticos."
— Gerencia de Operaciones, sesión de discovery
Cómo usé IA para ir más rápido sin perder profundidad
NotebookLM
Centralización y análisis de fuentes
Cargué las grabaciones y documentos de ambas reuniones en un solo notebook. Esto me permitió hacer preguntas cruzadas sobre el contenido, detectar contradicciones entre áreas y generar resúmenes estructurados sin perder matices. Lo que hubiera llevado días de análisis lo procesé en horas.
Lovable + Cursor
Prototipado · Validación funcional del MVP
Generé un prototipo funcional en Lovable para validar los flujos principales con stakeholders sin esperar el desarrollo. Esto aceleró las decisiones de alcance y permitió detectar problemas de UX antes de que el equipo de dev escribiera una línea de código.
Qué decidí y por qué
Separar acento decorativo de acento funcional
El sistema actual usaba colores sin criterio semántico. Definí que cada color debía comunicar algo específico: tecnología (FO/RF), estado de tarea, prioridad por reprogramaciones. Esto reduce el error humano sin agregar complejidad visual.
Trazabilidad como feature central, no como log técnico
El historial de reprogramaciones existía en CRM pero era invisible en el calendario. Decidí surfacearlo como un contador visual de prioridad ,cuantas más reprogramaciones, más urgente visualmente. Eso elimina la necesidad de consultas manuales entre áreas.
Estandarizar duraciones por tipo de tarea
El selector manual de tiempo era la fuente principal de error humano. Instalación = 2h, Asistencia = 1h, Retiro = 30min. Fijo. El sistema calcula el cupo automáticamente. El operador deja de tomar esa decisión.
Bolsa de tareas pendientes en lugar de Excel paralelo
Las tareas sin fecha o reprogramadas sin fecha vivían en un Excel nocturno de CC. Diseñé un Task Pool visual con drag & drop integrado al calendario, elimina la herramienta paralela y mantiene el registro completo dentro del sistema.
Design System con Shadcn como base
Para garantizar consistencia y velocidad de implementación, definímos junto al dev el usar Shadcn como base del DS. Los componentes ya tienen accesibilidad resuelta, el equipo de dev puede adoptar el sistema sin fricción y yo puedo iterar los tokens sin tocar el código base.
Qué entra y qué queda para después
Validación automática FO/RF
El sistema trae la tecnología desde CRM e impide asignaciones incompatibles.
Duraciones estandarizadas
Tiempos fijos por tipo de tarea. Cálculo automático del cupo de cuadrilla.
Historial de reprogramaciones
Contador visible en cada tarea. Estado completo desde creación hasta cierre.
Visibilidad de estados en tiempo real
Integración con Zeta Task para que CC vea si el técnico está en desplazamiento o en domicilio.
Combinación predictiva de tareas
Sugerencia automática de combinación óptima para llenar el cupo de 6 horas.
Regla de distancia nativa
Filtro automático de 15-18 min de desplazamiento máximo entre tareas.
Dónde está el proyecto hoy
Discovery
Entrevistas con Operaciones y Contact Center. Pain points mapeados y validados con gerencia
Prototipado
Prototipo funcional en Lovable + pulido con Cursor. Flujos validados con stakeholders, alcance del MVP definido
Design System
DS con base Shadcn, tokens definidos, componentes base en proceso
MVP v1
Implementación a cargo del equipo de desarrollo. Handoff técnico, seguimiento de implementación y revisión de diseño en código
Lo que este proyecto me enseñó
El problema real no estaba en el diseño
Las fricciones más críticas eran de proceso y de integración de sistemas. El diseño fue el puente para hacerlas visibles y negociables con el equipo técnico.
IA como herramienta de síntesis, no de reemplazo
NotebookLM no reemplazó el criterio de diseño, aceleró el tiempo de síntesis y me permitió dedicar más energía a las decisiones que sí requieren juicio humano.
Prototipo funcional > presentación estática
El prototipo en Lovable generó más conversaciones útiles con stakeholders que cualquier deck. Ver el flujo funcionando cambió la calidad de las decisiones de alcance.
Siguiente caso de estudio
Brixo Sales
App mobile para gestión de ventas de agentes tercerizados.
