En producción · en uso por el equipo
2025 · PWA multi-tenant
MiAuto Agenda
Agenda inteligente con buffers por zona para la red de ejecutivos de cuentas de MiAuto by Santander.
Agenda inteligente con buffers por zona para la red de ejecutivos de cuentas de MiAuto by Santander.
Soy ejecutivo de cuentas en MiAuto by Santander: gestiono operaciones de crédito vehicular y coordino la firma de cada una. Esa coordinación vivía en idas y vueltas de WhatsApp y me dejaba huecos muertos entre concesionarias. Calendly resolvía el self-service, pero su buffer fijo no entiende la geografía. Así que construí mi propia agenda: buffers de viaje variables por zona, horarios clasificados en cuatro niveles de conveniencia y reserva en un click. No sé programar — la escribí íntegramente con IA, pero la arquitectura, el diseño y cada funcionalidad salieron de los problemas reales del trabajo. Hoy la usa un grupo de ejecutivos del equipo y la devolución es muy buena. El multi-tenant y el panel de supervisión ya estaban listos para cuando dejara de ser una herramienta de uso personal.
Como ejecutivo de cuentas de MiAuto by Santander, mi rol es ser el nexo entre el vendedor de la concesionaria y la firma del crédito. El vendedor me manda el número de solicitud, yo reviso documentación, doy el OK para firmar, y recién ahí empieza la coordinación: cuándo y dónde firma el cliente.
El flujo previo era brutal: yo decía "tengo disponible X". El vendedor preguntaba al cliente. El cliente proponía otro horario. El vendedor me volvía a preguntar. Yo confirmaba o negaba. Si estaba en medio de otra firma, la respuesta podía tardar horas. Cada operación era un mini ping-pong de WhatsApp que se podía estirar todo el día.
Empecé usando Calendly. Resolvía el self-service pero rompía algo crítico: el buffer time fijo. Yo me muevo entre concesionarias — a veces dos están literalmente al lado, a veces hay 30 minutos de auto entre una y otra. Calendly me obligaba a poner siempre el mismo buffer. Si lo ponía corto, llegaba tarde. Si lo ponía largo, perdía huecos donde podía firmar cerca y ahorrarme un viaje. Y cualquier regla que le pusiera de cara al vendedor terminaba siendo una complicación más.
Así que decidí hacer mi propia aplicación. Lo curioso es que no sé programar: la construí 100 % con inteligencia artificial. Lo que puse fue lo otro — la arquitectura, el diseño, el funcionamiento y cada funcionalidad, pensados desde las necesidades reales del trabajo y desde los problemas que quería resolver.
La v1 la construí solo para mi propio uso, con mi Google Calendar como source-of-truth. Cuando apareció el interés del resto del equipo, ya estaba probada contra el trabajo real — no contra una idea de cómo debería ser el trabajo.
El concepto central no es "tiempo libre" — es "tiempo libre considerando dónde voy a estar antes". Las zonas y sus buffers son entidades configurables, no constantes en el código.
Mostrar todos los huecos válidos me llenaba el día de slots sueltos. Hoy cada horario llega clasificado en cuatro niveles, con el motivo a la vista: el vendedor no sabe nada de zonas ni de buffers, pero elige el que me ahorra el viaje.
Cuando mi supervisor mostró interés, refactoricé a multi-usuario antes de que me lo pidieran: calendarios independientes, zonas por ejecutivo y panel de supervisión. Cuando llegó el momento de sumar gente, no hubo que reescribir nada.
El recurso escaso de este trabajo no es el tiempo de reunión: es el tiempo de traslado. Por eso, antes de pintar un horario, el sistema mira dónde va a estar el ejecutivo antes y después, aplica el buffer que corresponde a ese par de zonas, y clasifica lo que sobrevive en cuatro niveles — cada uno con el motivo a la vista.
Ninguna opción se esconde: el sistema no puede imponerle la ruta a quien reserva, así que inclina la decisión y la explica. Esa es la parte que sostiene la cooperación en el tiempo — y la razón por la que el vendedor nunca tuvo que aprender una regla nueva.
Multi-tenant simple: cada ejecutivo tiene su propia URL pública (agenda.idevor.com/su-nombre), su Google Calendar vinculado por OAuth, sus zonas configurables y sus reglas de buffer. Encima, un panel de supervisión que ve la red completa. Node y Express contra PostgreSQL atrás; adelante, HTML/CSS/JS sin build step, con React solo donde la interacción lo justifica.
Los ejecutivos ya viven en su Google Calendar. No los podía sacar de ahí. La agenda lee y escribe ahí directamente — Google Calendar sigue siendo la verdad para el agente.
Cada agente configura sus propias zonas y los buffers entre ellas. La lógica geográfica del que opera en Maldonado no es la misma del que opera en Pocitos.
Los agentes la instalan desde el browser. Cero fricción de stores. Las push notifications avisan cuando alguien agenda una firma — el dato más crítico llega en tiempo real.
agenda.idevor.com/alvarosalazar es la URL que el vendedor recibe. Independiente, memorable, brandeable. Si el agente sale del equipo, la URL deja de funcionar sin tocar nada más.
Cuando un ejecutivo se ausenta, otro toma su cartera: las dos agendas se leen como una sola, cada reserva escribe eventos espejo en los dos calendarios y el cruce entre carteras usa un buffer más generoso. La firma no se cae porque alguien esté de licencia.
Después del OK de crédito, el vendedor recibe el link del ejecutivo. Ve solo horarios viables — ya filtrados por buffer geográfico — con los mejores arriba y el motivo de cada uno a la vista. Reserva con un click, sin volver a preguntar. Era el objetivo principal: que del lado del vendedor fuera lo más simple posible.
Cada ejecutivo configura sus propias zonas geográficas y los buffers entre ellas, incluso pares de zonas con tiempos atípicos medidos contra el tránsito real. Además tiene un módulo para el seguimiento de sus objetivos comerciales propios del rol, por bimestre.
Mapa de Uruguay pintado según la carga de firmas del día — verde, naranja, rojo, y gris donde no hay ejecutivo asignado. Se refresca solo cada 30 segundos. Debajo, disponibilidad en vivo, feriados, coberturas entre ejecutivos y un bloqueo global que reserva el mismo horario en toda la red de una.
Construir primero para mí mismo fue la mejor decisión de producto. Cuando llegó el interés del resto del equipo, la v1 ya estaba probada contra el trabajo real.
No sé programar y la app existe igual. La escribí íntegramente con IA — pero la arquitectura, el diseño, el funcionamiento y cada funcionalidad salieron de entender el problema desde adentro. Eso no lo delega nadie.
Lo que empezó como la solución a un problema mío terminó siendo algo que otras personas querían usar. La adopción no hubo que pedirla: apareció, y con una satisfacción que no esperaba.
Las funcionalidades del supervisor no salieron de un brief: me las hice yo, anticipándome. Estar listo antes de que lo pidan es lo que hizo que sumar gente fuera un trámite y no un proyecto.
