¿El rediseño de tu sitio empezó con cinco páginas y ahora alguien está pidiendo una tienda, un área privada y tres idiomas? Ahí puede haber un cambio de alcance. El problema aparece cuando el equipo lo descubre después de haber trabajado varias semanas, con fechas comprometidas y expectativas distintas.
Una diferencia de alcance no tiene por qué convertirse en una pelea. Se vuelve manejable cuando el proyecto tiene una base escrita: objetivos, páginas, funcionalidades, insumos, responsables, aprobaciones y cronograma. Sin esa base, cada conversación parece una interpretación contra otra.
Gulupa Digital trabaja desde Medellín con WordPress y Elementor Pro, y ha atendido a más de 500 empresas durante 10 años. Esa experiencia no convierte cada solicitud en un cobro adicional. Sirve para separar una corrección razonable de una nueva necesidad que cambia el trabajo comprometido.
Cómo se identifica un cambio de alcance real
Un cambio de alcance real aparece cuando la solicitud modifica un entregable, una funcionalidad, una cantidad o una condición que no estaba incluida en la cotización aprobada. La comparación debe hacerse contra el documento vigente, no contra una conversación aislada ni contra una idea que alguien recuerda vagamente. Cambiar el texto de un botón puede ser una corrección; añadir un sistema de reservas con disponibilidad, pagos y notificaciones probablemente exige otra evaluación. También puede cambiar el alcance una nueva integración, una página adicional, un idioma, una migración de contenido no prevista o una variación profunda de la arquitectura. La etiqueta no depende de que el pedido parezca pequeño. Depende de su efecto sobre horas, dependencias, pruebas, responsables y fecha de entrega. Si el documento no define el límite, la pregunta correcta es contractual: ¿cómo se clasifican y aprueban las solicitudes que aparecen durante el rediseño?
La señal más clara es que la petición obliga a rehacer una parte ya aprobada o agrega trabajo que necesita análisis, configuración, pruebas o coordinación con terceros. Una funcionalidad puede ocupar poco espacio visual y aun así alterar el proyecto por dentro.
Escenario ilustrativo: una empresa contrata un sitio corporativo con páginas informativas y formulario de contacto. Durante el diseño pide que cada vendedor tenga un panel para consultar oportunidades. El panel no es un ajuste de estilo. Implica usuarios, permisos, datos, seguridad y posiblemente una integración. La solicitud merece una revisión de alcance.
Otra señal es el cambio de objetivo. Si el proyecto se aprobó para presentar servicios y luego se pide vender productos en línea, la arquitectura deja de responder al mismo problema. Entrarían catálogo, carrito, checkout, pagos, correos y analítica de ventas. La conversación ya no consiste en escoger otro color.
También hay cambios que nacen de una omisión. Si una funcionalidad estaba claramente prometida y fue olvidada en la ejecución, no debería tratarse como trabajo adicional. Por eso conviene revisar la cotización, el alcance funcional, los entregables de diseño y las aprobaciones antes de decidir.
Una matriz sencilla ayuda a evitar discusiones:
- Solicitud: qué se está pidiendo exactamente.
- Documento de referencia: dónde aparece o dónde se evidencia que no aparece.
- Impact: diseño, desarrollo, contenido, pruebas, terceros o cronograma.
- Decisión: incluido, corrección, pendiente de cotizar o descartado.
Si tu proyecto ya acumula solicitudes dispersas, puedes comparar esa matriz con el alcance de diseño web profesional de Gulupa Digital. El objetivo es ordenar la conversación, no usar una página de servicio como sustituto del contrato.
Cómo se cotiza lo adicional sin perder control
Una solicitud adicional debería convertirse en una decisión visible antes de ejecutarse. La cotización no necesita ser un documento interminable, pero sí debe explicar qué se agrega, qué queda por fuera, cuánto cambia la inversión si aplica y qué efecto tiene sobre la fecha. Sin esa claridad, el cliente cree que pidió una cosa y el equipo termina entregando otra.
El primer paso es describir el resultado esperado. “Agregar membresías” es demasiado amplio. “Permitir registro, inicio de sesión, recuperación de contraseña y acceso a tres tipos de contenido protegido” permite estimar mejor. También hay que aclarar si el cliente entregará textos, imágenes, reglas de acceso, datos de usuarios o credenciales de terceros.
El segundo paso es separar las capas del cambio. Una nueva página puede afectar contenido y diseño, pero una nueva calculadora puede afectar investigación, interfaz, lógica, validación y medición. La propuesta adicional debe mostrar esas dependencias para que el decisor entienda qué está comprando.
Escenario ilustrativo: una clínica solicita un formulario de valoración. El formulario simple recoge nombre, correo y mensaje. El nuevo pedido exige seleccionar sede, servicio, fecha, enviar confirmación automática y conectar los datos con un CRM. La diferencia no está en la cantidad de campos; está en la lógica y las integraciones que deben probarse.
El tercer paso es explicar el impacto en el cronograma. Un cambio aprobado puede requerir más tiempo de diseño, desarrollo o pruebas. No conviene prometer que se mantendrá la fecha original si la nueva tarea consume recursos que no estaban reservados. La fecha revisada debe depender de los insumos y aprobaciones que correspondan.
El cuarto paso es registrar la aprobación. La persona que decide debe confirmar el cambio por el canal acordado, junto con sus condiciones. Si la empresa tiene un área de comunicaciones, un gerente y un proveedor técnico, conviene definir quién puede aprobar para evitar instrucciones cruzadas.
La inversión suele depender del alcance, la complejidad, las integraciones y los objetivos. Un proveedor serio puede pedir tiempo para revisar antes de entregar un valor. Esa pausa protege a ambas partes y evita convertir una estimación apresurada en una deuda de trabajo.
El artículo Términos y condiciones de Gulupa Digital puede servir como referencia pública, pero las condiciones aplicables deben confirmarse en la documentación de cada proyecto.
Qué no se considera cambio de alcance
No todo desacuerdo o ajuste implica una nueva cotización. Una corrección dentro del entregable puede formar parte del proceso acordado. También puede ser una corrección la solución de un error frente al diseño aprobado, una falla funcional atribuible a la implementación o una mejora menor que ya estaba prevista en la especificación.
La dificultad está en que “menor” no debe significar “lo que no cuesta mucho”. Una solicitud puede ser pequeña para quien la formula y costosa para quien debe construirla. La clasificación debe usar el alcance y el impacto, no la intuición del momento.
Si una página debía ser responsive y en un teléfono se desborda, corregir ese comportamiento se relaciona con el entregable. Si la página debía mostrar un formulario y ahora se quiere un portal de clientes, hay una nueva necesidad. Si el texto aprobado tenía un error ortográfico, editarlo suele ser distinto a reescribir toda la propuesta comercial porque cambió la estrategia.
Escenario ilustrativo: el cliente aprueba una página con un bloque de tres beneficios y después detecta que uno tiene una palabra incorrecta. Corregirla no equivale a pedir una nueva sección con comparativa, calculadora y descarga. Ambos pedidos llegan como “un cambio”, pero su alcance es diferente.
También conviene distinguir un cambio del cliente de un bloqueo externo. Si una pasarela de pagos cambia su documentación o un proveedor demora una credencial, el efecto puede ser real, aunque no sea una decisión de alcance. Debe quedar registrado por separado para analizar la fecha y las responsabilidades sin mezclar conversaciones.
La garantía de 35 días hábiles o gratis aplica a proyectos estándar y está condicionada al alcance aprobado, la entrega de insumos y el cumplimiento del cronograma del cliente. Un cambio aprobado durante el proyecto puede modificar la base con la que se evalúa el plazo. Pregunta cómo se documenta ese efecto y deja la respuesta en la cotización o el contrato.
Qué debe quedar escrito antes de continuar
Una buena gestión del cambio deja un rastro que cualquiera del equipo puede entender. No basta con una frase como “se ajustó la propuesta”. El registro debería incluir la versión del alcance, la solicitud concreta, las opciones evaluadas, las decisiones tomadas y las dependencias que siguen abiertas.
Incluye también la fecha de aprobación y el responsable. Si el cliente entrega contenido tarde, si faltan fotografías o si la persona que debe aprobar no está disponible, esos hechos afectan el proyecto de una forma distinta a una tarea adicional. Documentarlos evita que toda desviación termine etiquetada como problema técnico.
La trazabilidad es especialmente útil cuando participan varias áreas. Marketing puede pedir una landing, ventas puede solicitar un CRM y dirección puede pedir un cambio de posicionamiento. Un documento compartido permite revisar si el pedido cabe en el objetivo original o si conviene abrir una fase diferente.
Gulupa Digital estructura sus proyectos alrededor del descubrimiento estratégico, el diseño orientado a conversión, el desarrollo estructurado, la medición real y la optimización continua. Ese orden ayuda a revisar un cambio desde el negocio y no únicamente desde la pantalla. Una página nueva tiene sentido si resuelve una necesidad prioritaria y puede medirse.
Revisa también los accesos, las licencias, los plugins y las integraciones que el cambio pueda involucrar. Trabajar con WordPress y Elementor Pro permite construir muchos tipos de páginas, pero la herramienta no elimina las decisiones de arquitectura, seguridad, contenido y mantenimiento.
Para empresas con operación comercial activa, el costo de un cambio mal gestionado puede aparecer como retrabajo, retraso de campaña, capacitación repetida o datos que no llegan al equipo de ventas. Ese costo rara vez aparece en la primera conversación. El registro permite verlo antes de aprobar.
Si el documento actual no responde qué ocurre cuando se solicita trabajo adicional, conviértelo en una pregunta concreta al proveedor: ¿qué se considera fuera de alcance, cómo se aprueba, quién lo cotiza y qué pasa con la fecha? La respuesta debe quedar asociada al proyecto.
Hay otra revisión que suele pasarse por alto: el efecto del cambio sobre el lanzamiento. Una página adicional puede parecer inocua, pero si requiere nuevos textos, fotografías, traducciones o aprobaciones, puede desplazar otras tareas. La dirección debe decidir si esa solicitud entra en la versión inicial, se deja para una fase posterior o reemplaza algo que tenía menor prioridad.
Escenario ilustrativo: una empresa pide una sección de casos de éxito cuando el desarrollo ya está avanzado. El pedido puede mejorar la confianza del visitante, pero necesita seleccionar casos, obtener autorizaciones, preparar textos y revisar datos. Si no hay material listo, el impacto no está solo en construir la sección. También está en producirla correctamente.
La priorización evita que todo termine en “sí” o “no”. Pregunta qué problema resuelve el cambio, cuántas oportunidades puede apoyar, qué riesgo reduce y qué trabajo desplaza. Una solicitud con valor comercial puede entrar en la primera versión, pero eso debe ser una decisión explícita y no una adición silenciosa.
El equipo de ventas debería participar cuando el cambio afecta formularios, mensajes, llamados o calificación de prospectos. Una funcionalidad puede quedar técnicamente lista y ser poco útil si el equipo no sabe cómo atender los datos que recibe. La web forma parte del proceso comercial, no vive aislada en el navegador.
El cliente también debe protegerse de la falsa economía. Aceptar un adicional sin entender su alcance puede parecer rápido, pero producir un resultado incompleto genera otra ronda, otra integración o una corrección urgente después del lanzamiento. Pedir una descripción precisa antes de aprobar suele ahorrar fricción.
Cuando la solicitud es urgente, registra la razón de la urgencia y la alternativa. Puede ser mejor lanzar la versión aprobada y crear un backlog para la siguiente etapa. Esa decisión mantiene el control sobre la fecha sin perder la idea. El backlog debe tener responsable, prioridad y condición de entrada, no ser una carpeta donde se acumulan deseos.
Una revisión de alcance bien hecha protege la relación porque reemplaza la discusión personal por evidencia. Cliente y proveedor pueden no coincidir en la prioridad, pero sí pueden mirar el mismo documento y decidir con información. Esa es la diferencia entre administrar un proyecto y perseguir cambios por correo.
Frequently Asked Questions
¿Un cambio de texto siempre es un cambio de alcance?
No. Puede ser una corrección incluida si el texto forma parte del entregable y todavía está dentro del ciclo de aprobación acordado. Una reescritura completa por cambio de estrategia, nuevas páginas o investigación adicional puede requerir otra evaluación.
¿Quién decide si una solicitud está incluida?
La decisión debe salir de la documentación aprobada y del responsable definido para el proyecto. Si existe una duda, conviene que cliente y proveedor la revisen juntos y la registren antes de ejecutar.
¿Un cambio de alcance modifica la fecha de entrega?
Puede hacerlo cuando agrega diseño, desarrollo, pruebas, contenido o coordinación con terceros. La nueva fecha debe confirmarse con base en el trabajo adicional y en la disponibilidad de insumos y aprobaciones.
¿La garantía de 35 días hábiles cubre cualquier cambio solicitado?
La garantía de 35 días hábiles o gratis se comunica para proyectos estándar y depende del alcance aprobado, los insumos y el cronograma del cliente. El tratamiento de cambios posteriores debe revisarse en la cotización o contrato aplicable.
¿Qué hago si ya ejecutaron un adicional sin aprobación?
Pide un registro de la solicitud, el trabajo realizado, su impacto y la base contractual usada para ejecutarlo. Si la documentación no es clara, solicita una reunión de aclaración y evita aprobar nuevos cambios hasta cerrar ese punto.
¿Un rediseño puede convertirse en una tienda virtual?
Puede ocurrir, pero una tienda cambia la arquitectura y las necesidades operativas del proyecto. Deben revisarse catálogo, pagos, checkout, pedidos, analítica, contenido y mantenimiento antes de aceptar el cambio.
Si quieres revisar un cambio de alcance en tu rediseño, escribe a Gulupa Digital por WhatsApp. con el alcance aprobado y la solicitud concreta.


