Qué ofrecen los vendors españoles que hoy rankean en Perú
Si buscas 'software de agenda médica con IA' desde Perú, los primeros resultados suelen ser plataformas SaaS con sede en España: agenda online, recordatorios por SMS o email, un panel de reportes y, en los planes superiores, algún módulo de IA para sugerir horarios o resumir historias clínicas. Son productos maduros, con años de iteración sobre el mercado europeo, y cubren razonablemente bien el caso genérico de una consulta médica individual que necesita un calendario ordenado.
El problema no es la calidad del producto en sí — varios son sólidos dentro de su alcance — sino que están diseñados sobre supuestos de otro mercado: facturación bajo otro régimen fiscal, integraciones pensadas para seguros europeos, soporte en huso horario de Europa y, casi siempre, un canal de mensajería secundario o inexistente frente al chat web. Adoptar uno de estos productos en Perú significa aceptar esos supuestos como punto de partida, no adaptarlos a la operación local.
Esto no es un defecto del producto: es consecuencia de para qué mercado fue construido. Un vendor que factura la mayor parte de su negocio en España, Portugal o México invierte su roadmap en lo que ese mercado le pide, y el mercado peruano — más pequeño en volumen de clientes para ese vendor — rara vez tiene prioridad cuando se decide qué integración construir primero. Eso explica por qué el módulo de WhatsApp, cuando existe, suele ser una función añadida tarde y no el canal principal alrededor del que se diseñó el producto.
Qué no cubren: soporte local, WhatsApp, cumplimiento peruano
Tres huecos aparecen de forma consistente al evaluar estos vendors para una clínica peruana. El primero es el soporte: un ticket abierto a las 9am hora de Lima puede esperar hasta la tarde siguiente si el equipo de soporte opera en horario europeo, y un problema en la agenda de un día laboral no admite ese margen. El segundo es el canal: estas plataformas priorizan el chat web o el correo, cuando en Perú WhatsApp es, con diferencia, el canal donde el paciente espera poder escribir, confirmar o reprogramar una cita.
El tercero es el cumplimiento normativo local. Un producto diseñado bajo el RGPD europeo no está automáticamente alineado con la Ley 29733 de Protección de Datos Personales del Perú, que tiene su propio régimen de datos sensibles aplicado a información de salud, su propia autoridad de control y sus propios requisitos de consentimiento. Delegar el cumplimiento a un producto extranjero sin verificarlo caso por caso es un riesgo que pocas clínicas evalúan antes de firmar la suscripción. A esto se suma que SUSALUD, como entidad supervisora del sector salud en Perú, opera bajo criterios propios de habilitación y calidad de servicio que un vendor sin operación local rara vez conoce a detalle.
Hay un cuarto hueco menos visible pero igual de costoso: la integración con lo que la clínica ya usa. Estos productos suelen exigir migrar la agenda completa a su plataforma como condición para funcionar, en vez de conectarse al sistema de historias clínicas o facturación que la clínica ya opera. Esa migración forzada es, en la práctica, el motivo más frecuente por el que una clínica peruana prueba uno de estos SaaS y termina abandonándolo a los pocos meses: el costo de mover toda la operación no se justifica frente al beneficio de un calendario más moderno.
Alternativa: implementación a medida con soporte local
La alternativa no es necesariamente construir un sistema de agenda desde cero: es integrar la automatización sobre el sistema que la clínica ya usa, con soporte y criterio local, en vez de migrar toda la operación a una plataforma cerrada. Esto tiene una ventaja estructural sobre el SaaS genérico: la implementación se adapta a las reglas reales de la clínica (bloques por profesional, tipos de procedimiento, políticas de anticipación) en vez de forzar la operación a encajar en el modelo de datos del vendor.
El soporte local también cambia la naturaleza del problema cuando algo falla: un ajuste a una regla de agenda, una integración con el sistema de facturación existente o un cambio en el flujo de WhatsApp puede resolverse en el mismo huso horario, con alguien que conoce la operación específica de la clínica, no un ticket genérico dentro de una cola de soporte internacional.
Esto no significa que cualquier desarrollo a medida sea preferible a un producto probado: significa evaluar la implementación por lo que resuelve, no por la etiqueta de 'a medida' o 'SaaS'. Un buen proyecto local reutiliza componentes ya maduros — mensajería, orquestación, almacenamiento — y concentra el desarrollo propio en la parte que sí es específica de la clínica: las reglas de agenda, el flujo de WhatsApp con CRM y la integración con el sistema existente. Esa combinación reduce el riesgo frente a construir todo desde cero.
Costos comparados: suscripción vendor vs proyecto a medida
La comparación de costos no es tan simple como precio de licencia contra precio de proyecto. Un SaaS internacional cobra una suscripción mensual predecible, generalmente por usuario o por sede, con el costo de que cualquier necesidad fuera del producto estándar (una integración, un reporte específico, un flujo de WhatsApp con reglas propias) suele no estar disponible o requerir un plan superior que no siempre existe para el mercado peruano.
Un proyecto a medida tiene un costo inicial de implementación más alto, pero produce un sistema que ya está adaptado a la operación real desde el primer día, sin depender de que el roadmap de un vendor extranjero incluya, algún día, la función que la clínica necesita hoy. La decisión razonable depende del tamaño de la clínica y de cuánto se aleja su operación real del caso genérico que resuelve el SaaS: mientras más específicas sean las reglas de agenda y más central sea WhatsApp en la atención, más pesa la alternativa local.
Hay un costo adicional que rara vez entra en la comparación inicial: el costo de la fricción diaria. Un equipo de recepción que trabaja con un sistema que no refleja las reglas reales de la clínica termina compensando con procesos manuales paralelos — una planilla aparte, notas en papel, confirmaciones por teléfono que el sistema debería haber resuelto. Ese trabajo manual no aparece en la factura del SaaS, pero es un costo operativo real que compite con el precio de la suscripción cuando se hace la comparación completa.
Caso real: clínica en Lima con sistema propio
La implementación de khipura para una clínica en Lima resolvió justamente los tres huecos descritos: agenda integrada al sistema de historias clínicas ya existente, WhatsApp conectado a un CRM propio en vez de un chat web genérico, y reservas directas desde la web que se sincronizan con la misma agenda que usa el personal — sin depender de una plataforma extranjera ni de una segunda base de datos paralela.
El diseño se apoyó en un principio simple pero poco frecuente en el software genérico: la agenda de la clínica tiene reglas propias (bloques por sala, por profesional, por tipo de consulta) y el sistema se construyó para respetarlas desde el modelo de datos, no para forzarlas a encajar en una plantilla estándar de citas. Ese ajuste es, en la práctica, la diferencia entre un sistema que el equipo de recepción adopta sin fricción y uno que termina usándose solo a medias porque no refleja cómo trabaja realmente la clínica.
El soporte, además, quedó dentro del mismo huso horario y con conocimiento directo de la implementación: cualquier ajuste a una regla de agenda o a un flujo de WhatsApp se resolvió con el mismo equipo que construyó el sistema, sin depender de un proceso de soporte internacional ni de esperar que una función llegara en una futura versión del producto. Esa cercanía, más que cualquier función puntual, es lo que termina definiendo si una clínica peruana adopta un sistema o lo abandona a los pocos meses.
Qué preguntar antes de firmar con cualquier proveedor
Sea vendor internacional o desarrollo local, hay preguntas concretas que una clínica peruana debería resolver antes de firmar, en vez de decidir solo por precio de licencia o por la lista de funciones del sitio del proveedor. Ninguna de estas preguntas tiene una respuesta correcta universal — depende del tamaño de la clínica y de qué tan lejos está su operación real del caso genérico que resuelve un producto estándar — pero todas deberían tener una respuesta clara antes de firmar, no descubrirse recién cuando algo falla en producción.
- ¿En qué huso horario y en qué idioma opera el soporte, y cuál es el tiempo real de respuesta ante una falla en la agenda?
- ¿El sistema se integra con WhatsApp como canal principal, o solo como una función secundaria añadida al chat web?
- ¿Quién es responsable del cumplimiento de la Ley 29733 sobre los datos de salud que procesa el sistema: el proveedor, la clínica, o queda sin definir?
- ¿La agenda respeta las reglas reales de la clínica (bloques por sala, por profesional, por tipo de procedimiento) o exige adaptar la operación al modelo del producto?
- ¿Qué pasa con los datos y el historial de conversaciones si la clínica decide cambiar de proveedor más adelante?
