¿Cómo entrega una oportunidad ganada al equipo que la ejecuta?

01El problema de negocio

Se cierra una oportunidad. Ahora hay que construir, configurar, migrar o enseñar algo antes de que el cliente obtenga valor de lo que ha comprado, y quienes lo hacen no son las personas que lo vendieron.

Aquí es donde suele vivir el traspaso:

• Una conversación, o un mensaje en un canal, y una hoja de cálculo que el equipo de implementación mantiene por su cuenta.
• Lo que el comercial haya escrito en las notas de la oportunidad, que nunca es lo que el equipo de implementación necesita saber.
• Una fecha de inicio en la que nadie se pone de acuerdo, porque «ganada» y «lista para empezar» son hechos distintos separados por una factura.

Las consecuencias son previsibles y caras. Nadie sabe responder cuántos clientes están ahora mismo a mitad de implementación, ni cuáles van con retraso, porque la respuesta vive en una hoja de cálculo. Soporte se entera de que un cliente se ha puesto en marcha cuando ese cliente abre su primer ticket. Y los informes del propio equipo de ventas se degradan sin que nadie lo note, porque las oportunidades que cerró siguen en su pipeline meses después.

02Por qué falla el enfoque obvio

Añadir etapas de implementación al pipeline de ventas

Es el primer instinto y es el que sale caro. El pipeline ya tiene etapas y el registro de la oportunidad ya existe, así que las fases de implementación se añaden al final: Ganada → Configuración → Formación → Entregada.

Corrompe a la vez todas las métricas del pipeline, porque un pipeline mide un ciclo de vida y ahora está cargando con dos:

• El ciclo de venta pasa a ser el tiempo de venta más el de implementación. Una oportunidad cerrada en marzo y puesta en marcha en julio informa de un ciclo de cuatro meses en el que ningún comercial influyó.
• La tasa de conversión deja de significar nada, porque los registros salen del pipeline por motivos de implementación, no de ventas.
• El pronóstico ponderado cuenta los ingresos comprometidos como si todavía se estuvieran ganando.
• La antigüedad por etapa, el informe que todos usan para encontrar oportunidades atascadas, se llena de registros que no están atascados, sino simplemente en implementación.

Además, impone un único conjunto de campos y un único responsable a dos equipos. El comercial conserva un registro sobre el que ya no actúa; el equipo de implementación hereda un formulario lleno de campos sobre competidores y aprobación de descuentos.

Hacer el seguimiento en la cuenta

Mejor instinto, pero la forma sigue siendo la equivocada. La cuenta es el cliente, y un cliente puede comprar más de una vez: un segundo proyecto, una venta adicional que necesita su propia configuración. El estado de implementación en la cuenta solo puede describir un encargo, así que el segundo sobrescribe el primero y el historial desaparece.

Una lista de tareas

Las tareas son la herramienta adecuada para los pasos y la equivocada para un ciclo de vida. Una lista de diez tareas no puede decirle en qué etapa está un proyecto, no se puede analizar como un embudo y no distingue entre que vaya con retraso un proyecto y que vaya con retraso una tarea.

03Modelo de datos: dos pipelines, una relación

La implementación tiene su propio pipeline, con sus propias etapas, su propio responsable y su propio conjunto de campos. La oportunidad de venta ganada se clona en él.

En Coevera, un tipo de oportunidad se corresponde uno a uno con un pipeline, así que un segundo pipeline implica necesariamente un segundo tipo, lo que aquí resulta práctico, porque es exactamente la separación que se busca: un registro de implementación es algo distinto de un registro de venta, con un formulario distinto.

Fuente. Centro de ayuda de Coevera, Adding another pipeline.

Las etapas describen la implementación, no la venta

La implantación en producción de la que procede este blueprint usa cuatro, y la forma es generalizable:

Fíjese en la primera etapa. Ganada y lista para empezar son hechos distintos, normalmente separados por una factura, y dar a ese intervalo su propia etapa es lo que impide que la cola del equipo de implementación se llene de trabajo que no puede empezar.

Clonar de forma condicional

No todas las oportunidades ganadas requieren implementación. El clon solo se dispara cuando la oportunidad contiene algo real que entregar: una configuración, una formación, una migración de datos, un bloque de horas de consultoría. Una simple renovación de licencia no genera ningún registro de implementación y nunca aparece en la cola de ese equipo.

Esta única condición marca la diferencia entre un pipeline de implementación en el que el equipo confía y uno que ignora porque está lleno de cosas que no son su trabajo.

Alternativas descartadas

• Una entidad personalizada para el proyecto en lugar de un segundo tipo de oportunidad. Es defendible, y le cuesta el pipeline: las etapas, la vista de embudo, la antigüedad por etapa y los informes de tipo pronóstico vienen de serie con una oportunidad y hay que reconstruirlos sobre una entidad personalizada. Elíjala solo si la implementación no tiene realmente una progresión por etapas; consulte Blueprint 003 para esa decisión.
• Mover el registro entre pipelines en lugar de clonarlo. Entonces el pipeline de ventas pierde la oportunidad que cerró, y los informes históricos de ventas cambian retroactivamente cada vez que se entrega algo.
• Un registro, dos campos de estado: un estado de venta y un estado de implementación en la misma oportunidad. Cada informe, vista y proceso tiene que saber entonces qué campo le interesa, y el pipeline sigue mostrando solo uno de ellos.

04Configuración a nivel de campo

El registro de implementación necesita un pequeño conjunto de campos que al registro de venta no le sirven de nada.

05Automatización y lógica

El clon, y un proceso por pipeline de origen

El clon se dispara cuando el estado de la oportunidad de venta pasa a ganada, filtrado a las oportunidades que contienen algo que entregar. Crea el registro de implementación en la primera etapa, copia los campos básicos, aplica las cantidades predeterminadas por servicio y envía al cliente una confirmación cuyo texto varía según lo que compró.

Las oportunidades pueden llegar desde más de un pipeline de ventas, normalmente el de nuevo negocio y el de ventas adicionales. El conjunto de automatizaciones en producción usa un proceso hermano por pipeline de origen en lugar de un único proceso con una condición compuesta. Supone un poco más de mantenimiento y merece la pena: cada uno se entiende por sí solo, cada uno puede desactivarse de forma independiente y ninguno acaba con una condición que nadie puede editar con seguridad.

Tratar la puesta en marcha como un despliegue en abanico, no como un único proceso

Cuando un proyecto se pone en marcha, deben ocurrir varias cosas sin relación entre sí. Escribirlas como un único proceso produce algo que nadie querrá tocar dentro de un año. Escribirlas como cuatro da cuatro piezas que pueden leerse, desactivarse y volver a ejecutarse de forma independiente:

El tercero es el que los equipos olvidan, y es el verdadero traspaso. Que el equipo de implementación termine no es el final de la historia: quien responda al primer ticket de soporte de este cliente necesita saber qué se implementó, y una notificación con el alcance es lo que evita que empiece de cero.

El cuarto se dispara deliberadamente al día siguiente y no el mismo día. El día de la puesta en marcha hay mucho movimiento, y un recordatorio de seguimiento funciona mejor cuando el cliente ya ha usado el sistema.

Bifurcar el plazo por tipo, no por costumbre

El mismo campo requiere una aritmética distinta según el tipo de encargo: un proyecto cuenta desde la puesta en marcha, mientras que un bloque de horas de consultoría cuenta desde que se vendió y caduca tanto si se ha usado como si no. Dos ramas en un proceso, gobernadas por el campo de tipo de implementación, es todo lo que hace falta, y así el plazo deja de ser algo que la gente tiene que acordarse de establecer.

06Límites y compromisos

Un clon es una instantánea, y nada reconcilia las copias

Este es el coste del diseño, y merece la pena pagarlo, pero hay que planificarlo. En el momento de clonar, los dos registros coinciden. Después, ambos siguen cambiando y ningún mecanismo de la plataforma los mantiene alineados.

La implantación en producción ejecuta trabajos de relleno en ambas direcciones:

• Un trabajo programado diario que rellena el enlace al portal del cliente en los registros de implementación abiertos a partir de la cuenta, para los registros creados antes de que la cuenta lo tuviera.
• Un trabajo manual que copia la fecha de puesta en marcha de la cuenta al proyecto, para el caso en que alguien la registró primero en la cuenta.

Ninguno es elegante. Ambos son necesarios. Escríbalos cuando escriba el clon: la alternativa es escribirlos deprisa la primera vez que alguien pregunte por qué dos registros no coinciden.

El clon se dispara por el estado, y puede que las líneas de producto aún no estén adjuntas

El disparador es que la oportunidad pase a ganada; las cantidades predeterminadas por servicio se leen de lo que contiene la oportunidad. Si el estado cambia antes de que las líneas de producto estén en el registro (un comercial optimista, una importación, una integración que escribe primero el estado), la rama de combinación de servicios ve una lista de productos vacía y los valores predeterminados quedan mal sin que nadie lo advierta. Ningún error, solo un registro de implementación sin nada planificado.

Mitigaciones, por orden de preferencia: disparar con una señal posterior que implique que los productos existen; o aceptarlo y dar al equipo de implementación una vista de los registros en los que todas las cantidades están vacías, que es un filtro de cinco minutos y detecta todos los casos.

No existe una conversión nativa en proyecto

La plataforma no tiene ninguna operación integrada para «convertir esta oportunidad ganada en un registro de implementación». Lo que aquí se describe se monta a partir de una automatización de creación de registros relacionados y de una correspondencia de campos que usted mantiene. Cuando el formulario de ventas incorpora un campo que el registro de implementación necesita, hay que indicárselo al clon: nada lo detecta por usted.

Los informes entre pipelines hay que montarlos

«Cuánto tiempo pasa de ganada a puesta en marcha, por combinación de servicios» abarca dos conjuntos de registros, y ninguno de los dos pipelines puede responderlo por sí solo. Es la contrapartida directa de tener métricas limpias por pipeline: obtiene informes de ventas fieles e informes de implementación fieles, y la pregunta que abarca ambos exige cruzar los dos conjuntos de registros. Copiar la fecha de puesta en marcha a la cuenta existe en parte para que la versión habitual de esa pregunta pueda responderse desde un solo lugar.

07Verificación

Todo lo descrito aquí falla en silencio, así que las comprobaciones buscan registros que deberían existir y no existen, más que errores.

• Gane una oportunidad con cada combinación de servicios y confirme que aparece un registro de implementación con las cantidades correctas. Que una combinación funcione no significa que la tabla de ramas sea correcta; los valores predeterminados dependen de cada combinación y cada combinación es una ruta distinta.
• Gane una oportunidad sin nada que entregar y confirme que no se crea nada. El clon condicional importa tanto por lo que hace como por lo que no hace.
• Consulte los registros de implementación con todas las cantidades vacías. Es la huella del riesgo de orden descrito en §6, y debería ser una vista guardada en lugar de una comprobación ocasional.
• Establezca una fecha de puesta en marcha y compruebe las cuatro consecuencias: la copia en la cuenta, ambos plazos derivados, la notificación a soporte y la tarea de seguimiento del día siguiente. Después cambie la fecha y compruebe que todo se actualiza. Volver a dispararse ante un cambio es donde esto suele fallar.
• Reconcilie las dos copias mediante una consulta: registros de implementación cuya fecha de puesta en marcha no coincide con la de su cuenta. No debería devolver nada. Cuando devuelve algo, el trabajo de relleno no se ha ejecutado o se está ejecutando en la dirección equivocada.
• Ejecute los gemelos manuales sobre un registro que ya es correcto y confirme que no cambia nada. Un proceso que puede volver a ejecutarse pero no es idempotente es peor herramienta de reparación que no tener ninguna.

Qué indicaría una regresión: una oportunidad ganada con algo que entregar y sin registro de implementación; registros de implementación cuya etapa no se ha movido en más tiempo del que dura una implementación típica, lo que indica un proyecto atascado o un proceso que ha dejado de dispararse; cualquier campo de fecha en el que un gran número de registros comparten un mismo valor, lo que significa que algo ha estampado «hoy» en todo un lote.

Blueprints relacionados

• Blueprint 003: la pregunta previa. Allí se decide si la implementación merece un pipeline, una entidad personalizada o nada.
• Blueprint 008: el mismo argumento sobre la higiene del pipeline, aplicado a las renovaciones: los registros que permanecen en un pipeline por motivos ajenos a la venta degradan todas las métricas que produce el pipeline.
• Blueprint 009: por qué una derivación que puede volver a ejecutarse es la herramienta de recuperación, y qué ocurre con la automatización que estampa fechas cuando se dispara tarde.