Respuesta breve
Una presentación terminada no equivale a un proyecto que el cliente pueda operar. Esta guía separa cuatro entregas y propone un registro de aceptación verificable.
Qué significa aceptar cuatro líneas de trabajo con un solo brief
Una lista de entrega de proyecto digital registra lo que el comprador podrá utilizar cuando el proveedor deje de intervenir. Si el encargo reúne identidad de marca, sitio web, flujo de IA y marketing, cada activo necesita una ubicación operativa, una persona que pueda aprobarlo y una prueba repetible por un nuevo empleado. Esto es un método para compradores, no el resultado observado de un cliente de VITON13. Imaginemos una pequeña marca de ropa que estrena identidad y formulario de consultas: el caso es ficticio y no implica aumentos de ventas o conversiones. La pregunta útil no es si la presentación final parece completa, sino si la empresa puede abrir, modificar, medir y sostener lo que ha comprado.
Empieza por el brief firmado y la última versión escrita del alcance. Usa una línea de aceptación para cada área aunque un mismo estudio las haya coordinado. Un logotipo exportado no demuestra que la web funcione; una página publicada no prueba que el cliente controle la cuenta publicitaria; una respuesta convincente de IA no prueba una gestión segura de casos ambiguos. Designa una persona que decida por el cliente y otra que entregue cada línea. Anota versión, enlace a la evidencia, revisor, fecha y estado: aceptado, defecto, dependencia o cambio propuesto. El proceso público de VITON13 Studio distingue alcance escrito, revisión humana, revisiones, entrega y soporte. El registro convierte esas fronteras en algo comprobable.
Marca: un sistema editable, no solo un PDF pulido
En la línea de marca enumera logotipo maestro, variantes aprobadas, colores, tipografías, criterio visual, reglas de uso y aplicaciones representativas incluidas en el brief. Distingue el material que se puede ver del archivo fuente que otro diseñador podrá editar. Un PDF muestra la solución aprobada; un archivo de trabajo empaquetado y los datos sobre licencias tipográficas permiten crear un nuevo rótulo o plantilla sin rehacer el proyecto. Si el contrato solo prometía exportaciones, no añadas fuentes de manera retroactiva a la prueba de aceptación. Señala la necesidad operativa y acuerda si un paquete editable supone ampliar el alcance. Apunta dónde está cada elemento y ábrelo desde una cuenta del cliente.
Prueba la identidad en los soportes para los que se diseñó. En el ejemplo ficticio de ropa, coloca el logotipo en una cabecera móvil clara, una etiqueta oscura, un avatar estrecho y el pie de un correo. Comprueba el tamaño mínimo legible y la coincidencia de valores de color y nombres de fuentes con la guía. Compara con el brief firmado, no con una preferencia de última hora que nadie presupuestó. La fila sobre derechos debe distinguir piezas originales de fuentes e imágenes de terceros, indicar quién tiene cada licencia y las limitaciones de canal o territorio realmente pactadas. Es una cuestión contractual, no asesoramiento jurídico: recibir un archivo no debe confundirse con autorización ilimitada para cualquier uso futuro.
Web: código, acceso a producción y tareas reales
Para la web, pide el repositorio acordado, instrucciones de despliegue, titularidad de alojamiento y dominio, inventario de configuración sin secretos, modo de editar contenido y contacto para revertir un lanzamiento. No pongas contraseñas en la hoja de entrega; registra quién concede acceso y cuándo se rotará. Según GitHub, una transferencia cambia quién administra el repositorio; los webhooks, secretos y claves de despliegue siguen asociados, aunque algunas funciones dependen del plan del nuevo titular. Comprueba por separado el titular real, los administradores, la conexión externa de despliegue y la copia de seguridad. Un ZIP de código puede cumplir un contrato limitado, pero no equivale a un proceso operativo de publicación.
Prueba tareas en la web entregada, no solo en la vista previa de diseño. Con móvil y teclado, busca un producto o servicio, envía una consulta válida, provoca el error de un campo obligatorio y encuentra la información de privacidad o devoluciones pertinente. Para cada tarea apunta URL, dispositivo, fecha, resultado esperado y resultado observado. Revisa enlaces y formularios con contenido definitivo; si hay idiomas contratados, recorre al menos una ruta traducida. La iniciativa de accesibilidad del W3C recomienda evaluar pronto y de forma continua y aclara que ninguna herramienta automática determina por sí sola la accesibilidad. Usa el escáner como una parte de la evidencia y añade observaciones manuales. Un defecto sigue abierto hasta tener responsable y nueva prueba; una captura bonita no lo cierra.
Flujo de IA: errores representativos y una persona al mando
Un flujo de IA requiere evidencia propia porque la salida puede variar aunque la interfaz no cambie. Define qué tarea puede hacer, qué datos consulta, qué acción ejecuta y cuándo debe intervenir una persona. En la marca ficticia, un asistente podría redactar una respuesta sobre existencias, pero no inventar disponibilidad ni comprometer una fecha de entrega que el inventario no haya confirmado. Prueba una petición normal, ausencia de datos, notas contradictorias, una solicitud fuera de alcance y un intento de obtener información restringida. Guarda lo que hizo el sistema, lo esperado por el revisor y el funcionamiento del escalado. No incorpores datos reales de clientes a un paquete de pruebas públicas.
El marco de gestión del riesgo de IA de NIST presenta gobernar, mapear, medir y gestionar como funciones continuas, no como un sello de conformidad de una sola vez. Convierte esa idea en un registro breve: responsable, fuentes permitidas, versión del prompt o configuración, casos de prueba, acción del revisor, contacto ante incidentes y botón o procedimiento de pausa. Acordad quién paga al proveedor del modelo, quién cambia la configuración y qué ocurrirá si cambian sus condiciones. Una demostración favorable no acredita la precisión futura ni garantiza retorno económico. Aceptar debería significar que se superó el conjunto de pruebas pactado y que los límites restantes son visibles, con capacidad humana de detener el sistema ante una entrada incierta.
Marketing: cuentas, activos y definiciones de medición
La línea de marketing une la estrategia con las cuentas donde continuará el trabajo. Enumera audiencia y mensaje aprobados, creatividades, calendario, plan de medición, definiciones de informes y cuentas utilizadas. Por canal anota quién es titular, qué usuarios conserva el proveedor, qué permisos necesitan y quién puede retirarlos. La ayuda de Google Analytics explica que los usuarios pueden añadirse a nivel de cuenta o de propiedad y que esa elección determina el alcance de acceso. De ahí sale una prueba concreta: un administrador autorizado del cliente entra, ve la propiedad correcta, revisa los eventos pactados y confirma que el papel de la agencia no excede lo necesario. Una captura enviada por correo no sustituye ese acceso.
Deja el presupuesto de anuncios, la producción creativa, las suscripciones y los honorarios del estudio en líneas separadas. Un número en el panel no demuestra éxito si nadie definió evento, periodo ni regla de atribución. En el lanzamiento ficticio, la empresa podría considerar una consulta completada su evento principal; es una decisión propuesta para medir, no evidencia de más consultas. Guarda el punto de partida anterior a la campaña, los supuestos sobre etiquetas y consentimiento y la persona que verificará calidad de datos después. Entrega archivos creativos editables cuando el contrato los incluya, versiones finales aprobadas y un calendario comprensible para un equipo sustituto. Retira el acceso del proveedor después de confirmar el control del cliente y concluir el soporte contratado.
Propiedad, costes de terceros, cambios y soporte
El dueño de un activo y el de una cuenta pueden ser distintos. El cliente puede poseer el diseño mientras otra cuenta sostiene la licencia tipográfica; puede ser titular del dominio mientras el antiguo proveedor conserva el acceso DNS. Para alojamiento, dominios, fuentes, imágenes de archivo, API de IA, analítica y canales pagados que se utilicen realmente, registra titular, renovación, cuota recurrente, vía de cancelación y método de exportación. Marca como desconocido cualquier coste sin verificar, no como incluido. Para el repositorio, decide por escrito si se transferirá, se compartirá acceso o se abrirá en la organización del cliente. La guía de GitHub ayuda a comprobar consecuencias, pero no impone transferir siempre.
Diferencia un defecto de una petición nueva. El defecto incumple una condición de aceptación escrita; el cambio añade o modifica un requisito aprobado. El registro de comentarios debe guardar evidencia, prioridad, responsable y propuesta de resolución. Incluye las rondas de revisión contratadas, ventanas de respuesta, comienzo y fin del soporte y tareas cubiertas. Si falta un archivo fuente, una licencia o un acceso y eso impide probar, deja la línea bloqueada, no aceptada. Evita una única casilla de 'proyecto completo' cuando subsisten tareas abiertas. Se trata de un registro justo para comprador y proveedor, que evita reconstruir meses después el sentido de una aprobación verbal.
Modelo de hoja de aceptación adaptable
Crea una fila por entregable con estas columnas: ámbito; resultado acordado; activo y versión; responsable del cliente; responsable del proveedor; enlace de evidencia; prueba y resultado esperado; resultado observado; estado; coste externo o licencia; siguiente acción y fecha. Es una plantilla hipotética, no un caso realizado por VITON13 para un cliente identificado. Fila A: marca, paquete de identidad aprobado versión 1, responsable creativo del cliente, archivo editable abierto desde su propia cuenta, aceptado tras las pruebas de uso convenidas. Fila B: web, formulario versión 2, responsable de operaciones, envíos válidos e inválidos probados en móvil, defecto por mensaje de error confuso. El estado deriva de una observación, no de una impresión general.
Fila C: IA, asistente de borradores versión 1, revisor de operaciones; las existencias contradictorias deben escalarse, bloqueado hasta demostrar la cola de aprobación humana. Fila D: marketing, propiedad de Analytics y calendario, administrador del cliente; acceso confirmado pero definición de un evento aún pendiente, dependencia en lugar de aceptado. Añade otra fila para cargos recurrentes y personas responsables de renovaciones. Así un nuevo empleado puede entender la misma evidencia sin asistir a la presentación. Si el proveedor propone otro formato, conserva los campos antes que la apariencia. Lo importante es el hilo de decisión: promesa, prueba, fallo y persona que resolverá el siguiente paso.
Cerrar el proyecto sin ocultar preguntas abiertas
En la revisión final, lee la hoja línea por línea. Acepta lo que supera la prueba escrita, fija una fecha de repetición para defectos, presupuesta aparte los cambios y asigna permisos pendientes a una persona concreta. Pide al administrador del cliente que confirme el acceso personalmente, sin reenviar una contraseña. Guarda manifiesto final, referencias de licencias, instrucciones y aprobaciones en un espacio controlado por el cliente. Anota contacto de soporte y fecha exacta de conclusión, distinguiendo mantenimiento de trabajo nuevo. Si una herramienta renueva automáticamente, alguien debe saberlo antes del próximo cargo. La entrega termina cuando el destinatario puede operar el resultado, no cuando recibe una carpeta comprimida.
El método también limita las afirmaciones editoriales. Ninguna lista ni norma garantiza una web rentable, un sistema de IA seguro o campañas eficaces. GitHub, Google Analytics, NIST y W3C documentan prácticas concretas de plataforma o evaluación; cada equipo debe aplicarlas a su contrato y riesgos. El proceso público de VITON13 establece alcance, exclusiones y revisiones por escrito antes de empezar, seguidos por revisión, entrega y soporte. Esta guía convierte esa secuencia en un registro de evidencia para el comprador. Lleva la hoja a la siguiente reunión, solicita la prueba que falte y deja visible cada línea sin resolver hasta que una persona responsable la cierre.
Lista práctica
- Nombra una persona que decida por el cliente y una responsable de cada entrega.
- Relaciona cada activo prometido con su ubicación, versión, formato y prueba reproducible.
- Verifica el acceso del cliente al código, alojamiento, dominio y cuentas de medición.
- Ejecuta una tarea normal y otra con error en la web y en el flujo de IA.
- Registra suscripciones externas, titulares de licencias, renovaciones y responsables de cancelarlas.
- Separa lo aceptado, los defectos y las solicitudes de cambio presupuestadas aparte.
Preguntas frecuentes
¿Qué debe incluir la lista de entrega de un proyecto digital?
Incluye el resultado acordado, la versión y ubicación de cada entregable, quién controla el acceso, una prueba que otra persona pueda repetir, defectos abiertos, pagos externos, derechos o límites de licencia y el fin del soporte. Una captura de pantalla no demuestra que el cliente pueda mantener el trabajo.
¿Debe el cliente ser propietario del repositorio de GitHub?
Depende del contrato y del modelo de alojamiento. Si el repositorio debe pasar al cliente, puede crearse en su organización desde el principio o transferirse después. GitHub documenta condiciones y efectos de la transferencia; conviene comprobar administradores e integraciones al terminar.
¿Basta una demostración para aceptar una automatización con IA?
No. Prueba entradas habituales, datos ausentes y contradictorios, una aprobación humana identificada y una vía de escalado. Registra el resultado esperado y el observado. Una demostración vistosa muestra una posibilidad, pero no acredita el comportamiento del flujo en la operación cotidiana del cliente.