Un CRM cu AI își merită locul într-o vânzare industrială citind corect cererea, nu trimițând mai multe follow-up-uri

În fraza aceasta se ascund două afaceri. Echipamentul de capital este o achiziție de comitet, pe un ciclu de nouă până la optsprezece luni; prelucrarea după desenul clientului se decide în câteva zile, pe baza desenului, unde problema este volumul de cereri de ofertă, nu lungimea ciclului. Argumentele de mai jos despre cererea de ofertă, calificare și documentație se aplică la ambele, cele despre comitetul de decizie și scoring doar la vânzarea de echipament. Ce face AI bine în oricare dintre cazuri este îngust: remodelează text pe care îl aveți deja.

De ce automatizarea generică de CRM eșuează pe un ciclu lung de vânzare B2B

Manualul standard presupune un singur cumpărător, o evaluare scurtă, o piață mare și un volum de oportunități suficient cât scoringul să însemne ceva. Niciuna dintre acestea nu se verifică. O achiziție de echipament este judecată de un inginer de producție preocupat de timpul de ciclu, de un inginer de calitate preocupat de capabilitate, de un responsabil de mentenanță preocupat de piesele de schimb, de un achizitor preocupat de condiții și de un manager care răspunde de linia de CAPEX. Ei apar în momente diferite, așa că o secvență adresată „lead-ului” nu ajunge la nimeni.

Piața este și finită. Mulțimea adresabilă este suficient de mică încât aceleași nume să revină de-a lungul anilor și de la o companie la alta, pe măsură ce inginerii se mută între fabrici, și suficient de mică încât niciun model comportamental să nu aibă un set de antrenare demn de acest nume. Un mesaj automat iritant nu este o eroare de rotunjire aici. Este ținut minte, cu nume cu tot.

Comenzile se pierd rar din lipsa unui alt mesaj care întreabă dacă ați apucat să parcurgeți oferta. Se pierd pentru că nu ați fost prezent cu nimic util atunci când s-a scris lista de investiții de anul viitor, pentru că răspunsul tehnic a venit prea târziu sau pentru că cerința nu a fost niciodată consemnată într-o formă în care cineva să poată acționa. Niciuna dintre acestea nu este o problemă de cadență.

Citirea unei cereri de ofertă și extragerea cerinței

Cererile de ofertă sosesc în orice formă i-a venit clientului să trimită: un PDF, un fișier de calcul, un set de desene, trei paragrafe într-un e-mail, un formular de achiziții din care contează șase câmpuri. Un model extrage fiabil ceea ce este prezent ca text — cantitățile și ritmul livrărilor, datele și condițiile de livrare, lista de certificări, condițiile comerciale, codurile de reper numite în corpul mesajului — în timpul în care deschideți fișierul.

Ceea ce își are originea pe desen este o altă clasă de câmp. Tolerarea geometrică, simbolurile de sudură, sistemul de baze de referință, rugozitatea suprafeței, caracteristicile marcate drept critice: acestea sunt citite nefiabil, iar orice este raportat de pe un desen ajunge marcat ca sugestie neverificată pentru un inginer, niciodată ca valoare din care puteți oferta. Tratarea identică a celor două clase este drumul cel mai scurt de la o extragere utilă la o greșeală de ofertare.

Lămuriți întâi chestiunea proprietății. Setul de desene al clientului este proprietatea lui intelectuală, de obicei sub un acord de confidențialitate semnat cu mult înainte să sosească cererea, iar în aeronautică, apărare și în părți din automotive poate fi supus controlului exporturilor prin ITAR, EAR sau regulamentul UE privind produsele cu dublă utilizare. Verificați ce permite NDA-ul în privința prelucrării și a subcontractorilor înainte ca un desen să ajungă la un model, țineți lucrările controlate on-premise sau într-o instalare fără retenție și fără antrenare și păstrați o cale de excludere, astfel încât clienții și familiile de repere marcate să nu intre niciodată în flux.

Jumătatea mai valoroasă a rezultatului este ceea ce lipsește. Întrebările pe care le trimiteți înapoi în prima oră sunt cel mai puternic semnal de competență pe care îl veți trimite vreodată și împiedică un inginer să oferteze pe baza unei presupuneri pe care nu a verificat-o nimeni.

Două reguli despart o extragere utilă de una pe care inginerul o reface manual. Fiecare element își citează sursa: o foaie și o celulă acolo unde sursa este un fișier de calcul, o pagină și o zonă de pe ea acolo unde este o scanare. Iar modelul lasă un câmp gol în loc să ghicească, ceea ce este o rată pe care o măsurați per câmp pe propriul set de test, nu un comportament pe care îl obțineți instruindu-l să se abțină. Abținerea eșuează acolo unde există o valoare implicită plauzibilă, la o toleranță sau la o rugozitate standard, deci un câmp cu abținere mică și eroare mare este unul pe care îl lăsați unui om.

Redactarea primului răspuns tehnic fără a angaja compania

Primul răspuns decide dacă sunteți în evaluare. Unul bun numește aplicația în loc să mulțumească clientului pentru interes, reformulează cerința așa cum a fost înțeleasă, pune cele două-trei întrebări care schimbă răspunsul și se angajează la un pas următor cu o dată.

Un model furnizează structura aceasta într-un minut, iar un om editează și trimite. Trimiterea automată este alt sistem, nu altă setare a aceluiași, și niciun draft nu stabilește o specificație: orice cifră care ar putea ajunge într-o ofertă vine de la cineva cu autoritatea de a o angaja.

Rezumarea istoricului de cont și menținerea la zi a fișei din CRM

O oportunitate care durează de paisprezece luni este împrăștiată în o sută de e-mailuri, trei vizite, două serii de mostre și un test eșuat. Istoricul există și nu îl citește nimeni, așa că, atunci când pleacă responsabilul de cont, valoarea lui practică este zero. Un model care citește firul și îi face un briefing următoarei persoane este cu adevărat util.

Este însă și cu pierderi, iar ce cade disproporționat este angajamentul de un rând îngropat la mijloc: toleranța cedată, prețul menținut pentru o perioadă anunțată, excepția convenită într-o discuție telefonică. Un rezumat aproape corect, care omite tacit concesia, este mai rău decât niciunul. Deci tratați-l ca pe o cale de intrare în fir, legați fiecare afirmație de mesajul din care provine și scoateți angajamentele într-o listă separată, cu citări.

Aceeași capacitate rezolvă cea mai veche problemă din CRM. Oamenii de vânzări nu actualizează fișele pentru că actualizarea lor este introducere de date care nu dă nimic înapoi, iar răspunsul este cel pe care îl primește hala de producție: propuneți, nu impuneți. După o discuție, asistentul redactează nota și propune schimbarea de etapă și acțiunea următoare. Rămân propuneri, pentru că un asistent care modifică tacit valori sau date de finalizare distruge singurul lucru care trebuie să fie un CRM: o evidență în care oamenii cred.

Un CRM cu AI înlocuiește sistemul pe care îl aveți deja sau stă deasupra lui

În cea mai mare parte stă deasupra. Evidența contului, a oportunității și a comenzii rămâne unde este, fie că e Salesforce, Dynamics, HubSpot, Odoo sau modulul CRM al ERP-ului dumneavoastră. Asistentul citește din acea evidență, din căsuța de e-mail, din arhiva de oferte și din depozitul de documente și scrie înapoi trei lucruri: o notă, o propunere de modificare a unui câmp și o sarcină cu responsabil și termen, toate atribuibile și reversibile.

Deci proiectul este integrarea, nu modelul, iar ce eșuează de obicei este identificatorul care trebuie să supraviețuiască drumului dintre CRM, ERP și sistemul de documente, pentru că cheia de cont și codul de client nu au fost niciodată reconciliate. Dacă nu aveți CRM, CRM-ul vine primul: un asistent nu poate menține la zi o evidență care nu există.

La ce nu se pricepe AI și unde vă va costa

Nu vă cunoaște capabilitatea: că toleranța este realizabilă, dar numai la a doua operație, că un aliaj gripează în procesul dumneavoastră, că volumul anual declarat este de câteva ori mai mare decât a comandat vreodată segmentul acela. Nu are simțul consecinței comerciale și va scrie o frază sigură despre termenul de livrare la fel de ușor ca una nuanțată, pentru că amândouă sunt fraze bine formate. Și nici nu știe ce s-a schimbat după ce i-ați dat documentele, ceea ce face din actualitatea documentelor o responsabilitate operațională, nu o sarcină de instalare.

Calificarea cererilor care respectă un cumpărător tehnic: de ce scoringul nu este calificare

Scoringul atribuie un număr pe baza comportamentului: pagini vizitate, e-mailuri deschise, documente descărcate. Pe o piață cu atât de puțini cumpărători reali, asta măsoară mai ales curiozitatea, iar profilul pe care îl răsplătește cel mai constant este inginerul unui concurent care vă citește documentația.

Calificarea răspunde la alte întrebări. Există o aplicație în care se potrivește echipamentul nostru, descrisă suficient de concret cât să poată fi verificată. Există un buget și în ce perioadă. Cine decide și cine poate pune veto. Și ce se întâmplă dacă nu fac nimic.

Un asistent ajută doar punând întrebările la care un cumpărător tehnic vrea să răspundă. Un inginer vă dă fără ezitare reperul, materialul, volumul și timpul de ciclu și abandonează un formular care îi cere intervalul de mărime a companiei și plaja de buget. Cel mai subevaluat rezultat este refuzul rapid: cea mai mare parte din costul unei cereri proaste este ingineria de aplicație pe care o consumă înainte ca cineva să stabilească faptul că nu s-a potrivit niciodată.

Un chatbot cu AI care răspunde din documentația dumneavoastră în loc să inventeze

Puneți-i unui model de limbaj o întrebare despre produs și va răspunde din antrenarea lui, într-o proză care seamănă exact cu documentația dumneavoastră, fără nicio legătură între cât de sigur sună și cât este de adevărat. Într-o vânzare tehnică, acesta este cel mai rău eșec disponibil, pentru că un răspuns greșit este fotografiat, redirecționat și citat înapoi către dumneavoastră într-o ședință.

Ancorarea în propriile documente este ce îl face suportabil. Întrebarea regăsește pasaje din documentele dumneavoastră, iar modelul răspunde numai din ele și le citează, ceea ce transformă eșecul obișnuit în „nu am găsit acest lucru în documentație”. Cea mai mare parte a muncii este pe partea de documente: care documente sunt de referință, care sunt înlocuite și trebuie scoase din index — păstrate în sistemul de documente așa cum cere procedura dumneavoastră de calitate, dar inaccesibile asistentului — și care sunt confidențiale.

Nu elimină eșecul. Regăsirea returnează revizia înlocuită pentru că acea revizie se potrivește textual mai bine; returnează documentul corect, iar modelul citește greșit un tabel din el; nu găsește nimic relevant și răspunde oricum din antrenare. Citarea o înrăutățește pe fiecare dintre acestea, pentru că un răspuns greșit cu un nume de document atașat este crezut mai tare.

Deci impuneți restricțiile în sistem, nu într-un document de politică: răspunde numai din material publicat, numește documentul și revizia folosite, refuză în loc să deducă la întrebări de specificație, nu dă niciodată preț sau termen de livrare. Și înregistrați fiecare întrebare la care nu a putut răspunde, pentru că jurnalul acela este o listă scrisă de clienții dumneavoastră cu ceea ce nu publicaserăți.

Datele pe care le aveți deja și ce e nevoie ca să devină utilizabile

Mai multe decât credeți, într-o stare mai proastă decât credeți. Căsuța de e-mail conține ani de cereri de ofertă și schimburi tehnice, istoricul de ofertare conține ce ați oferit și la ce preț, iar motivele de pierdere conțin cel mai valoros set de date din companie, dacă le-a completat cineva onest. ERP-ul conține duratele de aprovizionare și datele de livrare, care merită verificate înainte să vă încredeți în ele: planificat față de realizat și dacă data promisă a fost suprascrisă de fiecare dată când a alunecat.

Apoi starea lor. Același client există de trei ori scris diferit, iar filiala din Germania este un cont separat, fără legătură cu societatea-mamă, așa că nimeni nu vede că grupul a cumpărat deja două linii. Iar motivul pierderii este „prețul” pe majoritatea fișelor, care este ce selectează oamenii atunci când motivul real a fost un răspuns lent.

Munca este lipsită de strălucire și reprezintă cea mai mare parte a proiectului: deduplicați conturile, modelați structurile de grup, stabiliți o singură locație de referință pentru documentație, cu un câmp explicit de revizie, înlocuiți motivul pierderii în text liber cu o listă scurtă din care un om de vânzări poate alege sincer. Un model construit pe aceste date moștenește fiecare eroare și o livrează cu încredere.

Predarea către un om și de ce o predare proastă distruge valoarea

Momentul în care asistentul se oprește și începe o persoană este locul în care clientul judecă întregul sistem. Un client își explică aplicația în detaliu, un om de vânzări sună două zile mai târziu și pune aceleași întrebări de la capăt, iar tot ce a câștigat automatizarea se cheltuiește în minutul acela.

O predare care funcționează duce cu ea conversația atașată oportunității, întrebarea care a provocat escaladarea, un responsabil cu nume, nu o căsuță comună, și un timp de răspuns de care răspunde cineva. Fiți onest în privința a ceea ce este asistentul, pentru că un cumpărător tehnic își dă seama în câteva schimburi de mesaje, și escaladați automat la orice angajament de specificație, orice preț, orice reclamație și ori de câte ori un client întreabă a doua oară.

Măsurarea onestă: timpul de răspuns și pipeline-ul calificat, nu mesajele trimise

Cele mai multe raportări despre aceste sisteme măsoară propria lor activitate: mesaje trimise, conversații gestionate, ore economisite printr-un multiplicator furnizat de producătorul soluției. Toate acestea cresc indiferent dacă s-a îmbunătățit ceva sau nu. Începeți în schimb cu timpul de la cerere până la primul răspuns tehnic de substanță, unde de substanță înseamnă că a abordat aplicația, nu că a confirmat primirea. Apoi timpul de la cererea de ofertă până la ofertă, pe cererile pe care le-ați acceptat ca fiind în aria dumneavoastră, și proporția celor care au ajuns la o ofertă, care scoate la iveală cererile care mor în coada unui inginer.

Măsurați cererile refuzate pe o axă separată, în câte zile au fost refuzate, pentru că acela este numărul pe care refuzul rapid există ca să îl scadă. O singură rată de ofertare calculată pe ambii numitori spune organizației să oferteze exact cererile pe care tocmai i-ați cerut să le refuze. Apoi pipeline-ul calificat, față de o definiție a calificării scrisă înainte de proiect, și numărul întrebărilor la care asistentul nu a putut răspunde, care ar trebui să scadă pe măsură ce publicați ce lipsea.

GDPR și ce așteaptă un cumpărător industrial european

Temeiul legal pentru comunicarea comercială B2B nu este uniform în Europa. Implementările naționale ale regulilor ePrivacy diferă, iar în unele state membre e-mailul comercial nesolicitat către un contact de business este tratat mult mai strict decât sugerează rezumatul obișnuit cu „interesul legitim”. Stabiliți-l cu un jurist, pe fiecare piață, și construiți sistemul astfel încât regulile să poată diferi de la o țară la alta fără o rescriere.

Restul sunt decizii de inginerie cu consecințe în achiziții. Chestionarul unui cumpărător va întreba unde este prelucrat textul cererii lui, dacă iese din UE, dacă antrenează modelul cuiva și cât timp este păstrat. Patru răspunsuri scurte vă trec de acel prim filtru: prelucrare în UE, fără antrenare pe conținutul clienților, o perioadă de păstrare definită, acces jurnalizat. În spatele filtrului stau un DPA semnat, o listă de subîmputerniciți, măsurile dumneavoastră tehnice și organizatorice și de obicei un certificat ISO 27001 sau SOC 2. Adunați-le înainte să sosească cererea.

Păstrați un om pe traseul oricărei decizii care refuză o cerere, ceea ce este atât designul corect, cât și sfârșitul discuției despre procesul decizional automatizat. Dincolo de lege, un cumpărător industrial european se așteaptă să fie tratat ca un profesionist, iar un „revin asupra discuției noastre” fabricat face mai mult rău pe o piață tehnică mică decât dacă nu ați trimite nimic.

De unde să începeți: primul proiect de AI în vânzări

Un singur flux, opt până la douăsprezece săptămâni, un responsabil cu nume în vânzări și unul în inginerie și o definiție scrisă a succesului înainte să se construiască ceva. Începeți cu traseul cererilor de ofertă primite: acolo este concentrată valoarea, iar modul de eșec este vizibil întâi pentru propriii dumneavoastră oameni.

Petreceți primele două săptămâni adunând cincizeci de cereri de ofertă reale din ultimii doi ani, cu ce s-a ofertat și ce s-a întâmplat. Acel set este testul, iar fără el evaluați pe demonstrații alese de cine le-a construit. Apoi construiți extragerea și lista informațiilor lipsă, revizuite de un inginer de aplicații față de ce s-a dovedit a fi cerința. Asistentul care vorbește cu clientul vine ultimul, pentru că numai el vorbește cu clienții nesupravegheat.

Scrieți criteriile de ieșire înainte de a începe: timpul până la primul răspuns pe un segment anume, orele de inginerie per cerere de ofertă și extragerea punctată față de acel set de referință, precizie per câmp și mai ales recall pe câmpurile care poartă riscul de ofertare. Rata de acceptare este un semnal de adopție, nu un criteriu de ieșire: odată ce inginerii știu că ea este nota, corecturile marginale încetează, iar erorile care contează sunt omisiuni pe care un recenzent care parcurge în fugă o listă îngrijită nu le va prinde. Decideți din timp ce veți refuza: comunicare în masă către exterior, orice trimitere fără revizuire, rularea acolo unde temeiul legal sau situația NDA este deschisă.

Unde se potrivește Meta Smart Factory

META CRM Bot de la MSF este produsul de pe partea de vânzări a acestei platforme; celelalte module de pe acest site — MES, APS, MRP, calitate, mentenanță, depozit — conduc fabrica. Construim ambele jumătăți, motiv pentru care argumentul de mai sus este despre succesiune și calitatea datelor, nu despre funcționalități.

Un lucru de numit, nu de ocolit: produsul acela este listat aici ca mesagerie multilingvă care funcționează non-stop, iar într-o vânzare tehnică nu aceea este partea de pornit prima. Restricțiile argumentate mai sus sunt configurare, nu marketing — redactare cu trimitere de către un om, escaladare la orice angajament de specificație, preț sau livrare, fără comunicare în masă către exterior pe o piață unde aceleași nume revin. Cereți-le în perioada de probă.

Partea care merită gândită este îmbinarea. Două întrebări domină o cerere industrială — puteți ține această caracteristică la acest ritm și va fi aici în săptămâna 34 — și la niciuna nu ar trebui să răspundă un asistent. Prima este capabilitatea procesului pe o caracteristică, o mașină și un dispozitiv de prindere anume, cu un studiu R&R care nu consumă jumătate din câmpul de toleranță, iar la un reper nou nu există istoric din care să răspunzi. A doua este o întrebare de capacitate în viitor, față de un portofoliu de comenzi care se schimbă zilnic. Livrarea la timp din trecut nu este capacitate, iar capacitatea de azi nu este capacitatea din săptămâna 34.

Ce poate face un asistent este să aducă dovezile și să le pună în fața persoanei care răspunde. Timpii de ciclu măsurați și rebutul de pe cel mai apropiat reper comparabil îi spun inginerului dumneavoastră dacă cererea justifică un studiu de capabilitate; portofoliul de comenzi din APS îi spune planificatorului dacă săptămâna 34 este plauzibilă. Data tot de la planificator vine. Dacă evidența de producție nu este de încredere, un strat de vânzări cu AI construit peste ea va oferta oricum din ea.

Deci prima conversație cu adevărat utilă nu este o demonstrație. Este o trecere în revistă a propriilor dumneavoastră cereri de ofertă recente și a ce s-a întâmplat cu fiecare, pentru că asta arată într-o după-amiază unde pierde timp vânzarea — și uneori răspunsul este că nu este partea pe care o poate repara un software.