Qué es un playbook.
Un playbook no documenta lo que hacéis: documenta lo que ya ha ganado, con el criterio dentro, para que lo repita alguien que no estaba. Escrito antes de que algo funcione dos veces, es una corazonada con formato de manual.
Un playbook es la secuencia escrita de algo que ya ha funcionado más de una vez, con el terreno donde aplica, el criterio de salida de cada paso y las excepciones, para que lo ejecute alguien que no estaba cuando funcionó. Si lo que describe no está validado, no es un playbook: es una corazonada documentada.
También: manual de ejecución · manual operativo · runbook
Agencia Snowball, Barcelona · Revisado el
Un playbook no documenta lo que hacéis. Documenta lo que ya ha ganado.
Un playbook es la secuencia escrita de algo que ya ha funcionado más de una vez, preparada para que la ejecute alguien que no estaba cuando funcionó. La diferencia con la documentación no es de tono ni de formato: la documentación recoge lo que se hace hoy, y por tanto conserva los vicios. Un playbook recoge solo lo que ganó, y dice en qué condiciones ganó.
La prueba del algodón es la persona que entra. Dale el documento a alguien con criterio pero sin contexto y mira si puede hacer el trabajo sin preguntarte. Si tiene que preguntarte tres veces, lo que has escrito es un recordatorio para ti. Un playbook existe justo para lo contrario: para que tú dejes de ser el cuello de botella. Convierte un resultado que vive en tu cabeza en un proceso que vive fuera de ella.
De ahí sale la condición que casi nadie respeta: el playbook va detrás del resultado, nunca delante. Escribir el manual de algo que todavía no ha ganado dos veces no es adelantar trabajo. Es fijar una corazonada por escrito y darle la autoridad de un procedimiento, que es peor que no tenerla, porque ahora hay tres personas ejecutándola con disciplina. Lo que va delante del resultado es un experimento; el manual va detrás.
Cuatro capas, y la que se olvida siempre es la misma.
Un playbook que sirve tiene el terreno donde aplica, la secuencia, el criterio de cada paso y el traspaso. La que se cae de la lista es la primera, y es la que decide si el manual sobrevive a su primer usuario.
El terreno es a quién sí y, sobre todo, a quién no. Un playbook sin la lista de casos a los que no aplica se rompe el primer día: la primera persona que lo use lo aplicará al caso que no toca, no funcionará, y concluirá que el playbook no funciona. Aquí van el ICP y su reverso, los casos que se rechazan a propósito. Y las excepciones se escriben con su alcance, no en general: rechazar clientes nuevos que no encajan no es lo mismo que soltar a los que ya están dentro, y si esa frase no está escrita, alguien hará lo segundo creyendo que cumple la regla.
La secuencia es la parte que todo el mundo escribe bien: los pasos, en orden. Lo que la convierte en playbook es la columna de al lado, el criterio de salida de cada paso: qué tiene que ser verdad para pasar al siguiente. Un pipeline con etapas y sin ese criterio es una carpeta con nombres bonitos, porque cada uno mueve las cosas cuando le parece. Con el criterio escrito, el manual deja de ser una lista de tareas y pasa a ser un marco de decisión.
Las reglas duras no salen de las buenas prácticas: salen de las pérdidas que has medido. En nuestro propio historial comercial —471 operaciones cerradas y unas 45 grabaciones de venta revisadas— el 89% de esas operaciones se apilaba en una sola etapa, la última, la de propuesta ya enviada. El manual que salió de ahí no dedica su cuerpo a conseguir más reuniones: lo dedica a cerrar lo que ya está enviado, porque ahí estaba el atasco. Un playbook se escribe sobre el cuello de botella, no sobre el organigrama.
Y esas reglas se escriben con grano fino. Una regla de playbook no dice “hacer seguimiento”: dice el día y dice el canal.
Sale la propuesta con la fecha de decisión ya puesta por ti, no por el cliente.
El día de la fecha: llamada, no correo. Si no coge, correo corto detrás.
Segundo toque, y trae algo nuevo dentro: un dato, un caso, una lectura.
Toque de cierre con disyuntiva: seguimos, o lo guardo con fecha de re-contacto.
El traspaso es la capa que separa un documento de un manual en uso. Se escribe por tramos —qué se lee y se acompaña el primer mes, qué se lleva ya con supervisión el segundo, qué se hace solo el tercero— y lleva dentro una válvula: si el manual choca con lo que dice en vivo quien lo escribió, manda la persona. Sin esa frase el playbook se convierte en ley, y la primera excepción legítima lo revienta delante de todo el equipo. La última pieza del traspaso es de tamaño: once secciones y un resumen que cabe en una pantalla. Un manual que solo se puede leer entero no se lee, y un playbook que nadie relee no se ejecuta.
Cuándo se escribe y cuándo es demasiado pronto.
Dos preguntas ordenan la decisión: ¿ha vuelto a pasar? y ¿sabes por qué pasó? Con esas dos, cualquier cosa que os haya funcionado cae en uno de cuatro sitios, y solo uno de los cuatro pide manual.
Es una anécdota. Lo que toca aquí no es redactar, es aislar la causa.
Si lo pasas a manual, se repetirá el ritual entero, con todo lo que sobraba dentro.
Buen aprendizaje, no manual. Un caso no aguanta el peso de un procedimiento.
Escríbelo antes de que quien lo hace cambie de tarea, de puesto o de empresa.
El cuadrante que hace daño no es el de la anécdota: es el de arriba, el que se repite y nadie sabe por qué. Ahí el manual documenta el ritual completo —la hora de la llamada, el orden de las diapositivas, el descuento que se colaba al final— sin distinguir lo que causaba el resultado de lo que simplemente estaba al lado. Se repite entero, cuesta el triple de lo que debería, y en cuanto una pieza cambia deja de funcionar sin que nadie sepa cuál era la pieza. Eso no se arregla escribiendo mejor: se arregla aislando la causa y anotando el aprendizaje validado antes de redactar una línea de manual.
El otro cuadrante engañoso es el de la vez única bien entendida. Sabes perfectamente por qué funcionó, y ha pasado una vez. Eso es un quick-win con buena explicación, y su sitio es el registro de aprendizajes. Un caso no aguanta el peso de un procedimiento: en cuanto el segundo intento sale distinto, el manual queda desautorizado y con él todos los demás.
Cuando sí toca, se escribe rápido y con dueño. Un playbook es lo que hace que meter una persona más multiplique en vez de dividir, y eso es escalabilidad operativa: la única forma de que crecer no signifique clonarte. Pero caduca en silencio, porque el canal cambia, el precio cambia y el competidor cambia. Se revisa con el mismo ritmo de revisión que las métricas, con fecha puesta y no cuando alguien se acuerde.
Y lo que decide si sigue vivo son los KPI que el propio manual manda mirar. Elige mal esa lista y el problema no se ve venir: si el playbook manda mirar impresiones o seguidores, lo que has sistematizado es una métrica de vanidad. Se ejecutará con disciplina, todo el mundo dirá que se está cumpliendo, y no moverá la North Star. Un playbook bien puesto se puede auditar por resultado: si se ejecuta y el número que importa no se mueve, el manual está mal, no el equipo.
Cuatro formas de escribir un playbook que nadie va a poder usar.
Escribirlo demasiado pronto
Un manual de algo que ha funcionado una vez es una corazonada con formato de procedimiento. El daño no es el documento: es que a partir de ese día la corazonada ya no se discute, se cumple. Si te lo estás planteando y no puedes nombrar la segunda vez que funcionó, todavía no toca.
Los pasos sin el criterio
Una secuencia de pasos sin la condición que cierra cada uno no se puede ejecutar ni auditar: nadie sabe cuándo un paso está terminado, así que todos avanzan cuando les parece y el manual no explica por qué dos personas obtienen resultados distintos siguiéndolo. El criterio es la mitad del playbook, no un anexo.
No decir a quién no aplica
Es el fallo que mata el manual el primer día. Sin la lista de casos excluidos, la primera persona que lo coja lo aplicará donde no toca, no funcionará, y a partir de ahí el playbook tiene un detractor con un ejemplo. Las excepciones se escriben con su alcance exacto: una regla sin alcance se interpreta en la dirección más cómoda.
Sin dueño y sin fecha de revisión
Un playbook sin alguien que responda por él caduca sin avisar, y lo peor de un manual caducado es que se sigue cumpliendo: el equipo ejecuta con disciplina algo que dejó de funcionar y el resultado se le atribuye a la ejecución. Escríbelo con quien de verdad lo hace bien —no con quien lo ha visto hacer— y ponle fecha de siguiente lectura el mismo día que lo publicas.
Lo que se pregunta sobre playbook.
¿Cuándo se escribe un playbook y cuándo es demasiado pronto?
Cuando algo ha funcionado más de una vez y entiendes por qué. Con una sola vez tienes un aprendizaje, no un manual; y si se repite pero no sabes la causa, escribirlo fija el ritual entero con todo lo que sobraba dentro. Si no puedes nombrar la segunda vez que funcionó, todavía no toca.
¿Qué diferencia hay entre un playbook y un manual de procesos?
El manual de procesos recoge lo que se hace hoy, funcione o no, así que conserva los vicios con más orden. El playbook recoge solo lo que ha ganado y dice en qué condiciones ganó. Uno describe el presente; el otro se puede ejecutar mañana sin ti delante.
¿Qué tiene dentro un playbook para que sirva de verdad?
Cuatro capas: el terreno donde aplica y a quién no aplica, la secuencia de pasos, el criterio de salida de cada paso y el traspaso por tramos, con una válvula escrita para las excepciones. Sin el criterio es una lista de tareas; sin el terreno se rompe el primer día que alguien lo usa donde no tocaba.
¿Cada cuánto se revisa un playbook?
Con el mismo ritmo con el que revisas las métricas, y con fecha puesta el día que lo publicas. Un playbook caduca en silencio porque el canal, el precio y el competidor cambian, y lo peor de un manual caducado es que se sigue cumpliendo: el equipo ejecuta con disciplina algo que ya no funciona.
Los que hacen falta para usar este.
Cómo se traduce una misión en indicadores y en trabajo de dos semanas.
La misión medible: a quién ayudas, cuánto y para cuándo. La facturación es su consecuencia, no la métrica.
Los deals vivos del CRM por etapa. Su limpieza vale más que su tamaño.
Un cambio hecho a propósito para contestar una pregunta, con el criterio de éxito decidido antes de mirar el resultado. Sin pregunta ni criterio no hay experimento: hay un cambio.
Las dos o tres acciones del sprint que mueven el objetivo. Si se caen, el sprint no ha servido aunque todo lo demás esté hecho.
La ficha de la persona que decide dentro del cliente: qué le preocupa, qué le hace decir que no y con qué palabras lo dice.
El porcentaje de la facturación que entra por un solo canal. Pasado cierto peso, un cambio de algoritmo o de puja te toca la caja entera.