Abans de comparar CRM: quatre preguntes que tancar primer

La tria de CRM no es decideix comparant CRM.

Quan una empresa es planteja comprar un CRM, el format de la decisió està estandarditzat pel mercat. Es demanen propostes a tres o quatre partners, es programen demos, es munta un quadre comparatiu amb els criteris habituals — preu per usuari, capacitat de personalització, integracions disponibles, reputació del proveïdor. I es treballa la decisió sobre la pregunta operativa que el format imposa: «Zoho o HubSpot?», «Odoo o Salesforce?», «quin d'aquests quatre és el millor per a nosaltres?».

Formulada així, en aquest moment i amb aquest material, aquesta pregunta és la que no toca. La decisió sobre quin CRM es pren tancant abans quatre preguntes sobre la pròpia operació comercial — no sobre la plataforma. Quatre preguntes que cap quadre comparatiu recull, que cap partner posa sobre la taula a la primera reunió i que gairebé mai es treballen abans d'avaluar opcions. Mentre no estiguin contestades, la fase d'avaluació produeix comparatives polides, presentacions convincents i decisions que no són decisions, sinó apostes elegantment justificades. La comparació de plataformes assumeix que saps què li demanaràs al sistema; aquestes quatre preguntes són el que decideix què li demanaràs.

Comparar plataformes abans de tancar aquestes quatre preguntes no accelera la decisió. La buida.

Quina decisió de direcció vols prendre més ben informat

Quan aquesta pregunta no es contesta abans, la parametrització del CRM es fa per defecte del partner: camps estàndard, etapes estàndard, informes estàndard. Funciona tècnicament. El que produeix, en canvi, és un sistema que serveix per a tot en general i per a res en concret. L'indicador més fàcil de detectar és el més persistent: la reunió mensual amb direcció es continua treballant fora del CRM. El CRM no es va dissenyar pensant en aquesta reunió, i per això la reunió no es prepara des del CRM.

La pregunta no és la tòpica de «què vols aconseguir amb el CRM?», que gairebé sempre es contesta amb generalitats: «millorar la previsió», «tenir-ho tot centralitzat», «guanyar visibilitat sobre l'equip». Aquestes respostes redacten una wishlist. La pregunta concreta és una altra: quina decisió de direcció comercial —entre les que ja prens avui amb pitjor informació de la que voldries— vols prendre més ben informat. Aquesta formulació redacta requisits, no desitjos.

Ben plantejada, la pregunta produeix respostes que es poden treballar. La previsió trimestral que presentes al comitè de direcció: quina previsió, sobre quina base d'oportunitats, amb quin criteri de probabilitat — i no la xifra que es munta a mà creuant intuïció amb tancaments de l'any anterior. L'assignació de recursos comercials per tipus de client o vertical: quins clients mereixen quin nivell d'atenció, amb quins senyals es decideix pujar o baixar prioritat — i no el repartiment històric que ningú ha revisat en dos anys. El moment de baixar prioritat o tancar com a perduda una oportunitat llarga: quins senyals agregats justifiquen aquesta decisió — i no la conversa recurrent de passadís entre direcció i comercial sobre si aquell compte continua viu. Cadascuna d'aquestes tres és una decisió real que la direcció pren amb freqüència i sovint amb poca evidència. Cadascuna és un requisit formulable cap al sistema.

La pregunta està contestada quan pots anomenar la decisió, dir amb quina dada la prendries millor, i ensenyar on viu aquesta dada avui: en un cap, en un Excel, en una conversa de passadís, enlloc. Si pots fer aquestes tres coses per a almenys dues o tres decisions concretes, estàs en condicions de començar a avaluar plataformes amb criteri. Si no pots anomenar la decisió —si la resposta més sincera sona a «tenir-ho tot més ordenat»—, continues a la wishlist. I la wishlist no informa una tria de CRM: només permet descartar les pitjors entre si.

Què fa que una conversa es converteixi en oportunitat per a tu

Aquesta no és la pregunta sobre la definició del procés comercial — aquesta és una altra, i la treballem en un altre lloc. El manifest del blog desenvolupa què separa unes fases de les altres i com es decideix cada salt. La pregunta d'aquest moment opera abans: què separa «estem parlant amb algú» de «això entra ja al pipeline». Sense aquest llindar tancat, el debat sobre fases és estèril, perquè les fases operen sobre material encara no qualificat.

Quan el llindar no està decidit abans de comprar el CRM, es compra un pipeline ple de converses primerenques catalogades com a oportunitats. Cada comercial aplica el seu propi llindar —un hi posa qualsevol conversa de prospecció, un altre espera a tenir proposta sobre la taula— sense criteri comú. El volum del pipeline deixa de representar res d'agregable. La previsió és matemàticament correcta i operativament enganyosa: la direcció no sap si el problema és d'activitat, de conversió o de qualificació, perquè les tres estan barrejades en el mateix número.

El llindar tanca dues dimensions, i convé tractar-les per separat.

Senyal mínim des del costat del client. Què ha d'haver dit o fet l'altra part perquè la conversa es consideri oportunitat. No n'hi ha prou amb interès genèric; cal un senyal comptable: pressupost declarat o estimat, decisor identificat per nom i rol, problema operatiu anomenat, calendari de decisió enunciat. La decisió és quin senyal concret —un de sol o una combinació— és condició necessària en cada negoci. El senyal varia; el que no varia és que ha d'estar anomenat, no assumit, i ha de ser el mateix per a tots els comercials.

Compromís mínim des del costat del propi equip. Què ha d'haver deixat per escrit el comercial. No n'hi ha prou que digui «això anirà»: un CRM no registra intuïcions. Cal que l'oportunitat estigui creada amb els camps clau emplenats: compte, contacte decisor, data estimada, import dins d'un rang acordat. Sense aquest mínim de compromís registrat, l'oportunitat pertany al cap del comercial, no al sistema. I el que pertany al cap no agrega.

La pregunta està contestada quan pots formular el llindar en una frase del tipus «una oportunitat entra al pipeline quan es compleix X des del costat del client i s'ha registrat Y des del nostre», i aquesta frase és la mateixa per a tots els comercials. Si la formulació canvia segons a qui preguntis, o si la direcció comercial mai ha enunciat un llindar perquè fins ara el criteri s'entenia sense formular-lo, continues sense criteri d'entrada. El CRM no l'inventarà: muntarà el pipeline sobre la indefinició que tingui al davant.

Decidida la decisió marc i decidit el llindar d'entrada, queda una pregunta d'abast: fins on arriba el que el CRM ha de gestionar.

Quines parts del cicle comercial vols que el CRM gestioni, i quines no

La pregunta d'abast es viu com a tècnica, i per això es delega — al partner, al departament d'IT, a la conversa d'implantació. El raonament implícit és que ja es veurà durant el projecte. El problema és que el que es decideix a mitja implantació es decideix sota pressió d'avanç: hi ha llicències contractades, hi ha equip format, hi ha dates de go-live compromeses. En aquest context, l'abast no es tanca per decisió de direcció comercial: es tanca per inèrcia tècnica o per pressió política, i cap de les dues contesta la pregunta que importa.

Quan la pregunta no es tanca abans, el que passa té dues conseqüències en cadena. La primera, l'abast creix. Màrqueting demana la seva part, postvenda la seva, direcció financera vol veure la previsió integrada amb pressupost. Cada incorporació sembla raonable mirada per separat; en conjunt, converteixen el projecte en una cosa que ja no és un CRM comercial, sinó un sistema operatiu de l'empresa sencera. La segona, derivada: la implantació s'allarga, el cost es multiplica, i el comercial —usuari primari del sistema— es queda amb una eina dissenyada per a tots els stakeholders, no per a la seva feina diària.

La pregunta d'abast es tanca tancant abans tres decisions diferents.

Funcions del cicle comercial que entren i funcions que no entren. Vendes, sí, per definició — és el que justifica el sistema. Màrqueting (gestió de leads, campanyes, nurturing) és opcional però condicionat: si entra, requereix tenir tancat abans el procés de qualificació màrqueting-comercial — quin lead passa a ser oportunitat, quan, amb quina informació mínima —, no després. Servei postvenda (incidències, renovacions, customer success) també és opcional, amb la seva pròpia condició: si entra, el CRM deixa de ser eina comercial i es converteix en eina de relació, amb conseqüències en governança, permisos i informes.

Operacions que entren i operacions que es queden fora. Facturació, gestió d'estocs, comptabilitat. La resposta per defecte és que es queden fora — viuen a l'ERP, no al CRM. Quan es posa una operació d'ERP al CRM perquè «ja que hi som», el que s'aconsegueix és carregar el sistema amb dades que el comercial no necessita i duplicar fonts de veritat per a dades que la resta de l'empresa sí que necessita. L'excepció s'ha de justificar explícitament, no assumir-se per proximitat.

Integracions que entren a la versió 1 i integracions que esperen a la versió 2. Email corporatiu, calendari, ERP, eines de màrqueting. Cada integració afegeix temps, cost i complexitat de manteniment. La pregunta a contestar és quines són condició necessària perquè el CRM funcioni des del dia u i quines poden esperar. Confondre «el que estaria bé tenir» amb «el que ha d'estar el primer dia» és la font més comuna de retard del go-live.

La pregunta està contestada quan pots ensenyar, abans de començar a avaluar plataformes, un mapa amb tres llistes — el que entra, el que no entra, el que espera a la versió 2 — i defensar per què cada element és a la llista on és. Si les llistes se senten provisionals, o si alguna resposta es contesta amb «ja es veurà durant la implantació», no estàs en condicions de demanar pressupost a partners. La proposta econòmica que et donaran serà per a una versió del projecte diferent de la que acabaràs implementant.

Decidides la decisió marc, el llindar d'entrada i l'abast, queda una pregunta sense la qual les tres anteriors no se sostenen: qui vetllarà perquè tot això continuï sent veritat quan el partner se'n vagi.

Qui serà responsable del CRM en operació

Aquesta pregunta s'omet amb més freqüència que les altres tres. La raó és que quan es compra un CRM, la conversa sobre el responsable gira gairebé sempre al voltant de la figura tècnica: administrador del sistema, key user, formador intern. Aquestes figures són necessàries, però contesten una altra pregunta — la de l'administració tècnica. La pregunta que aquí importa és diferent: és de govern comercial. Qui decideix si el CRM s'està fent servir com es va dissenyar, qui decideix quan el disseny ha de canviar, qui decideix quines excepcions s'admeten i quines no. Aquesta figura — la de l'amo operatiu — és la que gairebé ningú anomena abans de la primera demo. I quan no s'anomena, per defecte recau sobre el Director Comercial a les seves estones.

El que es compra quan la figura no està anomenada és un CRM que continua sent de tots i de ningú. Cada decisió sobre el sistema s'eleva al Director Comercial — des de "aquest comercial necessita camps extra" fins a "màrqueting demana canviar la qualificació de leads" —, i es contesta amb l'amplada de banda que el Director Comercial té, que gairebé mai és la que la decisió mereix. El CRM es degrada tècnicament i operativament, no per mala arquitectura inicial, sinó per absència de manteniment de criteri.

Un amo operatiu ben triat reuneix tres condicions. La primera, autoritat: poder tancar discussions sobre abast o ús sense haver d'escalar-ne cadascuna. La segona, criteri comercial: entendre per què el sistema es va dissenyar com es va dissenyar, no només com es configura. La tercera, amplada de banda real: temps assignat i reconegut a l'organigrama, no una responsabilitat afegida a cinc més. Quan una de les tres falta, l'amo operatiu és nominal: hi ha un nom a l'organigrama, però el CRM continua funcionant com si no existís. La pregunta correcta no és «qui ho porta?». És «quina autoritat, quin criteri i quin temps li hem assignat?».

La pregunta està contestada quan pots anomenar la persona, defensar per què reuneix les tres condicions, i ensenyar quantes hores setmanals protegides té assignades a la funció. Si només pots anomenar la persona — «això ho portarà en Tal» —, la pregunta continua oberta. I si la resposta més sincera al test de tancament és «això ho portaré jo», amb la direcció comercial assumint l'amo operatiu a més del seu rol, la pregunta no està contestada: està rebutjada. Portar bé un CRM en operació requereix una dedicació que el Director Comercial no té, i reconèixer-ho abans de la primera demo és el que protegeix el projecte dels sis o dotze mesos següents.

Les quatre preguntes no es contesten en abstracte. Es contesten, o no, abans de la primera demo.

Quina decisió de direcció vols prendre més ben informat. Què fa que una conversa es converteixi en oportunitat. Quines parts del cicle comercial entren i quines no. I qui vetllarà perquè el CRM continuï sent el que vas dissenyar sis mesos després de començar a fer-lo servir. Quatre preguntes, cap sobre la plataforma.

Si no pots anomenar la persona que serà l'amo operatiu del CRM abans de la primera demo, les altres tres preguntes tampoc no estan tancades — per molt que sembli que ho estan. La quarta és la que les sosté totes: sense algú amb autoritat, criteri i temps assignat, la feina de tancar la decisió marc, el llindar d'entrada i l'abast es desinfla quan el partner acaba la implantació. Les tres primeres es contesten perquè el CRM es compri bé. La quarta, perquè continuï estant bé.

La tria de CRM no s'accelera comparant opcions. S'accelera decidint abans què li demanaràs al sistema.