--- title: "¿Cómo entrega una oportunidad ganada al equipo que la ejecuta?" blueprint: 010 slug: handover-from-sales-to-delivery category: Traspaso published: 2026-09-23 revised: 2026-09-23 platform: Coevera CRM (formerly Pipeliner CRM) canonical: https://blueprints.coevera.com/es/blueprints/handover-from-sales-to-delivery/ language: es translation_of: https://blueprints.coevera.com/blueprints/handover-from-sales-to-delivery/ author: Lucia Schmidt publisher: Coevera customer_data: none --- # ¿Cómo entrega una oportunidad ganada al equipo que la ejecuta? **Respuesta corta.** Dé a la implementación **su propio pipeline** y clone en él la oportunidad ganada. No añada etapas de implementación al final del pipeline de ventas: un registro que recorre dos ciclos de vida corrompe a la vez la tasa de conversión, el ciclo de venta y el pronóstico ponderado. Clone **de forma condicional**, según si la oportunidad contiene realmente algo que entregar, y establezca en el nuevo registro valores predeterminados por servicio a partir de lo vendido. Después, trate la fecha de puesta en marcha como un único cambio de campo que se **despliega en abanico**: hacia la cuenta, hacia los plazos derivados y hacia fuera, como traspaso a soporte. Lo que todo el mundo descubre tarde: un clon es una **instantánea**, los dos registros se desvían y nada los reconcilia. Escriba los trabajos de relleno al mismo tiempo que el clon. ## 01 · El 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. ## 02 · Por 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. ## 03 · Modelo 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](https://help.coevera.com/en/articles/2723998-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: | Etapa | Qué significa | Condición de salida | |---|---|---| | A la espera del pago / presentación | Ganada, aún sin empezar | Pago recibido y reunión de presentación celebrada | | Configuración en curso | El reloj de la implementación está en marcha | Configuración completada | | Formación de usuarios — sistema en marcha | El cliente lo está usando | Formación impartida | | Servicios entregados | Terminado | — | 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](https://blueprints.coevera.com/es/blueprints/where-should-this-data-live/) 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. ## 04 · Configuració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. | Finalidad | Tipo | Lo establece | Notas | |---|---|---|---| | Tipo de implementación | Desplegable | Clon / manual | Bifurca las reglas de plazos; véase §5. Un proyecto y un bloque de horas de consultoría se comportan de forma distinta. | | Cantidades por servicio (configuración, formación, datos, formación de administradores) | Numérico | **Clon, a partir de la combinación de productos** | Valores predeterminados por combinación de servicios, para que el registro llegue rellenado en lugar de vacío. | | Fecha de inicio del proyecto | Fecha | Proceso, al iniciarse | No es la fecha en que se ganó. El reloj de la implementación arranca cuando empieza el trabajo. | | Fecha de puesta en marcha | Fecha | Manual | El único campo que se despliega en abanico. Véase §5. | | Fecha de fin del onboarding | Fecha | Proceso, derivada | Calculada a partir de la puesta en marcha. | | La formación debe completarse antes de | Fecha | Proceso, derivada | Calculada a partir de la puesta en marcha *o* de la creación del registro, según el tipo de implementación. | | Enlace al portal del cliente / a la suscripción | URL | Clon, más un trabajo de relleno | A menudo vacío en el momento de clonar. Véase §6. | | Fecha de puesta en marcha *en la cuenta* | Fecha | Proceso, desde el registro del proyecto | Para que la automatización a nivel de cuenta pueda verla sin recorrer la relación hasta el proyecto. | > **Por qué la cuenta lleva su propia copia de la fecha de puesta en marcha.** Es una duplicación, > y es deliberada. La automatización del lado de la cuenta (cadencias de éxito del cliente, > comprobaciones de salud, cualquier cosa programada) necesita filtrar por «este cliente está en > marcha y desde cuándo» sin tener que acceder a un registro relacionado. Los campos calculados > del espacio examinado solo hacen referencia a campos de su propia entidad; no se verificó si uno > puede leer un campo de un registro relacionado, así que no conviene depender de un campo > derivado en la cuenta para obtener la fecha del proyecto. Copiarla en el momento adecuado es el > mecanismo que la pone a disposición. ## 05 · Automatizació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: | Proceso | Disparador | Qué hace | |---|---|---| | La asignación canónica | Cambia la fecha de puesta en marcha | Copia la fecha a la cuenta; calcula la fecha de fin del onboarding | | Derivación de plazos | Cambia la fecha de puesta en marcha | Establece el plazo de formación, con una bifurcación según el tipo de implementación | | Traspaso a soporte | La etapa pasa a *sistema en marcha* | Notifica a soporte las licencias, el nivel y el alcance de la implementación | | Cierre del círculo | Programado, el día después de la puesta en marcha | Avisa al responsable y crea una tarea de seguimiento | 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. > **Cada asignación automática necesita un gemelo manual que pueda volver a ejecutarse.** El > conjunto de automatizaciones en producción empareja la asignación de la puesta en marcha con un > proceso de disparo manual que contiene una lógica idéntica. > > El motivo es estructural, no defensivo: un proceso que se dispara ante un cambio no se puede > repetir. Las fechas de puesta en marcha cambian, los registros se crean en desorden, una > automatización se desactiva durante una tarde. Sin un gemelo manual, la única reparación es > editar los campos a mano y confiar en no haberse olvidado de ninguno. El mismo razonamiento > aparece en [Blueprint > 009](https://blueprints.coevera.com/es/blueprints/automating-on-integration-owned-fields/), > donde una derivación que puede volver a ejecutarse es la herramienta de recuperación para toda > una clase de fallos. ## 06 · Lí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. ## 07 · Verificació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](https://blueprints.coevera.com/es/blueprints/where-should-this-data-live/): la pregunta previa. Allí se decide si la implementación merece un pipeline, una entidad personalizada o nada. - [Blueprint 008](https://blueprints.coevera.com/es/blueprints/forecasting-renewals-before-they-exist/): 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](https://blueprints.coevera.com/es/blueprints/automating-on-integration-owned-fields/): 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. ## Preguntas frecuentes ### ¿Cómo se entrega una oportunidad ganada del CRM a un equipo de implementación o de onboarding? Dé a la implementación su propio pipeline y clone en él la oportunidad ganada, en lugar de añadir etapas de implementación al final del pipeline de ventas. Ambos tienen responsables distintos, etapas distintas, campos distintos y definiciones distintas de lo que significa terminar, y un pipeline de ventas que continúa durante meses después de cerrarse la oportunidad no informa de nada útil: la tasa de conversión, el ciclo de venta y la antigüedad por etapa miden lo que no deben. Clone de forma condicional, según si la oportunidad contiene realmente algo que entregar, para que las oportunidades que no requieren implementación no aparezcan en la cola del equipo de implementación. Establezca en el clon valores predeterminados por servicio a partir de lo vendido. Asuma que un clon es una instantánea que se irá desviando de su origen y construya los trabajos de relleno que lo reconcilien. ### ¿La implementación debe ser un conjunto de etapas adicionales en el pipeline de ventas o un pipeline aparte? Un pipeline aparte. Las etapas adicionales mantienen un único registro recorriendo dos ciclos de vida, lo que corrompe todas las métricas del pipeline: una oportunidad cerrada en marzo que se pone en marcha en julio muestra un ciclo de venta de cuatro meses, y el pronóstico ponderado cuenta los ingresos comprometidos como si todavía se estuvieran ganando. Además, impone un único conjunto de campos y un único responsable a dos equipos cuyo trabajo apenas tiene nada en común. En Coevera, un tipo de oportunidad se corresponde uno a uno con un pipeline, así que un segundo pipeline significa un segundo tipo, y los dos registros están relacionados en lugar de ser idénticos. ### ¿Qué debe ocurrir en el CRM cuando un proyecto se pone en marcha? Trate la fecha de puesta en marcha como un único cambio de campo que se despliega en abanico, y escriba cada consecuencia como un proceso propio en lugar de uno grande. En una implantación en producción se disparan cuatro cosas a partir de ella: la fecha se copia del registro del proyecto a la cuenta del cliente para que la automatización a nivel de cuenta pueda verla; a partir de ella se calculan dos plazos derivados, con una bifurcación según el tipo de implementación; se notifica al equipo de soporte el alcance de la implementación, que es el verdadero traspaso desde implementación; y un día después un proceso programado del lado de la cuenta avisa al responsable y crea una tarea de seguimiento, lo que cierra el círculo de vuelta a éxito del cliente. Cada uno puede volver a ejecutarse por separado, algo importante porque las fechas de puesta en marcha cambian. ### ¿Por qué los registros clonados en el CRM necesitan trabajos de relleno? Porque un clon es una instantánea tomada en un momento dado, y ambas copias siguen cambiando después. Nada en la plataforma las reconcilia. La implantación en producción de la que procede este blueprint ejecuta dos trabajos de este tipo: uno diario que rellena un campo de enlace en los registros de implementación abiertos a partir de la cuenta cuando estaba vacío en el momento de clonar, y uno manual que copia la fecha de puesta en marcha en la dirección opuesta para los registros en los que la cuenta la tiene y el proyecto no. Ninguno es elegante y ambos son necesarios. Escríbalos cuando escriba el clon, no después de la primera vez que alguien pregunte por qué dos registros no coinciden. --- Publicado por Coevera. Abstraído al patrón reutilizable: sin nombres de clientes, sin datos de clientes, sin datos personales.