CRM HVAC — Customer 360
Propuesta de CRM para Airzone: del lead a la garantía en un solo sistema
- Producto, análisis de negocio y desarrollo dirigido con IA
- Septiembre 2026
Entorno de demostración con datos ficticios. Propuesta independiente: no es software oficial de Airzone ni contiene información confidencial.
Resumen
Un CRM Customer 360 que conecta el ciclo comercial con la base instalada de equipos de climatización: leads, presupuestos, instalaciones, garantías, tickets y técnicos de campo.
Propuesta / demo construida con información pública del sector y datos ficticios. No es software oficial de Airzone.
- modelos de datos (Prisma)
- 93
- pantallas
- 134
- roles con permisos en SQL
- 14
- tests E2E en verde
- 1344/1344
Construido con un agente de Claude guiado por reglas de proyecto (CLAUDE.md), especificación y tests. Dentro del producto, un asistente con Claude resume, sugiere la siguiente acción y clasifica, pero nunca modifica datos de negocio.
Sin demo pública: proyecto ejecutado en local.
Un producto que vive diez años en un edificio ajeno.
Un fabricante de control de climatización no vende una vez y se olvida: su producto se instala en un edificio de otro, conectado a una máquina de otro fabricante y montado por un instalador tercero. La relación con el cliente continúa durante años de garantías, mantenimientos y renovaciones.
Planteé esta propuesta para Airzone usando únicamente información pública del sector. El objetivo: demostrar cómo sería un CRM que entiende ese negocio en lugar de un CRM genérico adaptado a la fuerza.
Los CRM genéricos modelan clientes y oportunidades. Aquí no basta.
Un CRM estándar organiza clientes, oportunidades y tickets. En climatización falta la otra mitad: qué equipos hay instalados, en qué sitio, con qué sistema de control, bajo qué garantía y con qué historial técnico.
Sin esa costura, ventas y soporte trabajan con datos distintos, la compatibilidad entre equipos se supone en lugar de verificarse y las oportunidades de mantenimiento o renovación se pierden.
Dos mundos y su costura.
El sistema modela el ciclo comercial y la base instalada como un único recorrido.
Lead
Captación y scoring
Oportunidad
Pipeline por etapas
Configuración
Compatibilidad verificada
Presupuesto
Versionado inmutable
Instalación
Sitio · sistema HVAC · activos
Garantía
Activación y cobertura
Ticket
SLA y orden de trabajo
Renovación
Mantenimiento y upsell
Tres reglas que definen el producto.
- La compatibilidad es un dato verificado
- Si no hay una regla registrada para un modelo de máquina y un producto, el estado es «pendiente de validar» y la configuración no puede aprobarse.
- El histórico comercial es inmutable
- Una versión de presupuesto enviada no se edita: se crea la siguiente. El cliente acepta o rechaza desde un enlace público con token.
- La autorización se aplica en SQL
- Cada consulta se acota al ámbito del rol. Si falta el permiso, la consulta devuelve cero filas, no todas. 14 roles, desde super admin hasta solo lectura.
Lo que se puede hacer.
Capturas del recorrido de demostración (datos ficticios).
Un sistema completo, no una maqueta.
- CRM y ventas
- Leads con scoring, contactos, empresas con ficha 360 de 14 pestañas, pipeline Kanban, presupuestos con aprobaciones y pedidos.
- Base instalada
- Sitios, instalaciones, sistemas HVAC, activos, garantías y matriz de compatibilidad.
- Soporte y campo
- Tickets con SLA, órdenes de trabajo, planificador de técnicos, vista móvil «Mi jornada» y calendario CalDAV.
- Telemetría
- Diagnóstico remoto de instalaciones conectadas vía MQTT, con un simulador de pasarela claramente identificado.
- Marketing y analítica
- Campañas, consentimientos RGPD, analítica de ventas, clientes y soporte, mapa por provincia y constructor de informes.
- Administración
- Usuarios, roles, equipos, importación CSV, automatizaciones, webhooks firmados con HMAC y traza de auditoría append-only.
Capas con responsabilidades estrictas.
Next.js App Router sobre PostgreSQL. Cada servicio externo sigue el patrón interfaz + mock + adaptador real.
guard
Autenticación y autorización obligatorias en toda petición.
domain
Reglas de negocio puras y testeadas.
services / actions
Consultas y mutaciones mediante Server Actions.
providers
Integraciones intercambiables, todas ejecutables en local con Docker.
Yo dirijo; la IA ejecuta; los tests deciden.
El código lo escribió un agente de Claude. Las decisiones, los límites y los criterios de terminado los fijé yo.
Especificación
Negocio, roles, flujos y Definition of Done
Reglas
CLAUDE.md: stack decidido, no inventar información confidencial, no exponer secretos
Construcción
11 fases con registro de progreso
Evaluación
Revisión con toolchain real: 62 bugs registrados y corregidos
Verificación
typecheck, lint, unit, build y E2E antes de dar algo por terminado
Ejemplo real: al revisar la integración CalDAV se detectó que cualquier usuario podía leer el calendario; se añadió autenticación a Radicale.
Verificado, no prometido.
Cifras de ingeniería registradas en docs/testing.md el 24/09/2026. No son métricas de negocio: es una demo.
- tests unitarios en 34 suites
- 258
- tests E2E en verde, dos pasadas seguidas
- 1344
- matriz de acceso: rutas × roles
- 126 × 8
- pantallas auditadas con axe (WCAG 2.1 AA)
- 28
La IA escribe rápido. El criterio sigue siendo humano.
La velocidad de un agente de código es enorme, pero solo es útil si el problema está bien definido. Lo que más valor aportó no fue pedir pantallas, sino fijar reglas de negocio verificables y un criterio de terminado que no se puede saltar.
También aprendí a desconfiar del «todo verde»: la evaluación con el toolchain real encontró fallos de seguridad (IDOR, fugas de ámbito, throttling de login) que solo aparecen cuando se prueban permisos de verdad.