Un portal de clientes a medida es un área privada en la que cada cliente consulta sus pedidos, descarga sus facturas, abre incidencias y sube documentos, con datos que salen directamente de tu ERP o CRM. Bien hecho, responde por ti a las preguntas que hoy llegan por teléfono y por correo.
Esas preguntas tienen un coste que casi nadie mide. «¿En qué estado está mi pedido?», «¿me reenvías la factura de marzo?». Cada una interrumpe a alguien de administración, que busca el dato en el sistema interno y lo copia en un correo. Imagina una distribuidora con 300 clientes activos que recibe diez consultas de este tipo al día: si cada una lleva cinco minutos, son unas cuatro horas a la semana haciendo de intermediario entre el cliente y un dato que ya existe.
Al terminar este artículo sabrás qué debe incluir el portal, cómo garantizar que ningún cliente ve datos de otro y qué patrón de sincronización con el ERP encaja con tu caso.
Qué es un portal de clientes conectado con el software interno
Un portal de clientes conectado es una aplicación web con acceso autenticado que muestra a cada cliente la parte de tu información que le pertenece. Los datos siguen viviendo en el ERP, el CRM o la herramienta de soporte; el portal los consulta, los presenta y permite algunas acciones controladas, como descargar una factura o registrar una incidencia.
Lo que lo separa de una web corporativa es la conexión con tus sistemas y los permisos por usuario, dos piezas que resolvemos en cada proyecto de software a medida en Madrid. La comparativa entre página web y aplicación web ayuda a ubicar el proyecto.
Cuándo compensa desarrollar un portal de clientes a medida
Compensa cuando se cumplen varias de estas condiciones:
- Una parte relevante del trabajo de administración consiste en reenviar documentos o confirmar estados que ya están en el sistema.
- Tus clientes son empresas que necesitan descargar facturas, albaranes o certificados con regularidad.
- El ERP o el CRM que usas no tiene portal, o el suyo no permite adaptar permisos, marca ni flujos.
- Hay procesos propios (aprobaciones, reclamaciones, pedidos recurrentes) que ningún portal estándar recoge.
No compensa si tienes pocos clientes y pocas consultas, o si tu ERP ya incluye un portal que cubre casi todo lo que necesitas. En ese caso, configura bien el suyo.
Qué debe incluir la primera versión
Empieza por lo que genera más consultas y amplía después:
- Pedidos: estado, fecha prevista y seguimiento del envío. Origen del dato: ERP o sistema logístico.
- Facturas y abonos: listado y descarga en PDF. Origen del dato: ERP o programa de facturación.
- Incidencias: alta, adjuntos y estado. Origen del dato: CRM o herramienta de soporte.
- Documentos: contratos, certificados y fichas técnicas por cliente. Origen del dato: gestor documental o ERP.
- Usuarios de la empresa cliente: que el responsable de compras invite a sus compañeros sin llamarte. Origen del dato: el propio portal.
Si tus clientes trabajan desde el móvil, por ejemplo técnicos o comerciales en ruta, valora una app móvil para empresas además del portal web; en cómo se integra una app móvil con el ERP y el CRM explicamos las particularidades de ese canal.
Cómo aislar los datos de cada cliente
Este es el punto que más proyectos subestiman. En la edición 2025 del OWASP Top 10, el control de acceso roto sigue en el primer puesto y aparece en el 100 % de las aplicaciones analizadas. El fallo típico en un portal es el acceso directo a objetos: el cliente ve su factura en /facturas/1043, cambia el número a 1044 y descarga la de otra empresa.
La defensa se construye en capas:
- Autorización en cada petición: el backend comprueba que el recurso pertenece al cliente de la sesión, siempre, aunque el identificador sea difícil de adivinar. Deniega por defecto y permite solo lo explícito.
- Aislamiento en la base de datos: con PostgreSQL, la seguridad a nivel de fila filtra las filas por cliente incluso si una consulta de la API olvida el filtro.
- Roles dentro de la empresa cliente: el responsable de compras ve todo; un usuario de almacén, solo los pedidos.
- Registro de accesos: quién descargó qué documento y cuándo, para responder ante una reclamación.
La autenticación merece la misma atención. La guía de identidad digital del NIST, en su revisión 4 de la SP 800-63B, exige dos factores en el nivel AAL2 y que se ofrezca al menos una opción resistente al phishing, como las passkeys. Para un portal con facturas y contratos, el segundo factor es razonable desde el primer día.
Si el portal trata datos personales, el artículo 32 del RGPD pide garantizar la confidencialidad e integridad de los sistemas, y el aislamiento entre clientes es una medida directa para cumplirlo.
CodeZone Pro Tip: activa Row Level Security para que la base de datos filtre por cliente aunque la API falle
-- Tabla de facturas compartida por todos los clientes del portal
CREATE TABLE facturas (
id bigserial PRIMARY KEY,
cliente_id uuid NOT NULL,
numero text NOT NULL,
importe numeric(12,2) NOT NULL
);
-- Activamos RLS: sin una política que lo permita, no se devuelve ninguna fila
ALTER TABLE facturas ENABLE ROW LEVEL SECURITY;
ALTER TABLE facturas FORCE ROW LEVEL SECURITY;
-- Cada consulta solo ve las filas del cliente de la sesión (sin cliente fijado: 0 filas)
CREATE POLICY facturas_del_cliente ON facturas
FOR SELECT
USING (cliente_id = nullif(current_setting('app.cliente_id', true), '')::uuid);
-- La API fija el cliente tras validar el login, dentro de cada transacción
BEGIN;
SET LOCAL app.cliente_id = '6f1c2b1e-8a0d-4c3e-9f4a-2b7d1e5c9a01';
SELECT numero, importe FROM facturas; -- solo las suyas, aunque la API olvide el WHERE
COMMIT;La API sigue comprobando permisos, pero la base de datos actúa como segunda barrera: si alguien olvida el filtro en una consulta nueva, el resultado es una lista vacía y no una fuga de datos. El nullif evita un error cuando la sesión no tiene cliente fijado, y SET LOCAL impide que el valor se herede entre peticiones. Cuesta poco y cubre la categoría de riesgo que OWASP sitúa en primer lugar.
Cómo sincronizar el portal con el ERP y el CRM
Hay dos patrones, y la mayoría de los proyectos combina ambos.
Lectura en vivo: el portal consulta al ERP en el momento a través de su API. El dato siempre está actualizado, pero el portal depende de la disponibilidad y la velocidad del ERP. Si el ERP tarda cuatro segundos en responder, tu cliente espera cuatro segundos.
Réplica sincronizada: el portal mantiene su propia copia de lo que necesita mostrar (pedidos, facturas, estados) y la actualiza con webhooks o con procesos periódicos. Es rápido y sigue funcionando si el ERP se cae, a cambio de un pequeño retraso en los datos y de más trabajo de integración.
Un criterio práctico:
- Lectura en vivo para datos que cambian a menudo y cuyo retraso molesta, como el stock disponible.
- Réplica para documentos cerrados, como facturas emitidas o albaranes firmados, que no cambian después de crearse.
- Escritura siempre hacia el sistema de origen: una incidencia creada en el portal se registra en el CRM y el portal refleja su estado, nunca al revés.
Decide también qué ve el cliente cuando el ERP no responde: «datos actualizados a las 10:42» genera más confianza que un error genérico. Toda esta lógica vive en el servidor; en qué es un backend y cómo organiza la lógica de datos lo contamos con más detalle.
Si todavía no tienes un sistema central y los pedidos viven en hojas de cálculo, el portal no es el primer paso. Primero toca ordenar la operativa: pasar esos procesos de Excel a una aplicación o plantear un ERP a medida por módulos y fases. Y si la información comercial de cada cliente está en un CRM, el portal puede leerla de ahí; en la comparativa entre un CRM propio y uno comercial adaptado verás qué opción facilita más esa integración.
Rendimiento y experiencia de uso
Un portal lento acaba en una llamada. En sus métricas Core Web Vitals, Google considera buena experiencia un LCP de hasta 2,5 segundos y un INP de 200 milisegundos o menos, medidos sobre el percentil 75 de las visitas. La réplica sincronizada ayuda aquí, porque evita esperar al ERP en cada pantalla.
En el uso diario marcan la diferencia una búsqueda de facturas por número o importe y la descarga masiva para quien envía el trimestre completo a su gestoría.
Cuánto cuesta y cómo plantearlo por fases
El coste depende sobre todo del número de sistemas a integrar y del estado de sus APIs. Un portal con autenticación, dos o tres secciones y conexión con un ERP que ya expone una API suele encajar en lo que nuestra guía de costes de desarrollo según la complejidad define como complejidad media, entre 6.000 y 15.000 €. Si el ERP no tiene API y hay que construir la integración, o si el portal incluye flujos de aprobación propios, el proyecto sube de categoría.
Un plan por fases que suele funcionar:
- Fase 1: acceso seguro, facturas y pedidos. Es lo que más consultas elimina.
- Fase 2: incidencias y documentos, con avisos cuando cambia un estado, por correo o a través de la API de WhatsApp Business.
- Fase 3: usuarios múltiples por empresa cliente, informes y pedidos recurrentes.
Mide antes y después el número de consultas que recibe administración. Es la métrica que justifica la siguiente fase.
El Riesgo de Abrir un Portal sin Aislar los Datos
Un portal de clientes bien construido ahorra horas cada semana. Uno mal construido puede enseñar la factura de una empresa a su competidor. La diferencia se decide al principio, con la autorización en cada petición, el aislamiento en la base de datos y un plan de sincronización con el ERP.
En Codezone diseñamos y desarrollamos software a medida conectado con los sistemas que ya usas. Puedes ver algunos de los proyectos que hemos desarrollado y, si tus clientes todavía te llaman para pedir una factura, cuéntanos cómo trabajas hoy y qué sistemas usas.
