Agenda inteligente con buffers por zona para la red de ejecutivos de crédito de MiAuto Santander.
Soy ejecutivo de crédito en MiAuto Santander: recibo solicitudes de vendedores y coordino la firma de cada operación. La coordinación vivía en idas y vueltas de WhatsApp y dejaba huecos muertos en mi agenda. Construí una agenda self-service con buffers de viaje variables por zona — los vendedores ven solo horarios viables y reservan en un click. Cuando mi supervisor mostró interés en la herramienta, me adelanté a la pregunta obvia: qué necesitaría alguien que coordina la red entera. Así diseñé el segundo nivel — multi-usuario con calendarios independientes, panel de supervisor con mapa de ocupación nacional y bloqueo global de horarios — listo para escalar cuando llegue la autorización.
Como ejecutivo de crédito de MiAuto 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.
La v1 la construí solo para mi propio uso, con mi Google Calendar como source-of-truth. Validé la idea en mi día a día antes de pensar en escalarla.
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 llenaba mi día de slots sueltos. Sumé una vista de horarios recomendados que prioriza los que minimizan tiempo muerto entre firmas.
Cuando mi supervisor mostró interés, refactoricé a multi-usuario antes de que me lo pidieran. Me pregunté qué necesitaría alguien que coordina una red — no alguien que opera dentro de ella.
Multi-tenant simple: cada agente tiene su propia URL pública (agenda.idevor.com/su-nombre), su Google Calendar conectado por OAuth, sus zonas configurables y sus reglas de buffer. Encima, un panel de supervisor que ve la red completa.
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.
Después del OK de crédito, el vendedor recibe el link del ejecutivo. Ve solo horarios viables (ya filtrados por buffer geográfico) y los recomendados en la parte de arriba. Reserva con un click — sin volver a preguntar.
Cada agente configura sus propias zonas geográficas y los buffers entre ellas. También tiene un módulo de objetivos para llevar control de venta de accesorios, seguros y métricas comerciales propias del rol.
Mapa de Uruguay pintado con gradiente verde→naranja→rojo según ocupación de los agentes. Filtros por departamento y horario. Panel de bloqueo global para reservar slots de reunión en toda la red al mismo tiempo.
Construir primero para mí mismo fue la mejor decisión de producto. La v1 ya estaba probada en mi día a día cuando llegó el interés de mi supervisor.
El refactor a multi-tenant fue mucho más prolijo porque la v1 estaba bien diseñada para un caso real, no para una abstracción imaginaria.
Las funcionalidades del supervisor no salieron de un brief — me las hice yo, anticipándome: ¿qué necesitaría alguien que coordina una red entera, no alguien que opera dentro de ella?
Estar listo antes de que me pidieran escalarlo es parte del trabajo. Lo diseñé esperando autorización para presentarlo al resto de los ejecutivos.