Resumen en un minuto
Si tu SDR pasa el 70% de su tiempo persiguiendo leads que no van a cerrar, no tienes lead scoring. Tienes un Excel con celdas de colores y una intuición que no escala. Esto se arregla en 4–12 semanas con disciplina, no con una "función de IA".
79% de los leads B2B generados nunca llegan a cierre. Esta cifra circula en informes de MarketingSherpa y Forrester desde 2012 y en una década no se ha movido. En LATAM la cosa aprieta más: el mercado B2B SaaS regional pasó de USD 1.2B en inversión en 2020 a USD 4.8B+ en 2024 (trackers regionales de VC), pero el 80% de ese crecimiento se lo comen equipos SDR no optimizados que califican leads a ojo.
Lead scoring no es una "función del CRM" ni un botón mágico de IA. Es un contrato entre marketing y ventas sobre qué lead está listo para llamar hoy y cuál se queda en nurture hasta que madure. Sin un scoring formal, cada SDR construye su propio modelo de calificación en la cabeza — y esos modelos son incompatibles entre sí, no se verifican y se desploman a la primera rotación de equipo.
Este artículo es el pillar de lead scoring para equipos B2B en LATAM. Adentro: tres niveles de madurez (de reglas en el CRM a ML en producción), métricas exactas de calidad del modelo, un caso real en Mexico con conversión 3.1% → 8.7%, y una lista honesta de situaciones donde el scoring no va a funcionar — porque la mitad de los consultores regionales venden "modelo de IA" donde ni siquiera hay telemetría básica.
Lo firmo: Sergei Filatov / Hacker Sergio, Forbes 30 Under 30 LATAM. Hicimos predictive scoring y analítica de CRM para Aeroflot (loyalty +22%), Estée Lauder (remarketing de 12 marcas, ROAS 1.5× → 4.2×) y cadenas retail grandes en Rusia y Mexico. Ahora — para PYME y mid-market en LATAM con Machine Learning aplicado.
TL;DR para ejecutivos
- Lead scoring = ranquear leads por probabilidad de cierre. Sin esto, el SDR trabaja a ciegas y quema 60–70% del tiempo en contactos no objetivo.
- Tres niveles de madurez: (1) reglas en Odoo/HubSpot/Salesforce — 1–2 semanas; (2) regresión logística — 4–6 semanas; (3) gradient boosting (XGBoost/LightGBM) con MLOps — 8–12 semanas.
- Mínimo de datos para ML: 500 leads/mes + 12 meses de historia + ≥ 100 deals cerrados como clase positiva.
- Métricas baseline de calidad: AUC-ROC ≥ 0.75, precision@top-decile ≥ 3× la conversión base, lift en el primer decil ≥ 2.5×.
- ROI típico en LATAM: MQL→demo del 3% al 8% en 90 días, +30–50% en velocidad del deal, payback 6–12 semanas.
- Dónde NO funciona: startups con < 100 leads/mes, sales cycle > 18 meses, outbound con ICP distinto en cada campaña.
Contexto: por qué ahora, por qué en LATAM
El lead scoring como concepto existe desde los años 80. IBM popularizó BANT (Budget, Authority, Need, Timeline) para calificar clientes enterprise. En 2008 HubSpot y Marketo democratizaron el scoring basado en reglas para SMB: cada acción del lead (abrir email, descargar un whitepaper, visitar la página de pricing) sumaba puntos; superado el umbral, el lead pasaba a SDR.
Desde 2018 el estándar para B2B SaaS con ≥ 500 leads/mes es el predictive lead scoring vía ML. Salesforce Einstein, HubSpot Predictive Scoring, Marketo Predictive Audiences, Microsoft Dynamics Sales Insights — todos comparten una idea: el modelo aprende de tus datos históricos de win/loss y predice a qué lead nuevo se parece estadísticamente cada quien que cerró antes.
#1. Tres cambios estructurales en LATAM 2024–2026
B2B SaaS en plena expansión. Tiendanube, Bitso, Kavak, Clip, Cobre, Nowports cerraron series B–D enfocadas en eficiencia operativa. Eso significa más roles de CRO/RevOps en la región, que llegan con playbook americano y exigen lead scoring como pieza mínima de un sales process viable.
WhatsApp como canal primario. En Mexico, Colombia, Argentina y Peru, el 70–85% de la comunicación B2B pasa por WhatsApp Business. Esto rompe el funnel clásico de email: el lead no deja correo ni descarga PDF — escribe "Quiero info" en el chat 30 segundos después de ver el anuncio. El lead scoring tiene que incorporar velocidad de respuesta en WhatsApp, longitud del primer mensaje, especificidad de la pregunta. Eso no viene listo en HubSpot, Salesforce ni Marketo — hay que hacer feature engineering custom.
SDRs asistidos por IA. ChatGPT, Claude y Gemini ya están metidos en el stack del CRM vía Zapier, Make, Bardeen o integraciones directas por API. El SDR no escribe el first-touch a mano: elige entre 5 variantes generadas. El scoring deja de ser solo un filtro y se convierte en dispatcher — decide qué prompt-template darle al modelo para cada lead específico.
#2. ¿En cuál de las tres situaciones estás?
Si manejás un equipo B2B en CDMX, Bogotá, Lima, Santiago o Buenos Aires en 2026:
- A. No tenés lead scoring. Los SDR atienden leads en orden de llegada (FIFO), conversión MQL→demo abajo del 5%, nadie entiende por qué. Por nuestra estimación: ~60% de las B2B de la región.
- B. Tenés scoring por reglas, pero no se calibra hace un año o más. Las reglas las escribió el head of sales anterior, el ICP cambió dos veces, los pesos nadie los revisó. La conversión se degrada 10–15% al año por drift.
- C. Tenés un modelo ML, pero sin MLOps. Alguien de data science construyó el scoring hace un año, lo subió a producción vía cron-job, y el modelo está driftando — sin monitoreo.
Qué hacer en cada caso — abajo.
Tres niveles técnicos de madurez
#1. Nivel 1 — Scoring basado en reglas en el CRM (1–2 semanas)
La base con la que arranca cualquier empresa. Dentro de Odoo CRM, HubSpot, Salesforce o Pipedrive definís reglas del tipo "+10 si rol CEO/CTO", "+15 si la empresa tiene 50–500 empleados", "−20 si el email es gmail.com", "+25 si visitó /pricing en los últimos 7 días".
Feature set mínimo para LATAM B2B:
Demográficas:
- Rol (CEO/CTO/Director — peso alto; Analyst/Coordinator — peso bajo)
- Tamaño de empresa (50–500 empleados — sweet spot del mid-market SaaS)
- Industria (e-commerce, fintech, cadena retail — prioridad; agencias, freelancers — abajo)
Firmográficas:
- Geolocalización (CDMX, São Paulo, Bogotá, Lima, Santiago — arriba; ciudades tier-2 — abajo)
- Stack tecnológico (Shopify, VTEX, Stripe, AWS — peso alto)
- Etapa de la empresa (Series A+ vs bootstrap)
Comportamiento:
- Abrió email en los últimos 7 días (+5)
- Visitó /pricing (+15), /demo (+25)
- Descargó case-study (+10)
- Respondió la secuencia de nurture (+20)
Señales negativas:
- Email personal (gmail/hotmail/yahoo): −10
- Job-seeker / estudiante por perfil: −30
- Competidor: −1000 (excluir de facto)
En Odoo se configura con el módulo crm_score (community) o predictive_lead_scoring (Enterprise). En HubSpot, el Score builder de Marketing Hub Professional/Enterprise. En Salesforce, Lead Scoring + Einstein Lead Scoring. Umbrales: MQL = ≥ 50 puntos, SQL = ≥ 80, hot = ≥ 100. Se ajustan según la distribución de tus datos históricos.
#2. Nivel 2 — Regresión logística (4–6 semanas)
Cuando las reglas llegan a meseta (suele ser a los 6–12 meses), saltás a ML. La regresión logística es el primer paso correcto: interpretable (cada feature tiene un coeficiente con signo entendible), entrena rápido, no overfittea en datasets chicos.
Stack:
- Python 3.11+, scikit-learn, pandas, numpy
- Storage: PostgreSQL (la DB de Odoo) o BigQuery/ClickHouse para analítica
- Feature engineering: dbt o Airflow
- Serving: endpoint FastAPI con webhook hacia el CRM
Pipeline:
- Extracción — todos los leads de los últimos 12–24 meses con outcome (closed_won / closed_lost / no_response).
- Labels — binario: 1 = closed_won dentro de 90 días desde la creación, 0 = todo lo demás.
- Features — 15–30 atributos demográficos / firmográficos / comportamentales.
- Train/test split — 80/20, estratificado por label.
- Training —
LogisticRegression(class_weight='balanced', penalty='l1')para datos desbalanceados + feature selection automático. - Evaluación — AUC-ROC, curva precision-recall, calibration plot, matriz de confusión.
- Deploy — modelo en joblib + FastAPI + cron retraining cada 30 días + registry en MLflow.
Métricas objetivo:
- AUC-ROC ≥ 0.75 (random baseline = 0.5)
- Precision@top-10% ≥ 3× la conversión base
- Lift en el primer decil ≥ 2.5×
Si obtenés AUC < 0.65 — los datos son ruidosos o los features no separan las clases. No deploys: cavá en features y data quality.
#3. Nivel 3 — Gradient boosting (XGBoost/LightGBM, 8–12 semanas)
Cuando tenés ≥ 5 000 leads/mes y hay interacciones no lineales complicadas entre features (por ejemplo, tamaño_empresa × industria × source — pura no-linealidad), pasás a boosting.
Ventajas:
- Captura mejor interacciones no lineales y efectos pairwise.
- Maneja missing values nativamente.
- SHAP values para interpretabilidad — crítico para ventas: tienen que entender por qué el score es ese.
Desventajas:
- Requiere más positive examples (5 000+).
- Más complejo en producción (versioning, monitoring, A/B testing).
- Puede overfittear rápido en segmentos chicos.
Adicionales al stack:
- MLflow para experiment tracking y model registry.
- DVC o LakeFS para versioning de datos.
- Evidently AI o Arize para drift monitoring.
- Dashboard en Grafana para métricas de negocio (conversión por score-bucket).
Métricas de producción:
- AUC-ROC ≥ 0.82
- Precision@top-decile ≥ 4× la conversión base
- Detección de drift: PSI < 0.1 por feature, mensual.
- Cadencia de recalibración: ≤ 30 días.
| Nivel | Tiempo | Leads/mes mínimo | AUC esperado | Costo típico USD |
|---|---|---|---|---|
| 1 · Reglas en CRM | 1–2 sem | 50+ | — | 3 000–8 000 |
| 2 · Regresión logística | 4–6 sem | 500+ | 0.72–0.80 | 15 000–35 000 |
| 3 · XGBoost + MLOps | 8–12 sem | 5 000+ | 0.82–0.88 | 40 000–120 000 |
#4. Integración con Odoo (patrón para PYME LATAM)
Arquitectura típica: un servicio Python fuera de Odoo lee leads vía la API XML-RPC cada hora, los scorea, escribe de vuelta en expected_revenue o en un campo custom ml_score + score_explanation (text con la explicación SHAP). Eso le da al SDR una columna sortable en la vista Kanban y asignación automática por umbral vía las automations de Odoo (base_automation). Si querés profundizar en cómo se monta esto sin morir en el intento, mirá el pillar de Machine Learning para PYME LATAM.
Cuándo funciona — y cuándo no
La mitad de los startups LATAM compran "AI lead scoring solutions" y pierden tres meses porque no se cumplen las condiciones básicas. Esta es la sección más importante del artículo.
#1. Sí funciona (luz verde)
Tenés ≥ 500 leads/mes y ≥ 12 meses de historia. ML necesita estadística. 100 leads/mes × 12 meses = 1 200 leads, de los cuales ~50–80 closed_won. No alcanza ni para regresión logística. Rule-based: OK con 50 leads/mes; ML: desde 500/mes.
ICP claro y un solo sales process. Un único tipo de cliente ideal (por ejemplo, e-commerce Shopify-stores con USD 1–10M de GMV en Mexico/Colombia) — el modelo aprende un patrón. Tres ICPs con ciclos distintos — necesitás tres modelos, no uno.
Marketing y ventas alineados sobre qué significa "qualified". Lo más difícil. Si el head of marketing piensa que MQL = "descargó PDF" y el VP Sales que MQL = "empresa con ≥ USD 5M ARR" — el modelo aprende ruido. El lead scoring se implementa después del SLA marketing↔ventas, no antes.
Datos limpios en el CRM. ≥ 80% de los leads tienen los campos obligatorios completos (company, role, source, industry). Si el 40% es "N/A" en industria — el modelo no aprende, gradient boosting va a inventar patrones falsos en el missing-pattern.
#2. No funciona (luz roja — no gastes plata)
Startup con < 100 leads/mes. No lances ML. Hacé rule-based, enfocate en velocity del pipeline y tracking manual de conversión. A los 12–18 meses — revisás.
Sales cycle > 18 meses. Si vendés enterprise deals de USD 250k+ con ciclo de 2–3 años, los labels (closed_won) llegan demasiado tarde. Para cuando el modelo está entrenado — el mercado ya cambió. Usá MEDDIC/MEDDPICC a mano.
Outbound-only con ICP distinto en cada campaña. Cambiás target-vertical cada semana — el modelo no generaliza. Hacé playbooks separados, no un scoring común.
Un producto / un cliente. Enterprise deals (1–2 al año) — estadísticamente no tiene sentido. Scoreá a mano con custom research por cuenta.
WhatsApp-only sin logging en CRM. Problema clásico en LATAM: los SDR escriben desde WhatsApp personal y no se loguea nada. Lead scoring sin telemetría es inútil. Primero arreglá tracking (WhatsApp Business API vía Twilio / 360dialog / Gupshup + integración con Odoo/HubSpot), después scoreás.
#3. Zona gris
- PYME con 200–500 leads/mes. Se puede hacer rule-based + regresión logística simple. ROI sobre XGBoost no se justifica.
- Marketplace / two-sided. El scoring funciona para un lado (sellers o buyers), pero necesitás un modelo diferente para cada lado.
- Freemium SaaS / PLG. El "lead" es signup, no contact form. Lo que tenés que scorear es usage-behavior, no demographic. Eso es product-led growth scoring — metodología distinta.
Cinco errores que matan el lead scoring
#1. No usar time-decay en features comportamentales
Un lead que abrió un email ayer ≠ un lead que lo abrió hace tres meses. La mayoría de los modelos rule-based los cuentan igual. A los 6 meses tenés "leads zombi" con 150 puntos que se enfriaron en Q1.
Solución: a cada evento comportamental asignale half-life. Email open = 14 días. Pricing visit = 30 días. Demo request = 90 días. En Odoo se hace con una scheduled action que recalcula el score diariamente con decaimiento exponencial.
#2. Demasiados features → overfitting
"Más features = mejor" es un mito. Con 200 closed_won y 80 features el modelo encuentra "patrones" en el ruido. Train AUC = 0.95, en leads nuevos — random.
Solución: regla práctica — no más de N/10 features, donde N = positive examples. 200 closed_won = máximo 20 features. L1 regularization (Lasso) para feature selection automático. Cross-validation obligatorio antes de deploy, no solo train/test split.
#3. Ignorar señales negativas
La mayoría de las empresas scorean solo "lo que suma valor" (abrió, descargó, visitó). Eso produce score inflation: cada lead "activo" tiene 80+ puntos, pero el 90% es basura.
Solución: restá explícitamente por red flags. Email personal: −10. Job-seeker role: −30. Competidor: −1000 (excluir). IP fuera del ICP-geo: −20. Bot-pattern (10+ pages en 30 segundos): −50.
#4. No recalibrar el modelo regularmente
Un modelo entrenado en enero, para diciembre driftea 15–25%. El mercado cambia, el ICP evoluciona, aparecen canales nuevos. Sin retraining — el score se degrada.
Solución: cron el día 1 de cada mes — reentrenar con los datos frescos de los últimos 12 meses, comparar performance, deploy solo si AUC no empeoró. Todas las versiones en el MLflow registry para rollback.
#5. Pasarle scores al SDR sin contexto
El SDR recibe "Lead X = 87". ¿Qué significa? ¿Por qué 87 y no 65? Sin explicación, o ignora el scoring (si su intuición discrepa), o lo sigue ciegamente (peor todavía).
Solución: cada score viene con explicación vía SHAP values: "87 puntos: +25 rol CTO, +20 empresa 100–500, +15 visitó /pricing 3× esta semana, +27 demographic match". El SDR ve el fundamento, lo valida y calibra su intuición. En Odoo — campo custom score_explanation (HTML text); el servicio ML escribe ahí un bullet-list renderizado.
#6. Bonus LATAM: ignorar el engagement por WhatsApp
Si el 70% del sales process pasa por WhatsApp pero el scoring se basa en email opens — sos ciego al señal principal. Integrá la WhatsApp Business API (Twilio, 360dialog, Gupshup, Wati) con el CRM, logueá message velocity, response time, message length y la razón questions/statements como features. Esto suele aportar +0.05–0.08 al AUC en la mayoría de los casos B2B LATAM.
Caso: SaaS B2B en Mexico — del 3.1% al 8.7% MQL→demo en 90 días
Contexto (anonimizado por NDA). Mid-market B2B SaaS en Mexico, target: cadenas retail con 50+ puntos de venta. 5 200 leads inbound al mes, 7 SDR en el equipo, deal-size promedio USD 24k ARR, sales cycle 90 días.
Problema. La conversión MQL→demo llevaba año y medio clavada en 3.1%. Los SDR se quejaban: el 70% de los leads asignados no respondía o decía "no estoy interesado". Marketing consideraba bueno su trabajo (cost-per-MQL USD 12); ventas decía que los leads eran basura. El conflicto clásico marketing↔ventas sin base numérica.
Qué hicimos en 90 días:
Días 1–14 — diagnóstico. Extrajimos 47 000 leads de los últimos 12 meses desde HubSpot y Salesforce, los unimos por la clave email. Analizamos la distribución de closed_won por features. Descubrimos: el 80% de los deals reales venía de empresas con 50–250 puntos retail, usando Shopify o VTEX, con rol "Director de Operaciones" o "CTO". El scoring vigente no los destacaba — los pesos estaban inflados por "email opens" (una métrica fácil de inflar).
Días 15–45 — rule-based v2. Reescribimos las reglas en HubSpot:
- Peso alto: ≥ 50 puntos retail, retail/e-commerce, rol Director+, usa Shopify/VTEX.
- Negativos: agencias, freelancers, email gmail, IP fuera de Mexico.
- Comportamental: visita /pricing + /demo-request + ≥ 2 emails abiertos = +50 bonus.
A los 30 días: MQL→demo del 3.1% al 5.4%. El proyecto ya se había pagado.
Días 46–90 — modelo ML (regresión logística). Construimos un modelo predictivo con 18 features (demographic + firmographic + behavioral + WhatsApp velocity). AUC en test = 0.79, precision@top-decile = 4.2×. Reemplazamos el score basado en reglas por el modelo, dejando el rule-based como fallback para cold-start (leads con menos de 7 días de historia).
Resultados al día 91:
| Métrica | Antes | Después | Delta |
|---|---|---|---|
| MQL → demo | 3.1% | 8.7% | +180% |
| SDR utilization en leads de calidad | 32% | 58% | +26 pts |
| Demo → closed_won | 18% | 23% | +5 pts |
| ARR por SDR / trimestre | baseline | +47% | +47% |
| Costo del proyecto (todo incluido) | — | USD 38k | — |
| Payback | — | 6 semanas | — |
"El SDR dejó de pelearse con marketing. Ya nadie discute la lista de leads de la mañana — la lista es la lista, ordenada por probabilidad de cierre."
Qué NO funcionó. Un intento de sumar features de contenido WhatsApp con un mini-NLP-classifier overfitteó en el dataset chico (6 meses de logging WhatsApp). Lo rollbackeamos y postergamos hasta acumular 12+ meses de datos. Plan: Q2 2026.
Cierre: ingeniería, no magia
El lead scoring no es una "AI feature" que comprás y olvidás. Es un proceso: SLA marketing↔ventas, telemetría limpia en el CRM, modelo iterativo, monitoreo de drift. Sin cualquiera de los cuatro pilares — plata tirada.
En LATAM esto pega especialmente fuerte: ~60% de las B2B siguen con un "scoring" de Excel de 2019, ~25% compraron HubSpot Predictive y nunca lo configuraron, ~10% construyeron ML pero no lo monitorean. Solo ~5% lo hace bien. Si estás en los primeros tres grupos — tenés 3–6 meses de ventaja sobre tus competidores que también recién están despertando. Aprovechá.
¿Querés diagnosticar tu propio funnel? Pediná una auditoría de 30 minutos — miramos juntos tu Odoo/HubSpot/Salesforce y te decimos derecho en qué nivel de madurez estás y si conviene meterle ML hoy. Sin venta detrás.
Para seguir leyendo
- Machine Learning para PYME LATAM — overview de servicios — pillar madre.
- Predicción de churn (abandono de clientes) — el paso siguiente después del scoring.
- Demand forecasting para retail — otro servicio ML.
- Fraud detection en e-commerce — caso de uso vecino.
- Business Intelligence: dashboards para equipos de ventas — monitoreo del scoring en producción.
- Odoo CRM en Mexico — pillar país con sección CRM.
- Odoo CRM en Colombia — equivalente para Colombia.
- Auditoría de Odoo — servicio diagnóstico.
- Marketing Attribution — analítica relacionada.
- Caso: Estée Lauder — remarketing de 12 marcas con targeting predictivo — caso metodológicamente cercano.
Preguntas frecuentes
¿Cuánto cuesta implementar lead scoring en LATAM?
Depende del nivel. Rule-based en Odoo/HubSpot: USD 3 000–8 000 (2–4 semanas; auditoría + setup + training del equipo). Regresión logística: USD 15 000–35 000 (6–10 semanas + integración). XGBoost en producción con MLOps: USD 40 000–120 000 (10–16 semanas + 3 meses de soporte).
Las PYME con 200–500 leads/mes suelen arrancar en el nivel 1; mid-market con 1 000+ leads — directo al nivel 2.
¿Qué ROI esperar de verdad?
Rango realista: MQL→demo sube 50–180% en los primeros 90 días después del nivel 2. SDR-utilization +20–35%. Payback en casos B2B LATAM: 6–12 semanas.
No hay garantías. Si el ICP está difuso o los datos son pocos, el ROI cae. Por eso el filtro de "cuándo NO funciona" es la parte más importante del proyecto.
Lead scoring vs lead nurturing — ¿cuál es la diferencia?
Scoring es ranking de los leads existentes. Nurturing es la secuencia de email/WhatsApp para los que todavía no están listos. Funcionan juntos: el scoring decide quién va a demo ya, quién a nurture y quién se descarta.
Sin scoring, el nurturing spamea a todos por igual y arde la lista.
¿Se puede usar ChatGPT o Claude para lead scoring?
LLM-based scoring es metodología de nicho. Sirve para datos cualitativos (analizar el primer mensaje en WhatsApp, evaluar fit por descripción de empresa). Mala para la tarea clásica de ranking: cara, lenta, no se interpreta, inestable.
Usá LLM como feature-extractor para un modelo ML clásico, no como reemplazo del modelo.
¿Qué hago con los leads que sacaron score bajo?
No los borres. Tres opciones: (1) flow de nurture automático a 90 días; (2) re-scoring cada 30 días (el comportamiento cambia); (3) sweep final con oferta personalizada antes de archivar al día 90.
Un 5–8% de los "fríos" revive a los 60–180 días, sobre todo en LATAM donde el ciclo de decisión suele ser más largo que en USA.
¿Cómo se integra con Odoo en la práctica?
Tres patrones: (1) el módulo nativo predictive_lead_scoring de Odoo Enterprise — simple, caja cerrada; (2) servicio Python externo vía XML-RPC que escribe en un campo custom — flexible, requiere dev; (3) modelo sklearn en Postgres vía PL/Python — lento, cero infra.
Para PYME LATAM recomendamos la opción 2 — el sweet spot entre flexibilidad y costo de mantenimiento.
¿De dónde saco datos si el CRM está vacío?
Si no tenés 12 meses de historia — no hagas ML. Primero 3–6 meses de rule-based + logging disciplinado de cada touchpoint. En paralelo, comprá intent-data (ZoomInfo, Apollo, Clearbit, Cognism) para enrichment y arrancar con features demográficas robustas.
El ML llega a los 12 meses. Saltarse este paso es la causa #1 de proyectos fracasados.
¿Qué herramientas usan los equipos data-metrics.pro?
Stack típico: Python 3.11 + scikit-learn + XGBoost para modelos; PostgreSQL como source-of-truth; FastAPI para serving; MLflow para tracking; Evidently AI para drift; Grafana para dashboards de negocio.
Para CRM-side: Odoo Enterprise o HubSpot Pro, según lo que ya tenga el cliente. No imponemos stack — adaptamos al existente.
