Alta de usuarios B2B
El botón de «crear cuenta» no crea ninguna cuenta
En B2C, el registro es un trámite: email, contraseña, dentro. La alta de usuarios B2B es un proceso de negocio con aprobadores, plazos, jerarquía y un ERP que tiene la última palabra sobre si esa persona existe. Y casi siempre se especifica en una línea del briefing.
Lo que vas a leer: por qué el usuario web no es el cliente, los ocho pasos reales de una alta de usuarios B2B, cómo evitar que el cuello de botella sea el comercial, los seis roles que hacen falta y por qué el correo de activación decide más que el flujo de aprobación.
Respuesta rápida
- El cliente vive en el ERP. El usuario web vive en el eCommerce. La alta de usuarios B2B no funciona hasta que separas esas dos cosas.
- El alta real tiene ocho pasos y tres sistemas: el solicitante, el ERP, el comercial y el equipo interno.
- El cuello de botella no es técnico: es un comercial que no responde emails. Se resuelve con un botón dentro del correo, no con más correos.
- Un alta no da acceso. Da un rol. Sin una matriz de permisos explicada en pantalla, todo el mundo acaba siendo «Administrador».
- Puedes tener el mejor flujo de aprobación del sector. Si el correo de activación cae en spam, tu tasa de alta la decide un filtro antispam.
01
El usuario web no es el cliente. Y esa distinción lo ordena todo
Vengo de cerrar la auditoría de un distribuidor industrial con 30.000 clientes en su ERP y más de 200 usuarios administradores en la web. La alta de usuarios B2B ocupó más tiempo de análisis que el checkout. No es casualidad.
El cliente vive en el ERP. Tiene código, comercial asignado, condiciones negociadas, riesgo de crédito y una relación comercial que a veces lleva veinte años funcionando. El usuario web vive en el eCommerce. Es una persona con credenciales, un rol y unos permisos. No son lo mismo. Ni siquiera están en el mismo sistema.
Una empresa cliente puede tener quince usuarios web: el jefe de compras, dos administrativos, el contable, el técnico que solo entra a descargar despieces y el responsable de obra que prepara carritos por proyecto. Todos cuelgan del mismo código de cliente. Ninguno de ellos existe en el ERP como usuario.
El ERP gobierna con quién haces negocio. El eCommerce gobierna quién entra por la puerta.
Esta frontera es la que decide dónde vive cada dato, y la que evita el error clásico de cualquier integración ERP-eCommerce: intentar que el ERP gestione contraseñas.
02
El flujo real de una alta de usuarios B2B, paso a paso
El alta B2B no es un formulario. Es una secuencia con cuatro actores: el solicitante, el ERP, el comercial y el equipo interno.
1. El interesado se registra aportando sus datos y el código de cliente de su empresa.
2. El sistema valida ese código contra el ERP de forma síncrona. No basta con que el número tenga el formato correcto: tiene que existir, estar activo y tener un comercial asignado.
3. Se genera una solicitud pendiente en el back office interno. La cuenta ya está creada, pero inerte.
4. Se notifica al comercial responsable de esa cuenta. Es él quien sabe si esa persona debe entrar.
5. El comercial aprueba o deniega.
6. Si nadie responde en un plazo, la solicitud escala al equipo interno, que actúa como respaldo.
7. Aprobada la solicitud, el usuario recibe un enlace con token para establecer su contraseña.
8. La cuenta queda operativa.
Ocho pasos. Tres sistemas. Dos personas ajenas al solicitante. Compáralo con el «email + contraseña + dentro» del B2C y entenderás por qué esto nunca sale de serie en ninguna plataforma.
Cuatro palabras en el briefing —«formulario de registro»— para el flujo más enredado del proyecto.
03
El comercial no responde emails. Dale un botón
Aquí está el cuello de botella real de la alta de usuarios B2B, y no es técnico. El circuito habitual es este: el comercial recibe un correo pidiéndole que valide un alta, y responde por email a marketing con un «sí» o un «no». Marketing lee, entra al back office y ejecuta la decisión.
Tres personas y dos días para un clic. Mientras tanto, un cliente que quería comprar está mirando una pantalla de «cuenta pendiente de activación». Que es exactamente el momento de máxima intención de compra que acabas de desperdiciar.
La corrección es simple y cambia el flujo entero: enlace seguro con token dentro del propio email del comercial. Dos botones, aprobar y denegar, con los datos del solicitante a la vista. La decisión se ejecuta desde el correo, sin entrar a ningún sistema. Y un temporizador detrás: si el comercial no actúa en el plazo definido, la solicitud escala automáticamente al equipo interno.
Que el escalado sea automático o manual es una decisión de negocio, no de arquitectura. Pero tiene que existir. Sin él, el alta depende de que un comercial abra el correo un martes por la tarde.
Todo flujo de aprobación sin escalado por inactividad acaba siendo un flujo de aprobación sin aprobación.
04
Un alta no da acceso. Da un rol
Segundo error frecuente en cualquier proyecto de alta de usuarios B2B: tratar el acceso como un interruptor binario. En B2B el acceso es granular, porque dentro de un mismo cliente hay funciones muy distintas. En el caso que analizamos convivían seis perfiles.
| Rol | Qué puede hacer |
|---|---|
| Administrador | Sin restricciones sobre la cuenta de su empresa |
| Compras | Crea y consulta sus pedidos, gestiona direcciones y carritos guardados |
| Espectador | Consulta, sin capacidad de compra |
| Contable | Acceso a facturas y recibos. No compra, no negocia |
| Documentación | Fichas técnicas, manuales, disponibilidad. Nada económico |
| Listas de difusión | Solo recibe comunicaciones. Ni siquiera navega |
Fíjate en el perfil «Documentación». Es un técnico que necesita despieces y certificados, y al que no quieres enseñar ni un precio. Ese perfil no existe en ningún eCommerce del mundo salvo que lo construyas.
Y añade un detalle que parece cosmético y no lo es: un cuadro explicativo de permisos en la propia interfaz. Si el administrador del cliente tiene que adivinar qué implica cada rol, asignará «Administrador» a todo el mundo. Lo he visto muchas veces.
Un modelo de permisos que no se explica en pantalla se degrada solo.
05
La delegación: tu cliente gestiona a su propia gente
Esta es la pieza que separa un portal B2B serio de un catálogo con login. El administrador del cliente da de alta, edita y elimina a los usuarios de su propia empresa. Les asigna roles. No pasa por ti.
Con las consecuencias que eso tiene, algo que también aparece al segmentar cuentas de cliente: un cliente puede tener varios administradores, y un administrador puede eliminar a otro. Hay que decidir conscientemente si eso está permitido, porque en algún momento dos socios enfadados lo van a probar.
Multiplica por más de doscientos administradores y entenderás la escala. Cada uno gestionando su parcela de usuarios, con sus altas, sus bajas y sus cuentas fantasma de gente que ya no trabaja allí.
La delegación no es una funcionalidad. Es la única forma de que esto no colapse en tu mesa de soporte.
06
Y aun así, soporte va a intervenir
Porque en la alta de usuarios B2B el alta perfecta no existe. El back office interno necesita, como mínimo, cuatro funciones. Ninguna de las cuatro viene de serie. Las cuatro se usan a diario.
Desbloqueo de usuarios
El caso más frecuente, y casi siempre por la misma causa: el correo de activación.
Reset con token único
Nunca contraseñas temporales asignadas a mano. Eso es una brecha de seguridad con formato de favor.
Cambio de email del administrador
Cuando la persona responsable deja la empresa. Si no puedes hacerlo, has perdido el control de esa cuenta.
Suplantación de identidad
Que tu equipo entre al área privada en el contexto del cliente. Sin esto, cada incidencia se resuelve a ciegas por teléfono.
El reset con token único no es una preferencia de diseño: es la práctica recomendada por el OWASP Forgot Password Cheat Sheet, que exige que el enlace sea de un solo uso y caduque, y que no se toque la cuenta hasta que ese token se valide.
07
El eslabón que nadie audita: el email
Todo el circuito que acabo de describir termina en un correo electrónico. La activación de cuenta y la recuperación de contraseña son emails. Si ese email no llega, el proceso entero no existe.
En el caso analizado, los correos de activación caían sistemáticamente en spam en determinados dominios de un mercado concreto. Resultado: usuarios legítimos, aprobados por su comercial, incapaces de entrar. Y un equipo interno desbloqueando cuentas a mano, uno por uno, cada semana.
Puedes tener el mejor flujo de aprobación del sector. Si el correo de activación acaba en spam, tu tasa de alta la decide un filtro antispam.
La entregabilidad no es un asunto de IT. Es la puerta de entrada de tus clientes a tu canal digital, y merece la misma atención que el checkout: dominio de envío dedicado, autenticación correcta —el tipo de exigencias que recogen las directrices de remitente de Gmail—, monitorización de rebotes y una revisión seria de qué correos salen desde el ERP y cuáles desde el eCommerce.
08
Nueve desarrollos que no vienen de serie
Repaso rápido de lo que hay que construir a medida en cualquier proyecto de alta de usuarios B2B, porque la alta de usuarios B2B no es un formulario de tres campos: validación síncrona del código de cliente contra el ERP, estado «pendiente de aprobación», enrutado de la solicitud al comercial correcto, aprobación por token desde el email, escalado por inactividad, seis roles con matriz de permisos propia, CRUD delegado de usuarios en el área privada, suplantación de identidad desde el back office y exclusión de registros por país.
Nueve desarrollos. Ninguno de ellos es «el módulo de registro».
Por eso la elección de plataforma en B2B no se juega en lo que trae de serie, sino en lo limpio que sea el mecanismo para construir lo que no trae. Si el sistema de eventos y extensiones es sólido, esto se implementa en semanas. Si no lo es, acabas parcheando el núcleo y rezando para no actualizar nunca.
El alta de usuario no es la puerta del eCommerce. Es el primer proceso de negocio que ese eCommerce ejecuta.
09
El registro es tu primera conversación operativa
Cuando alguien pide acceso a tu portal B2B, no está creando una cuenta. Está pidiendo entrar en tu operativa.
Y tu respuesta a esa petición —lo rápido que llega, quién decide, qué ve al entrar— es la primera prueba real de que tu canal digital funciona como un sistema y no como un folleto con carrito. Especificar eso en una línea del briefing es empezar el proyecto con una deuda.
Diséñalo como lo que es: no la puerta del eCommerce, sino el primer proceso de negocio que ese eCommerce ejecuta.
Preguntas frecuentes
¿Qué es la alta de usuarios B2B y en qué se diferencia del registro B2C?
En B2C el registro es email, contraseña y dentro. En B2B es un proceso de negocio con ocho pasos y tres sistemas: el solicitante se registra con el código de cliente, ese código se valida contra el ERP, se notifica al comercial responsable, el comercial aprueba o deniega, y solo entonces la cuenta queda operativa. No hay alta de usuarios B2B sin ese circuito de aprobación.
¿Por qué en la alta de usuarios B2B el usuario web no es lo mismo que el cliente del ERP?
Porque son dos sistemas distintos con propósitos distintos. El ERP gobierna con quién haces negocio: código de cliente, comercial asignado, condiciones y riesgo de crédito. El eCommerce gobierna quién entra por la puerta: credenciales, rol y permisos. Un mismo cliente puede tener quince usuarios web —compras, contabilidad, un técnico de despieces— sin que ninguno exista como usuario en el ERP.
¿Cómo se evita que el comercial sea el cuello de botella de la alta de usuarios B2B?
Sacando la decisión del correo tradicional. Un enlace seguro con token dentro del propio email, con dos botones —aprobar y denegar— y los datos del solicitante a la vista, permite decidir en un clic sin entrar a ningún sistema. Y un temporizador con escalado automático al equipo interno evita que el alta dependa de que un comercial concreto abra el correo un día concreto.
¿Qué roles necesita un portal B2B además de comprador y administrador?
En una alta de usuarios B2B bien diseñada hacen falta como mínimo seis: administrador sin restricciones, compras (crea y consulta pedidos), espectador (solo consulta), contable (facturas, sin datos comerciales), documentación (fichas técnicas y manuales, sin precios) y listas de difusión (solo recibe comunicaciones). Ese último grupo —perfiles técnicos o administrativos que no deben ver precios— es el que casi ningún eCommerce trae de serie, y es el mismo principio que exige un buen catálogo técnico por roles.
¿Qué es la delegación de usuarios y por qué es imprescindible?
Es la pieza de la alta de usuarios B2B que más se olvida: que el administrador de cada cliente dé de alta, edite y elimine a los usuarios de su propia empresa sin pasar por tu equipo. Con más de doscientos administradores en cartera, es la única forma de que las altas y las bajas no colapsen tu mesa de soporte. Exige decidir conscientemente si un administrador puede eliminar a otro administrador de su misma cuenta.
¿Qué pasa si el correo de activación cae en spam?
El proceso entero deja de existir para ese usuario, por perfecto que sea el flujo de aprobación detrás. Es un problema de entregabilidad, no de UX: dominio de envío dedicado, autenticación correcta y monitorización de rebotes merecen la misma atención que el checkout. Sin eso, tu tasa de alta la decide un filtro antispam y no tu diseño.
Para terminar
El alta de usuario no es la puerta del eCommerce. Es el primer proceso de negocio que ejecuta.
La alta de usuarios B2B se diseña con la misma seriedad que el checkout, o se paga con soporte desbordado durante años. No es un formulario: es el primer proceso operativo que tu cliente vive contigo.
Del dato al pedido. Sin fricciones.
