La implementación es el trabajo técnico de hacer que el producto corra en el entorno del cliente; el onboarding es el journey de valor que lleva al cliente de “el producto corre” a “no podemos vivir sin él”. Se solapan en el tiempo y la gente los confunde constantemente, pero responden preguntas distintas, los poseen roles distintos y fallan de maneras distintas. La implementación pregunta “¿está configurado, integrado y en vivo?” El onboarding pregunta “¿alcanzó el cliente el outcome que compró?” Un deal puede estar totalmente implementado y ser un fracaso total de onboarding — esa brecha es exactamente de donde viene el churn de la primera renovación.
La distinción, con precisión
- Implementación es acotada, técnica y tiene un estado de terminado binario. Aprovisionar la instancia, conectar las fuentes de datos, cablear las integraciones (SSO, sync de CRM, webhooks), migrar datos legacy, configurar el workspace y probar que un workflow real corre de punta a punta. El éxito es observable y objetivo: la plomería funciona. Es un proyecto con un scope, un statement of work y un test de aceptación.
- Onboarding es abierto, dirigido por outcomes y tiene un estado de terminado difuso. Abarca la implementación pero no termina cuando la plomería funciona — termina cuando el cliente alcanzó personalmente el outcome que compró (time-to-first-value) y ese uso se expandió más allá del champion hacia la adopción habitual del equipo. El éxito es que el cliente diga “esto valió la pena”, instrumentado como un hito de valor real.
Dicho de otro modo: la implementación es un subconjunto del onboarding en el tiempo, no un sinónimo. La implementación es una etapa dentro del journey de onboarding — la etapa de setup. Tratar “implementación completa” como “onboarding completo” es la manera más común de reportar una victoria vacía y luego perder la cuenta en la renovación.
Quién es dueño de cada uno
La división de propiedad es el punto entero de separar los dos conceptos. Confundirlos significa que un rol recibe un trabajo para el que no está equipado.
| Dimensión | Implementación | Onboarding |
|---|---|---|
| Dueño principal | Especialista de implementación / solutions engineer / professional services | CSM (o especialista de onboarding) |
| Skill set | Técnico: APIs, migración de datos, integraciones, config | Relación + outcome: success planning, adopción, alineación ejecutiva |
| Estado de terminado | Binario — el workflow corre de punta a punta | Outcome — primer valor alcanzado, adopción habitual |
| Se mide por | Entrega a tiempo y en scope; resolución de tickets | Time-to-value (TTV), salida de Etapa 3, uso activo semanal |
| Horizonte de tiempo | Días a semanas (proyecto acotado) | Semanas a un trimestre (hasta que la cuenta gradúa a CS continuo) |
En empresas chicas una persona usa ambos sombreros — pero los roles siguen siendo distintos incluso cuando el headcount es uno, y el trabajo debe trackearse como dos workstreams. En mid-market y enterprise se separan: un equipo de professional services o de implementación posee el proyecto técnico, y el CSM posee el journey de valor envuelto a su alrededor. El CSM sigue siendo responsable del outcome todo el tiempo, incluso durante la implementación, porque al cliente no le importa en qué parte del organigrama vive el retraso.
Dónde le entrega uno al otro
La entrega de la implementación al onboarding es la costura de mayor riesgo en el ciclo de vida del cliente, y es donde el contexto se evapora. El equipo de implementación termina el proyecto técnico, marca el ticket como cerrado y pasa a la siguiente cuenta — y el CSM hereda un producto configurado sin registro de lo que el cliente realmente quería lograr. Entonces el cliente le re-explica sus metas a una persona nueva mientras el reloj de valor sigue corriendo.
Haz la entrega explícita, no implícita:
- Lleva el success plan hacia adelante por escrito. El success plan mutuo acordado en el kickoff — la propia definición de éxito del cliente y el sponsor ejecutivo nombrado — es el artefacto que sobrevive la entrega. Implementación lo lee al entrar; el CSM lo posee al salir.
- Define el trigger de la entrega como una puerta de valor, no una puerta de config. La entrega no es “config terminada” — es “config terminada Y un workflow real corrió de punta a punta con los propios datos del cliente”, para que el CSM herede algo sobre lo que el cliente realmente pueda construir valor, no una cáscara vacía.
- Corre una transición conjunta, no un fire-and-forget. Un solapamiento corto donde implementación y el CSM están ambos en una llamada con el cliente previene el reinicio en frío. El CSM escucha el contexto técnico de primera mano; el cliente nunca se repite.
Existen tools para hacer esta costura visible para ambos lados. Rocketlane corre el proyecto de implementación con un plan de cara al cliente y trackea la puerta de aceptación; Arrows y Dock mantienen el plan de onboarding compartido y los criterios de éxito visibles a través de la entrega; una plataforma de CS como Gainsight instrumenta las salidas de etapa y dispara una alerta de health-score cuando una cuenta se estanca entre “implementada” y “adoptada”.
Errores comunes
- Dar la cuenta por terminada en la implementación. La plomería funciona, el ticket se cierra y nadie confirma el primer valor. Guarda: el criterio de salida del programa es el outcome declarado por el cliente (Etapa 3 del onboarding), nunca el test de aceptación de la implementación.
- Sin dueño nombrado durante la costura. Implementación ya entregó y el CSM no levantó, así que la cuenta queda sin dueño por una semana. Guarda: un único dueño responsable en cada momento, con la fecha de entrega y el dueño por escrito, no asumidos.
- El scope creep de la implementación se come el reloj de valor. Una integración custom larga empuja el primer valor semanas hacia adelante mientras todos reportan el proyecto como “on track”. Guarda: trackea el time-to-value como una métrica separada que corre durante la implementación, para que una integración que se atrasa aparezca como una violación de TTV, no como un estatus verde del proyecto.
- Forzar el modelo sobre puro self-serve. Un producto PLG sin setup de toque humano no tiene equipo de implementación del cual entregar. Guarda: colapsa la implementación en la activación in-product e instrumenta el TTV con product analytics — no hay costura que manejar porque no hay entrega.
Relacionados
- Customer onboarding — el journey completo de cuatro etapas dentro del cual vive la implementación
- Time to value — la métrica que corre a través de ambos
- Customer health score — donde una entrega estancada aparece primero
- Rocketlane — gestión del proyecto de implementación