Antes de comparar CRMs: cuatro preguntas que cerrar primero

La elección de CRM no se decide comparando CRMs.

Cuando una empresa se plantea comprar un CRM, el formato de la decisión está estandarizado por el mercado. Se piden propuestas a tres o cuatro partners, se programan demos, se monta un cuadro comparativo con los criterios habituales — precio por usuario, capacidad de personalización, integraciones disponibles, reputación del proveedor. Y se trabaja la decisión sobre la pregunta operativa que el formato impone: «¿Zoho o HubSpot?», «¿Odoo o Salesforce?», «¿cuál de estos cuatro es el mejor para nosotros?».

Formulada así, en ese momento y con ese material, esa pregunta es la que no toca. La decisión sobre qué CRM se toma cerrando antes cuatro preguntas sobre la propia operación comercial — no sobre la plataforma. Cuatro preguntas que ningún cuadro comparativo recoge, que ningún partner pone sobre la mesa en la primera reunión y que casi nunca se trabajan antes de evaluar opciones. Mientras no estén contestadas, la fase de evaluación produce comparativas pulcras, presentaciones convincentes y decisiones que no son decisiones, sino apuestas elegantemente justificadas. La comparación de plataformas asume que sabes qué le vas a pedir al sistema; estas cuatro preguntas son lo que decide qué le vas a pedir.

Comparar plataformas antes de cerrar esas cuatro preguntas no acelera la decisión. La vacía.

Qué decisión de dirección quieres tomar mejor informado

Cuando esta pregunta no se contesta antes, la parametrización del CRM se hace por defecto del partner: campos estándar, etapas estándar, informes estándar. Funciona técnicamente. Lo que produce, en cambio, es un sistema que sirve para todo en general y para nada en concreto. El indicador más fácil de detectar es el más persistente: la reunión mensual con dirección se sigue trabajando fuera del CRM. El CRM no se diseñó pensando en esa reunión, y por eso la reunión no se prepara desde el CRM.

La pregunta no es la tópica de «¿qué quieres conseguir con el CRM?», que casi siempre se contesta con generalidades: «mejorar la previsión», «tener todo centralizado», «ganar visibilidad sobre el equipo». Esas respuestas redactan wishlist. La pregunta concreta es otra: qué decisión de dirección comercial —entre las que ya tomas hoy con peor información de la que querrías— quieres tomar mejor informado. Esa formulación redacta requisitos, no deseos.

Bien planteada, la pregunta produce respuestas que se pueden trabajar. La previsión trimestral que presentas en comité de dirección: qué previsión, sobre qué base de oportunidades, con qué criterio de probabilidad — y no la cifra que se monta a mano cruzando intuición con cierres del año anterior. La asignación de recursos comerciales por tipo de cliente o vertical: qué clientes merecen qué nivel de atención, con qué señales se decide subir o bajar prioridad — y no el reparto histórico que nadie ha revisado en dos años. El momento de bajar prioridad o cerrar como perdida una oportunidad larga: qué señales agregadas justifican esa decisión — y no la conversación recurrente de pasillo entre dirección y comercial sobre si aquella cuenta sigue viva. Cada una de esas tres es una decisión real que la dirección toma con frecuencia y a menudo con poca evidencia. Cada una es un requisito formulable hacia el sistema.

La pregunta está contestada cuando puedes nombrar la decisión, decir con qué dato la tomarías mejor, y enseñar dónde vive ese dato hoy: en una cabeza, en un Excel, en una conversación de pasillo, en ningún sitio. Si puedes hacer esas tres cosas para al menos dos o tres decisiones concretas, estás en condiciones de empezar a evaluar plataformas con criterio. Si no puedes nombrar la decisión —si la respuesta más sincera suena a «tener todo más ordenado»—, sigues en la wishlist. Y la wishlist no informa una elección de CRM: solo permite descartar las peores entre sí.

Qué hace que una conversación se convierta en oportunidad para ti

Esta no es la pregunta sobre la definición del proceso comercial — esa es otra, y la trabajamos en otro sitio. El manifiesto del blog desarrolla qué separa unas fases de otras y cómo se decide cada salto. La pregunta de este momento opera antes: qué separa «estamos hablando con alguien» de «esto entra ya en el pipeline». Sin ese umbral cerrado, el debate sobre fases es estéril, porque las fases operan sobre material aún no calificado.

Cuando el umbral no está decidido antes de comprar el CRM, se compra un pipeline lleno de conversaciones tempranas catalogadas como oportunidades. Cada comercial aplica su propio umbral —uno mete cualquier conversación de prospección, otro espera a tener propuesta sobre la mesa— sin criterio común. El volumen del pipeline deja de representar nada agregable. La previsión es matemáticamente correcta y operativamente engañosa: la dirección no sabe si el problema es de actividad, de conversión o de calificación, porque las tres están mezcladas en el mismo número.

El umbral cierra dos dimensiones, y conviene tratarlas por separado.

Señal mínima desde el lado del cliente. Qué tiene que haber dicho o hecho la otra parte para que la conversación se considere oportunidad. No basta con interés genérico; hace falta una señal contable: presupuesto declarado o estimado, decisor identificado por nombre y rol, problema operativo nombrado, calendario de decisión enunciado. La decisión es qué señal concreta —una sola o una combinación— es condición necesaria en cada negocio. La señal varía; lo que no varía es que tiene que estar nombrada, no asumida, y tiene que ser la misma para todos los comerciales.

Compromiso mínimo desde el lado del propio equipo. Qué tiene que haber dejado por escrito el comercial. No basta con que diga «esto va a ir»: un CRM no registra intuiciones. Hace falta que la oportunidad esté creada con campos clave rellenados: cuenta, contacto decisor, fecha estimada, importe dentro de un rango acordado. Sin ese mínimo de compromiso registrado, la oportunidad pertenece a la cabeza del comercial, no al sistema. Y lo que pertenece a la cabeza no agrega.

La pregunta está contestada cuando puedes formular el umbral en una frase del tipo «una oportunidad entra en el pipeline cuando se cumple X desde el lado del cliente y se ha registrado Y desde el nuestro», y esa frase es la misma para todos los comerciales. Si la formulación cambia según a quién preguntes, o si la dirección comercial nunca ha enunciado un umbral porque hasta ahora el criterio se entendía sin formularlo, sigues sin criterio de entrada. El CRM no va a inventarlo: va a montar el pipeline sobre la indefinición que tenga delante.

Decidida la decisión-marco y decidido el umbral de entrada, queda una pregunta de alcance: hasta dónde llega lo que el CRM tiene que gestionar.

Qué partes del ciclo comercial quieres que el CRM gestione, y cuáles no

La pregunta de alcance se vive como técnica, y por eso se delega — al partner, al departamento de IT, a la conversación de implantación. El razonamiento implícito es que ya se verá durante el proyecto. El problema es que lo que se decide a mitad de implantación se decide bajo presión de avance: hay licencias contratadas, hay equipo formado, hay fechas de go-live comprometidas. En ese contexto, el alcance no se cierra por decisión de dirección comercial: se cierra por inercia técnica o por presión política, y ninguna de las dos contesta la pregunta que importa.

Cuando la pregunta no se cierra antes, lo que ocurre tiene dos consecuencias en cadena. La primera, el alcance crece. Marketing pide su parte, postventa la suya, dirección financiera quiere ver la previsión integrada con presupuesto. Cada incorporación parece razonable mirada por separado; en conjunto, convierten el proyecto en algo que ya no es un CRM comercial, sino un sistema operativo de la empresa entera. La segunda, derivada: la implantación se alarga, el coste se multiplica, y el comercial —usuario primario del sistema— se queda con una herramienta diseñada para todos los stakeholders, no para su trabajo diario.

La pregunta de alcance se cierra cerrando antes tres decisiones distintas.

Funciones del ciclo comercial que entran y funciones que no entran. Ventas, sí, por definición — es lo que justifica el sistema. Marketing (gestión de leads, campañas, nurturing) es opcional pero condicionada: si entra, requiere tener cerrado antes el proceso de calificación marketing-comercial — qué lead pasa a ser oportunidad, cuándo, con qué información mínima —, no después. Servicio postventa (incidencias, renovaciones, customer success) también es opcional, con su propia condición: si entra, el CRM deja de ser herramienta comercial y se convierte en herramienta de relación, con consecuencias en gobernanza, permisos y reportes.

Operaciones que entran y operaciones que se quedan fuera. Facturación, gestión de stocks, contabilidad. La respuesta por defecto es que se quedan fuera — viven en el ERP, no en el CRM. Cuando se mete una operación de ERP en el CRM porque «ya que estamos», lo que se consigue es cargar el sistema con datos que el comercial no necesita y duplicar fuentes de verdad para datos que el resto de la empresa sí necesita. La excepción tiene que justificarse explícitamente, no asumirse por proximidad.

Integraciones que entran en versión 1 e integraciones que esperan a versión 2. Email corporativo, calendario, ERP, herramientas de marketing. Cada integración añade tiempo, coste y complejidad de mantenimiento. La pregunta a contestar es cuáles son condición necesaria para que el CRM funcione desde el día uno y cuáles pueden esperar. Confundir «lo que estaría bien tener» con «lo que tiene que estar el primer día» es la fuente más común de retraso de go-live.

La pregunta está contestada cuando puedes enseñar, antes de empezar a evaluar plataformas, un mapa con tres listas — lo que entra, lo que no entra, lo que espera a versión 2 — y defender por qué cada elemento está en la lista en la que está. Si las listas se sienten provisionales, o si alguna respuesta se contesta con «ya se verá durante la implantación», no estás en condiciones de pedir presupuesto a partners. La propuesta económica que te van a dar va a ser para una versión del proyecto distinta de la que vas a acabar implementando.

Decididas la decisión-marco, el umbral de entrada y el alcance, queda una pregunta sin la cual las tres anteriores no se sostienen: quién va a velar por que todo eso siga siendo verdad cuando el partner se vaya.

Quién va a ser responsable del CRM en operación

Esta pregunta se omite con más frecuencia que las otras tres. La razón es que cuando se compra un CRM, la conversación sobre responsable gira casi siempre en torno a la figura técnica: administrador del sistema, key user, formador interno. Esas figuras son necesarias, pero contestan a otra pregunta — la de la administración técnica. La pregunta que aquí importa es distinta: es de gobierno comercial. Quién decide si el CRM se está usando como se diseñó, quién decide cuándo el diseño tiene que cambiar, quién decide qué excepciones se admiten y cuáles no. Esa figura — la del dueño operativo — es la que casi nadie nombra antes de la primera demo. Y cuando no se nombra, por defecto recae sobre el Director Comercial en sus ratos.

Lo que se compra cuando la figura no está nombrada es un CRM que sigue siendo de todos y de nadie. Cada decisión sobre el sistema se eleva al Director Comercial — desde "este comercial necesita campos extra" hasta "marketing pide cambiar la calificación de leads" —, y se contesta con el ancho de banda que el Director Comercial tiene, que casi nunca es el que la decisión merece. El CRM se degrada técnica y operativamente, no por mala arquitectura inicial, sino por ausencia de mantenimiento de criterio.

Un dueño operativo bien elegido reúne tres condiciones. La primera, autoridad: poder cerrar discusiones sobre alcance o uso sin tener que escalar cada una. La segunda, criterio comercial: entender por qué el sistema se diseñó como se diseñó, no solo cómo se configura. La tercera, ancho de banda real: tiempo asignado y reconocido en el organigrama, no una responsabilidad añadida a otras cinco. Cuando una de las tres falta, el dueño operativo es nominal: hay un nombre en el organigrama, pero el CRM sigue funcionando como si no existiera. La pregunta correcta no es «¿quién lo lleva?». Es «¿qué autoridad, qué criterio y qué tiempo le hemos asignado?».

La pregunta está contestada cuando puedes nombrar a la persona, defender por qué reúne las tres condiciones, y enseñar cuántas horas semanales protegidas tiene asignadas a la función. Si solo puedes nombrar a la persona — «esto lo va a llevar Fulano» —, la pregunta sigue abierta. Y si la respuesta más sincera al test de cierre es «esto lo voy a llevar yo», con la dirección comercial asumiendo el dueño operativo además de su rol, la pregunta no está contestada: está rechazada. Llevar bien un CRM en operación requiere una dedicación que el Director Comercial no tiene, y reconocer eso antes de la primera demo es lo que protege el proyecto de los seis o doce meses siguientes.

Las cuatro preguntas no se contestan en abstracto. Se contestan, o no, antes de la primera demo.

Qué decisión de dirección quieres tomar mejor informado. Qué hace que una conversación se convierta en oportunidad. Qué partes del ciclo comercial entran y cuáles no. Y quién va a velar por que el CRM siga siendo lo que diseñaste seis meses después de empezar a usarlo. Cuatro preguntas, ninguna sobre la plataforma.

Si no puedes nombrar a la persona que va a ser dueña operativa del CRM antes de la primera demo, las otras tres preguntas tampoco están cerradas — por mucho que parezcan estarlo. La cuarta es la que las sostiene a todas: sin alguien con autoridad, criterio y tiempo asignado, el trabajo de cerrar la decisión-marco, el umbral de entrada y el alcance se desinfla cuando el partner termina la implantación. Las tres primeras se contestan para que el CRM se compre bien. La cuarta, para que siga estando bien.

La elección de CRM no se acelera comparando opciones. Se acelera decidiendo antes qué le vas a pedir al sistema.