Yapay zeka destekli bir CRM, sanayi satışında yerini daha çok hatırlatma mesajı göndererek değil, talebi doğru okuyarak kazanır

Bu cümlenin içinde iki ayrı iş saklı. Yatırım malı, dokuz ila on sekiz aylık bir döngüde komiteyle alınır; müşteri resmine göre talaşlı imalatta ise karar, resme bakılarak günler içinde verilir ve sorun döngünün uzunluğu değil, teklif talebi hacmidir. Aşağıdaki teklif talebi, niteleme ve dokümantasyon başlıkları ikisi için de geçerli; satın alma komitesi ve puanlama başlıkları yalnızca yatırım malı satışı için. Yapay zekanın her iki durumda da iyi yaptığı iş dardır: zaten elinizde olan metni yeniden biçimlendirir.

Genel amaçlı CRM otomasyonu uzun B2B satış döngüsünde neden tutmaz

Standart reçete tek bir alıcı, kısa bir değerlendirme, büyük bir pazar ve puanlamanın bir anlam ifade etmesine yetecek kadar fırsat hacmi varsayar. Bunların hiçbiri geçerli değil. Bir yatırım malı alımını, çevrim süresine bakan bir üretim mühendisi, proses yeterliliğine bakan bir kalite mühendisi, yedek parçaya bakan bir bakım şefi, ödeme şartlarına bakan bir satın almacı ve yatırım bütçesinden sorumlu bir yönetici birlikte değerlendirir. Hepsi farklı anlarda devreye girer; bu yüzden "potansiyel müşteri" diye tek bir muhataba kurgulanmış bir mesaj dizisi kimseye ulaşmaz.

Pazar da sınırlı. Ulaşılabilir alıcı kümesi, mühendisler fabrika değiştirdikçe aynı isimlerin yıllar ve şirketler boyunca tekrar tekrar karşınıza çıkacağı kadar küçük; ve hiçbir davranış modeline adı anılmaya değer bir eğitim seti sağlamayacak kadar küçük. Rahatsız edici bir otomatik mesaj burada yuvarlama hatası değildir. İsimle birlikte hatırlanır.

İşler, "teklifi inceleme fırsatınız oldu mu" diye soran bir mesaj daha eksik kaldığı için nadiren kaybedilir. Gelecek yılın yatırım listesi yazılırken ortada işe yarar bir şeyle bulunmadığınız için, teknik cevap geç döndüğü için ya da ihtiyaç hiçbir zaman kimsenin aksiyon alabileceği bir biçimde yazıya dökülmediği için kaybedilir. Bunların hiçbiri bir mesaj sıklığı sorunu değildir.

Teklif talebini okumak ve ihtiyacı ortaya çıkarmak

Teklif talepleri, müşterinin canı nasıl istediyse o biçimde gelir: bir PDF, bir Excel, bir resim seti, e-postada üç paragraf, altı alanı anlamlı olan bir satın alma şablonu. Bir model, metin olarak orada duran her şeyi — adetler ve sipariş çekiş düzeni, tarihler ve teslim şartları, istenen belgeler listesi, ticari koşullar, gövdede adı geçen parça numaraları — dosyayı açmanın aldığı sürede güvenilir biçimde çıkarır.

Kaynağı teknik resim olan alanlar bambaşka bir sınıftır. Geometrik toleranslama (GD&T), kaynak sembolleri, datum yapısı, yüzey pürüzlülüğü, kritik olarak işaretlenmiş karakteristikler: bunlar güvenilir biçimde okunmaz ve resimden gelen her veri, mühendise doğrulanmamış bir öneri olarak işaretlenmiş şekilde ulaşmalıdır; üzerinden teklif verilecek bir değer olarak değil. Bu iki sınıfa aynı muameleyi yapmak, işe yarar bir veri çıkarımından teklif hatasına giden en kısa yoldur.

Önce mülkiyet sorusunu çözün. Müşterinin resim seti onun fikri mülkiyetidir, genellikle talep gelmeden çok önce imzalanmış bir gizlilik sözleşmesine (NDA) tabidir ve havacılık, savunma ve otomotivin bazı kollarında ITAR, EAR ya da AB çift kullanımlı mallar tüzüğü kapsamında ihracat kontrolüne girebilir. Bir resim modele ulaşmadan önce NDA'nın veri işleme ve alt yükleniciler konusunda neye izin verdiğini kontrol edin; kontrole tabi işi kendi sunucunuzda (on-premise) ya da veri saklamanın ve model eğitiminin kapalı olduğu bir kurulumda tutun; işaretli müşterilerin ve parça ailelerinin bu akışa hiç girmemesi için bir hariç tutma yolu bulundurun.

Çıktının daha değerli yarısı, eksik olanlardır. İlk saat içinde geri gönderdiğiniz sorular, gönderebileceğiniz en güçlü yetkinlik sinyalidir ve bir mühendisin kimsenin kontrol etmediği bir varsayım üzerinden teklif vermesini engeller.

İşe yarar bir veri çıkarımını, mühendisin elle baştan yaptığı bir çıkarımdan iki kural ayırır. Her kalem kaynağını gösterir: kaynak bir Excel ise sayfa ve hücre, taranmış bir belge ise sayfa ve o sayfadaki bölge. Ve model, tahmin yürütmek yerine alanı boş bırakır — bu, modele "emin değilsen boş bırak" demekle elde edilen bir davranış değil, kendi test setinizde alan bazında ölçtüğünüz bir orandır. Boş bırakma, akla yatkın bir varsayılan değerin bulunduğu yerde çöker; bir toleransta ya da standart bir yüzey pürüzlülüğünde olduğu gibi. Dolayısıyla boş bırakma oranı düşük, hata oranı yüksek olan bir alanı insana bırakırsınız.

Şirketi taahhüt altına sokmadan ilk teknik yanıtı hazırlamak

Değerlendirmeye girip girmediğinizi ilk yanıt belirler. İyi bir ilk yanıt, müşteriye ilgisi için teşekkür etmek yerine uygulamayı adıyla anar, ihtiyacı anladığı şekliyle yeniden ifade eder, cevabı değiştirecek iki üç soruyu sorar ve tarihi belli bir sonraki adımı taahhüt eder.

Bu iskeleti bir model bir dakikada kurar; düzeltip gönderen insandır. Otomatik göndermek, aynı sistemin farklı bir ayarı değil, başka bir sistemdir; ve hiçbir taslak şartname beyan etmez: teklife dönüşme ihtimali olan her rakam, onu taahhüt etme yetkisi olan birinden gelir.

Müşteri geçmişini özetlemek ve CRM kaydını güncel tutmak

On dört aydır süren bir fırsat; yüz e-postaya, üç ziyarete, iki numune üretimine ve başarısız bir denemeye yayılmıştır. Geçmiş kayıtlıdır ve kimse okumaz; müşteri temsilcisi işten ayrıldığında pratik değeri sıfırdır. Yazışmayı okuyup bir sonraki kişiyi bilgilendiren bir model gerçekten işe yarar.

Aynı zamanda kayıplıdır ve dışarıda kalan şey, orantısız biçimde, ortalarda bir yere gömülmüş tek satırlık taahhüttür: verilen tolerans tavizi, belirli bir süre için sabitlenen fiyat, telefonda kabul edilen istisna. Neredeyse doğru olan ve verilen tavizi sessizce atlayan bir özet, hiç özet olmamasından kötüdür. Bu yüzden onu yazışmaya giriş kapısı olarak kullanın, her ifadeyi geldiği mesaja bağlayın ve taahhütleri kaynak gösterilmiş ayrı bir listeye çıkarın.

Aynı yetenek, CRM'in en eski sorununa da dokunuyor. Satışçılar kayıtları güncellemez, çünkü güncellemek geri hiçbir şey vermeyen bir veri girişidir; çözüm de üretim sahasında geçerli olanla aynı: talep etme, öner. Bir görüşmenin ardından asistan notu yazar, aşama değişikliğini ve bir sonraki aksiyonu önerir. Bunlar öneri olarak kalır; çünkü değerleri ya da kapanış tarihlerini sessizce değiştiren bir asistan, bir CRM'in olmak zorunda olduğu tek şeyi, insanların inandığı bir kaydı yok eder.

Yapay zeka destekli CRM, hâlihazırda kullandığınız sistemin yerini mi alır yoksa üstüne mi oturur

Çoğunlukla üstüne oturur. Müşteri, fırsat ve sipariş kaydı olduğu yerde kalır; ister Salesforce, Dynamics, HubSpot, Odoo olsun, ister ERP'nizin CRM modülü. Asistan bu kayıttan, posta kutusundan, teklif arşivinden ve doküman arşivinden okur ve geriye üç şey yazar: bir not, önerilmiş bir alan değişikliği ve sahibi ile tarihi belli bir görev — hepsi kime ait olduğu belli ve geri alınabilir.

Yani proje modelin kendisi değil, entegrasyondur; ve genellikle tökezleyen şey, CRM, ERP ve doküman sistemi arasındaki yolculuktan sağ çıkması gereken tekil kimliktir — çünkü müşteri kaydı anahtarı ile cari hesap numarası hiçbir zaman eşleştirilmemiştir. CRM'iniz yoksa önce CRM gelir: bir asistan, var olmayan bir kaydı güncel tutamaz.

Yapay zekanın iyi olmadığı şeyler ve size nerede pahalıya mal olacağı

Sizin yeteneğinizi bilmez: toleransın tutturulabilir olduğunu ama yalnızca ikinci operasyonda tutturulabildiğini, bir alaşımın sizin proseste yapıştığını, belirtilen yıllık adedin o segmentin bugüne dek sipariş ettiğinin birkaç katı olduğunu. Ticari sonuç duygusu yoktur; termin süresi hakkında iddialı bir cümleyi, temkinli bir cümle kadar kolay yazar, çünkü ikisi de dilbilgisi açısından kusursuz cümlelerdir. Dokümanları ona verdikten sonra neyin değiştiğini de bilmez; bu da doküman güncelliğini bir kurulum işi değil, süregelen bir operasyon sorumluluğu yapar.

Teknik alıcıya saygı gösteren bir niteleme: puanlama neden niteleme değildir

Puanlama, davranıştan bir sayı üretir: gezilen sayfalar, açılan e-postalar, indirilen dokümanlar. Gerçek alıcı sayısının bu kadar az olduğu bir pazarda bu, çoğunlukla merakı ölçer; en güvenilir biçimde ödüllendirdiği profil ise dokümantasyonunuzu okuyan bir rakip mühendisidir.

Niteleme başka soruları yanıtlar. Ekipmanımızın oturduğu, kontrol edilebilecek kadar somut tarif edilmiş bir uygulama var mı. Bütçe var mı, hangi dönemde. Kim karar veriyor ve kim veto edebiliyor. Ve hiçbir şey yapmazlarsa ne olur.

Bir asistan yalnızca teknik alıcının cevaplamak isteyeceği soruları sorarak yardımcı olur. Bir mühendis parçayı, malzemeyi, adedi ve çevrim süresini seve seve verir; şirket çalışan sayısı aralığı ve bütçe bandı isteyen bir formu ise yarıda bırakır. En hafife alınan çıktı hızlı hayırdır: kötü bir talebin maliyetinin büyük kısmı, hiç oturmadığı anlaşılana kadar tükettiği uygulama mühendisliğidir.

Uydurmak yerine kendi dokümantasyonunuzdan cevap veren bir sohbet robotu

Bir dil modeline ürünle ilgili bir soru sorun; eğitim verisinden, tam olarak sizin dokümantasyonunuz gibi okunan bir dille cevap verir ve kulağa ne kadar emin geldiği ile doğru olup olmadığı arasında hiçbir ilişki bulunmaz. Teknik bir satışta bu, olabilecek en kötü hatadır; çünkü yanlış cevabın ekran görüntüsü alınır, iletilir ve bir toplantıda size karşı okunur.

Bunu yaşanabilir kılan şey, cevabı kendi dokümanlarınıza dayandırmaktır. Soru, kendi dokümanlarınızdan ilgili bölümleri getirir; model yalnızca onlardan cevap verir ve kaynak gösterir. Böylece sık görülen hata, "bunu dokümantasyonda bulamadım" cevabına dönüşür. İşin büyük kısmı doküman tarafındadır: hangi dokümanlar geçerli, hangileri yürürlükten kalkmış ve indeksten çıkarılmalı — kalite prosedürünüzün gerektirdiği gibi doküman sisteminde saklanmaya devam eder ama asistanın erişemeyeceği yerde durur — ve hangileri gizli.

Bu, hatayı ortadan kaldırmaz. Arama, metinsel olarak daha iyi eşleştiği için yürürlükten kalkmış revizyonu getirir; doğru dokümanı getirir ama model içindeki bir tabloyu yanlış okur; ilgili hiçbir şey bulamaz ve yine de eğitim verisinden cevap verir. Kaynak gösterimi bunların her birini daha da kötüleştirir, çünkü yanına doküman adı iliştirilmiş yanlış bir cevaba daha çok inanılır.

Bu yüzden kısıtları bir politika dokümanında değil, sistemin içinde zorunlu kılın: yalnızca yayımlanmış dokümanlardan cevap ver, kullandığın dokümanı ve revizyonu belirt, şartname sorularında çıkarım yapmak yerine cevabı reddet, hiçbir koşulda fiyat ya da termin süresi verme. Ve cevaplayamadığı her soruyu kayda geçirin; çünkü o kayıt, müşterilerinizin sizin adınıza yazdığı "yayımlamadıklarınız" listesidir.

Zaten elinizde olan veri ve onu kullanılabilir hale getirmenin bedeli

Sandığınızdan çok, sandığınızdan kötü durumda. Posta kutusunda yıllara yayılmış teklif talepleri ve teknik yazışmalar duruyor; teklif geçmişinde neyi hangi fiyata verdiğiniz duruyor; kaybedilen iş nedenlerinde ise — dürüstçe doldurulmuşsa — şirketin en değerli veri seti duruyor. ERP'de termin süreleriniz ve teslim tarihleriniz var; onlara güvenmeden önce kontrol etmeye değer: planlanana karşı gerçekleşen ve söz verilen tarihin her kaydığında üzerine yazılıp yazılmadığı.

Sonra verinin hali. Aynı müşteri farklı yazımlarla üç kez kayıtlı; Almanya'daki iştiraki ana şirketle hiçbir bağı olmayan ayrı bir kayıt, dolayısıyla grubun zaten iki hat satın aldığını kimse görmüyor. Kaybetme nedeni de kayıtların çoğunda "fiyat" — ki bu, gerçek neden yavaş dönen bir cevap olduğunda insanların seçtiği şıktır.

İş cazip değil ve projenin büyük kısmı bu: mükerrer müşteri kayıtlarını birleştirin, grup şirketi yapısını modelleyin, açık bir revizyon alanı olan tek bir geçerli dokümantasyon konumunda anlaşın, serbest metin kaybetme nedenini bir satışçının dürüstçe seçebileceği kısa bir listeyle değiştirin. Bu verinin üzerine kurulan bir model, her hatayı devralır ve onu kendinden emin bir dille size geri verir.

İnsana devir ve kötü bir devrin değeri neden yok ettiği

Müşteri, sistemin tamamını asistanın durup bir insanın devraldığı anda değerlendirir. Müşteri uygulamasını ayrıntısıyla anlatır, iki gün sonra bir satışçı arar ve aynı soruları baştan sorar; otomasyonun kazandırdığı her şey o bir dakikada harcanır.

İşleyen bir devir şunları taşır: fırsata iliştirilmiş görüşme kaydı, devri tetikleyen soru, ortak bir posta kutusu değil adı konmuş bir sahip ve birinin hesabını verdiği bir yanıt süresi. Asistanın ne olduğu konusunda dürüst olun; teknik alıcı bunu birkaç mesaj içinde zaten anlar. Şartname taahhüdü içeren her konuda, her fiyatta, her şikâyette ve müşteri aynı şeyi ikinci kez sorduğu her seferde otomatik olarak insana devredin.

Dürüstçe ölçmek: gönderilen mesaj sayısı değil, yanıt süresi ve nitelikli fırsat havuzu

Bu sistemlerle ilgili raporlamanın çoğu, sistemin kendi faaliyetini ölçer: gönderilen mesaj, yürütülen görüşme, tedarikçinin verdiği bir katsayıyla hesaplanmış tasarruf edilen saat. Bir şey iyileşsin ya da iyileşmesin, bunların hepsi yükselir. Onun yerine talebin gelişinden ilk anlamlı teknik yanıta kadar geçen süreyle başlayın; anlamlıdan kasıt, yanıtın alındı teyidi vermek yerine uygulamaya değinmiş olmasıdır. Sonra kapsam içinde kabul ettiğiniz talepler için teklif talebinden teklife geçen süre ve bunların teklife dönüşen oranı; bu oran, bir mühendisin kuyruğunda ölen talepleri ortaya çıkarır.

Reddettiğiniz talepleri ayrı bir eksende ölçün: reddetmenin kaç gün aldığını. Çünkü hızlı hayırın düşürmek için var olduğu sayı budur. Her iki paydayı tek bir teklif verme oranında birleştirmek, organizasyona az önce reddetmesini söylediğiniz taleplere teklif vermesini söyler. Sonra, projeden önce yazılmış bir "nitelikli" tanımına göre nitelikli fırsat havuzu ve asistanın cevaplayamadığı soruların sayısı — ki eksik olanı yayımladıkça bu sayı düşmeli.

GDPR ve bir Avrupalı sanayi alıcısının beklediği şeyler

B2B iletişimin hukuki dayanağı Avrupa genelinde tek tip değil. ePrivacy kurallarının ulusal uygulamaları farklılık gösteriyor ve bazı üye devletlerde, bir kurumsal muhataba izinsiz gönderilen ticari e-posta, alışılmış "meşru menfaat" özetinin ima ettiğinden çok daha katı ele alınıyor. Bunu her pazar için hukuk danışmanınızla karara bağlayın ve sistemi, kurallar ülkeye göre değişebilsin diye baştan yazmayı gerektirmeyecek şekilde kurun.

Geri kalanı, satın alma sonuçları olan mühendislik kararlarıdır. Bir alıcının soru formu; talep metninin nerede işlendiğini, AB dışına çıkıp çıkmadığını, herhangi birinin modelini eğitip eğitmediğini ve ne kadar süre saklandığını soracaktır. Dört kısa cevap sizi o ilk elemeden geçirir: işleme AB içinde, müşteri içeriğiyle model eğitimi yok, tanımlı bir saklama süresi var, erişim loglanıyor. Elemenin arkasında imzalı bir veri işleme sözleşmesi (DPA), bir alt işleyen listesi, teknik ve idari tedbirleriniz ve genellikle bir ISO 27001 ya da SOC 2 belgesi durur. Bunları talep gelmeden önce hazırlayın.

Bir talebi reddeden her kararın yolunda bir insan bulundurun; bu hem doğru tasarım hem de otomatik karar verme tartışmasının sonu demektir. Hukukun ötesinde, bir Avrupalı sanayi alıcısı kendisine bir profesyonel gibi davranılmasını bekler; uydurulmuş bir "görüşmemizin devamı olarak" cümlesi, küçük bir teknik pazarda hiçbir şey göndermemekten daha çok zarar verir.

Nereden başlamalı: satışta ilk yapay zeka projesi

Tek bir iş akışı, sekiz ila on iki hafta, satışta bir ve mühendislikte bir adı konmuş sahip ve hiçbir şey kurulmadan önce yazıya dökülmüş bir başarı tanımı. Gelen teklif talebi akışıyla başlayın: değer orada yoğunlaşıyor ve hata durumunu önce kendi insanlarınız görüyor.

İlk iki haftayı, son iki yıldan elli gerçek teklif talebini — neyin teklif edildiği ve sonunda ne olduğuyla birlikte — toplamaya ayırın. Test seti odur; o olmadan, sistemi kuranın seçtiği demolar üzerinden değerlendirme yaparsınız. Sonra veri çıkarımını ve eksik bilgi listesini kurun; bir uygulama mühendisi bunları, ihtiyacın sonunda ne çıktığıyla karşılaştırarak gözden geçirsin. Müşteriyle konuşan asistan en sona kalır, çünkü müşteriyle gözetimsiz konuşan tek bileşen odur.

Çıkış kriterlerini başlamadan önce yazın: adı konmuş bir segmentte ilk yanıt süresi, teklif talebi başına mühendislik saati ve veri çıkarımının o referans veri setine göre puanlanması — alan bazında precision ve her şeyden önce teklif riski taşıyan alanlarda recall. Kabul oranı bir çıkış kriteri değil, benimsenme sinyalidir: mühendisler puanın bu olduğunu öğrendiği anda sınırdaki düzeltmeler kesilir; asıl önemli hatalar ise, derli toplu bir listeyi göz gezdirerek okuyan bir kontrolcünün yakalayamayacağı atlamalardır. Neyi reddedeceğinize önceden karar verin: hacimli giden iletişim, gözden geçirilmeden gönderen her şey, hukuki dayanağın ya da NDA durumunun açıkta olduğu yerde çalıştırmak.

Meta Smart Factory bu resmin neresinde

MSF'nin META CRM Bot ürünü, bu platformun satış tarafındaki bileşenidir; bu sitedeki diğer modüller — MES, APS, MRP, kalite, bakım, depo — fabrikayı çalıştırır. İki yarıyı da biz geliştiriyoruz; yukarıdaki yazının özelliklerden çok sıralama ve veri kalitesi üzerine olmasının sebebi de bu.

Üstünden geçmek yerine adını koymak gereken bir nokta var: o ürün burada, günün her saati çalışan çok dilli mesajlaşma olarak anlatılıyor ve teknik bir satışta ilk açılacak bileşen o değil. Yukarıda savunulan kısıtlar pazarlama değil, konfigürasyondur — taslağı model hazırlar, gönderen insandır; şartname, fiyat ya da teslimat taahhüdü içeren her konuda insana devir; aynı isimlerin tekrar tekrar karşınıza çıktığı bir pazarda hacimli giden iletişim yok. Bunları bir deneme kurulumunda isteyin.

Asıl üzerinde düşünülmeye değer yer, ek yeridir. Bir sanayi talebine iki soru hâkimdir — bu karakteristiği bu tempoda tutturabiliyor musunuz ve 34. haftada burada olur mu — ve ikisi de bir asistanın cevaplaması gereken sorular değildir. Birincisi, belirli bir karakteristik, tezgâh ve bağlama aparatı üzerinde, tolerans bandının yarısını yiyip bitirmeyen bir ölçüm sistemi analiziyle birlikte proses yeterliliği sorusudur ve yeni bir parçada cevap verilecek bir geçmiş yoktur. İkincisi, her gün değişen bir sipariş defterine karşı ileriye dönük bir kapasite sorusudur. Geçmişteki zamanında teslimat performansı kapasite değildir ve bugünkü kapasite 34. haftanın kapasitesi değildir.

Bir asistanın yapabileceği şey, kanıtı toplayıp cevabı verecek kişinin önüne koymaktır. En yakın benzer parçadaki ölçülmüş çevrim süreleri ve fire oranları, mühendisinize bu talebin bir yeterlilik çalışmasını hak edip etmediğini söyler; APS'deki sipariş defteri de planlamacınıza 34. haftanın gerçekçi olup olmadığını söyler. Tarihi yine planlamacı verir. Üretim kaydı güvenilir değilse, onun üzerine kurulmuş bir yapay zeka satış katmanı yine de o kayıttan teklif verir.

Dolayısıyla daha işe yarar ilk görüşme bir demo değildir. Kendi son teklif taleplerinizin ve her birine ne olduğunun birlikte gözden geçirilmesidir; çünkü bu, satışın zamanı nerede kaybettiğini bir öğleden sonrada gösterir — ve bazen cevap, kaybın yazılımın düzeltebileceği yerde olmadığıdır.