Cómo ordenamos el alta de clientes corporativos en un portal único, con trazabilidad y control de accesos desde el primer día.
Una empresa de servicios industriales con operaciones en Córdoba y Buenos Aires nos planteó un problema concreto: cada nuevo cliente corporativo tardaba entre tres y cinco semanas en quedar operativo. El alta dependía de planillas compartidas por correo, carpetas en un servidor de archivos y aprobaciones que se perdían entre áreas. Comercial cerraba el contrato, pero Legales, Finanzas y Operaciones recién se enteraban días después. Nadie tenía una vista clara de en qué etapa estaba cada cliente ni quién tenía la pelota.
El pedido no era "digitalizar todo", sino algo más acotado: un portal donde el alta de un cliente nuevo siguiera un flujo definido, con estados visibles, responsables asignados y registro de cada paso. Trabajamos sobre la operación real, no sobre un ideal. Relevamos primero qué documentos se pedían siempre, cuáles variaban según el tipo de contrato y en qué momentos se generaban cuellos de botella.
El portal se armó sobre una base de datos relacional con roles diferenciados: el ejecutivo comercial carga los datos iniciales, Legales valida documentación, Finanzas confirma condiciones de facturación y Operaciones habilita el servicio. Cada transición de estado queda registrada con usuario, fecha y comentario. Los documentos se almacenan cifrados y con control de acceso por rol, algo que en el esquema anterior era imposible de garantizar.
El resultado más visible fue el tiempo de alta: bajó de semanas a pocos días hábiles en los casos estándar. Pero el cambio de fondo fue otro. Cuando algo se detiene, ahora se sabe dónde y por qué. Eso permitió ajustar el proceso con datos en la mano en lugar de discutir percepciones. También redujimos la exposición de información sensible, que antes circulaba en adjuntos sin control. El siguiente paso fue conectar el portal con el sistema de facturación para evitar doble carga, algo que quedó documentado como fase dos.
Ver el siguiente caso de la serie o hablar con el equipo sobre un flujo de alta similar.
Detrás del portal hay un equipo que trabaja con empresas privadas argentinas en integración de software corporativo, bases de datos y controles de acceso. La autoría de este proyecto está a cargo de perfiles con experiencia en despliegues B2B y en la coordinación entre áreas de sistemas, legales y comercial.
Diego Sanchez Lopez lidera la definición técnica del portal: modelo de datos de clientes, validación de identidad documental y trazabilidad de cada alta. Trabaja junto a Valeria Martinez Silva, responsable de la capa de seguridad y de los criterios de retención de información sensible. Adrian Gomez Lopez coordina la integración con los sistemas internos de facturación y soporte. Para consultas puntuales sobre el alcance, los tiempos de implementación o la documentación del proyecto, el canal directo es el correo institucional o el teléfono de la oficina en Córdoba.
El portal de alta de clientes no lo armó un equipo genérico de desarrollo. Detrás hay perfiles que ya habían trabajado con integraciones bancarias, validación de identidad y migración de datos maestros en empresas privadas de Argentina. Eso explica varias decisiones del proyecto: por qué ciertos formularios se dividieron en etapas, por qué la trazabilidad quedó en una capa separada y por qué el módulo de documentos exige firma antes de habilitar el siguiente paso.
La rotación del equipo fue baja durante los ocho meses de implementación. Eso permitió mantener criterio sobre los mismos flujos en lugar de rehacer acuerdos cada trimestre.
Definió el modelo de datos del portal y la separación entre el registro inicial y el expediente del cliente. Viene de proyectos de core bancario, así que impuso reglas de auditoría desde el primer sprint en lugar de agregarlas al final.
Tradujo el proceso comercial de alta, que antes vivía en planillas y correos, a un flujo con estados claros. Su trabajo se notó en la reducción de consultas internas sobre "en qué etapa está cada cliente".
Conectó el portal con los sistemas de facturación y con el repositorio documental. La parte difícil no fue la API, sino acordar qué hacer cuando una validación falla a mitad del proceso sin perder lo ya cargado.
Revisó el manejo de credenciales, los permisos por rol y el registro de accesos a documentos sensibles. Su criterio fue que cada acción del cliente quede atribuible a una persona, no solo a una sesión.
Acompañó la puesta en marcha con el equipo de atención y armó el material de soporte interno. Buena parte de los ajustes posteriores al lanzamiento salieron de sus observaciones sobre casos reales de alta.
Si tu empresa maneja altas de clientes con documentación, validaciones y varios responsables, vale la pena revisar el caso completo antes de definir el alcance.
Hablar con el equipo del proyectoCanales de soporte para el portal de onboarding
El portal de Client Onboarding Portal no termina cuando se publica la primera versión. Las primeras semanas concentran la mayor cantidad de dudas: accesos que no llegan, documentos que se cargan dos veces, validaciones que rechazan un CUIT por un espacio de más. Por eso definimos canales separados según la urgencia y el tipo de problema, con tiempos de respuesta distintos para cada uno. No todos los casos necesitan una llamada, y no todos pueden esperar un correo.
Cuando el portal queda inaccesible o un lote de altas falla a mitad de proceso, el equipo de guardia recibe la alerta por el canal directo habilitado en el contrato. Se confirma recepción, se aísla el componente afectado y se informa un estado parcial antes de cerrar. Este canal está reservado para bloqueos reales de operación, no para consultas de configuración.
Dudas sobre reglas de validación, permisos por rol o flujos de aprobación se canalizan por correo a la mesa de soporte. Respondemos dentro del día hábil siguiente con una explicación y, si hace falta, un ajuste de configuración. Cada caso queda registrado con su número para que el equipo del cliente pueda retomarlo sin repetir contexto.
Los pedidos que no son urgentes, como agregar un campo al formulario o modificar una notificación, se agrupan y se despliegan en la ventana de mantenimiento acordada. Esto evita interrupciones en horario productivo y permite probar los cambios antes de que lleguen a los usuarios finales. El cliente recibe el detalle de lo incluido en cada entrega.
Antes de abrir un ticket conviene revisar la sección de preguntas frecuentes, donde están las respuestas a los casos más repetidos: recuperación de contraseña, carga masiva de contactos y estados de solicitud. Muchas dudas se resuelven ahí sin esperar respuesta. Si el caso no aparece, el formulario de contacto deriva el mensaje al equipo correspondiente.
Para consultas que no sean una urgencia operativa, escribí a info@savyata.com o llamá al +54 9 11 5590 5593. También podés revisar las preguntas frecuentes o los términos del servicio antes de iniciar un reclamo formal.