Statement of work en Estados Unidos: qué debe incluir para definir bien el servicio contratado

En Estados Unidos, el statement of work o SOW es un documento contractual que describe con precisión qué servicio se va a prestar, cómo se medirá su ejecución y bajo qué condiciones se considerará cumplido. Aunque no existe un formato único impuesto por una norma federal para todos los casos, el SOW suele formar parte de contratos de servicios, acuerdos con proveedores, consultorías, desarrollo tecnológico, outsourcing y proyectos por fases. Su función práctica es reducir ambigüedades: delimita el alcance, evita discusiones sobre entregables y facilita reclamar incumplimientos cuando el servicio no se ajusta a lo pactado.

En el marco legal estadounidense, el SOW no es necesariamente un contrato independiente. Con frecuencia actúa como anexo, apéndice o documento incorporado por referencia dentro de un acuerdo marco, como un Master Services Agreement (MSA). Su fuerza obligatoria depende de cómo esté integrado en el conjunto contractual, de la firma o aceptación de las partes y de las reglas aplicables sobre formación de contratos, prueba documental y, en ciertos sectores, sobre firmas electrónicas y transacciones electrónicas. Si el lenguaje del SOW es claro y coherente con el resto del contrato, suele ser una herramienta decisiva para determinar si hubo cumplimiento o incumplimiento.

Qué es jurídicamente un statement of work

Un SOW es una descripción operativa del servicio contratado. Su objetivo no es solo decir “qué trabajo se hará”, sino definir qué incluye y qué no incluye, con qué estándares, en qué secuencia y con qué criterios de aceptación. En litigios o arbitrajes comerciales, ese detalle puede ser determinante para resolver disputas sobre alcance, retrasos, calidad del trabajo o pagos condicionados.

En la práctica estadounidense, el SOW puede cumplir funciones distintas según la relación contractual:

• Especificación del servicio dentro de un contrato principal.
• Documento de proyecto que concreta una fase, una tarea o un entregable.
• Anexo operativo para adaptar condiciones generales a un encargo concreto.
• Referencia para facturación, hitos, aceptación y penalizaciones contractuales.

La importancia jurídica del SOW aumenta cuando el contrato principal contiene cláusulas generales y el detalle real del trabajo queda en el anexo. En ese escenario, cualquier contradicción entre ambos documentos debe resolverse con reglas de interpretación contractual, lo que puede variar según la ley estatal aplicable y la redacción de cláusulas de prelación o jerarquía documental.

Cuándo se usa habitualmente en Estados Unidos

El SOW se utiliza sobre todo en relaciones B2B, donde el servicio depende de una definición técnica o comercial precisa. Es frecuente en tecnología, marketing, ingeniería, consultoría, construcción especializada, recursos humanos externalizados, servicios profesionales y proyectos creativos.

En algunos sectores, el SOW se integra en un esquema más amplio con otros documentos contractuales:

• MSA: fija términos jurídicos generales como responsabilidad, confidencialidad, indemnización, propiedad intelectual y resolución de disputas.
• SOW: define el trabajo específico de cada proyecto o pedido.
• Change order o modificación: ajusta alcance, precio o plazo cuando el proyecto cambia.

También puede aparecer en contratos públicos o con entidades reguladas, aunque en esos casos la documentación y el procedimiento pueden estar condicionados por reglas específicas de contratación pública, normativas sectoriales o requisitos internos de la entidad contratante.

Qué debe incluir para definir bien el servicio contratado

Un SOW útil en Estados Unidos no se limita a una descripción genérica del encargo. Debe permitir que un tercero entienda qué se espera exactamente de cada parte. Cuanto más técnico o complejo sea el servicio, más importante resulta la precisión.

1. Identificación de las partes y del proyecto

El documento debe indicar quién presta el servicio, quién lo contrata y a qué proyecto concreto se refiere. Conviene incluir nombres legales completos, y si el SOW se integra en un contrato principal, la referencia exacta a ese contrato o al número de pedido, propuesta o orden de trabajo asociada.

2. Objeto y alcance del trabajo

El scope of work es el núcleo del documento. Debe describir:

• qué tareas se realizarán;
• qué actividades quedan excluidas;
• qué supuestos o dependencias existen;
• si el servicio incluye solo ejecución, también asesoramiento, soporte o mantenimiento;
• si el proveedor responde por resultados concretos o solo por medios razonables.

Las exclusiones son tan importantes como las inclusiones. Muchos conflictos nacen porque una parte entiende que una tarea estaba implícita y la otra considera que era trabajo adicional.

3. Entregables y criterios de aceptación

El SOW debe identificar los entregables con detalle suficiente: informes, código, diseños, campañas, planos, análisis, implementaciones, sesiones de formación o cualquier otro resultado tangible o verificable.

También es recomendable fijar criterios de aceptación. Sin esa referencia, la discusión suele centrarse en apreciaciones subjetivas. Un buen SOW puede indicar, por ejemplo:

• qué características mínimas debe tener el entregable;
• qué pruebas o validaciones se usarán;
• quién revisa y acepta;
• qué ocurre si el cliente no responde en determinado plazo, si las partes lo pactan;
• cómo se corrigen defectos o no conformidades.

4. Plazos, hitos y calendario

El documento debe fijar fechas o una cronología razonable para inicio, hitos intermedios y entrega final. En Estados Unidos, los tribunales suelen atender al texto pactado para valorar si un retraso constituye incumplimiento, pero el efecto de una fecha puede depender de si la cláusula se redactó como condición esencial, plazo orientativo o simple estimación comercial.

Cuando el proyecto depende del cliente, conviene reflejar las entregas o aprobaciones necesarias por su parte. Si el retraso del cliente impide avanzar, esa circunstancia puede afectar a la responsabilidad del proveedor, siempre que el contrato lo contemple con claridad.

5. Precio, método de facturación y gastos

El SOW debe explicar cómo se pagará el servicio:

• precio fijo;
• tarifa por hora o por día;
• pagos por hitos;
• retainer;
• modelo mixto.

conviene detallar qué gastos reembolsables existen, si hay límites, si requieren autorización previa y qué documentación se exige para su reembolso. La claridad en este punto evita disputas sobre viajes, software, materiales o subcontrataciones.

6. Responsabilidades de cada parte

Un SOW bien redactado asigna obligaciones concretas. El proveedor suele asumir tareas técnicas o de ejecución, mientras que el cliente puede tener deberes de colaboración: facilitar información, acceso a sistemas, validaciones, contenido, aprobaciones o personal de contacto.

La distribución de responsabilidades importa porque en muchos conflictos el problema no es la ejecución en sí, sino la falta de insumos o decisiones por parte del cliente. Si el SOW no define esas obligaciones, resulta más difícil atribuir causas del retraso o del incumplimiento.

7. Supuestos fuera de alcance y gestión de cambios

Los proyectos cambian con frecuencia. Por eso, el SOW debería reservar un mecanismo para change requests, órdenes de cambio o adendas. Ese mecanismo debe explicar quién puede solicitar cambios, cómo se aprueban y qué efecto tienen sobre precio, plazo y entregables.

También es útil enumerar expresamente lo que no está incluido: soporte fuera de horario, integraciones adicionales, iteraciones ilimitadas, migraciones, licencias, formación extra o mantenimiento posterior. Sin esa delimitación, un cliente puede considerar que el servicio incluía más de lo que el proveedor entendía.

8. Estándares de calidad y nivel de servicio

Cuando el SOW se usa en servicios continuados, puede incorporar estándares de desempeño o service levels. Por ejemplo, tiempos de respuesta, disponibilidad, tiempos de corrección o métricas de entrega. Estos parámetros deben ser realistas, medibles y coherentes con el resto del contrato.

Si no hay una definición objetiva de calidad, la controversia se desplaza a conceptos amplios como “razonable”, “profesional” o “satisfactorio”, que pueden ser suficientes en algunos contextos, pero suelen generar más discusión probatoria.

9. Propiedad intelectual y uso de materiales

En Estados Unidos, la titularidad y la licencia sobre resultados del trabajo deben tratarse con especial cuidado, sobre todo en software, contenidos, diseño y consultoría técnica. El SOW puede remitirse al contrato principal, pero si el proyecto genera obras, código o materiales originales, conviene indicar si se ceden derechos, si se concede una licencia limitada o si hay componentes preexistentes del proveedor.

También es útil distinguir entre:

• materiales del cliente;
• materiales preexistentes del proveedor;
• trabajos desarrollados específicamente para el proyecto.

10. Confidencialidad, datos y seguridad

El SOW puede reforzar obligaciones de confidencialidad, tratamiento de datos o medidas de seguridad, especialmente cuando el proveedor accede a información sensible, datos personales o sistemas internos. El nivel de detalle debe ajustarse al tipo de servicio y a la ley aplicable, que puede variar según el estado, el sector y la naturaleza de los datos.

Si el trabajo implica tratamiento de datos de consumidores, empleados o usuarios, puede ser necesario coordinar el SOW con el contrato principal y con anexos específicos de privacidad o seguridad. No conviene asumir que una cláusula genérica basta para cubrir obligaciones regulatorias que dependen del contexto.

Elementos especialmente sensibles por el derecho estadounidense

Al redactar un SOW en Estados Unidos, hay varias cuestiones que suelen generar litigios o interpretaciones discutidas:

• Merger o integración contractual: si el SOW se integra en el contrato completo o si es solo una referencia preliminar.
• Orden de prelación: qué documento prevalece si el SOW contradice el MSA o una orden de compra.
• Firmas y aceptación electrónica: la validez puede depender de la ley aplicable y del modo de aceptación, aunque en general las firmas electrónicas pueden ser válidas bajo normas federales y estatales.
• Autoridad para obligar a la empresa: la persona que firma o aprueba debe tener facultades suficientes, sobre todo en organizaciones grandes.
• Relación entre obligaciones de medios y de resultado: si el texto promete un resultado específico, el nivel de exigencia contractual puede subir de forma relevante.

Cuando el SOW se usa como documento operativo y no como contrato autónomo, es importante revisar si el contrato principal exige que toda modificación se haga por escrito y con firma. Si no se sigue ese procedimiento, puede discutirse la validez de cambios informales por correo, mensajería o conductas de ejecución, dependiendo de la ley aplicable y de la conducta de las partes.

Diferencias con otras figuras parecidas

Problemas frecuentes en la práctica

Un SOW mal redactado suele fallar en los mismos puntos: demasiada vaguedad, ausencia de entregables medibles, falta de coordinación con el contrato principal y falta de mecanismo para cambios. En servicios técnicos, además, aparece el problema de redactar el texto con lenguaje empresarial cuando en realidad se necesitan parámetros operativos concretos.

Las disputas más comunes suelen girar en torno a:

• si una tarea estaba o no incluida en el alcance;
• si el trabajo entregado cumplía el estándar pactado;
• si el retraso se debió al proveedor o a la falta de cooperación del cliente;
• si un cambio verbal o por correo obligó a ampliar el servicio;
• si procede cobrar por trabajo adicional no previsto;
• si el rechazo de un entregable fue justificado.

En litigios estadounidenses, la prueba documental pesa mucho. Un SOW con lenguaje concreto, versiones controladas, referencias internas claras y aprobación inequívoca suele ofrecer una base mucho más sólida que correos dispersos o descripciones comerciales genéricas.

Cláusulas y datos que conviene revisar antes de firmar

La revisión previa del SOW no debe centrarse solo en el texto técnico. También importa la coherencia jurídica y económica del conjunto contractual. Conviene verificar:

• si el SOW identifica correctamente el contrato principal;
• si hay contradicciones entre anexos;
• si los hitos de pago dependen de aceptación expresa o tácita;
• si se prevén limitaciones de responsabilidad o exclusiones específicas;
• si el cambio de alcance exige aprobación escrita;
• si el texto distingue entre horas estimadas y obligación de resultado;
• si los derechos sobre el trabajo final están regulados;
• si existen dependencias del cliente que puedan retrasar el proyecto.

Ejemplo de estructura funcional de un SOW

Una organización habitual del documento puede incluir: identificación de partes, descripción del proyecto, alcance, exclusiones, entregables, cronograma, responsabilidades, criterios de aceptación, precio, facturación, cambios, propiedad intelectual, confidencialidad y firmas. No existe un único orden obligatorio, pero la secuencia debe facilitar una lectura rápida y evitar saltos lógicos.

En proyectos complejos, puede ser útil añadir anexos técnicos, tablas de entregables o matrices de responsabilidades. Si se usan, deben estar coordinados con el cuerpo del SOW para que no generen contradicciones internas.

Cuándo conviene apoyo legal especializado

En Estados Unidos, un SOW puede parecer un documento operativo sencillo, pero sus efectos económicos y probatorios son relevantes. Conviene una revisión jurídica cuando el servicio es de alto valor, hay propiedad intelectual involucrada, se manejan datos sensibles, existen penalizaciones por retraso, se pactan niveles de servicio exigentes o el contrato se va a usar en varios estados con leyes potencialmente distintas.

También resulta especialmente recomendable cuando el SOW se firma junto con un MSA, una orden de compra y varias enmiendas, porque el mayor riesgo no suele estar en un único párrafo, sino en la falta de coordinación entre documentos que deben funcionar como un conjunto coherente.