Hay una forma bastante fácil de crear «software para un sector».

Coges un programa genérico, cambias algunos nombres, añades varias pantallas específicas, fotografías bonitas y una página que dice que está «diseñado para profesionales como tú».

Nos interesa bastante poco construir KERP Clínicas de esa manera.

Tampoco queremos cometer el error opuesto: sentarnos con una lista infinita de peticiones y convertir el producto en la suma de todo lo que cada clínica pida.

Un buen software vertical necesita algo más difícil.

Tiene que entender qué partes de un negocio son realmente diferentes, cómo se relacionan entre sí y qué excepciones importan cuando el software se enfrenta al trabajo de verdad.

Y eso no se aprende únicamente programando.

Lo aprendimos construyendo software para otro sector

KERP no empezó en medicina estética.

Llevamos años construyendo software de gestión y una de nuestras verticales más desarrolladas es la de tiendas de bebé y puericultura.

Desde fuera, una tienda es una tienda.

Desde dentro, esa frase sirve de poco.

Una lista de nacimiento no es simplemente un carrito con muchos productos.

Un artículo reservado no puede tratarse siempre como stock disponible.

Una venta que empieza en la tienda física y continúa online no debería obligar a gestionar dos negocios distintos.

Comprender esas diferencias cambia el software.

No porque haya que llenar el producto de funciones «especiales», sino porque la representación equivocada de una operación termina obligando a las personas a compensarla manualmente.

Ese aprendizaje es una de las razones por las que estamos construyendo KERP para nuevos sectores.

No queremos ofrecer el mismo programa con otra fotografía.

Queremos averiguar qué debe entender el producto para que el negocio no tenga que adaptarse continuamente al software.

Medicina estética tampoco es una agenda con pacientes

Desde fuera puede parecer sencillo:

entra una consulta, se reserva una cita y un profesional atiende al paciente.

Pero sólo hace falta seguir el proceso un poco más para que empiecen a aparecer relaciones específicas.

Una conversación puede convertirse en una cita.

La cita puede necesitar una determinada disponibilidad profesional.

La atención puede generar información clínica, fotografías, consentimientos y tratamientos.

Un procedimiento puede estar relacionado con determinados productos, lotes o cantidades.

Después pueden existir cobros, revisiones, nuevas sesiones o seguimiento.

Y la dirección necesita mirar todo eso desde otro nivel: actividad, capacidad, consumo, costes y trabajo pendiente.

Eso no significa que todas las clínicas funcionen igual.

De hecho, suponer que funcionan igual sería exactamente el error que queremos evitar.

Dos clínicas pueden ofrecer tratamientos parecidos y organizar responsabilidades, agenda, revisiones, compras o seguimiento de maneras diferentes.

Ahí empieza el trabajo interesante.

No estamos empezando con una presentación de PowerPoint

También queremos ser claros sobre el punto en el que estamos.

KERP Clínicas no es todavía una idea que algún día pretendemos programar.

Existe ya una base funcional importante.

Actualmente estamos trabajando sobre un sistema que conecta, entre otras piezas:

• conversaciones procedentes de WhatsApp, Instagram y Messenger;
• responsables, estados e histórico;
• paso de prospecto a paciente;
• agenda multiprofesional y disponibilidad;
• historia clínica;
• consentimientos y fotografías;
• tratamientos;
• facturación y cobros;
• productos, stock, lotes y costes;
• proveedores y compras;
• seguimiento;
• y gestión de la jornada del equipo.

Eso nos permite hacer algo mucho más útil que enseñar mockups:

seguir un caso completo y comprobar dónde el modelo resiste y dónde se equivoca.

Y que exista software funcionando no convierte automáticamente nuestras hipótesis en ciertas.

Lo difícil empieza cuando el software toca la realidad

Desde un despacho podemos diseñar un recorrido impecable.

La realidad tiene una costumbre desagradable: no leer nuestros diagramas.

Puede aparecer una excepción que habíamos considerado irrelevante.

Dos personas pueden repartirse una tarea de una forma que no esperábamos.

Un dato que parecía imprescindible puede resultar innecesario.

Otro que no habíamos previsto puede condicionar todo el siguiente paso.

Una automatización que parece fantástica en una demo puede ser molesta cuando se repite cincuenta veces.

O podemos haber diseñado perfectamente el caso normal y fatalmente el caso que obliga a una clínica a detenerse y resolver algo a mano.

Eso es lo que queremos descubrir ahora.

No necesitamos que una clínica nos confirme que nuestras ideas son buenas.

Necesitamos que encuentre dónde son malas.

Por qué no queremos declarar terminado KERP Clínicas sin clínicas

Un software vertical no demuestra que comprende un negocio porque incluya las palabras adecuadas en un menú.

Lo demuestra cuando soporta situaciones reales sin obligar constantemente al equipo a inventar soluciones alrededor del programa.

Por eso queremos contrastar el producto con clínicas reales antes de hablar de una versión terminada.

Hay cuestiones que sólo podemos validar de esa forma.

Por ejemplo:

¿qué información necesita realmente recepción cuando una consulta se convierte en cita?

¿Dónde termina una tarea y empieza la responsabilidad de otra persona?

¿Qué excepciones aparecen en agenda?

¿Qué información necesita acompañar a un tratamiento?

¿Qué debería proponerse automáticamente y qué debería quedar siempre bajo decisión humana?

¿Qué necesita ver dirección sin obligar al equipo a registrar datos sólo para alimentar un informe?

¿Dónde se está introduciendo dos veces la misma información?

¿Y qué parte de nuestro modelo es simplemente una buena idea que no sobrevive al trabajo cotidiano?

No conocemos todavía todas esas respuestas.

Decir lo contrario sería vender seguridad que aún no hemos ganado.

Queremos trabajar con un grupo pequeño por una razón

Más adelante abriremos una convocatoria específica para clínicas que quieran participar en esta fase.

Todavía no hemos cerrado sus condiciones y no vamos a inventarlas en este artículo.

Sí tenemos clara una cosa: queremos trabajar con pocas clínicas a la vez.

No para fabricar una falsa sensación de escasez.

Para poder profundizar.

Si sólo preguntamos a cien personas qué funciones quieren, podemos terminar con una lista muy larga.

Si seguimos con atención cómo trabajan unas pocas clínicas, podemos descubrir por qué existe una necesidad, cuándo aparece, qué excepción la rompe y si el problema es común o específico de una organización.

Son aprendizajes distintos.

Ahora necesitamos más del segundo.

Colaborar tampoco significa construir todo lo que nos pidan

Hay otro matiz importante.

No queremos diseñar KERP mediante votación.

Una clínica puede pedir un botón concreto y estar señalando en realidad un problema mucho más profundo.

Otra puede resolver el mismo problema de una forma completamente distinta.

Una petición puede ser crítica para una clínica y perjudicial para otras.

Y algunas ideas simplemente no deberían entrar en el producto.

El trabajo de una clínica colaboradora no será diseñar KERP por nosotros.

Será mucho más valioso:

mostrarnos su realidad con suficiente detalle como para que nuestras suposiciones puedan fallar.

A nosotros nos corresponde convertir lo aprendido en un producto coherente y decidir qué problemas merecen una solución generalizable.

Qué queremos poner a prueba

Tenemos varias hipótesis de producto que ahora pueden confrontarse con la operación real.

Una de ellas es que parte del valor está en conservar la continuidad entre cosas que habitualmente se contemplan por separado: captación, cita, información clínica, tratamiento, cobro, consumo, coste y seguimiento.

Otra es que muchas automatizaciones sólo son realmente útiles si conocen suficiente contexto y saben cuándo dejar la decisión a una persona.

Otra es que la dirección puede tomar mejores decisiones cuando los datos comerciales, operativos y económicos conservan sus relaciones, en lugar de aparecer como estadísticas aisladas.

Son hipótesis.

El siguiente paso no consiste en escribirlas más fuerte en una web.

Consiste en intentar romperlas.

Qué buscamos de una clínica colaboradora

No buscamos una clínica que nos diga que todo está bien.

Tampoco necesitamos que cambie su forma de trabajar para encajar en KERP.

Nos interesa justamente lo contrario.

Queremos entender cómo funciona su operativa actual, qué necesita conservar, dónde aparecen las excepciones y qué ocurre cuando ponemos KERP delante de esas situaciones.

A veces eso confirmará una decisión.

Otras veces obligará a cambiarla.

Y habrá ocasiones en las que descubramos que una necesidad pertenece únicamente a un contexto concreto y no debe convertirse en una regla del producto.

Eso también sería un buen resultado.

Porque el objetivo de esta fase no es poder decir que hemos terminado antes.

Es equivocarnos ahora donde todavía es barato corregirlo.

Construir software vertical exige tomar partido

Hay una tentación fácil en cualquier producto empresarial: añadir suficiente flexibilidad para que «sirva para todo».

El resultado suele ser que nadie reconoce realmente su forma de trabajar.

Nosotros queremos tomar decisiones.

Pero queremos tomarlas después de comprender qué estamos decidiendo.

La experiencia de KERP en puericultura nos ha enseñado que las diferencias aparentemente pequeñas de un sector pueden cambiar profundamente cómo debe comportarse el software.

Ahora toca descubrir cuáles son realmente esas diferencias en medicina estética.

Ya tenemos suficiente producto para empezar esa conversación en serio.

Lo que no tenemos —y no queremos fingir que tenemos— es el conocimiento operativo que sólo puede aparecer cuando el software entra en contacto con clínicas reales.

Ahí empieza la siguiente fase.

Si diriges una clínica y este enfoque te interesa

Más adelante publicaremos las condiciones de la convocatoria para clínicas colaboradoras.

Todavía no anunciamos número de plazas, duración ni condiciones económicas porque no están cerradas.

Si quieres que te avisemos cuando lo estén, puedes escribir a hola@kerp.es con el asunto:

«Clínicas colaboradoras»

No supone solicitar una plaza ni asumir ningún compromiso.

Simplemente nos permitirá avisarte cuando la convocatoria esté preparada.

Mientras tanto, puedes ver qué existe ya en KERP para clínicas de medicina estética y cómo estamos conectando el proceso completo.