Candidatura CRO · Somos Internet
Mis hipótesis para Somos.
Encontré varias oportunidades donde cambiar el orden, la fricción o la conversación
podría cambiar la conversión.
No tengo acceso a los datos internos de Somos. Así que separé lo que puedo observar
públicamente, lo que hipotetizo y cómo lo probaría.
OBSERVACIÓN PÚBLICA
+
HIPÓTESIS
+
PLAN DE EXPERIMENTACIÓN
La gran pregunta
¿Dónde estamos haciendo más difícil
que el usuario avance?
DescubrimientoSomos internet.com · el home ya elige WhatsApp
↓
CTA¿la elección del canal es clara?
↓
WhatsApp / Checkoutdos mundos que no se miden igual
↓
Elegibilidad¿se pregunta al final?
↓
Datos de contactonombre · celular · correo
↓
Agendamientoel punto donde se cierra
↓
Instalaciónla conversión que de verdad importa
Fricción que observé — cada pregunta es una hipótesis en potencia:
¿La elección del canal es clara?
¿La respuesta de WhatsApp es suficientemente rápida?
¿Pedimos datos antes de saber si el usuario califica?
¿La elegibilidad aparece demasiado tarde?
¿El formulario refleja el contexto colombiano?
Mis hipótesis para Somos
Un backlog priorizado, no un informe.
01
Eligibility first — mover la elegibilidad antes de los datos de contacto
Podría reducir fricción y captura innecesaria de datos de quien no califica.
HIPÓTESIS
impacto alto · confianza alta · fácil de probar
02
WhatsApp response time — medir la conversación, no solo el copy
El tiempo hasta la primera respuesta podría ser una variable crítica de conversión que hoy no estamos midiendo.
HIPÓTESIS
impacto alto · confianza media · esfuerzo medio
03
Qualified conversion — definir "conversión real"
Optimizar el primer paso puede subir el volumen sin subir el resultado real.
HIPÓTESIS
impacto alto · confianza alta · esfuerzo medio
04
Colombia-first phone input — resolver la fricción del teléfono
Un flujo optimizado para números colombianos podría reducir errores y abandono.
SUPUESTO
impacto medio · confianza alta · fácil de probar
05
Conversion × capacity — el guardrail del sistema
Un experimento ganador puede no ser un ganador de negocio si la operación no puede absorber la demanda.
REQUIERE VALIDACIÓN
importancia alta · confianza baja · validación interna
La puntuación es mi propuesta de priorización, no un dato de Somos.
Lo que importa: por qué esta hipótesis, qué evidencia la sostiene y qué aprenderíamos.
01 — La hipótesis más fuerte HIPÓTESIS
¿Estamos preguntando la elegibilidad demasiado tarde?
El recorrido público pide los datos de contacto antes de saber si el
usuario puede ser cliente. Si una persona puede descubrir que no califica antes de entregar
sus datos, reducimos esfuerzo innecesario y mejoramos la claridad del recorrido.
Actual
Contacto → Nombre → Celular → Correo → Elegibilidad → Agendamiento
Propuesto
Elegibilidad → Contacto → Nombre → Celular → Correo → Agendamiento
Puede mejorar: experiencia del usuario · conversión calificada · eficiencia del funnel ·
minimización de captura innecesaria de datos.
SIMULACIÓN · no elegibles detectados al final del recorrido en el modelo
Experimento
Control: Contacto → Elegibilidad
Variante: Elegibilidad → Contacto
Métrica primaria
PrimariaAgendamientos elegibles / inicios del funnel
Secundarias
- Completion rate · tiempo de completación
- Abandono por paso · datos capturados de no elegibles
Guardrails
- Sin caída en agendamientos calificados
- Sin aumento de errores de elegibilidad
- Sin aumento de contactos de soporte
Qué haría: validar primero el volumen real de usuarios no elegibles y el impacto de mover este paso.
02 — Conexión directa con el rol HIPÓTESIS
El problema de WhatsApp puede no ser el copy.
Puede ser el tiempo.
WhatsApp no es solamente otro CTA: es una conversación. Y una conversación tiene una
variable crítica: el tiempo.
Instrumentaría el flujo así — hoy probablemente no se mide:
CTA → Chat iniciado → Primera respuesta → Usuario responde → Usuario calificado → Agendamiento
- Tiempo hasta la primera respuesta
- Conversación → calificado · calificado → agendamiento
- Abandono antes de la primera respuesta · abandono después de calificar
SIMULACIÓN · del tráfico entra por WhatsApp · min a la primera respuesta · se pierde calificando
Hipótesis primaria
Reducir el tiempo de primera respuesta puede aumentar la tasa de conversaciones que llegan a agendamiento.
Experimentos posibles
SLA de respuesta rápida vs. comportamiento actual
Acuse automatizado inmediato vs. sin acuse
Guardrails
- Calidad de conversación · tasa de leads calificados
- Carga del asesor · conversaciones inválidas o de baja calidad
Qué haría: antes de tocar el copy, medir si estamos perdiendo conversiones por tiempo.
03 — La definición que cambia el norte HIPÓTESIS
Una conversión no siempre es
un buen resultado.
El rol pide "conversión real". Si el norte es el lead, optimizar el primer paso puede aumentar
el volumen sin aumentar el resultado real.
La cadena que de verdad importa
Lead → Lead calificado → Instalación agendada → Instalación completada
Optimizar el primer paso sin mirar los siguientes puede llenar la parte de arriba del embudo
y no mover la parte de abajo — que es donde vive el negocio.
Jerarquía de métricas propuesta
PrimariaInstalaciones calificadas / inicios de embudo
SecundariaConversión de checkout
GuardrailsElegibilidad inválida · no-show · retraso operativo · cancelaciones
Qué haría: definir con el equipo qué es "conversión real" para Somos antes de ejecutar el primer experimento.
04 — Hipótesis de apoyo SUPUESTO
¿Estamos resolviendo un problema global que
para el usuario colombiano no existe?
Si el servicio opera en Colombia, ¿por qué el usuario debería resolver complejidad internacional?
No planteo que el campo actual sea malo: planteo que puede ser más complejo de lo que el contexto exige.
SIMULACIÓN · de abandono en el paso del teléfono en el modelo
Clave: no optimizaría el campo porque "se ve más simple". Lo haría si los datos muestran que la fricción está afectando una métrica de negocio.
Hipótesis
Un input Colombia-first podría reducir errores, tiempo de interacción y abandono.
Experimento
Control: selector de país internacional
Variante: +57 preseleccionado · formato colombiano indicativo · mínima interacción
Métricas
PrimariaCompletación calificada de checkout
SecundariasTasa de error del campo · tiempo · abandono
Guardrails
- Sin aumento de registros de teléfono inválidos
- Sin caída de agendamientos calificados
05 — Hipótesis de sistema REQUIERE VALIDACIÓN INTERNA
¿Qué pasa después de ganar el experimento?
Antes de escalar un experimento ganador, validaría si el sistema puede absorber el resultado.
Más conversión → Más agendamientos → Más demanda operativa → ¿Más instalaciones?
Lo que habría que validar:
- Capacidad de instalación · tiempo de espera
- Cola de pendientes · cancelaciones
- Completación de instalaciones
Qué haría: usar este modelo solo como guardrail — el criterio de decisión incluye que la operación pueda absorber el resultado. No lo presento como diagnóstico de Somos.
Modelo de capacidad — SIMULACIÓN
Cifras simuladas con semilla fija para demostrar el método. En Somos se validaría con datos internos.
Cómo lo probaría · implementación sintética
Las hipótesis necesitan un sistema
para convertirse en decisiones.
Observación→Hipótesis→Priorización ICE→Experimento→Métrica primaria→Guardrails→Evaluación estadística→Decisión→Documentación
Construí una implementación sintética para demostrar cómo operaría este loop: embudo modelado paso a paso,
marco de experimentos con reglas de decisión estadísticas y resultados reproducibles. SIMULACIÓN
$ npm run run-all
prueba z de dos proporciones · IC 95% · MDE · potencia
experimentos leídos ·
El motor de decisiones
Mi objetivo no es encontrar ganadores.
Es tomar mejores decisiones.
SHIP
- La métrica primaria mejora
- Las guardrails siguen sanas
- La confianza estadística es suficiente
ITERATE
- Hay señal
- Pero la evidencia es insuficiente
- O el mecanismo necesita refinamiento
STOP
- La métrica primaria empeora
- O una guardrail se viola
- Se documenta y se aprende
RESULTADO SIMULADO
Un experimento "ganador" que se bloquea porque rompe una guardrail:
Para cerrar
Si tuviera acceso a los datos internos,
empezaría aquí.
1
Validar el orden de la elegibilidad y medir el volumen real de usuarios no elegibles.La hipótesis más fuerte, la más barata de validar.
2
Instrumentar WhatsApp de punta a punta, sobre todo el tiempo hasta la primera respuesta.El canal de mayor volumen y el menos medido.
3
Definir "conversión real" como métrica de negocio.Instalación calificada, no lead capturado.
4
Ejecutar el primer experimento de alta confianza y bajo riesgo.Y que producto y desarrollo puedan implementarlo rápido.
5
Construir el pipeline de hipótesis para que el equipo lo use después.Un sistema, no un informe.
La oportunidad no es hacer más dashboards. Es convertir cada señal en una hipótesis,
cada hipótesis en un experimento, y cada experimento en una decisión.
Luis Cárdenas · Growth & Data Analytics
Dashboard en /
Apéndice — metodología técnica
El cómo, sin robarle espacio
a las hipótesis.
$ npm run run-all — pipeline completo, reproducible
$ npm run web — dashboard local
$ npm test — tests: unit, fuzz, invariantes
semilla fija: · hipótesis con ICE
0 dependencias externas · Node puro
API: /api/overview · /api/funnel · /api/experiments · /api/backlog
El backlog priorizado que ya construí para la candidatura: