Materiales del cliente: qué comprobar antes del kickoff

El cliente ha enviado una carpeta. Hay un logotipo, cuatro documentos, varias imágenes y un mensaje: «Con esto podéis empezar». Antes del kickoff, comprueba qué tarea puede empezar con cada material, quién verifica que sirve y qué falta para aceptarlo. Una carpeta llena no responde a esas preguntas.

Esta ficha está pensada para una agencia que ya ha acordado el trabajo. No vuelve a negociar el presupuesto ni calcula disponibilidad del equipo: convierte la entrega de materiales en una decisión operativa. Puedes aplicarla en una hoja compartida, sin comprar ninguna herramienta.

Pide entradas para tareas, no una carpeta «completa»

Empieza por el primer entregable y recorre sus tareas. Para maquetar una página necesitas contenido identificado; para decidir un recorte necesitas la fotografía original; para comprobar cambios necesitas acceso al entorno correcto. Si no puedes nombrar la tarea que depende de una petición, revisa si realmente hace falta pedirla ahora.

La guía de kickoff de Atlassian propone acordar propósito, roles y criterios de éxito. Aquí añadimos una comprobación previa y más concreta: las entradas que permiten ejecutar la primera parte del trabajo. Es un método editorial propuesto, no un estándar de certificación.

Distingue materiales para empezar de materiales para publicar. El acceso de publicación puede esperar si la primera fase ocurre en un entorno de pruebas. En cambio, el texto principal quizá condicione la estructura desde el primer día. Pon una fecha necesaria por tarea; no conviertas la fecha de la reunión en un plazo indiscriminado para todo.

Define «sirve» antes de recibirlo

«Enviar fotos» deja demasiado por interpretar. Escribe «enviar el original de la fotografía principal, comprobar que admite el recorte acordado y confirmar el uso previsto». El criterio debe describir una prueba pequeña que otra persona pueda repetir.

Para textos, identifica secciones, idioma, versión y persona que confirma el contenido. Para identidad visual, pide el archivo utilizable y la variante elegida; una captura del logotipo no demuestra que exista un original vectorial. Para accesos, prueba la acción necesaria desde la cuenta asignada. Recibir una invitación no prueba que esa cuenta pueda trabajar.

La documentación de Google Drive distingue permisos de lector, comentador y editor. Por eso «el enlace abre» y «puedo editar» son comprobaciones distintas. No pidas contraseñas en la ficha ni abras un enlace a todo el mundo para solucionar un permiso individual. Registra la referencia al acceso, no el secreto.

El cliente aporta el material; la agencia verifica si sirve para la tarea. Una misma persona puede coordinar varias entradas, pero «el cliente» y «nosotros» no bastan como responsables cuando nadie sabe a quién escribir.

Ejemplo hipotético: cinco entradas, dos aceptadas

Una agencia prepara una página de campaña de cinco secciones. Estos datos son inventados para practicar; los días son relativos al comienzo previsto, no plazos recomendados.

Hay 2 de 5 entradas aceptadas: 2 ÷ 5 = 40%. Ese porcentaje describe el inventario, no la preparación del proyecto. Cuatro entradas aceptadas tampoco permitirían maquetar el contenido si la única pendiente fuese K01. La importancia depende de la tarea bloqueada, no del número de filas verdes.

El diseño puede explorar una dirección con el logotipo aceptado si esa exploración no exige texto definitivo ni fotografía. Deja escrita esa limitación. No presentes una maqueta con marcadores provisionales como contenido ya aprobado.

Copia una ficha que deje una acción pendiente visible

Usa una fila por dependencia y conserva el identificador cuando llegue otra versión:

ID / material / tarea que depende de él:
Criterio observable de aceptación:
Quién aporta / quién comprueba:
Necesario antes de / versión recibida:
Estado: pendiente / recibido / por corregir / aceptado / no necesario
Evidencia de la comprobación y fecha:
Siguiente acción / responsable / próxima revisión:
Si no llega: tarea que puede avanzar y tarea que espera:

«Recibido» significa que existe una entrega pendiente de comprobación. «Por corregir» debe indicar el fallo concreto, no una valoración como «material malo». «No necesario» requiere motivo y persona que decide; no sirve para esconder una entrada que nadie consigue.

Cuando cambie una versión aceptada, comprueba qué tareas usaban la anterior. Guarda la nueva referencia y reabre únicamente las comprobaciones afectadas. Si cambia el entregable acordado, hace falta una decisión de alcance separada; corregir la ficha no la sustituye.

Envía una petición que se pueda resolver

En el ejemplo, el mensaje podría ser: «Para maquetar faltan el texto de la sección 5 y la confirmación de versión de K01. Para la cabecera necesitamos el original de K03; la miniatura recibida tiene 320 px. Desarrollo comprobará K04. Confirma quién aporta las dos correcciones y cuándo estarán; entonces revisaremos las tareas que pueden empezar».

No prometas una nueva fecha automáticamente cuando llegue el archivo. Todavía hay que verificarlo y comprobar la disponibilidad real. Tampoco interpretes el silencio como aceptación. En una agencia, centralizar esta petición ayuda a que cada especialista no solicite una versión distinta.

Si la tarea nunca estuvo definida, vuelve a la preparación del presupuesto. Si las peticiones internas se multiplican sin aportar nada a la entrega, revisa el orden de eliminar, automatizar y delegar. Una ficha más larga no es necesariamente una ficha mejor.

Termina el kickoff con una decisión por tarea: puede empezar, espera una dependencia o necesita aclaración. Anota quién hará la próxima comprobación. El resultado útil no es haber celebrado la reunión: es que la persona que empieza mañana sepa qué puede usar.