Portal de clientes B2B: datos, accesos y primer alcance

Un portal de clientes B2B es un espacio privado donde una empresa cliente consulta información o inicia gestiones sobre su relación con tu negocio. Elegí una tarea recurrente: seguir una solicitud de servicio, descargar un documento habilitado o aportar información que falta. Describí qué necesita completar la persona sin pedirle a tu equipo que busque cada dato.

Un CRM organiza el trabajo interno; el portal expone al cliente sólo el recorrido y la información que le corresponden. No hace falta replicar el CRM, mostrar sus notas internas ni abrir todos sus módulos. Si lo que necesitás es recibir y validar legajos de empresas que te abastecen, la decisión es otra: un portal de documentación de proveedores.

Antes de encargar pantallas, registrá qué consulta se repite, en qué sistema está la respuesta y quién puede resolverla hoy. Si la información todavía depende de una conversación interna o de una regla no definida, el portal no puede convertirla por sí solo en una respuesta confiable.

Hay funciones nativas que pueden cubrir un primer alcance. HubSpot documenta un portal de soporte para gestionar tickets y aclara que sólo aparecen tickets, no conversaciones sin ticket asociado. La documentación vigente distingue esta experiencia de la anterior. No lo des por equivalente a un portal de facturas o de toda la operación.

Zoho CRM documenta portales que dan acceso a módulos y registros relacionados según permisos. Eso ofrece otra base para evaluar, pero no prueba que los datos de un ERP externo ya estén conectados. Son capacidades declaradas por los proveedores, consultadas el 4 de noviembre de 2026; no productos probados por Duotach ni una recomendación de licencia.

Pedí que cada alternativa recorra la misma tarea y sus excepciones. Una función que ya existe puede requerir configuración; un dato que vive en otro sistema puede requerir integración; una regla que ninguno cubre puede justificar desarrollo. Separar esos trabajos evita presupuestar una aplicación completa para resolver un acceso o un formulario.

Armá una ficha por información que verá el cliente. Indicá sistema de origen, responsable, relación con la cuenta, frecuencia de actualización y comportamiento cuando la fuente no responde. No prometas tiempo real si la conexión entrega un corte diario. Mostrar la última actualización permite interpretar el dato, pero no vuelve vigente una copia que ya no sirve para decidir.

Definí también cómo se traducen los estados internos. Una solicitud recibida por el portal no equivale a una orden aceptada por operaciones; una orden aceptada no equivale a trabajo terminado. La interfaz debe decir cuál de esos hechos ocurrió y qué paso sigue. Conservá una referencia que permita a soporte encontrar el registro interno sin exponer notas privadas.

Esta matriz es una propuesta de alcance para adaptar con operaciones e IT. No describe un producto instalado ni acredita una integración existente.

Definí quién invita, qué relación comercial habilita el acceso, qué puede consultar o solicitar cada perfil y quién lo revoca. Dos personas de una misma empresa pueden necesitar alcances diferentes. Acordá si una ve sólo sus solicitudes, todas las de su cuenta o determinadas áreas. No supongas que coincidir en el dominio del correo define esa relación.

La guía de autorización de OWASP diferencia identidad de autorización y recomienda privilegio mínimo, denegación por defecto y comprobación de permisos en cada solicitud. También exige proteger recursos como archivos y no confiar el control a la pantalla. Fuente consultada el 4 de noviembre de 2026; citarla no certifica la seguridad de un portal.

Convertí los permisos acordados en pruebas de consulta, descarga y modificación. Incluí una persona de otra cuenta y una persona cuyo acceso se retiró. En un entorno de prueba autorizado, comprobar sólo que desaparece un botón no alcanza: verificá también el acceso directo al recurso. No uses datos de clientes reales para una demostración pública.

Considerá dos cuentas ficticias, Norte y Sur. Norte tiene la solicitud SR-47 y su documento de entrega; Sur tiene SR-82. Una persona de Norte puede ver SR-47 y solicitar una corrección, pero no confirmar que el trabajo está terminado. La validación final pertenece a operaciones. Estos datos y reglas son inventados para ilustrar una prueba, no un caso ni un resultado de Duotach.

Primero, la persona consulta SR-47 y ve el estado confirmado por la fuente, junto con su actualización. Después solicita una corrección: el portal registra el pedido y su referencia, pero conserva el estado del trabajo hasta que operaciones lo resuelve. Cerrá el recorrido comprobando la decisión interna y la actualización visible; un formulario enviado no demuestra resolución.

Luego probá el mismo recorrido sin conexión al origen. Acordá si el portal permite consultar una copia identificada como anterior, registra la solicitud como pendiente o detiene la operación. Nunca debe presentar un estado inventado como confirmado. Finalmente, verificá que Norte no pueda consultar ni descargar información de Sur, aunque conozca su referencia.

Antes del desarrollo, acordá el resultado esperado y la evidencia para cada situación. La siguiente tabla continúa el ejemplo ficticio; no es un test ya ejecutado sobre un producto. Probala sobre la versión candidata a entrega, con registros autorizados para ensayo.

Incluí el alta y la recuperación de acceso, además de la tarea principal. Un portal técnicamente disponible puede seguir derivando todo al correo si el cliente no logra entrar, no reconoce el estado o no sabe a quién pedir ayuda. Registrá esas dificultades durante una prueba con personas habilitadas, sin asumir que una pantalla intuitiva para el equipo técnico lo será para quien la usa.

Pedí que identifique la tarea incluida, las cuentas y perfiles alcanzados, los sistemas que consulta, las acciones que puede iniciar y qué queda fuera. Separá configuración, integración, desarrollo y preparación de datos. La disponibilidad de una API no demuestra que exista el permiso para leer los documentos o realizar la acción necesaria.

Incluí responsables de las invitaciones, de la información incorrecta, de las fallas de sincronización y del soporte al usuario. Infraestructura, almacenamiento, licencias y mantenimiento necesitan condiciones propias. El número de usuarios no alcanza para comparar presupuestos si uno incluye conexión al sistema operativo y el otro sólo carga manual.

Completá el alcance con la entrega de código, accesos y documentación y el mantenimiento posterior. El portal no debería depender de que una persona del proveedor actualice cada documento indefinidamente, salvo que ese trabajo esté expresamente contratado.

Antes de habilitar el primer circuito, registrá el volumen de esa tarea, su canal actual y cómo se reconoce una resolución correcta. Después observá tareas completadas, fallos de acceso, información desactualizada y gestiones que vuelven al equipo. Compará períodos equivalentes y la misma clase de solicitud; más inicios de sesión no demuestran menos trabajo administrativo.

Para una descarga, comprobá que se entregó el documento correcto a la cuenta habilitada. Para una corrección, comprobá que operaciones la resolvió y que el cliente pudo conocer la respuesta. Separá apertura, solicitud recibida y tarea resuelta. Esta guía no promete un porcentaje de reducción de consultas, ahorro o aumento de ventas.

Duotach desarrolla software a medida para empresas. Podés consultar por un portal integrado describiendo qué necesita resolver el cliente y dónde está la información. El relevamiento de tus sistemas, las pruebas específicas y la implementación forman parte del trabajo pago que se acuerde; no se ofrece una auditoría gratuita ni disponibilidad inmediata.