Comités de compra de tecnología de ventas: quién debe realmente aprobar una nueva herramienta

Dos tipos de compra de tecnología de ventas fallan de maneras casi opuestas, y ambas son lo bastante comunes como para tener nombre dentro de la mayoría de las organizaciones de ingresos. En el primero, un VP se enamora de una herramienta en una conferencia, la aprueba con su propia línea de presupuesto, y seis semanas después TI mata la integración porque nadie revisó cómo maneja los datos de clientes. En el segundo, sales ops hace una evaluación cuidadosa y bien documentada, elige una herramienta técnicamente sólida, y los representantes dejan de usarla en silencio en un mes, porque nadie que realmente trabaja una secuencia o registra una llamada todos los días tenía un asiento en la sala.

Ambos fallos se remontan a la misma causa raíz: decidió el grupo de personas equivocado.

Los asientos que realmente importan

Un líder de ventas dueño del presupuesto. Alguien tiene que ser dueño de la decisión y del costo, y responder si la herramienta no cumple. Esta persona suele iniciar la compra y no debería ser la única firma en ella.

Sales ops o revenue operations. Es la persona que entiende qué le hará la herramienta al modelo de datos, a la estructura de campos del CRM, a los reportes construidos encima, y a las demás herramientas con las que necesita comunicarse. Una herramienta que parece simple en la demo puede romper en silencio automatizaciones existentes o duplicar un campo que ya poseen otras tres herramientas. Ops detecta eso antes de firmar, no después.

Un representante de los usuarios finales. El asiento que más se omite, y cuya ausencia causa más dolor después de la compra. Un representante o un gerente de primera línea que realmente va a correr una secuencia, registrar una llamada, o revisar un dashboard en esta herramienta cada día debería opinar sobre la usabilidad antes de firmar el contrato. Las herramientas elegidas enteramente por liderazgo u ops sin esta opinión siguen un patrón bien documentado: elecciones técnicamente correctas que los representantes simplemente evitan.

TI o seguridad. Necesario siempre que la herramienta toque datos de clientes, se integre con el CRM, o requiera inicio de sesión único y aprovisionamiento de acceso a datos. Saltarse este paso no elimina el riesgo, solo mueve la revisión a después de firmar el contrato, momento en que dar marcha atrás es costoso y vergonzoso.

Finanzas. Necesario para cualquier compra que exceda un equipo pequeño y único, en particular para precios basados en uso que pueden escalar de forma impredecible con la plantilla o el volumen de actividad. Un precio por usuario que parecía razonable con diez usuarios puede convertirse en una cifra muy distinta con cincuenta.

Dos fallos, y por qué se repiten

La tercera fila importa tanto como las dos primeras. Añadir a cada posible stakeholder en cada decisión no arregla el problema, solo cambia una decisión mala y rápida por una decisión mediocre y lenta. El objetivo es tener a las personas correctas según el tamaño de la decisión, no a la mayor cantidad de personas en cada decisión.

Ajustar el tamaño del comité a la compra

No toda herramienta merece el grupo completo. Una herramienta de 50 dólares al mes para un solo equipo, sin acceso a datos sensibles, puede razonablemente seguir siendo decisión del dueño del presupuesto, idealmente con una revisión de dos minutos de ops para confirmar que no duplica algo que ya está en el stack. Un nuevo CRM, una plataforma de engagement para toda la empresa, o cualquier cosa que toque datos personales de clientes merece el comité completo, incluyendo TI y finanzas, porque el costo de equivocarse crece con qué tan integrada queda la herramienta.

Una forma simple de trazar la línea: pregunta si la herramienta se integra con el CRM, si maneja datos de clientes o prospectos más allá de lo que un representante escribe manualmente, y si el precio escala con el uso de una forma difícil de predecir. Cualquier "sí" empuja la compra hacia el comité completo. Todos los "no" hacen defendible un proceso más ligero.

Cómo es realmente una aprobación ligera

Para compras pequeñas, esto no necesita un proceso formal, solo un hábito: el dueño del presupuesto redacta un párrafo resumiendo qué hace la herramienta, quién la usará, y qué datos toca, y lo envía a ops y, si es relevante, a TI antes de firmar. Esto cuesta un día, no un trimestre, y detecta la mayoría de los fallos descritos arriba sin convertir cada compra pequeña en una evaluación de varias semanas.

La prueba real

Antes de firmar, haz dos preguntas sin importar el precio de la herramienta. Quién la usará cada día, y si tuvo voz en la decisión. Qué toca o con qué se conecta, y si alguien lo verificó. Una compra que responda ambas con honestidad rara vez termina muerta en la revisión de TI o ignorada en silencio por el equipo para el que se compró. Una que no puede responderlas suele fallar por una razón que ya era visible antes de firmar el contrato, no después.