Un Statement of Work (SOW) mal definido es la causa principal de los conflictos en los proyectos de implementación de CRM. El cliente asume que cierta funcionalidad está incluida, el consultor asume que no lo está, y el resultado es un proyecto que se alarga, genera fricciones y termina con una relación deteriorada. Un SOW sólido protege a las dos partes desde el primer día.
Un Statement of Work es el documento que define exactamente qué está incluido en el proyecto, qué no está incluido, quién hace qué, en qué plazos y con qué criterios de aceptación. No es un contrato legal (aunque puede ser parte de uno), es un documento operativo que guía la ejecución del proyecto.
En proyectos de implementación de CRM, el SOW es especialmente crítico porque el alcance es difícil de visualizar antes de empezar. El cliente no sabe exactamente cuántas propiedades necesita, cuántos workflows van a configurarse o cuántas horas de formación requiere el equipo. Sin un SOW que defina los límites, esas decisiones se van tomando durante el proyecto sin un marco de referencia claro.
Una descripción clara y específica de qué se va a configurar: objetos y propiedades, pipeline de ventas, automatizaciones, integraciones, usuarios y permisos, y formación. Cada elemento debe estar listado con suficiente detalle para que no haya ambigüedad sobre si está incluido o no.
Ejemplo concreto: "Configuración de un pipeline de ventas con 6 etapas definidas en el workshop de diagnóstico, con criterios de entrada/salida por escrito y probabilidades asignadas. No incluye la configuración de un pipeline adicional para upsell o expansión."
Tan importante como definir qué está incluido es especificar qué no lo está. Las exclusiones más habituales en implementaciones de CRM: configuración de Customer Success, integraciones con sistemas no mencionados en el SOW, limpieza de datos adicional más allá del volumen acordado, formación de nuevos empleados después del go-live.
Cada fase del proyecto debe tener entregables concretos con criterios de aceptación verificables. No "pipeline configurado", sino "pipeline con X etapas, probabilidades asignadas y campos requeridos por etapa, validado por el manager de ventas". Sin criterios de aceptación, cualquier versión del entregable puede ser cuestionada.
Qué necesita aportar el cliente para que el proyecto avance: disponibilidad del owner del proyecto, acceso al CRM actual y sus datos, participación en los workshops de diagnóstico, validación de entregables en plazos acordados. Un proyecto de implementación de CRM requiere implicación activa del cliente; sin esa implicación, el proyecto se retrasa.
Un proceso claro para gestionar las solicitudes de cambio que inevitablemente aparecen durante el proyecto. Cómo se documentan, cómo se valoran (en tiempo y coste), cómo se aprueban y cómo se incorporan al proyecto. Sin este proceso, los cambios de alcance se acumulan informalmente y el proyecto termina costando el doble de lo acordado.
En implementaciones de CRM, el pago vinculado a hitos es más saludable que el pago mensual por tiempo. Los hitos típicos: inicio del proyecto (30%), aprobación del modelo de datos (20%), go-live (30%), revisión de adopción a 30 días (20%). Alinear el flujo de caja con los hitos de entrega crea los incentivos correctos para ambas partes.
En MomentumHUB entregamos un SOW detallado en cada propuesta de implementación, con alcance, exclusiones, entregables verificables y gestión de cambios incluida. Si quieres ver cómo estructuramos el alcance para tu caso, escríbenos aquí.
No exactamente. El contrato es el documento legal que regula la relación entre cliente y proveedor. El SOW es el anexo técnico que define el alcance del proyecto. En muchos casos, el SOW es un anexo del contrato. Lo importante es que estén alineados: el contrato no puede contradecir al SOW ni viceversa.
Suficiente para que cualquiera de las dos partes pueda responder a la pregunta "¿esto está incluido en el proyecto?" sin necesidad de preguntar al otro. Cada elemento de configuración debe estar listado. Cada integración que no está en la lista debe aparecer explícitamente en las exclusiones. El exceso de detalle es preferible a la ambigüedad.
Con el proceso de gestión de cambios documentado en el SOW. Cada solicitud de cambio se documenta, se valora en tiempo y coste, y se aprueba formalmente antes de ejecutarse. Es incómodo decirle a un cliente que una modificación tiene coste adicional, pero es mucho menos incómodo que terminar el proyecto con horas no facturadas y un cliente que espera todo lo que pidió sin pagar más.
Después del workshop de diagnóstico o discovery, no antes. Un SOW bien definido requiere entender en profundidad el proceso del cliente, sus datos actuales y sus necesidades reales. Un SOW genérico entregado como parte de la propuesta inicial sin diagnóstico previo suele ser impreciso y genera los conflictos que el SOW pretende evitar.