Ir al contenido

HelixVM: la conversión no es un número. Es una variable.

Telemedicina con IA · operaciones de pacientes · una reconstrucción del problema de conversión que empieza por la medición
5 de julio de 2026 por
Hugo Acurio

La respuesta corta

Yo (Hugo Acurio) construí el sistema de operaciones de pacientes detrás del crecimiento de telemedicina de HelixVM, que cubrió más de 100K atenciones a pacientes en unos 18 meses, en un modelo diseñado para tratar a los pacientes dentro de la primera hora desde su llegada. Descompuse la conversión en una cascada etapa por etapa, encontré que la restricción real era la capacidad y no la demanda, y ajusté la oferta a ella con un equipo interno dimensionado para las horas pico más una red de profesionales clínicos contratados que cubría las horas valle y la brecha de licencias en 51 estados. La admisión con IA y un humano en el circuito (human-in-the-loop) elevó la conversión 40% y redujo a la mitad el tiempo de cita, con una persona todavía en el circuito.

El tablero que vi

HelixVM crecía rápido hacia un hito que más tarde anunciaría públicamente, su paciente número 100,000, en un modelo diseñado para dar tratamiento dentro de la primera hora desde la llegada del paciente. La ansiedad operativa, tal como la planteaba el equipo, era la conversión: demasiados pacientes entraban al embudo y muy pocos completaban la atención.

Debajo de ese planteamiento vi dos problemas, y ninguno era el que se estaba discutiendo.

Primero, nadie podía ver en qué punto del recorrido se estaban perdiendo de verdad los pacientes. "La conversión es X por ciento" es un solo número puesto sobre un camino largo y de muchas etapas, y un solo número esconde todo lo que importa. No se puede arreglar una fuga que no se puede ubicar.

Segundo, y este fue el que cambió todo el enfoque: la tasa de conversión se trataba como una constante por alcanzar, cuando en realidad es una variable. Se mueve porque se mueven las cosas que la producen. Tratarla como una meta que se alcanza a fuerza de voluntad es el error. Tratarla como el resultado de un sistema, uno que se puede descomponer y dirigir, es la jugada del operador.

Marketing leyó los números como un problema de conversión y salió a buscar arreglos en el embudo. El tablero decía otra cosa. La demanda está aguas arriba y en su mayor parte fuera de su control, así que la conversión es una variable de oferta, no de marketing. Cuando un profesional clínico se reportaba enfermo, la conversión se movía. Eso no se resuelve con una landing page.



El sistema que inventé

Paso uno: la cascada de conversión. En lugar de un solo número de conversión, construí una cascada: un desglose etapa por etapa del recorrido del paciente, desde el primer contacto hasta la atención facturable, con la caída y su causa adjuntas en cada paso. Admisión, luego proceso, luego coincidencia de expectativas, luego programación de citas, luego plataforma, luego cancelaciones, luego inasistencias, luego profesional clínico, luego atención facturable. Cada caída recibió una causa, además de un porcentaje. Por primera vez, el problema de conversión tenía una dirección en cada etapa.

Paso dos: la conversión como variable. Con la cascada en su lugar, la conversión dejó de ser un número que defender y se convirtió en un resultado que yo podía descomponer. Cada etapa era un término de la ecuación, y cada término podía moverse con algo específico. Ese replanteamiento convirtió una ansiedad difusa en un conjunto de palancas manejables, ordenadas según movieran la demanda o la capacidad.

Paso tres: la restricción se reveló sola. Con la admisión fuerte y las primeras etapas sanas, la conversión seguía perdiéndose, y se perdía en las etapas gobernadas por la capacidad y no por la demanda. El cuello de botella estaba en la habilidad de la operación para ajustar la oferta a la demanda que ya estaba ganando, no en atraer pacientes. Ese es el hallazgo que la cascada se construyó para sacar a la luz, y es el que redirigió todo el esfuerzo.

Si la conversión sigue a la oferta, el trabajo es hacer que la oferta se flexibilice frente a la demanda. Pero la capacidad clínica propia solo se flexibiliza en una dirección sin costo, porque los clínicos ociosos en un valle son puro gasto y nadie en esa etapa tiene el balance para sostenerlo. Así que la elasticidad había que alquilarla en lugar de tenerla en planta: un equipo interno dimensionado para las horas pico principales, una red de profesionales clínicos contratados que cubría las horas valle y la brecha de licencias en 51 estados, y el pronóstico de S&OP guiando el ajuste entre ambos. Los representantes de servicio al cliente (CSR) cargaban con la elasticidad humana.



Lo que construí

Un instrumento de medición que la operación no tenía: la cascada completa, etapa por etapa, causa por causa, legible para la dirección en tiempo real. Sobre él, la disciplina operativa para tratar la conversión como un sistema que se dirige y no como un número que se persigue, con las palancas agrupadas según movieran la demanda o la capacidad.

Arquitectura de cobertura clínica en 51 jurisdicciones, cadencia de pronóstico de S&OP, SOP de admisión y escalamiento, tableros de KPI por departamento, admisión asistida por IA que redujo los tiempos de cita y la política de inasistencias. Todo dentro del perímetro de HIPAA (manejo de PHI bajo BAA), operado con la misma disciplina que el trabajo regulatorio del lado farmacéutico.


El resultado

Por fin la operación podía ver la conversión en lugar de adivinarla, y podía actuar sobre la parte que de verdad gobernaba el resultado. El replanteamiento llevó la conversación de "¿por qué el número está bajo?" a "¿qué etapa, qué causa, demanda o capacidad?", que es la diferencia entre tratar el síntoma que la operación suponía tener y diagnosticar el que tenía de verdad.

Las cifras internas específicas están protegidas por un acuerdo de confidencialidad (NDA) y no se reproducen aquí. El hito de los 100,000 pacientes y el modelo de tratamiento en menos de una hora son declaraciones públicas de la propia HelixVM.


Lo que esto demuestra

La jugada transferible aplica a cualquier operación que tenga enfrente un número que quiere mejorar: construir el instrumento antes del arreglo, descomponer el número en el sistema que lo produce y encontrar la restricción antes de gastar un dólar en mover algo. Ver el tablero, inventar el sistema y construirlo. Cambia el dominio; el cableado sigue siendo el mismo.


Compartir
Etiquetas
Archivo

Preguntas frecuentes

¿Cómo escalar las operaciones de pacientes en telemedicina a más de 100,000 pacientes?

Deje de gestionar la conversión como un solo número y empiece a medir el camino que la produce. Para HelixVM construí una cascada etapa por etapa, desde la admisión hasta la atención facturable, encontré que la restricción real era la capacidad clínica y no la demanda, y ajusté la oferta a ella con un equipo interno dimensionado para las horas pico más una red de profesionales clínicos contratados que cubría las horas valle y la brecha de licencias en 51 estados. Ese sistema llevó a la operación a más de 100K atenciones a pacientes en unos 18 meses.

¿Qué mejora la conversión en la admisión de pacientes de telemedicina?

La admisión con IA y un humano en el circuito elevó la conversión 40% y redujo a la mitad el tiempo de cita. La palanca fue una cascada etapa por etapa del recorrido del paciente, con la caída y su causa adjuntas en cada paso, para ver exactamente en qué punto del recorrido se perdían de verdad los pacientes.

¿Cuál es la mayor restricción al escalar una empresa de telemedicina?

La capacidad, no la demanda. Con la admisión y las primeras etapas sanas, la conversión seguía perdiéndose en las etapas gobernadas por la capacidad clínica. La solución fue un equipo interno dimensionado para las horas pico más una red de profesionales clínicos contratados que cubría las horas valle y la brecha de licencias en 51 estados, para que la oferta pudiera flexibilizarse frente a la demanda en lugar de quedarse fija.