Un extranet para clientes se presenta a menudo como una serie de pantallas: panel de control, documentos, pedidos, perfil y soporte. En realidad, se convierte en una puerta de entrada al sistema de información. Expone datos, desencadena operaciones y representa a la empresa en cada interacción. Su diseño debe, por lo tanto, reunir producto, arquitectura, seguridad y explotación.
El éxito no se mide por el número de funcionalidades. Un buen extranet reduce las solicitudes manuales, hace que la información sea fiable, acelera las tareas recurrentes y le da al cliente una comprensión clara de su situación. También debe impedir que un usuario acceda al expediente de otra empresa, que un documento caducado siga siendo presentado o que una operación se repita por error.
Partir de las tareas, no del menú
El encuadre comienza con los eventos de la relación con el cliente: solicitar un servicio, enviar un documento, seguir un expediente, validar una propuesta, descargar un informe, pagar, señalar una anomalía o agregar un colaborador.
Para cada tarea, documentar:
- el desencadenante ;
- la información necesaria;
- el actor y su organización;
- los estados posibles;
- las validaciones;
- los sistemas implicados;
- las pruebas a conservar;
- las notificaciones;
- los errores y repeticiones.
Este método evita reproducir en el portal la estructura interna de la empresa. El cliente no debe conocer los nombres de los servicios ni los códigos técnicos para lograr su objetivo.
Definir una fuente de verdad por dato
El portal puede mostrar información procedente de un CRM, de un ERP, de una aplicación empresarial o de un almacenamiento documental. Es necesario designar al propietario de cada dato y la dirección de sincronización.
Una copia local puede mejorar el rendimiento o la resiliencia, pero requiere una regla de frescura, una gestión de conflictos y una visibilidad sobre la última sincronización. Los datos ingresados en el extranet deben ser validados antes de ser propagados en los sistemas críticos.
El navegador nunca debe convertirse en la fuente de verdad para una operación importante. Toda acción debe ser controlada del lado del servidor con una clave de idempotencia cuando sea posible el envío doble.
Diseñar la autorización antes de las pantallas
La autenticación responde a «¿quién eres?». La autorización responde a «¿qué puedes hacer en este recurso específico?». Esta segunda pregunta es la más difícil.
Un cliente puede pertenecer a una sociedad, acceder a varios sitios, delegar derechos o disponer de un rol temporal. Una misma persona puede ser administradora de un establecimiento y simple lectora de otro. El modelo debe por lo tanto combinar rol, alcance y condiciones.
Las reglas esenciales son:
- rechazo por defecto;
- control del lado del servidor sobre cada acción;
- alcance explícito por organización o recurso;
- separación de funciones sensibles;
- fecha de vencimiento de las delegaciones;
- registro de cambios de derechos;
- pruebas sistemáticas de accesos horizontales y verticales.
Cadena de confianza de un extranet, desde la autenticación hasta los servicios de negocio y el registro de auditoría.
Autenticación: adaptar el nivel de confianza al riesgo
Una cuenta y una contraseña no siempre constituyen una estrategia suficiente. El extranet puede ofrecer una autenticación multifactor, un SSO con el proveedor de identidad del cliente, claves de acceso o mecanismos de recuperación reforzados.
El nivel debe depender de las acciones. Consultar una noticia no tiene el mismo impacto que descargar un documento sensible o modificar un beneficiario. Se puede solicitar una reautenticación antes de una operación crítica.
Los procesos de creación, invitación, suspensión y salida de un usuario deben diseñarse con el mismo cuidado que la conexión. Las cuentas huérfanas y las invitaciones sin fecha de expiración son riesgos frecuentes.
Construir un tablero de control orientado a la acción
El tablero de control debe responder a tres preguntas: ¿qué está pasando, qué requiere mi atención y cuál es la próxima acción?
Una pila de cartas estadísticas rara vez es suficiente. Las prioridades pueden ser: piezas faltantes, validación pendiente, fecha límite, incidente, nueva versión de un documento o mensaje del soporte. Cada elemento debe conducir a una acción clara y mantener su contexto.
Los indicadores deben utilizar definiciones compartidas con el negocio. Un «expediente en curso» no debe significar una cosa en el extranet y otra en el back-office.
Documentos: versión, prueba y control de acceso
El almacenamiento documental debe distinguir el archivo, su versión, sus metadatos y sus derechos. Una URL predecible o duradera no debe eludir la autorización. Las descargas sensibles pueden usar enlaces cortos firmados, siempre verificados por el servidor.
Para cada documento, prever:
- tipo y estado;
- propietario y perímetro;
- fecha de emisión y de expiración;
- versión reemplazada;
- huella o prueba de integridad cuando sea necesario;
- reglas de conservación;
- accesos y descargas registradas.
La vista previa debe estar aislada y los archivos entrantes analizados. Los formatos no seguros no deben ejecutarse en el contexto de la aplicación.
Notificaciones sin ruido ni fuga de información
Una notificación debe informar sin revelar datos sensibles en un canal no controlado. El correo electrónico puede anunciar que un documento está disponible y luego redirigir al extranet autenticado en lugar de adjuntar el archivo.
El usuario debe poder elegir ciertas preferencias, pero las alertas de seguridad o las obligaciones contractuales pueden permanecer impuestas. Los envíos deben ser idempotentes, rastreables y agrupados cuando ocurran varios eventos.
Integraciones y procesos asíncronos
Las llamadas a sistemas terceros fallan. La arquitectura debe prever colas de mensajes, reintentos, límites de tasa, retrasos, correlación y estado visible. Una acción no debe presentarse como terminada si solo está en espera de procesamiento.
Los webhooks entrantes deben ser autenticados, reproducibles de forma segura y desduplicados. Las API salientes deben aplicar retrasos, circuitos de corte y políticas de reintento adecuadas para no amplificar una falla.
Búsqueda y navegación
La navegación por organización interna rara vez es intuitiva. Una búsqueda transversal puede abarcar carpetas, pedidos, documentos y referencias, respetando los derechos antes y después de la indexación.
Los filtros deben permanecer comprensibles, conservar el estado en la URL cuando esto facilite el compartir y proporcionar una alternativa a las tablas anchas en móviles. Las exportaciones deben respetar el mismo alcance que la pantalla.
Accesibilidad y usos reales
Un extranet se utiliza a menudo en situaciones de urgencia, en una computadora bloqueada, un móvil o con tecnologías de asistencia. Los formularios deben conservar los datos en caso de error, anunciar claramente las validaciones y permitir una navegación completa con el teclado.
Las tablas complejas requieren encabezados correctamente asociados, una vista responsive y, a veces, una versión por tarjetas. Los tiempos de sesión deben ser señalados y el usuario debe poder prolongar su sesión sin perder su trabajo.
Diario de auditoría y soporte
Es necesario poder reconstruir los eventos importantes: conexión, cambio de derecho, descarga, validación, modificación de un dato, envío a un tercero. Un registro de auditoría debe estar protegido, fechado, correlacionado y limitado a la información necesaria.
El soporte cuenta con una vista de asistencia que explica el contexto sin permitir la suplantación silenciosa. Cualquier toma de control o suplantación debe ser explícita, autorizada, temporal y registrada.
Diseñar la explotación desde la planificación
El extranet necesita supervisión técnica y de negocio: disponibilidad, errores, colas bloqueadas, sincronizaciones retrasadas, notificaciones fallidas y procesos anormalmente abandonados. Se deben definir objetivos de servicio realistas según la criticidad.
Copia de seguridad, restauración, plan de recuperación y gestión de secretos forman parte del producto. Los entornos de prueba deben utilizar datos anonimizados o sintéticos.
Medir el valor
Los buenos indicadores no se limitan al número de conexiones. Seguir:
- tiempo necesario para realizar una tarea;
- parte de las solicitudes procesadas sin intervención manual ;
- número de recordatorios por pieza faltante ;
- errores de entrada y correcciones;
- plazo de puesta a disposición de los documentos ;
- contactos de soporte evitados o mejor calificados ;
- satisfacción en los recorridos críticos.
Una disminución de conexiones puede ser positiva si las notificaciones y automatizaciones hacen que algunas visitas sean innecesarias.
Un extranet es un producto duradero
La primera versión debe priorizar algunos recorridos completos, seguros y medibles. Los cimientos —identidad, derechos, datos, auditoría, integraciones y observabilidad— permiten luego agregar funciones sin multiplicar las excepciones.
Partitech diseña, retoma y mantiene plataformas empresariales conectadas al sistema de información. La intervención puede abarcar la definición funcional, la arquitectura, la experiencia del usuario, el desarrollo, la seguridad, la validación y la operación del extranet a lo largo del tiempo.
Hablemos de su proyecto
Encajar o modernizar su extranet con Partitech. Contacte a Partitech.