MasterShield

El problema: el volumen no es el problema

Cuando entran más conversaciones de las que el equipo puede sostener, la reacción intuitiva es contratar a alguien más. Pero la mayoría de esas conversaciones no necesitan una persona: son la misma pregunta de precio, de disponibilidad o de qué producto corresponde.

Lo que sí necesita una persona es la conversación con quien ya decidió comprar. Y esa es justamente la que llega tarde, porque está haciendo cola detrás de las otras.

Qué hace el agente

Conversa, cotiza sobre la matriz de precios real —control solar, privacidad y seguridad—, releva los datos comerciales que el equipo necesita, le asigna un puntaje de calificación al contacto y carga todo en el CRM para que un asesor llame.

El asesor no recibe un mensaje suelto: recibe un contacto perfilado, con la conversación entera y una reunión agendada. Ese es el cambio que se nota del otro lado — el equipo dejó de leer conversaciones para decidir cuáles valían la pena.

Qué quedó funcionando

El agente atiende las conversaciones entrantes y sincroniza con Kommo, el CRM que MasterShield ya usaba. No hubo que cambiar la herramienta con la que trabaja el equipo comercial: el agente entra por donde ya estaban las conversaciones y deja los contactos donde el asesor ya los busca.

Es el patrón que repetimos en los agentes de atención: el sistema se adapta a la operación que existe, no al revés. Un agente que obliga a cambiar el CRM se usa dos semanas.

Cómo está construido

Python con FastAPI, PostgreSQL sobre Supabase para la capa de memoria, la API de Claude para la conversación, y sincronización con Kommo como CRM.

Un detalle que define el diseño: el estado de cada conversación vive en base de datos, no en memoria del proceso. El servicio se reinicia con cada deploy, y un lead que no llegó al CRM porque el proceso se reinició en el medio no se arregla después.

El resultado

Ninguna conversación queda sin respuesta y el equipo recibe clientes ya perfilados y con reunión agendada.