Inspiración

En el kickoff, Alestra nos contó un problema que cualquier cliente reconoce: explicar lo mismo hasta 3 veces, esperar hasta 3 semanas por una propuesta y ver que casi siempre tiene que entrar un arquitecto de soluciones. Lo que más nos llamó la atención fue su aclaración: el problema no son los arquitectos, es que el conocimiento que ya existe no llega al vendedor en el momento en que el cliente pregunta.

Ahí nació Salestrack: un copiloto que escucha la reunión y convierte al vendedor en un asesor experto en tiempo real, con el catálogo de Alestra como única fuente de verdad.

Qué hace

Escucha la reunión (micrófono o audio de la computadora) y transcribe en español directamente en la Mac. El audio nunca sale del equipo.
Le dice al vendedor qué preguntar, con las preguntas clave de cada producto del catálogo, y mide el % de levantamiento en vivo.
Dibuja un mapa de rutas de solución donde cada burbuja es un producto real del catálogo y lleva la frase exacta del cliente que la justifica.
Cotiza al instante la parte estándar con plazos, paquetes, descuentos e IVA, calculados en código.
Detecta cuándo sí hace falta un arquitecto con las 10 reglas de escalamiento de Alestra (ESC-01 a ESC-10) y un semáforo por ruta: verde, amarillo o rojo.
Escribe dos documentos al colgar: la propuesta comercial para el cliente y el brief técnico para ingeniería, que el arquitecto valida en el Modo ingeniería en lugar de volver a levantar el requerimiento.

Cómo lo construimos

App de escritorio: Electron, React y TypeScript, con React Flow y dagre para el mapa, Zustand para el estado y SQLite para guardar sesiones, correcciones y cada llamada a la IA.
Transcripción local: un sidecar en Python con FastAPI, WebSockets, silero-vad y mlx-whisper (large-v3-turbo) fijo en español, con vocabulario de Alestra para que términos como SD-WAN, OCI o DRaaS salgan bien.
Claude como motor central: claude-haiku-5-5 revisa la conversación cada 25 segundos y actualiza un estado único del trato; claude-sonnet-5-5 atiende las acciones del vendedor: solución, plan, trabajo a la medida, "Pregúntale al experto" y los documentos finales. Todo el catálogo va en un prefijo con prompt caching.
Catálogo oficial: importamos los 45 productos, 7 paquetes, condiciones comerciales, 10 reglas de escalamiento y 10 casos de clientes del patrocinador a datos tipados que la app y las pruebas comparten.

Claude no inventa: el diseño anti alucinación

Esta fue la decisión más importante. Claude elige, el código calcula.

En las herramientas que usa Claude, el SKU es un enum de los 45 productos oficiales: no puede proponer un producto que no existe.
Claude no puede escribir precios. Si en su salida aparece un monto, incluso escrito como "12 mil" o "doce mil novecientos pesos", se rechaza.
Toda afirmación sobre el cliente necesita evidencia: el id del fragmento de la transcripción donde lo dijo.
Lo que el vendedor edita a mano queda bloqueado y la IA no lo sobrescribe.
Nunca responde "no sé": si algo no está en el catálogo, ofrece las preguntas clave del producto más cercano o "Lo confirmo con un arquitecto", con la regla que aplica.

Los precios salen de una función pura. Para cada línea (i) con cantidad (q_i) y precio de lista (p_i), la mensualidad con plazo y paquete es

$$ M = \sum_i q_i \, p_i \,(1 - d_{\text{plazo}})\,(1 - d_{\text{paquete},i}) $$

con (d_{\text{plazo}} = 0.05) a 24 meses y (0.10) a 36 meses, y (d_{\text{paquete},i} = 0.08) solo en los productos del paquete. El contrato completo es

$$ T = 36\,M + U, \qquad T_{\text{IVA}} = 1.16\,T $$

donde (U) son los cargos únicos, que no llevan descuento. Para el caso Aceros del Valle eso da (M = \$41{,}378.40) al mes sin IVA, y lo verificamos a mano contra el catálogo.

Retos

El catálogo cambió a media jornada. Empezamos con un catálogo que armamos nosotros y a mediodía llegó el oficial del patrocinador, con otras familias de productos y otras reglas. Como los datos se generan desde un solo importador, cambiar de catálogo fue reimportar y ajustar las reglas, no reescribir la app.
Herramientas demasiado grandes para el modo estricto. En la primera prueba con Claude real, la API rechazó los esquemas porque la gramática compilada era demasiado grande. Dejamos en modo estricto solo los que caben y validamos el resto en código.
Tamaño correcto de los productos. El modelo a veces elegía un paquete de nube que no alcanzaba para los servidores del cliente. Ahora el código ajusta el paquete según los núcleos que el cliente dijo, y Claude solo reporta los hechos.
Cuándo escalar. Distinguir "pagamos AWS con tarjeta" (método de pago) de "procesamos pagos con tarjeta" (regla de escalamiento) nos obligó a separar hechos de conclusiones: Claude reporta hechos con evidencia y el código decide las reglas.

Lo que aprendimos

La confianza en una herramienta de ventas no viene de que la IA sepa mucho, sino de que nunca diga algo que no puede respaldar.
Separar lo que decide el modelo de lo que calcula el código hace que el sistema sea verificable: tenemos 158 pruebas automáticas y un chequeo con Claude real que pasa los 35 criterios en cuatro casos del patrocinador.
Un buen copiloto no reemplaza al arquitecto: le entrega el levantamiento completo para que valide en lugar de volver a preguntar.

Impacto esperado

Indicador	Hoy	Con Salestrack
Sesiones hasta tener el requerimiento	3	1
Tiempo para la propuesta económica	hasta 3 semanas	el mismo día para la parte estándar
Participación del arquitecto	casi siempre, desde el levantamiento	solo valida los puntos que marcan las reglas