Cómo está hecha esta web

No es una web con un formulario pegado. Son seis piezas que trabajan juntas: la página, el formulario, la base de datos donde caen las solicitudes, el panel para gestionarlas, la capa de seguridad y el trabajo de rendimiento.

• La webArchivos estáticos compilados. Sin servidor de aplicación detrás.
• El formularioValidado dos veces, protegido contra spam y contra envíos duplicados.
• El CRMBase de datos propia con historial de cada cambio.
• El accesoCódigo temporal por correo. Sin registro público.
• La seguridadPolítica de contenido activa y permisos a nivel de dato.
• El rendimientoLo primero que se ve no espera a JavaScript.

Esta web se compila una vez y se publica como archivos: HTML, hojas de estilo e imágenes. Cuando alguien la abre, el servidor no consulta ninguna base de datos ni ejecuta ningún programa. Se limita a entregar el archivo.

Eso elimina de golpe la mayor parte de los problemas que sufren las webs corporativas: no hay gestor de contenidos que actualizar cada mes, no hay plugins que se rompan entre sí, y no hay una base de datos expuesta a internet esperando a que alguien la encuentre.

Qué se gana

Menos piezas que puedan fallar, menos mantenimiento recurrente y una web que carga rápido sin depender de la potencia del servidor.

Qué cuesta

Cambiar un texto no es entrar en un panel y pulsar guardar: hay que volver a generar el sitio y subirlo. Para una web corporativa que cambia poco es un buen intercambio. Para un medio que publica a diario, no lo sería.

El formulario de diagnóstico es la pieza que más nos importa: es por donde entra el negocio. Un formulario que pierde una solicitud cuesta bastante más que uno que tarda un segundo más en enviarse.

Esto es lo que ocurre entre que alguien pulsa enviar y usted recibe el aviso:

1. 1Los datos se comprueban en el navegador y se vuelven a comprobar en el servidor. Lo segundo es lo que cuenta: la validación del navegador se puede saltar.
2. 2Se descartan los envíos automáticos, con un campo trampa invisible para las personas y con una verificación de Cloudflare.
3. 3Se limita el número de envíos desde un mismo origen, para que nadie pueda inundar el buzón.
4. 4La solicitud se guarda en la base de datos y se envía el aviso por correo.

Hay un detalle que suele pasarse por alto y que da bastantes disgustos: si alguien pulsa dos veces el botón, o la conexión se corta y reintenta, no se crean dos solicitudes. El sistema reconoce que es el mismo envío y lo guarda una sola vez.

Ningún filtro detiene el cien por cien del spam. Por eso hay varias capas en lugar de una: lo que se escapa de una, lo para la siguiente.

Las solicitudes no caen en la bandeja de entrada ni en la hoja de cálculo de nadie. Caen en una base de datos propia, con un panel para gestionarlas: estado, prioridad, próxima acción, notas e historial de todo lo que ha pasado con cada solicitud.

Qué se gana

Los datos están en un sitio que no depende del plan contratado con nadie, no se paga por usuario, y el historial es completo: cada cambio queda registrado con quién lo hizo y cuándo.

Qué cuesta

Hay que construirlo y mantenerlo. Un CRM de mercado se pone en marcha en una tarde y trae funciones que aquí no existen.

Cuándo compensa

Cuando el proceso comercial es sencillo y lo que se necesita es control del dato. Si la empresa necesita previsiones, embudos complejos o un equipo comercial grande, tiene más sentido un CRM de mercado bien integrado.

Una decisión que merece mención: las solicitudes no se borran nunca. Se archivan. Un borrado accidental de un cliente potencial no tiene vuelta atrás, y no compensa el riesgo por ahorrar una fila en una tabla.

El panel no tiene registro público: no existe una página donde crear una cuenta. El acceso se hace pidiendo un código de un solo uso que llega por correo. No hay contraseña que reutilizar, filtrar o adivinar.

Por debajo, los permisos no viven en el código de la web sino en la propia base de datos. Aunque alguien consiguiera las credenciales públicas de la página, la base de datos seguiría rechazando cualquier consulta sobre las solicitudes. La protección no depende de que el programa se comporte bien.

El navegador también recibe instrucciones estrictas sobre qué puede cargar y desde dónde, y los archivos que nunca deberían ser públicos —configuración y mapas de código— están bloqueados en el servidor.

La home tiene una escena tridimensional. Ese tipo de elemento suele salir caro: si la página espera a que cargue para mostrar algo, el visitante mira una pantalla vacía durante segundos y una parte se va.

Aquí el orden está invertido a propósito:

• El titular y el texto principal están en el HTML y se ven aunque JavaScript no llegue a ejecutarse.
• La escena 3D no se descarga al abrir la página. Espera a que el navegador esté libre y a que el elemento esté cerca de la pantalla.
• Si el dispositivo pide menos animación o va con ahorro de datos, no se descarga nunca y queda un fondo de marca en su lugar.

El resultado es que el bloque más pesado del sitio, que ronda los dos megabytes, no forma parte de lo que se descarga al entrar. El JavaScript inicial se queda por debajo de 250 KB comprimidos.

Casi ninguna empresa necesita un CRM hecho a medida, y decirlo forma parte del trabajo. Lo que sí se traslada a prácticamente cualquier negocio es más sencillo:

• Una web que carga rápido y no depende de un mantenimiento constante.
• Un formulario que no pierde solicitudes ni duplica las que llegan.
• Un aviso inmediato cuando alguien contacta, para no responder al día siguiente.
• Un sitio donde las solicitudes quedan ordenadas, en lugar de repartidas entre el correo y el móvil.

Si reconoce alguno de esos problemas en su empresa, el primer paso es una conversación para ver qué parte merece la pena resolver primero.