El formulario que evita empezar con los ojos vendados
Un cliente puede sonar listo por teléfono y todavía no saber quién tiene el dominio, dónde está el hosting, qué cuenta paga el email o quién recibe los códigos de verificación. Ahí es donde un proyecto sencillo se convierte en un viernes a las 4:40 p. m. con todo el mundo buscando “el login”.
Un formulario de onboarding IT no es burocracia. Es la forma más simple de pedir la información correcta antes de tocar DNS, email, hosting, Shopify, Odoo o cualquier otro ERP. Para un proveedor pequeño de tecnología, ese formulario protege tiempo, reputación y acceso.
Mapa rápido del onboarding
- El formulario que evita empezar con los ojos vendados
- Resumen para proveedores de IT ocupados
- Qué debe pedir un formulario de onboarding IT
- Cómo usarlo sin parecer complicado
- Errores que convierten el onboarding en otro problema
- Tu próxima versión del formulario
- Preguntas frecuentes
- Cierre, límites y referencias
Resumen para proveedores de IT ocupados
- Mejor para: técnicos independientes, micro-MSPs, diseñadores web técnicos y proveedores que manejan dominios, email, hosting, ecommerce o aplicaciones de negocio.
- Idea principal: no aceptes tocar sistemas críticos sin saber quién decide, quién paga, quién aprueba y quién puede recuperar acceso.
- Tiempo estimado: 20 a 40 minutos para que el cliente complete una primera versión, más 30 minutos de llamada para confirmar huecos.
- Resultado realista: menos interrupciones, menos “¿quién tiene eso?” y una ruta más clara si algo falla.
- Cuándo no usarlo: no reemplaza un contrato, un diagnóstico técnico o una auditoría de seguridad cuando el sistema ya está roto.
Qué debe pedir un formulario de onboarding IT
El formulario debe separar información operativa de información sensible. No tiene que pedir contraseñas. Sí debe identificar dónde vive cada sistema, quién lo controla y qué tan urgente es cada componente para el negocio.
Para una tienda online pequeña, por ejemplo, el formulario puede revelar que Shopify está a nombre del dueño, el dominio está en GoDaddy, el DNS está en Cloudflare, el email está en Google Workspace y la facturación la recibe una persona que no trabaja en tecnología. Esa mezcla no es mala, pero sin mapa se vuelve peligrosa.
Campos que no pueden faltar
- Datos del negocio: nombre legal, nombre comercial, teléfono principal, dirección postal y persona que aprueba cambios.
- Contacto técnico autorizado: quién puede decir “sí, hazlo” cuando hay que tocar DNS, hosting o email.
- Dominio: registrador, fecha aproximada de renovación, email dueño y método de recuperación.
- DNS: dónde se administran los registros, por ejemplo Cloudflare, GoDaddy, Raxan.net u otro proveedor.
- Hosting y página web: proveedor, tipo de plataforma, ambiente de producción y contacto de soporte.
- Email: proveedor, dominios conectados, cuentas críticas y quién administra usuarios.
- Tienda online: Shopify, WooCommerce u otra plataforma, más quién aprueba cambios de pago, envío o catálogo.
- Aplicaciones de negocio: Odoo o cualquier otro ERP, CRM, sistema de facturación, helpdesk y herramientas internas.
- Contactos de emergencia: dueño, gerente, contacto de facturación, contacto técnico y suplente.
Términos que conviene aclarar
- Dueño de cuenta: persona o empresa que tiene control legal y práctico de una plataforma.
- Administrador: usuario con permiso para cambiar configuración crítica.
- Contacto de recuperación: email o teléfono usado para restablecer acceso.
- Sistema crítico: servicio que afecta ventas, cobros, comunicación o entrega al cliente.
Escenario realista: el cambio “rápido” que no era rápido
Imagina que un cliente pide mover su página a otro hosting porque “eso es rápido”. Al revisar el formulario, descubres que el dominio vence en 12 días, el DNS lo maneja otra agencia, el email usa el mismo dominio y el contacto de recuperación es un empleado que ya no trabaja allí.
Sin onboarding, el proveedor puede romper correo, perder acceso o quedar atrapado entre dos terceros. Con onboarding, la conversación cambia: primero se confirma propiedad, luego se documenta DNS, después se programa la migración en una ventana razonable.
Cómo usarlo sin parecer complicado
El error común es mandar un formulario enorme como si fuera un examen. El cliente pequeño no siempre sabe qué es DNS, SPF, MX o MFA. Tu trabajo es pedir la información en lenguaje claro y convertir las respuestas en un mapa técnico.
Una buena regla: usa el formulario para recoger pistas, no para obligar al cliente a diagnosticar su propio sistema. Si contesta “no sé”, esa respuesta también vale. Te dice que hay que investigar antes de tocar.
Proceso simple en cinco pasos
- Envía el formulario después de la primera conversación. Así el cliente entiende por qué lo estás pidiendo.
- Marca campos como “imprescindible”, “útil” o “lo revisamos juntos”. Eso reduce ansiedad y evita respuestas inventadas.
- Pide capturas, facturas o nombres de proveedores, no contraseñas por WhatsApp. Para acceso, usa invitaciones, usuarios temporeros, acceso delegado o un gestor de contraseñas.
- Confirma quién aprueba cambios críticos. El contacto que “sabe de computadoras” no siempre es quien tiene autoridad.
- Cierra con una llamada de 30 minutos. Repasa huecos, riesgos y próximos pasos antes de tocar producción.
Guía rápida de decisión
- Si el cliente sabe dónde está todo, agenda el trabajo con una lista de cambios y responsables.
- Si el cliente no sabe quién controla el dominio, pausa el proyecto técnico y empieza por recuperación de propiedad.
- Si el cliente quiere tocar DNS de inmediato, pide una ventana de cambio, backup de registros actuales y aprobación escrita.
- Si el cliente se niega a documentar accesos, no aceptes responsabilidad por resultados que no puedes controlar.
Errores que convierten el onboarding en otro problema
Un formulario de onboarding mal hecho puede crear más confusión. Si pide demasiada información, el cliente no lo completa. Si pide contraseñas en texto plano, crea un riesgo innecesario. Si no distingue entre dueño, usuario y administrador, deja los mismos huecos de siempre.
El objetivo no es llenar una carpeta bonita. El objetivo es que cualquier persona autorizada pueda entender qué sistemas existen, quién decide y qué se debe revisar antes de hacer cambios.
Errores comunes y cómo corregirlos
- Pedir passwords en el formulario: pasa porque parece rápido → usa invitaciones, enlaces seguros, acceso delegado o gestor de contraseñas.
- Aceptar “mi primo tiene eso” como respuesta final: pasa por querer cerrar la venta rápido → pide nombre, rol, proveedor y ruta de recuperación.
- No preguntar por facturación: pasa porque parece administrativo → muchas pérdidas de dominio y hosting empiezan con una tarjeta vencida.
- No separar emergencia de proyecto normal: pasa cuando todo se maneja por chat → define qué cuenta como caída crítica y qué requiere agenda.
Opciones para recoger información sin frenar el proyecto
| Opción | Mejor para | Pros | Contras |
|---|---|---|---|
| Formulario básico | Primer contacto y proyectos pequeños | Rápido, fácil de repetir, deja rastro escrito | Puede quedarse corto si hay muchos sistemas |
| Llamada de descubrimiento | Clientes que no conocen sus accesos | Permite explicar términos y detectar riesgos | Consume más tiempo antes de cotizar |
| Auditoría inicial pagada | Ambientes con dominio, email, tienda y ERP | Reduce sorpresas y crea un mapa técnico real | Algunos clientes esperan una cotización gratis |
| Sesión guiada por pantalla | Recuperar información sin pedir contraseñas | Más seguro que pedir credenciales por chat | Requiere coordinar horario con el dueño de cuenta |
Tu próxima versión del formulario
Empieza pequeño. Un formulario de una página puede ser mejor que un documento perfecto que nadie completa. Para la primera versión, enfócate en las áreas donde un error cuesta más: dominio, DNS, email, hosting, tienda online, ERP y contactos autorizados.
Luego añade campos según el tipo de cliente. Un restaurante con delivery puede necesitar preguntas sobre POS y pedidos online. Una oficina profesional puede necesitar más detalle sobre email, archivos compartidos y cuentas de facturación. Una tienda puede requerir Shopify, pasarela de pago, envíos y catálogo.
Mini SOP para usarlo cada vez
- Crear una copia del formulario por cliente o proyecto.
- Guardar respuestas en una carpeta interna con permisos limitados.
- Confirmar dueño, administrador y contacto de recuperación para cada sistema crítico.
- Registrar qué información falta antes de enviar una propuesta final.
- Revisar el formulario otra vez antes de tocar DNS, email, hosting o tienda online.
Checklist mínimo para copiar y adaptar
- Nombre del negocio y persona que aprueba cambios.
- Dominio principal y proveedor donde se compró.
- Proveedor de DNS y copia de registros actuales si aplica.
- Hosting, plataforma web y contacto de soporte.
- Proveedor de email y cuentas críticas.
- Shopify, WooCommerce, Odoo o cualquier otro sistema de negocio.
- Contacto de facturación y método de renovación.
- Contacto de emergencia y suplente.
- Método seguro para acceso, sin contraseñas por chat.
- Lista de sistemas que no se deben tocar sin autorización escrita.
Lo importante antes de tocar sistemas del cliente
Un formulario de onboarding IT no elimina todos los riesgos, pero obliga a nombrarlos antes de que exploten. También le enseña al cliente que tu trabajo no es improvisar sobre cuentas ajenas, sino proteger continuidad, propiedad y cambios bien hechos.
Para un proveedor pequeño, ese detalle cambia la relación. El cliente deja de verte como “la persona que arregla cosas” y empieza a verte como alguien que trae orden. Ese orden es lo que permite cobrar mejor, responder con más calma y evitar trabajos que nacen mal desde el primer día.
Preguntas frecuentes
Q1. ¿Un formulario de onboarding IT debe pedir contraseñas?
A1. No debería pedir contraseñas en texto plano. Es mejor usar acceso delegado, invitaciones de usuario, cuentas temporeras, sesiones guiadas por pantalla o un gestor de contraseñas con permisos controlados. El formulario debe identificar dónde está el acceso y quién lo autoriza, no convertirse en una lista de secretos.
Q2. ¿Qué hago si el cliente no sabe quién controla su dominio?
A2. Trata eso como un riesgo del proyecto, no como un detalle menor. Antes de mover web, email o DNS, pide facturas, emails de renovación, capturas del panel y cualquier pista del registrador. Si la propiedad no está clara, el primer trabajo debe ser documentar y recuperar control antes de hacer cambios.
Q3. ¿Cuánto debe tardar el onboarding de un cliente pequeño?
A3. Para un cliente simple, puede tomar entre 20 y 40 minutos completar el formulario y otros 30 minutos revisarlo contigo. Si hay varios dominios, email, ecommerce, ERP y proveedores externos, conviene tratarlo como descubrimiento formal. El tiempo invertido al inicio suele evitar horas perdidas durante una emergencia.
By: Marcus Irizarry
Why trust this: Guía editorial basada en operaciones de IT para pequeños proveedores, documentación de proyectos y prácticas públicas de seguridad de cuentas.
Last updated: 2026-06-14
Disclosure: No hubo colocación pagada que influyera en este post.
Descargo de responsabilidad
Este contenido es orientación general para proveedores de servicios de tecnología. No sustituye asesoría legal, contractual, contable o de ciberseguridad profesional. Ajusta tus formularios, permisos y procesos según el tipo de cliente, los contratos vigentes y los requisitos de cada plataforma.