Una presentación de kickoff con un cliente convierte una compra acordada en un plan de trabajo compartido. Debe aclarar el objetivo del cliente, las responsabilidades de ambos equipos, la información necesaria para empezar y el proceso de aceptación. Una visita guiada por el producto no basta.
Empieza por el resultado que el cliente ya ha acordado perseguir. Después muestra el trabajo necesario para alcanzarlo, incluidas las tareas que le corresponden. Cuando ese documento esté definido, convierte el plan de incorporación en diapositivas con Presenti y adáptalo a quienes asistirán. Mantén los compromisos dentro del alcance aprobado: una línea temporal atractiva no debe crear promesas nuevas.
Define qué debe quedar resuelto en la reunión
Al terminar el kickoff, los participantes deben saber quién hará qué a continuación y qué decisiones pendientes pueden frenar el avance. Es una tarea distinta de convencer a alguien para que compre. No repitas el discurso comercial ni presentes una lista de funciones antes de hablar de la implementación.
La guía de Asana sobre reuniones de inicio, en inglés explica la necesidad de alinear objetivos, alcance, entregables, responsabilidades y comunicación. En un proyecto para un cliente, muestra las dos partes: qué aporta tu equipo, qué aporta el cliente y quién acepta cada resultado.
Invita a las personas capaces de resolver las primeras decisiones de implementación. Si no puede asistir quien patrocina el proyecto del lado del cliente, aclara quién puede representar el objetivo acordado y qué decisiones deben esperar. Estar presente no equivale a tener autoridad para decidir.
Organiza las diapositivas alrededor de una implementación concreta
Considera un proyecto ilustrativo de puesta en marcha de un portal de solicitudes de servicio. El cliente quiere que un equipo de soporte haga un piloto con tres tipos de solicitud. El alcance inicial incluye configuración, una importación de prueba y un ensayo del piloto. El despliegue a toda la empresa y otros tipos de solicitud quedan fuera de esta fase.
Expresa el objetivo sin inventar un resultado: «Preparar al equipo de soporte para pilotar tres tipos de solicitud acordados». No lo sustituyas por «Reducir el tiempo de resolución un 40 %» si no se han acordado ese objetivo, su referencia inicial y cómo se medirá. El kickoff puede definir la medición del éxito; no puede informar de beneficios que aún no han ocurrido.
| Elemento acordado | Significado en el ejemplo | Prueba o punto pendiente |
|---|---|---|
| Alcance del piloto | Un equipo y tres tipos de solicitud identificados | Documento de alcance aprobado y lista de flujos seleccionados |
| Configuración | Formularios y asignación de esos tipos de solicitud | La persona responsable del proceso del cliente confirma las reglas. |
| Importación de prueba | Una muestra de datos en el entorno de pruebas | La persona responsable de los datos proporciona una muestra aprobada. |
| Preparación del piloto | Los usuarios completan las tareas de prueba acordadas. | Registro del ensayo y responsable de aceptación identificado |
Deja accesible la referencia del alcance aprobado para quienes participen en la reunión. La tabla ayuda a entenderlo, pero una diapositiva no sustituye al acuerdo que rige el proyecto ni a su proceso de cambios.
Muestra las responsabilidades de ambos equipos
Una lista que solo incluye tareas del proveedor oculta dependencias que pueden detener la incorporación del cliente. Para cada entregable, identifica quién lo produce, quién aporta la información del cliente y quién lo acepta. Una persona puede desempeñar varios roles, pero cada responsabilidad debe quedar explícita.
| Trabajo | Responsabilidad del equipo de implementación | Responsabilidad del cliente | Aceptación |
|---|---|---|---|
| Configuración de asignaciones | Configurar las reglas acordadas. | La persona responsable del proceso aporta y aclara las reglas. | Esa persona comprueba los recorridos de solicitudes de prueba. |
| Importación de prueba | Relacionar los campos y ejecutar la importación. | La persona responsable de datos aporta una muestra aprobada y explica los campos. | Comprueba los resultados de conciliación acordados. |
| Ensayo del piloto | Preparar el ensayo y registrar incidencias. | Quien dirige el equipo facilita la participación de los usuarios del piloto. | La persona responsable del piloto revisa resultados y asuntos sin resolver. |
Sustituye los roles genéricos por nombres confirmados en el documento privado de trabajo. No adoptes los roles de este ejemplo público como si fueran una cadena de aprobación válida para tu proyecto. Si falta asignar uno, señálalo como decisión pendiente en lugar de atribuírselo sin más a quien esté en la reunión.
Acuerda la aceptación antes de convertir fechas en compromisos
«Importación terminada» puede significar que se ha subido un archivo, que se han creado registros o que el cliente ha comprobado el resultado. Son estados distintos. Acuerda pruebas observables de aceptación mientras todavía se está planificando el trabajo.
En el ejemplo, la importación de prueba podría exigir dar cuenta de los 50 registros de la muestra aprobada. Si se importan 47 y fallan tres, la conciliación solo queda completa cuando los tres fallos están identificados y explicados; eso no implica aceptar automáticamente la importación. La persona con autoridad de aceptación decide si los problemas pendientes permiten pasar a la siguiente etapa.
Del mismo modo, «formación impartida» no equivale a «equipo del piloto preparado». Un ensayo podría pedir a dos usuarios designados que envíen, asignen y cierren cada tipo de solicitud en el entorno de pruebas. Registra lo que ocurre y lo que necesita atención. Es un criterio propuesto para el ejemplo, no una exigencia universal para cualquier incorporación de clientes.
Haz visibles las condiciones reales del calendario
Una línea temporal pulida resulta peligrosa si oculta información pendiente. Muestra el requisito junto a cada hito: reglas aprobadas antes de configurar, muestra autorizada antes de probar la importación y usuarios disponibles antes del ensayo.
Por ejemplo, el plan de trabajo podría apuntar a una importación de prueba el jueves si la muestra aprobada llega el lunes. Si llega el miércoles, no mantengas el jueves en verde sin revisarlo. Quien dirige la implementación debe evaluar el tiempo de preparación restante y confirmar la fecha o proponer otra secuencia.
Utiliza tres etiquetas claras: fecha acordada, fecha objetivo de planificación y pendiente de programar. Explica con lenguaje corriente por qué cada fecha es provisional. No llenes todo el calendario de advertencias: coloca la condición al lado del hito al que afecta.
Termina con tareas útiles para la primera semana
| Próxima acción | Rol responsable | Cuándo se necesita | Prueba de finalización |
|---|---|---|---|
| Confirmar los tres tipos de solicitud y su asignación | Responsable del proceso del cliente | El lunes, antes de comenzar la configuración | Lista de flujos revisada |
| Proporcionar la muestra aprobada de 50 registros | Responsable de datos del cliente | El lunes, antes de preparar la importación | Muestra disponible por el canal seguro acordado |
| Devolver las preguntas sobre correspondencia de campos | Responsable de implementación | Después de inspeccionar la muestra | Preguntas asignadas a personas concretas |
| Confirmar participantes y disponibilidad para el ensayo | Responsable del equipo del cliente | Antes de reservar el ensayo | Participantes identificados y horario confirmado |
Los días de la semana son ilustrativos. Sustitúyelos por fechas reales solo después de confirmar las dependencias. Revisa la tabla en la reunión para que el silencio no se interprete como acuerdo.
Acuerda también cómo se comunicará una tarea bloqueada. Una regla útil identifica el contacto, la información que debe incluirse y el siguiente momento de decisión. «Escalar si es necesario» deja los tres elementos sin resolver.
Utiliza una estructura de siete diapositivas
- Propósito y resultado deseado: qué debe hacer posible esta fase.
- Alcance: entregables incluidos y exclusiones más relevantes.
- Ejemplo de funcionamiento: recorrido de una solicitud o un usuario por la solución prevista.
- Responsabilidades compartidas: ejecución, información del cliente y aceptación.
- Hitos y dependencias: fechas acordadas frente a objetivos condicionales.
- Comunicación: canal de trabajo, reuniones de revisión y cómo llegan los bloqueos a quien decide.
- Acciones de la primera semana: responsable, plazo y prueba de cada tarea.
Deja las demostraciones extensas del producto en un anexo o en otra sesión cuando distraigan de las decisiones de inicio. Más adelante, una revisión trimestral del negocio, explicada en esta guía en inglés podrá comparar resultados observados con el objetivo del cliente. Esa revisión posterior tiene una función distinta de acordar ahora el plan de implementación.
Da a la herramienta los límites, además del plan
Pega el documento acordado en la entrada de texto de Presenti. Pide una estructura editable, no un plan de proyecto inventado. El siguiente ejemplo mantiene visible el trabajo del cliente:
Crea un borrador de siete diapositivas para una reunión de inicio con un cliente sobre un piloto ilustrativo de portal de solicitudes de servicio. Alcance: un equipo, tres tipos de solicitud, configuración, importación de prueba de 50 registros y ensayo del piloto. Separa las responsabilidades del cliente y del equipo de implementación. Distingue el alcance acordado de los criterios de aceptación propuestos y las fechas condicionales. Termina con las acciones de la primera semana. No inventes resultados del cliente, condiciones contractuales, fecha de lanzamiento ni duración prometida de la implementación.
Antes de compartir la presentación, comprueba que cada responsable haya aceptado su función y que el cliente pueda distinguir una propuesta de un compromiso. El documento está listo cuando ambos equipos pueden explicar la siguiente acción en los mismos términos.
