El hospital que no cierra, y el sistema que sí se detenía
Un hospital veterinario que opera 24 horas, los siete días de la semana. Consulta, hospitalización, estética y venta de producto en mostrador, todo en la misma sede. Lo único que tenían en digital era un software de agenda genérico —no hecho para una clínica— y ahí se acababa el sistema. El resto de la operación vivía en objetos físicos: la bitácora de hospitalización, el pizarrón donde se leía qué pacientes estaban internados, la libreta y el formato impreso de recepción, y los Excel que alguien alimentaba en paralelo para todo lo que la agenda no sabía hacer. Las recetas se escribían en Word.
Ninguna de esas piezas se hablaba con las otras. El paciente internado existía en la bitácora y en el pizarrón, pero lo que se le hacía y lo que se le consumía no llegaba solo a ninguna cuenta. El inventario existía en una hoja de cálculo que nunca se enteraba de lo que se gastaba en un servicio. El historial clínico estaba repartido entre lo anotado a mano y lo recordado. Y el pegamento entre todas las piezas era WhatsApp: los avisos y los pendientes se pasaban por chat y se quedaban ahí.
No hubo una gota que derramara el vaso. Fue desgaste. Lo que finalmente movió la decisión fue que, para saber cómo iba el negocio, había que armar la respuesta a mano cada vez —y que ninguna herramienta del mercado hacía las cosas como este hospital las hace.
El antes y el después: seis piezas que no se hablaban, contra un solo lugar donde se acumula todo.
Las decisiones de ingeniería, y lo que descartamos
Por qué no compramos un paquete
La primera opción evaluada fue la obvia: comprar un software veterinario de los que ya existen. Se descartó por una razón que suena menor y no lo es. Ninguno entendía la cuenta abierta de hospitalización.
La cuenta de un paciente internado no es un carrito de compras. Se va acumulando durante horas o días, mientras el paciente sigue ahí: cada procedimiento, cada medicamento, cada insumo consumido. No se "abandona" ni se "vacía", y el inventario que descuenta refleja consumo real, no una intención de compra. Un sistema que modela eso como una venta pendiente termina obligando al personal a llevar la cuenta por fuera —que es exactamente el problema del que veníamos.
Así que el modelo de datos se construyó alrededor de ese concepto: órdenes que son cuentas abiertas, con estatus por servicio, anticipos parciales, comentarios por servicio y avisos escalonados cuando una cuenta lleva demasiado tiempo sin actualizarse —con un rol de respaldo para cuando el responsable directo no responde. Las áreas de trabajo tienen lugares físicos asignables, porque en un hospital importa saber en qué jaula está cada paciente.
Cuatro aplicaciones en lugar de una
La ruta cómoda era una sola aplicación con permisos por rol. Se optó por lo contrario: cuatro aplicaciones separadas, compiladas por separado, cada una con su propio punto de entrada.
El back-office del personal, el portal donde el dueño de la mascota consulta su cartilla de vacunación, el sitio público y el flujo de alta autoservicio son cuatro audiencias con cuatro perfiles de riesgo distintos. El recepcionista a las tres de la mañana y el cliente que quiere ver los servicios en proceso de su perro no tienen por qué cargar el mismo código, ni exponer la misma superficie. El costo fue mantener cuatro compilaciones en lugar de una; a cambio, el portal del cliente puede cambiar sin tocar una línea de lo que usa el personal.
Cuatro aplicaciones, cuatro audiencias — una sola plataforma y un solo modelo de datos.
El control de acceso es propio, no un paquete: roles que agrupan habilidades, y habilidades que se cruzan con los módulos para armar, por usuario, el menú que ese usuario puede ver. Encima van autenticación de dos factores, expiración periódica de contraseñas con historial para que no se reciclen, y bloqueo de sesión. Es más de lo que pide una clínica promedio, y es deliberado: aquí hay expediente clínico y datos personales.
Reportes fijos, o preguntar en español
Para la parte de inteligencia de negocio evaluamos hacer una batería de reportes cerrados. Se descartó porque los reportes fijos contestan las preguntas que alguien anticipó, y el problema original era justamente que las preguntas nuevas no tenían de dónde salir.
En su lugar hay un chat: el administrador escribe la pregunta en español y el sistema la traduce a una consulta. La cadena tiene cuatro escalones: un modelo pequeño y barato decide qué tablas son relevantes, se arma el contexto de esquema sólo con esas tablas, un modelo mayor genera la consulta SQL, y un sanitizador la valida antes de ejecutarla. El resultado se devuelve como texto, tabla o gráfica, y se puede exportar.
El detalle que importa: esa consulta no corre contra la base de producción. Corre contra una conexión de MySQL que sólo tiene permiso de lectura. No confiamos en que el modelo nunca escriba una sentencia destructiva; le quitamos la posibilidad de hacerlo. El sanitizador es la primera línea, los permisos de la base son la que de verdad sostiene.
La cadena completa — y al final, una conexión que no puede escribir aunque quisiera.
Lo que corre solo
Buena parte del valor no está en pantallas sino en procesos que ocurren sin que nadie los dispare: diecinueve tareas programadas. Recordatorios de cita que se revisan cada minuto, confirmaciones el día previo, marcado automático de no-asistencia, avisos de stock bajo de producto e insumo, recordatorios de vacunación, felicitaciones de cumpleaños de la mascota, vencimiento de consultas incluidas, escalamiento de cuentas sin actualizar cada quince minutos, y el aviso al cliente cuando su saldo del monedero está por vencer.
Los envíos de WhatsApp van por plantillas aprobadas, en lotes, sobre una cola en Redis —con monitoreo del saldo del proveedor dos veces al día, porque una campaña que se queda a la mitad por falta de crédito es peor que no mandarla. Los errores del sistema llegan por Telegram al equipo técnico. El correo rota entre varios servidores configurados, para que un buzón saturado no tumbe los avisos del día.
La agenda de citas usa vista por recurso: cada columna es un colaborador o un área, que es como el personal ya pensaba el día antes de que existiera el sistema.
Lo que cambió
Los números de este caso salieron de consultar la base de datos, no de la memoria de nadie.
El sistema lleva decenas de miles de citas registradas desde junio de 2022, y el volumen mensual se multiplicó por seis entre 2022 y lo que va de 2026: la misma plataforma absorbió el crecimiento sin cambiar de sistema y sin migrar nada a medio camino.
Volumen mensual de citas, indexado: 1× en 2022, 6× en 2026.
El ausentismo se volvió medible. Antes no había dónde registrarlo: una cita a la que nadie llegaba no dejaba rastro, así que "se nos cae mucha gente" era una impresión y no un dato. Hoy cada cita tiene estatus, el sistema marca por su cuenta las no-asistencias del día anterior y el número está en el tablero, mes con mes, desde diciembre de 2022. No afirmamos que el software haya reducido el ausentismo —revisamos los datos y no hay evidencia limpia para atribuírselo— y esa es justamente la razón por la que medirlo vale: es la condición para atacarlo con algo que no sea el instinto.
Las recetas dejaron de escribirse en Word. Hoy se arman desde el expediente del paciente y salen en PDF. Sigue tomando varios minutos —capturar es capturar— pero menos que antes, y sobre todo la receta queda guardada en el expediente en lugar de vivir en la carpeta de documentos de alguien.
El dueño ve los números sin pedirlos. Cinco tableros —ventas, servicios, productos, clientes y control operativo con producción por colaborador— más el chat para lo que no está en ningún tablero. La pregunta que antes se armaba a mano ahora se escribe.
Qué haríamos distinto
Dos cosas, con honestidad.
El modelo asume una sola sede. Horarios, áreas de trabajo y caja están pensados para un punto de operación. Si el negocio abriera sucursales, no sería configurar: habría que tocar bastante. Fue la decisión correcta en 2022 —construir para sucursales que no existían habría retrasado el arranque— pero es una deuda real y la nombramos como tal.
Se modeló sobre la marcha, con el hospital operando. Conceptos como la cuenta abierta o la vigencia del saldo del monedero se entendieron bien después de haberlos construido una primera vez, y hubo que rehacer partes. De las 172 migraciones de base de datos que tiene el sistema hoy, 150 se escribieron después de que ya estaba en producción. Con más tiempo de análisis previo sobre esos dos conceptos nos habríamos ahorrado reescrituras; con menos tiempo de análisis y más de operación real, aprendimos cosas que ninguna junta habría revelado. No tenemos claro que el balance se pudiera mejorar mucho.
No vigilamos nuestras propias automatizaciones. El hueco de seis meses sin recordatorios de cita apareció hasta que consultamos la base para escribir este caso, cuatro años después. La tarea corría todos los minutos, no lanzaba ningún error y simplemente no mandaba nada. El sistema monitorea el saldo del proveedor de WhatsApp y avisa por Telegram cuando algo truena, pero nadie vigilaba el caso contrario: un proceso que deja de hacer trabajo en silencio. Un contador de "recordatorios enviados hoy" con un umbral mínimo lo habría cachado en 48 horas. Es la corrección más barata de toda la lista y la que más habría rendido.
El stack, en corto
Laravel sobre PHP 8.4, MySQL y Redis para colas y caché. Cuatro aplicaciones Vue compiladas por separado, con 164 componentes. Autenticación por cookie de sesión, dos factores y acceso con Google. WhatsApp transaccional y masivo por plantillas. Generación de PDF, importación y exportación en Excel, catálogo nacional de códigos postales para las direcciones. Y por debajo, 131 modelos y 172 migraciones que describen un negocio que nadie había escrito antes.
La primera versión salió a producción en mayo de 2022, tres meses después de arrancar, con clientes, mascotas, catálogo, citas, órdenes y expediente médico. Todo lo demás —monedero, portal del cliente, alta autoservicio, chat de inteligencia de negocio, manual embebido— se construyó encima, con el hospital funcionando, durante los cuatro años siguientes. Sigue en desarrollo.
Si tu operación se parece a esta —procesos que ningún paquete entiende y que hoy viven en Excel y en la cabeza de alguien— eso es lo que hacemos en plataformas de gestión interna.
Ficha técnica
Servicios aplicados
Stack tecnológico