Clínica de larga estadía
De WordPress a aplicación de gestión
Años de evolución, respondiendo a las necesidades de cada momento. Un proyecto que sigue creciendo: hoy son más de 14 páginas, backend propio y panel de seguimiento de leads.
Ver el sitioLa privacidad es lo primero
El tipo de dato definió el stack, no la preferencia técnica.
El proyecto maneja datos de categoría sensible. Eso impone un estándar distinto: menos herramientas, menos tránsito y menos superficie donde el dato pueda quedar expuesto.
Por eso el sitio salió de WordPress. Un CMS supone plugins, actualizaciones y código de terceros conviviendo con la información en el mismo servidor, y cada pieza añadida es una dependencia que hay que auditar. En HTML esa superficie desaparece: todo se resuelve con lo que el servidor ya corre, sin intermediarios. La base vive fuera del directorio público.
La medición sigue el mismo criterio y se ajusta a las políticas de Google y Meta sobre categorías sensibles: se mide el rendimiento de cada campaña, nunca información de la persona.
- HTML
- PHP
- SQLite
- JavaScript
- Apps Script
Tres hitos, tres tecnologías
El proyecto lleva años evolucionando para responder a lo que el negocio necesita en cada momento.
El sitio público
WordPress funcionaba bien. Se cambió porque el proyecto ya pedía tres cosas que un CMS genérico solo concede a medias: protección de datos, control y desempeño. Cada plugin y cada actualización es código ajeno corriendo en el mismo servidor donde vive la información. En HTML estático esa superficie no existe.
Sin plugins que actualizar, sin código externo que auditar y sin licencias que renovar. Control real sobre cada página, con navegación móvil con reglas propias, URLs limpias y SEO trabajado desde la estructura. Y un sitio mucho más liviano y rápido, que pesa en el posicionamiento y en la carga desde un celular.
La reescritura no buscaba solo un sitio mejor, sino una base sobre la que se pudiera construir.
Más control sobre la medición
Las primeras campañas comenzaron cuando el sitio aún estaba en WordPress. La migración a HTML abrió una nueva oportunidad: llevar la medición al código y controlar directamente los eventos de los CTA, el envío de formularios y los redirects posteriores a cada conversión. Google Tag Manager, Google Ads conversion tracking y Meta Pixel pudieron integrarse así alrededor de acciones verificables y páginas de gracias específicas para cada flujo.
Para las campañas se mantuvieron dos landings y dos formularios independientes: /cotiza para Google Ads y /cotiza-fb para Meta Ads. Ambos persiguen el mismo objetivo, pero terminan en páginas de gracias diferentes, donde se registra la conversión correspondiente. La separación evita depender de parámetros persistidos en la URL o en el navegador y mantiene inequívoca la atribución de cada canal.
La experiencia y la medición se separaron en el frontend; la validación, el registro y las notificaciones permanecieron centralizados en un handler PHP.
Del envío a la respuesta
Los cuatro formularios fueron diseñados para sentirse simples. El visitante completa sus datos, recibe validación inmediata y realiza el envío de forma asíncrona: la interfaz permanece activa mientras el servidor procesa la solicitud y comunica el resultado con claridad. En los formularios de campaña, una respuesta válida conduce a la página de gracias correspondiente.
Después de validar los datos, la consulta queda registrada y el visitante recibe un correo automático que confirma su recepción. Al mismo tiempo, el equipo es notificado para comenzar el seguimiento. La conversión se mide después de completar ese proceso, de modo que los reportes representen contactos enviados correctamente y no intentos incompletos.
Además, cada contacto alimenta un registro de marketing mediante fire-and-forget, sin añadir espera al usuario. El sistema está diseñado para contener errores: si una integración secundaria tarda o falla, la consulta ya fue registrada y notificada. Así, un problema aislado no se convierte en una pérdida de información ni interrumpe la experiencia.
El panel que usa el equipo
A medida que aumentaron las consultas, el correo y las planillas siguieron sirviendo como registro, pero no mostraban con claridad el estado de cada caso ni qué gestiones estaban pendientes. El siguiente paso fue desarrollar un sistema de gestión a medida, integrado directamente al backend del sitio. Cada nueva consulta queda disponible de forma inmediata para su seguimiento, sin importaciones periódicas ni sincronizaciones manuales.
No todas las consultas requieren el mismo recorrido. Contacto general, admisiones y postulaciones laborales cuentan con etapas propias, mientras la bandeja prioriza solamente lo que necesita atención. Cuando un caso se cierra, se archiva: sale de la vista de trabajo, pero permanece disponible en el historial para conservar su trazabilidad.
Para comenzar sin perder el contexto acumulado, varios años de registros históricos distribuidos en distintas planillas fueron migrados con Python. El proceso normalizó formatos heterogéneos y los incorporó a una base estructurada mediante reglas reproducibles. La clasificación se apoyó en el origen verificable de cada registro, no en interpretaciones automáticas de su contenido, reduciendo errores y dejando una migración auditable.
Stack en evolución
Cada pieza entró en una etapa concreta y algunas cambiaron de función a medida que el sistema maduró. El criterio fue aumentar el control sin sumar una carga operativa que el proyecto no necesitaba.
| Tecnología | Por qué esa |
|---|---|
| HTML estático + Bootstrap 4 + jQuery 3.6 + vanilla JS | Despliegue directo en cPanel y sin build step. Se conservó la interfaz ya probada y las nuevas interacciones se implementaron con control directo sobre el código. |
| PHP nativo, sin Composer | El runtime disponible en cPanel se ajustó según los requisitos del panel. Permitió implementar formularios, sesiones e integraciones con despliegue directo y sin incorporar un framework de aplicación. |
| SQLite vía PDO | Persistencia relacional y transacciones para un equipo y una concurrencia acotados, sin operar un servidor de base de datos adicional. |
Correo nativo de PHP (mail()) |
Aprovecha la capacidad transaccional disponible en el hosting para notificaciones y correos de confirmación. El registro previo evita que un problema de correo implique perder la consulta. |
| Python para migración | Permitió normalizar años de datos heterogéneos mediante un proceso reproducible. Se utilizó como herramienta de migración, sin quedar como dependencia de producción. |
| GTM + Google Ads + Meta Pixel | Eventos y páginas de conversión definidos por flujo, con señales útiles para reportes y smart bidding sin trasladar esa complejidad al equipo. |
| Google Apps Script | Registro paralelo y desacoplado. Comenzó como herramienta operativa y evolucionó hacia una capa de conciliación: permite contrastar los contactos registrados por el sistema con las conversiones atribuidas por Google Ads y Meta Ads, sin intervenir en el flujo principal. |
Lo que quedó en operación
14 páginas
Un sitio institucional que incluye dos landings de campaña con recorridos de conversión independientes.
4 formularios
Contacto general, postulación laboral, Google Ads y Meta Ads, con validación y confirmación automática.
Años de registros
El historial se incorporó a un sistema de seguimiento conectado directamente con los nuevos contactos.
8 documentos
Documentación técnica versionada sobre arquitectura, cambios, respaldo y restauración.