Cómo armamos el portal de alta de clientes para un data center privado en Buenos Aires, con racks, fibra y turnos de acceso.
El proyecto arrancó con una situación bastante concreta: un data center privado en el corredor sur de Buenos Aires recibía entre ocho y doce altas nuevas por mes, y cada una se resolvía por correo, planillas sueltas y llamadas para confirmar detalles que ya estaban escritos en algún PDF. La tarea no era diseñar una web bonita. Era ordenar el ingreso de un cliente nuevo al edificio: qué rack ocupa, qué par de fibra óptica se le asigna, qué rango de IPs internas se reserva, qué ventana horaria tiene para entrar técnicos con equipamiento y quién firma el acta de entrega.
Antes de tocar pantallas revisamos tres meses de altas reales. Aparecieron patrones incómodos: dos clientes compartían la misma etiqueta de puerto en switches de agregación distintos, el formulario de acceso de visitantes no contemplaba turnos nocturnos y la documentación de fibra se actualizaba a mano en una planilla que nadie cerraba. Ese relevamiento definió el alcance del portal más que cualquier pedido formal.
El portal quedó dividido en cuatro pasos secuenciales, no en un formulario largo. El primero valida los datos fiscales y técnicos del cliente contra una tabla interna de racks disponibles. El segundo asigna recursos físicos: par de fibra, puerto de agregación, rango de direccionamiento y potencia reservada por U. El tercero genera el alta de accesos con reglas de horario y credenciales temporales para técnicos externos. El cuarto cierra con un acta digital firmada que queda versionada.
La decisión menos obvia fue no automatizar la asignación de fibra. El equipo de planta externa prefirió mantener una confirmación humana sobre el par óptico antes de bloquearlo, porque en instalaciones con fibra oscura contratada los tramos cambian más seguido de lo que un sistema puede reflejar sin auditoría. El portal propone, la persona confirma. Eso agregó un paso, pero bajó los errores de etiquetado a casi cero en los primeros cuatro meses.
El tiempo de alta pasó de un promedio de nueve días hábiles a tres, contando la firma del acta. Los reclamos por accesos denegados en portería cayeron porque las credenciales temporales ahora se emiten con la ventana horaria correcta desde el inicio. La planilla de fibra dejó de existir como documento paralelo: el portal es la fuente única y el equipo de planta la consulta desde el celular antes de subir a la sala.
Quedaron cosas afuera a propósito. No integramos facturación ni monitoreo de consumo energético por rack, porque el cliente ya tenía herramientas para eso y sumarlas habría estirado el proyecto sin resolver el problema original. Lo que sí quedó pendiente para una segunda etapa es el portal espejo para bajas y mudanzas de rack, que hoy sigue resolviéndose por correo.
Podés ver cómo encaramos otros trabajos similares en proyectos o escribirnos directo desde contacto si estás ordenando altas en tu propio data center.
Canales de soporte para el portal de onboarding
El portal de onboarding que implementamos para una empresa de servicios logísticos en Rosario concentra altas de usuario, carga de credenciales y validación de contratos en un solo flujo. Cuando algo falla a mitad de camino, el equipo de soporte necesita saber por dónde entró el pedido y qué tan urgente es antes de tocar el sistema. Por eso definimos tres vías de contacto con tiempos de respuesta distintos, y una regla simple: si el alta bloquea una operación en curso, se trata como incidente y no como consulta.
Es el canal que usamos para todo lo que necesita registro: errores de validación de documentos, altas rechazadas por datos incompletos o dudas sobre permisos por rol. Respondemos dentro de las 24 horas hábiles y dejamos el hilo abierto hasta cerrar el caso. Conviene adjuntar el ID de solicitud que aparece en la pantalla de confirmación.
Lo reservamos para bloqueos que impiden operar: sesiones que no cargan, credenciales que no se propagan a los sistemas internos o caídas del portal durante una ventana de alta programada. Atendemos de lunes a viernes de 9 a 18, hora de Buenos Aires. Fuera de ese horario, el buzón registra el pedido y se retoma a primera hora.
Los casos que dependen de un tercero, como la validación de identidad o la firma de un contrato, quedan en estado pendiente y se revisan cada 48 horas. Si el proveedor externo no responde en ese plazo, escalamos y avisamos al cliente por correo. No hace falta volver a escribir para preguntar: el ticket se actualiza solo.
Las dudas sobre el funcionamiento general del portal, los permisos por rol y los formatos de archivo aceptados están cubiertas en la sección de preguntas frecuentes. Antes de abrir un ticket, vale la pena revisar si el caso ya está documentado.
Ficha técnica del proyecto
Analista de infraestructura de red y responsable del seguimiento del Client Onboarding Portal
Laura coordina la capa de integración del portal desde el lado de infraestructura: define cómo se autentican los clientes nuevos contra el directorio corporativo, qué enlaces de fibra óptica B2B se reservan para el canal de alta disponibilidad y qué métricas de latencia se revisan antes de habilitar cada alta. Antes de este proyecto trabajó en migraciones de backbone en data centers privados del AMBA, así que suele insistir en validar la planta externa antes de tocar el equipamiento activo.
Para consultas sobre el portal, la documentación de integración o el estado de un alta en curso, responde por correo y por teléfono en horario laboral. Los temas de capacidad de almacenamiento y procesamiento de datos se derivan al equipo de hardware empresarial, que mantiene su propio registro de cambios.
El proyecto Client Onboarding Portal no salió de una sola cabeza. Lo armamos entre perfiles de redes, plataforma y soporte que ya venían trabajando con clientes corporativos que contratan fibra oscura y racks privados en Buenos Aires. Cada uno aportó una parte concreta: topología, permisos, trazabilidad y tiempos de respuesta.
Definió el flujo de alta de circuitos dentro del portal: qué datos pide el formulario, en qué orden y qué validaciones corren contra el inventario de fibra antes de habilitar un puerto en el rack del cliente.
Se ocupó de la capa de identidad y roles. Cada empresa que entra al portal ve solo sus enlaces, sus tickets y sus métricas de consumo, sin exponer información de otros clientes alojados en el mismo data center.
Conectó el portal con el sistema de facturación y con el monitoreo de switches. Cuando un enlace nuevo queda activo, el alta se refleja en ambos lados sin carga manual, algo que antes consumía varias horas por cliente.
Documentó los casos de uso reales que aparecieron durante las primeras semanas: altas parciales, cambios de dirección técnica y reclamos por latencia. Esa lista terminó definiendo qué avisos automáticos envía el portal.
Armó los tableros internos que muestran cuánto tarda cada etapa del onboarding, desde la solicitud hasta el enlace operativo. Con esos números ajustamos el proceso y detectamos dónde se frenaban los expedientes.
El portal de alta de clientes nació de un problema concreto: cada nuevo contrato de servidores dedicados o de fibra oscura en un data center privado se gestionaba por correo, con planillas sueltas y llamadas cruzadas entre el área comercial y el equipo de infraestructura. En un trimestre con doce altas simultáneas, dos racks quedaron asignados a la misma empresa y una VLAN se configuró con la nomenclatura del cliente anterior. Nada grave, pero suficiente para frenar la puesta en marcha varios días.
Antes de tocar el portal, el equipo de redes recibía la información en tres formatos distintos según quién hubiera cerrado la venta. El formulario ahora pide de entrada el rango de direccionamiento, la cantidad de puertos de fibra y el consumo eléctrico estimado por rack. Con esos tres datos, el aprovisionamiento deja de depender de una cadena de correos.
El portal consulta el inventario de racks libres antes de confirmar una asignación. Si el cliente pide una jaula completa en una sala con la capacidad de refrigeración al límite, el sistema marca la solicitud y deriva a un ingeniero. Esa validación evitó que se vendieran dos espacios que compartían el mismo circuito de energía redundante.
Una vez aprobada el alta, el portal genera una ficha de traspaso con los datos que operaciones necesita para el monitoreo: contacto técnico del cliente, ventana de mantenimiento acordada y criticidad del servicio. Antes esa información llegaba por WhatsApp y se perdía. Ahora queda registrada y se puede auditar qué cambió entre una alta y la siguiente.
La firma de contratos y la facturación siguen en el circuito administrativo habitual. El portal cubre desde la solicitud técnica hasta la entrega del servicio, no el proceso comercial completo. Tampoco gestiona cambios de configuración posteriores: para eso sigue existiendo un ticket formal. Preferimos no forzar todo dentro de la misma herramienta y dejar cada paso donde tiene sentido.
El tiempo promedio entre la firma y el servicio operativo bajó de once a cuatro días hábiles en altas estándar. Los errores de nomenclatura en VLAN desaparecieron porque el portal genera el nombre a partir del identificador del cliente. Y el equipo de redes dejó de mantener una planilla paralela que siempre quedaba desactualizada. No es un cambio espectacular, pero se nota en la operación diaria.