Software, agencia o equipo interno: quién paga el trabajo que no aparece en la propuesta

Una propuesta de agencia llega con una tarifa mensual. Una plataforma muestra el precio de la suscripción. La alternativa interna parece no añadir una factura. En una reunión hipotética, alguien coloca las tres cifras en una tabla y pregunta cuál resulta más barata. La comparación parece ordenada, pero todavía no describe quién entrevistará al experto, comprobará las afirmaciones, aprobará la pieza y atenderá lo que ocurra después de publicarla.

Para comparar software, agencia o equipo interno conviene seguir el trabajo completo, no solo el importe contratado. Comprar una herramienta, encargar un servicio y asignar una tarea a una persona son decisiones distintas: distribuyen de otra manera la ejecución, el conocimiento y la responsabilidad. Ninguna elimina por sí sola el tiempo necesario para decidir qué puede afirmar una organización ante su mercado.

Este artículo propone una ficha de decisión para líderes y equipos B2B. No ofrece precios de mercado, porcentajes de ahorro ni un ganador universal. Tampoco atribuye a Strateria funciones que no se hayan comprobado. La idea central es sencilla: compara el mismo resultado revisable y registra qué trabajo queda dentro de la organización bajo cada alternativa.

Antes del precio, escribe el encargo que estás comprando

«Necesitamos contenido» no basta para comparar ofertas. Puede significar publicar novedades, explicar una decisión compleja, convertir experiencia en una guía o abrir conversaciones con clientes. Cada propósito requiere materiales, participantes y revisiones diferentes. Si una propuesta cubre redacción y otra incluye investigación y seguimiento, comparar sus importes como si entregaran lo mismo produce una conclusión poco útil.

Define una pieza concreta: una explicación de un problema frecuente del comprador, con una tesis respaldada, una tabla que ayude a decidir y una adaptación para LinkedIn. Añade quién conoce el tema, quién valida las afirmaciones y qué información no puede compartirse. Después pregunta a las tres opciones cómo llevarían ese mismo encargo desde la conversación inicial hasta una versión aprobada.

El Service Manual del Gobierno británico recomienda que una fase de descubrimiento empiece por el problema y su contexto, en lugar de partir de una solución tecnológica decidida. También contempla detenerse o recurrir a otras formas de resolverlo. Es orientación para servicios públicos, no evidencia de que una modalidad editorial sea superior a otra; aquí la usamos para ordenar la pregunta previa a la compra. Fuente: https://www.gov.uk/service-manual/agile-delivery/how-the-discovery-phase-works

Software: la suscripción no asigna un responsable editorial

Una herramienta puede resultar conveniente cuando el equipo tiene criterio, materiales y una rutina, pero encuentra fricción al ejecutar tareas repetibles. La cuestión no es cuántos textos puede producir una demostración, sino qué parte del encargo permite terminar y cuánto trabajo necesita alrededor. Configurar contexto, aprender a revisar o resolver una integración también consume capacidad.

Durante una prueba, anota quién prepara la información inicial y quién corrige el resultado. Si un experto debe reescribir las afirmaciones centrales, ese tiempo forma parte del recorrido aunque no aparezca en el precio de la licencia. A la inversa, si una tarea se resuelve con menos intervención, conserva la evidencia y las condiciones de la prueba sin convertir una experiencia puntual en una promesa general de ahorro.

Cuando interviene IA, la revisión de hechos y límites merece una tarea explícita. El AI Risk Management Framework del NIST es voluntario y aborda la confiabilidad en el diseño, uso y evaluación de sistemas de IA. No certifica una plataforma ni demuestra un resultado comercial. Para esta comparación sirve como recordatorio de que evaluar una salida y gestionar sus riesgos son trabajo, no detalles que desaparecen al automatizar. Fuente: https://www.nist.gov/itl/ai-risk-management-framework

Agencia: entregar contexto también es parte del servicio

Una agencia puede aportar capacidad de ejecución, especialización y una mirada externa. Eso no significa que conozca de antemano los límites de la oferta o el criterio técnico de la empresa. Antes de contratar, aclara cómo obtiene esa información, quién la valida y qué ocurre cuando la persona experta no está disponible.

Una propuesta útil hace visibles los entregables, las rondas de revisión, las exclusiones y la forma de resolver desacuerdos. «Gestión integral» necesita desglosarse: ¿incluye responder comentarios, contrastar una fuente o coordinar la aprobación de un caso? No se trata de exigir que todo esté incluido, sino de evitar que cada parte espere que la otra asuma un trabajo sin dueño.

La guía británica Define your purchasing strategy pide considerar requisitos, capacidades internas, costo del ciclo de vida y distintas combinaciones de construir y comprar. Su contexto es la contratación tecnológica gubernamental, no el precio de los servicios creativos. La aplicación editorial que proponemos es limitada: revisar qué se compra, qué capacidades se mantienen y cómo continúa la operación cuando termina la relación. Fuente: https://www.gov.uk/guidance/define-your-purchasing-strategy

Equipo interno: una tarea asignada desplaza otras tareas

El trabajo interno puede facilitar el acceso a conocimiento, la proximidad con clientes y la continuidad de voz. También necesita capacidad disponible. Una persona que ya tiene otras responsabilidades no gana horas porque una línea del presupuesto diga «lo hacemos nosotros». Para evaluar esta opción, identifica qué actividad dejaría de hacer o qué prioridad tendría que cambiar.

Conviene distinguir desembolso adicional, tiempo de trabajo y costo de oportunidad. No son tres importes que deban sumarse siempre. Si ya incluiste el salario correspondiente a las horas dedicadas, añadir de nuevo ese mismo valor como oportunidad produce doble conteo. Puedes registrar el tiempo y la actividad desplazada por separado, y monetizar solo aquello que tenga una base explicable.

También importa la continuidad. Si una sola persona conserva las entrevistas, las claves y el criterio de publicación, una ausencia puede detener el flujo. Documentar decisiones y preparar un relevo requiere esfuerzo inicial; omitirlo no hace desaparecer la dependencia. Evalúa esa condición con el mismo cuidado que dedicarías a la salida de una agencia o al cambio de una plataforma.

La comparación empieza a ser justa cuando sigue todo el recorrido

La tabla siguiente es una herramienta de trabajo, no una escala validada. Las celdas no describen capacidades universales de cada modalidad. Indican preguntas que debes resolver con una muestra, una propuesta concreta o una conversación con el equipo.

Para cada fila, escribe responsable, tiempo observado o estimado, condición contractual y evidencia pendiente. No conviertas una estimación en tiempo medido. Tampoco registres una promesa del proveedor como una capacidad ya demostrada. Estas distinciones permiten comparar sin fabricar precisión donde todavía hay incertidumbre.

Calcula lo comparable y deja visibles los supuestos

Elige un período y una unidad comunes. Por ejemplo, un ciclo de trabajo con una pieza desarrollada y su adaptación social, bajo el mismo nivel de revisión. Es un ejemplo de diseño de prueba, no una recomendación de volumen. Mezclar una licencia mensual con un proyecto único y una dedicación interna indefinida impediría interpretar el resultado.

Puedes separar tres bloques: desembolso externo, dedicación interna necesaria y costos de transición. Incluye en el primero solo lo realmente contratado; en el segundo, tareas y horas sin ocultarlas detrás de «apoyo puntual»; en el tercero, formación, traslado de materiales y salida cuando correspondan. Si una partida no puede estimarse aún, márcala como pendiente y explica qué información falta.

El Technology Code of Practice relaciona necesidades de usuarios, integración, privacidad y estrategia de compra dentro del ciclo de vida tecnológico. No aporta una fórmula financiera para tu empresa. Su contribución a esta ficha es evitar que la evaluación se reduzca a una pantalla o a una tarifa sin considerar el entorno donde debe funcionar. Fuente: https://www.gov.uk/guidance/the-technology-code-of-practice

Prueba también cómo saldrías de la decisión

Pregunta qué conservarías si dentro de unos meses cambias de modalidad: textos editables, fuentes, imágenes con sus permisos, historial de decisiones y conexiones. Solicita un ejemplo de entrega o exportación cuando corresponda. Un archivo final puede ser suficiente para un encargo y claramente insuficiente para otro; la condición debe fijarse antes de construir la dependencia.

La orientación británica sobre dependencia técnica en la nube propone equilibrar el valor recibido con la portabilidad y considerar el costo y el tiempo de salida. No exige eliminar toda dependencia ni demuestra que la opción más portable sea siempre la mejor. Trasladado con cautela al trabajo editorial, sugiere una pregunta útil: ¿la dependencia que aceptamos tiene un beneficio identificable y una salida comprendida? Fuente: https://www.gov.uk/guidance/managing-technical-lock-in-in-the-cloud

La combinación de modalidades también puede tener sentido: criterio y aprobación internos, ejecución externa y una herramienta compartida para una tarea concreta. No la adoptes por parecer equilibrada. Comprueba que los traspasos no añadan una coordinación que nadie haya presupuestado y que cada participante sepa qué debe entregar.

Conclusión

Software, agencia y equipo interno distribuyen el trabajo de manera diferente. Para decidir, empieza por el mismo encargo, sigue preparación, producción, revisión y continuidad, y separa evidencia de estimaciones. La opción más conveniente será la que cubra tus condiciones con una dedicación y unos compromisos que puedas sostener, no necesariamente la que muestre la cifra inicial más baja. Antes de pedir otra propuesta, prueba una pieza y escribe quién asumió cada parte del recorrido. Para profundizar en la evaluación funcional, utiliza también las doce preguntas del artículo anterior: https://strateria.app/blog/elegir-herramienta-contenido-doce-preguntas

Referencias

• Gobierno del Reino Unido, How the discovery phase works: https://www.gov.uk/service-manual/agile-delivery/how-the-discovery-phase-works
• NIST, AI Risk Management Framework: https://www.nist.gov/itl/ai-risk-management-framework
• Gobierno del Reino Unido, Define your purchasing strategy: https://www.gov.uk/guidance/define-your-purchasing-strategy
• Gobierno del Reino Unido, The Technology Code of Practice: https://www.gov.uk/guidance/the-technology-code-of-practice
• Gobierno del Reino Unido, Managing technical lock-in in the cloud: https://www.gov.uk/guidance/managing-technical-lock-in-in-the-cloud