Comprador técnico y comprador económico: qué declaran quienes evalúan software

La diferencia está en el trabajo que desempeña cada persona durante una compra. El comprador técnico evalúa cómo funciona un producto y si se ajusta a las necesidades de la organización. En el marco MEDDICC, el comprador económico tiene la autoridad general sobre la decisión de compra. Son cuestiones que conviene aclarar, pero el cargo de una persona no basta para responderlas. ^[3][4]

Nuestro estudio utiliza una medida más concreta y directamente observable: las responsabilidades que las personas seleccionaron en una encuesta. Los participantes podían indicar varias funciones en la elección o el uso de software en su organización. Nos centramos en quienes seleccionaron la evaluación, recomendación o preselección y comprobamos si también seleccionaron la decisión final de compra y la aprobación o gestión del presupuesto. ^[5]

Estas opciones de la encuesta no equivalen a las categorías de los marcos de ventas. Quien evalúa una herramienta no tiene por qué ser especialista técnico. Quien gestiona su presupuesto no tiene por qué tener la autoridad general para comprarla. Seleccionar responsabilidades de decisión y de presupuesto tampoco demuestra que ambas se ejerzan sobre la misma herramienta.

Esta distinción ayuda a formular una pregunta útil. Si un posible cliente pide una comparación técnica, el equipo de marketing sabe que necesita información. La siguiente conversación puede aclarar qué evalúa, qué puede decidir y quién más necesita esa información.

Entre los 9664 participantes que seleccionaron la evaluación, recomendación o preselección en la encuesta internacional y voluntaria de Stack Overflow de 2026, 7505 no seleccionaron ni la decisión final ni la aprobación o gestión del presupuesto. Representan el 77,7 % de este grupo de evaluadores. Es la mayor de las cuatro categorías de la tabla. ^[1]

Las demás categorías muestran el solapamiento que se perdería al separar simplemente a evaluadores y compradores. En total, 1041 evaluadores seleccionaron ambas responsabilidades; 744, la decisión final sin la opción de presupuesto; y 374, la opción de presupuesto sin la decisión final. Sus proporciones fueron del 10,8 %, 7,7 % y 3,9 %, respectivamente.

Cada evaluador figura en una sola categoría. Los porcentajes describen al mismo grupo de participantes y se pueden interpretar conjuntamente. Los valores redondeados suman el 100,1 %; los recuentos originales suman exactamente 9664.

Conviene interpretar con cuidado «ninguna de las dos opciones seleccionada». Solo indica las dos opciones que una persona no marcó. No verifica que carezca de autoridad, que no tenga influencia o que no pueda presentar a otra persona. La encuesta tampoco identificó una compra concreta cuyos participantes pudiéramos reconstruir.

Mantén la pregunta del evaluador en el centro de la primera respuesta. Si necesita entender una integración, explica qué conexión está disponible, qué configuración exige y qué limitaciones relevantes tiene. Puede que más adelante necesite una justificación de negocio, pero esta no resuelve una duda de compatibilidad pendiente.

Después, pregunta para qué se utilizará esa información. ¿Le servirá para probar el producto, recomendar una lista de opciones, preparar una conversación sobre presupuesto o tomar una decisión? Puede haber más de una respuesta. El solapamiento observado en la encuesta es una razón para contemplarlo en el briefing.

Para un creador que explica software empresarial, esto cambia el encargo. Una demostración puede responder a una duda concreta de evaluación y ofrecer una referencia que los espectadores puedan compartir. El briefing debe indicar qué permite comprobar la demostración y dónde consultar la información del producto. No debe pedir al creador que dé a entender que el espectador tiene autoridad de compra o que ya se ha cerrado una venta.

En una agencia, esta distinción debe acompañar el traspaso de información de contenidos a ventas. Anota qué preguntó el contacto y qué información recibió. Mantén aparte sus respuestas sobre presupuesto o aprobación final, incluida la aclaración de si se refieren a esta compra. Así, la siguiente persona entenderá la situación sin convertir una interacción con un contenido en una clasificación de comprador no verificada.

Para el equipo de marketing, una conclusión práctica es recoger por separado las responsabilidades declaradas de evaluación, presupuesto y decisión. Así se conserva lo que el contacto realmente ha dicho y queda a la vista la siguiente pregunta pendiente.

Utiliza estas preguntas para una compra concreta. Deja una respuesta en blanco si todavía no se conoce. Un espacio vacío hace visible la duda; rellenarlo a partir de un cargo supuesto la ocultaría.

Compra prevista: ¿Qué herramienta, plan o cambio se está considerando? Indica el uso propuesto y el equipo que lo utilizaría. Anota si se trata de una compra nueva, una sustitución o una ampliación.

Tarea de evaluación: ¿Qué necesita comprobar el contacto? Escribe la pregunta con sus palabras, por ejemplo, si una conexión permite realizar el flujo de trabajo que necesita. Anota qué sería una respuesta satisfactoria y quién puede verificar ese detalle del producto.

Información que hay que aportar: ¿Qué demostración, especificación, ejemplo o referencia responde a esa pregunta? Indica quién se encarga de ella y cuándo se comprobó. Distingue una función disponible de una capacidad prevista o un ejemplo ilustrativo.

Responsabilidad presupuestaria: ¿El contacto aprueba el presupuesto, lo gestiona, prepara una solicitud o tiene otra función? Pregunta por la compra prevista en concreto. Anota las dudas pendientes en vez de agrupar tareas diferentes bajo una única etiqueta de responsable del presupuesto.

Decisión final: ¿Quién puede aprobar esta compra y qué falta para tomar la decisión? Si el contacto describe a personas distintas, diferencia a quien recomienda de quien decide.

Otros participantes y siguiente paso: ¿Quién más necesita revisar la información? Acordad qué documento o conversación viene después, quién lo preparará y cuándo lo necesita el contacto. Así, el creador, el equipo de marketing y el comercial podrán trabajar a partir de la misma pregunta.

Úsalo como registro de la conversación. Revisa los campos si cambian la compra prevista o sus participantes y distingue las respuestas del contacto de las suposiciones aún pendientes de comprobar.

Imagina una empresa de software que prepara una demostración para una agencia. La persona responsable de operaciones quiere saber si el producto permite pasar una campaña aprobada al flujo de informes que ya utiliza su equipo. Es un ejemplo ficticio de cómo usar el briefing, no un participante observado ni una campaña medida.

La primera versión del briefing podría decir: «Compra prevista: una herramienta para el traspaso de campañas de la agencia. Tarea de evaluación: confirmar el traspaso exacto que necesita el equipo de operaciones. Información: un ejemplo documentado con una conexión disponible y sus requisitos de configuración». Esto basta para dar a un creador o especialista de producto un encargo concreto.

Antes de grabar la demostración, el equipo comprueba la conexión. Si no está disponible, debe indicarlo en el briefing y en la siguiente conversación. Si solo funciona con un plan o una configuración determinados, el ejemplo debe dejar clara esa condición.

Después, el equipo de marketing pregunta qué ocurrirá tras la revisión técnica. Supongamos que el contacto explica que recomendará una herramienta, que una persona de finanzas revisará la solicitud de presupuesto y que un director tomará la decisión final. Son respuestas supuestas para este ejemplo. Deben anotarse como responsabilidades distintas para esta compra, junto con las personas y los pasos pendientes que identifique el contacto.

El plan de contenidos ya puede concretarse. El evaluador recibe la demostración verificada del flujo de trabajo y su referencia. Quien prepara la solicitud de presupuesto recibe el precio vigente, el alcance y los costes de implantación conocidos. Para la decisión final, se puede utilizar un resumen del uso propuesto, los requisitos confirmados y las preguntas pendientes.

Los tres materiales deben basarse en los mismos datos del producto. El resumen de negocio no debe prometer una función que falta en la demostración. La página técnica no debe ocultar un requisito de plan que cambie el precio. Dar un énfasis distinto a cada material no justifica presentar datos diferentes.

Si, en cambio, el contacto dice que evalúa la herramienta, gestiona su presupuesto y toma la decisión final, el briefing puede reflejar ese solapamiento. El equipo podría facilitar un único documento conciso con secciones claramente diferenciadas. La encuesta no determina cuál de estas situaciones se aplica a la agencia; la conversación sí puede aclararlo.

El siguiente paso es concreto: confirmar el flujo de trabajo solicitado, enviar la información acordada y anotar las preguntas pendientes. Cuando responda el contacto, el equipo podrá actualizar el campo correspondiente en vez de reconstruir desde cero lo que sabe sobre la compra.

Utilizamos los datos públicos de la encuesta de desarrolladores de Stack Overflow de 2026, vinculados a una versión concreta del archivo para que otro analista pueda recuperar el mismo fichero de entrada. El fichero contiene 30.903 respuestas. Según el productor, el trabajo de campo se realizó del 23 de junio al 5 de agosto de 2026, con participantes de 169 países. La participación fue voluntaria: los resultados describen este grupo de respuestas publicado, no una muestra representativa de todas las empresas o compradores de software. ^[1][2]

La pregunta sobre funciones relacionadas con el software era opcional y permitía seleccionar varias respuestas. Para comprobar los totales publicados, conservamos a los 20.042 participantes que la respondieron. El análisis principal incluyó después a los 9664 que seleccionaron la evaluación, recomendación o preselección. Todos los porcentajes de la tabla principal utilizan ese grupo de evaluadores como denominador. ^[1][5]

Antes de examinar las combinaciones de respuestas, fijamos la versión de entrada, las etiquetas exactas de las opciones, las reglas para valores ausentes, los criterios de inclusión y las cuatro categorías. Comprobamos el fichero original, las definiciones de columnas, los identificadores únicos, las condiciones que determinaban quién recibía la pregunta y los recuentos de respuestas no ausentes. Dos implementaciones desarrolladas de forma independiente reprodujeron exactamente el denominador de la pregunta y los seis recuentos de opciones publicados.

Para cada evaluador, comprobamos si había seleccionado la decisión final y la aprobación o gestión del presupuesto. Cada respuesta pertenece a una de las cuatro categorías según esas selecciones. Dividimos el recuento de cada categoría entre 9664 y redondeamos los porcentajes por separado a un decimal. Este análisis no utiliza ponderaciones de encuesta, intervalos de confianza poblacionales ni estimaciones causales.

También definimos de antemano dos comprobaciones adicionales: una versión que excluía a los evaluadores que seleccionaron simultáneamente la opción de no tener ninguna función y un desglose en cinco grupos fijos de tamaño de empresa. No publicamos ni el análisis de sensibilidad completo ni el desglose completo por tamaño porque no cumplieron nuestras reglas de publicación preestablecidas. No utilizamos ninguno de esos resultados no publicados para afirmar estabilidad ni diferencias según el tamaño de la empresa.

El grupo principal debe tener al menos 500 participantes y ninguna celda con un recuento positivo inferior a diez. El análisis de sensibilidad debe contar también con al menos 500 participantes, ninguna celda de resultados con un recuento positivo inferior a diez y ninguna celda de excluidos con un recuento positivo inferior a diez. Esta última condición evita revelar un grupo pequeño mediante una resta. En el desglose por tamaño, cada uno de los cinco grupos fijos debe tener al menos 100 participantes y ninguna celda con un recuento positivo inferior a diez. Si no se cumple alguna condición, se omite todo el conjunto de resultados correspondiente; no combinamos categorías después de ver las respuestas.

Son criterios editoriales de suficiencia y publicación, no una afirmación de representatividad estadística ni una garantía formal de privacidad. Conservamos el conjunto de respuestas publicado por el productor. El fichero público no incluye sus indicadores internos de consentimiento, calidad y detección de bots, por lo que no podemos reconstruir de forma independiente todas las decisiones utilizadas para formar ese conjunto. ^[2]

Las preguntas describen responsabilidades en una organización, no una transacción verificada. Las tareas que seleccionó una persona pueden referirse a herramientas diferentes. No seleccionar una opción no demuestra falta de autoridad, y las respuestas no identifican a las otras personas que intervienen en una compra. Estos límites importan al trasladar un porcentaje de encuesta a una conversación con un cliente.

Las descargas incluyen los resultados agregados que cumplen los criterios, el código de cálculo y el método exacto. No contienen registros ni identificadores de participantes. La encuesta original está disponible por separado bajo Open Database License y Database Contents License; el paquete de reproducción conserva las atribuciones y los avisos aplicables. ^[6][7]