Bu kararın zor tarafı, karar anında elinizde yeterli bilgi olmamasıdır. Şirket CRM'i henüz kullanmamıştır, ekibin sistemle nasıl çalışacağı tahminden ibarettir, süreçlerin yazılı hali çoğu zaman yoktur. Dolayısıyla kapsam, bilinen her ihtiyacı tek seferde kapsayacak şekilde değil, öğrenmeye izin verecek şekilde çizilmelidir.

Pratikte şu ayrımı yapmak işe yarar. Bir talebin ilk faza girip girmeyeceğini belirleyen soru, o talebin önemli olup olmadığı değildir. Neredeyse her talep bir yerde önemlidir. Doğru soru şudur: bu olmadan ekip sistemi günlük işinde kullanabilir mi? Cevap evetse o talep ikinci faza bırakılabilir.

Bu noktada sık yapılan hata, aşama sayısını olduğundan fazla tutmaktır. Her ara adımın ayrı bir aşama olması gerekmez. Bir aşamanın var olması için o aşamada fırsatın gerçekten beklediği ve yönetimin o bekleyen fırsatlarla ilgili bir karar verdiği bir durum olmalıdır.

Mevcut süreci kurmanın bir faydası daha vardır. Ekip sistemde kendi çalışma biçimini gördüğünde CRM'i kendisine dayatılan bir yük olarak değil, zaten yaptığı işin kaydı olarak algılar. Süreci kurulum sırasında değiştirirseniz, ekip aynı anda hem yeni bir yazılım hem de yeni bir çalışma biçimi öğrenmek zorunda kalır. Bu iki değişikliği aynı haftaya sıkıştırmak, ikisinin de yarım kalmasına yol açar.

Omurgayı kurarken şu soruya net cevap verin: aynı müşteriyle birden fazla iş yapıyorsanız, bu işlerin her biri ayrı bir kayıt mı, yoksa tek kaydın farklı satırları mı? Cevap sektöre göre değişir ve veri modelinin tamamını belirler.

Kullanıcı ekranlarını tasarlarken yöneticinin değil, temsilcinin bakış açısını temel alın. Yöneticinin ihtiyacı rapordur ve rapor zaten temsilcinin doldurduğu veriden üretilir. Temsilci doldurmuyorsa rapor da yoktur.

Raporu az tutmanın bir faydası daha vardır. Yönetim az sayıda rapora bakarsa, o raporların beslendiği alanların doğru doldurulması ekip için somut bir beklentiye dönüşür. Otuz raporun olduğu bir sistemde hiçbir alanın doldurulması gerçek anlamda takip edilemez.

Birincisi, hazır başlamışken diğer sistemi de bağlayalım talebidir. Entegrasyon ilk fazda yalnızca bir koşulda yapılmalıdır: o entegrasyon olmadan kullanıcı aynı veriyi iki yere girmek zorunda kalıyorsa. Diğer tüm entegrasyonlar bekleyebilir. Hangi verinin hangi sistemde yaşayacağı kararı, iki sistem de canlıdayken çok daha isabetli verilir.

İkincisi, geçmiş verinin tamamını taşıyalım talebidir. Veri taşıma kararı hacimle değil, kullanımla verilmelidir. Satış ekibinin bugün gerçekten baktığı dönem neyse, ilk fazda taşınacak veri odur. Arşiv niteliğindeki eski kayıtlar ikinci fazda, hatta çoğu zaman hiç taşınmadan ayrı bir yerde tutulabilir.

Üçüncüsü, raporda şu kırılım da olsun talebidir. Bu talep neredeyse her zaman yeni bir alan açılması anlamına gelir ve yeni alan, onu dolduracak kullanıcı için yeni bir yük demektir. Rapor kırılımı istemek kolaydır, o kırılımı besleyecek veriyi her gün girmek zordur. Talebi karşılarken ikinci kısmı da konuşun.

Dördüncüsü, yönetimden gelen ve tartışmaya kapalı görünen taleptir. Bu talepler genelde bir yöneticinin önceki şirketinde gördüğü bir kurguyla gelir ve ekip bunu sorgulamaz. Burada yapılması gereken talebi reddetmek değil, talebin hangi kararı besleyeceğini sormaktır. Cevap netse talep ilk faza girer. Cevap belirsizse, o kurgunun ikinci fazda gerçek veriyle tasarlanması hem daha isabetli hem de daha ucuz olur.

Bu dört talebin ortak noktası, hiçbirinin kötü niyetle gelmemesidir. Hepsi şirketin işine yarayacağı düşünülerek istenir. Kapsamı korumak, bu taleplere hayır demek değil, hepsine bir sıra numarası vermektir.

Pratikte ilk fazı satış modülü, temel veri modeli, kullanıcı ekranları ve birkaç raporla sınırlı tutmak, ikinci fazda otomasyon, puanlama ve ek departmanlarla genişletmek işleyen bir düzendir. Kurulum sürecinin adım adım nasıl ilerlediğini ve hangi kararların hangi aşamada verildiğini Zoho kurulum ve devreye alma sayfamızda ayrıntılı anlattık.

Projenin hangi çalışma modeliyle yürütüleceği de kapsam kararıyla doğrudan bağlantılıdır. Kapsamı net çizilmiş bir ilk faz ile açık uçlu ilerleyen bir iyileştirme çalışması farklı modellerle yürütülür, bu modelleri ve hangi durumda hangisinin tercih edildiğini çalışma modelleri sayfamızda şeffaf biçimde paylaşıyoruz.

Farklı sektörlerde kapsamın nasıl çizildiğini merak ediyorsanız, anonimleştirilmiş proje örneklerimizde her projenin hangi ihtiyaçla başladığını ve nerede sınır çizildiğini görebilirsiniz.

•  Bir talebin ilk faza girip girmeyeceğini belirleyen soru, o talep olmadan ekibin sistemi günlük işinde kullanıp kullanamayacağıdır.

•  İlk fazın değişmez dört başlığı: sahadaki gerçek satış akışı, veri modelinin omurgası, kullanıcının günlük işini bitiren ekranlar ve yönetimin baktığı birkaç rapor.

•  Puanlama, gelişmiş otomasyon ve tahminleme ikinci faza bırakılır, çünkü doğru kurgulanmaları için sistemde gerçek veri gerekir.

•  İkinci faza geçiş takvimle değil üç işaretle belirlenir: ekip hatırlatmasız kullanıyor, raporlar güvenilir, talepler deneyimden geliyor.

Süre, kapsamın genişliğine, karar vericilerin erişilebilirliğine ve taşınacak verinin durumuna göre değişir. Bu yüzden sayfalarımızda örnek süre vermiyoruz. Süreyi en çok etkileyen üç kalem şunlardır: kaç farklı satış sürecinin sisteme gireceği, başka bir sistemden veri taşınıp taşınmayacağı ve kurulum sırasında kararların ne hızda verilebildiği.

İkinci faz ek maliyet anlamına mı geliyor?

İkinci faz ayrı bir çalışmadır ve kendi eforu vardır. Ancak kapsamı baştan geniş tutmanın maliyeti de ortadan kalkmaz, sadece tek faturada görünür. Fazlı ilerlemenin avantajı, ikinci fazda yapılacak işin tahmine değil gerçek kullanıma dayanması ve bu sayede boşa kurulan yapıya ödeme yapılmamasıdır.

Kapsam dışı bıraktığımız bir konu kritik çıkarsa ne yapıyoruz?

Kapsam bir sözleşme metni değil, bir öncelik sıralamasıdır. İlk faz sırasında kritik olduğu anlaşılan bir konu öne alınabilir, karşılığında başka bir madde ikinci faza kayar. Önemli olan toplam kapsamın kontrolsüz büyümemesidir, sıranın hiç değişmemesi değil.

Küçük bir ekibiz, yine de fazlara bölmemiz gerekir mi?

Ekip küçüldükçe fazlı ilerlemenin önemi artar. Küçük ekiplerde CRM'i kurgulayacak ayrı bir sistem yöneticisi genelde yoktur, kurulum sırasında verilen kararları aynı kişiler günlük işlerinin arasında verir. Kapsamı dar tutmak bu durumda karar yükünü de azaltır.

Bunu yapmak zorunlu hale geliyor, çünkü alıcı davranışında ölçülebilir bir kayma var. G2'nin Mart 2026'da 1.076 B2B karar vericiyle yaptığı araştırmaya göre yazılım araştırmasına doğrudan bir yapay zeka sohbet aracıyla başlayanların oranı %51'e çıktı; bir yıl önce bu oran %29'du. Aynı araştırmada katılımcıların %71'i yazılım araştırmasında yapay zeka sohbet araçlarından faydalandığını, %69'u bu araçların yönlendirmesiyle başlangıçta düşündüğünden farklı bir tedarikçiye yöneldiğini, %33'ü ise daha önce tanımadığı bir tedarikçiden satın aldığını söylüyor.

Bu yazıda bu trafiğin neden ölçülmesi zor olduğunu, CRM tarafında hangi yapının kurulması gerektiğini ve kanal görünür hale geldiğinde hangi kararların verilebileceğini ele alıyoruz.

Birincisi yukarıdaki G2 araştırması. Dikkat çekici olan tek başına %51 oranı değil, bir yılda %29'dan %51'e çıkan hız. B2B alıcı davranışı genelde yavaş değişir; bu hızda bir kayma sık görülmüyor.

İkincisi atıf tarafı. Demandbase verisine göre ChatGPT kaynaklı B2B site trafiği bir yıl içinde yaklaşık dört katına çıktı. Yani sadece araştırma davranışı değişmiyor, bu davranış siteye tıklama olarak da yansıyor.

Bu iki veriyi birleştirdiğinizde tablo şu: alıcı, sizinle temas etmeden önce hakkınızda bir değerlendirme yapıyor ve bu değerlendirmeyi sizin sayfanızda değil bir modelin cevabında yapıyor. Sonra ya sizi listeye dahil ediyor ya etmiyor.

✓  Referrer bilgisi çoğu zaman kayboluyor. Kullanıcı asistanın verdiği cevaptaki bağlantıya tıkladığında kaynak bilgisi her zaman taşınmıyor. Taşınmadığında oturum doğrudan trafik olarak kaydediliyor.

✓  Kullanıcı bağlantıya hiç tıklamıyor olabilir. Asistan markanızı söylüyor, kullanıcı markanızı ayrı bir sekmede arıyor veya doğrudan adresi yazıyor. Bu durumda kanal marka araması veya doğrudan trafik olarak görünüyor ve gerçek tetikleyici kayıt altına girmiyor.

✓  Yolculuk tek oturumda tamamlanabiliyor. Asistan zaten karşılaştırmayı yapmış, kullanıcı doğrulama için geliyor ve formu aynı oturumda dolduruyor. Kısa oturum süresi ve tek sayfa görüntüleme, bu ziyaretçiyi analitik tarafında ilgisiz bir ziyaretçi gibi gösteriyor.

Sonuç şu: analitik aracınızdaki kanal raporu bu kanalı olduğundan küçük gösteriyor. Kanalın gerçek büyüklüğünü öğrenmenin en güvenilir yolu, ziyaretçiye sormak ve cevabı CRM'de tutmak.

Birincisi zorunlu olmaması. Zorunlu yapıldığında form terk oranı artıyor ve gelen cevapların kalitesi düşüyor, çünkü insanlar geçmek için ilk seçeneği işaretliyor.

İkincisi seçeneklerin ziyaretçinin diliyle yazılması. "Organik arama" ziyaretçinin kullandığı bir ifade değil. "Google'da ararken buldum" ve "ChatGPT gibi bir yapay zeka asistanı önerdi" ziyaretçinin tanıdığı ifadeler.

Üçüncüsü serbest metin seçeneğinin açık bırakılması. Beklemediğiniz cevaplar bu alandan geliyor ve kanal listesini güncellemeniz gereken anı da bu cevaplar haber veriyor.

Örnek: sistem oturumu doğrudan trafik olarak kaydetmiş, ziyaretçi ise formda yapay zeka asistanı önerdi diye işaretlemiş. Bu iki kaydı tek alanda tutarsanız biri diğerini eziyor. İki ayrı alanda tuttuğunuzda arada bir fark oluşuyor ve o fark tam olarak ölçmek istediğiniz şey.

Dönem sonunda bu iki alanı karşılaştırmak, analitik aracınızın bu kanalı ne kadar eksik gördüğünü de gösteriyor. Bu bilgi, bütçe konuşmasında analitik raporundan daha güvenilir bir dayanak oluyor.

✓  İçerik yapısı kararı. Bu kanaldan gelen ziyaretçiler belirli sayfalara düşüyorsa, o sayfaların yapısı asistanların alıntılamaya uygun biçimde düzenlenmeye değer. Soru bazlı başlıklar, cevabı öne alan giriş, SSS bölümü ve kaynak gösterme bu tarafta doğrudan etki ediyor.

✓  Ürün sayfası derinliği kararı. Asistanlar karşılaştırma yaparken ürün ve fiyat bilgisinin net olduğu sayfaları tercih ediyor. Fiyat ve özellik bilgisini belirsiz bırakan sayfalar bu karşılaştırmanın dışında kalıyor.

✓  Satış konuşması kararı. Bu kanaldan gelen aday, karşılaştırmayı zaten yapmış olarak geliyor. Satış görüşmesinin tanıtımla başlaması gereksiz; doğrulama ve itiraz karşılama ile başlaması daha verimli. Bu bilgi CRM'de işaretliyse satış temsilcisi görüşmeye buna göre hazırlanabiliyor.

Üçüncü madde en çok atlanan madde. Kaynak bilgisi pazarlama raporu için değil, satış konuşmasını değiştirmek için de kullanılabilir.

Yöntem şu: alıcınızın soracağı soruları alıcının diliyle yazın ve asistanlara sorun. Kendi ürün adınızı içeren sorular değil, kategori sorularını sorun. "Zoho CRM iyi mi" sorusu size bir şey öğretmez, çünkü zaten markayı içeriyor. "Türkiye'de küçük bir ekip için hangi CRM uygun" sorusu öğretir, çünkü listeye girip girmediğinizi gösterir.

Test ederken üç şeyi kaydedin:

•  Cevapta yer alıyor musunuz, hangi sırada ve hangi nitelemeyle

•  Cevapta kimler var, yani asistan sizi kimlerle aynı kümede değerlendiriyor

•  Cevabın kaynak olarak gösterdiği sayfa hangisi, sizin sayfanız mı yoksa üçüncü bir site mi

Üçüncü madde en çok bilgi taşıyan madde. Asistan sizi anlatırken kaynak olarak kendi sayfanızı değil bir dizin sitesini veya bir haberi gösteriyorsa, o konuda sizin sayfanız yeterince açık yazılmamış demektir. Düzeltilecek yer de tam olarak orası.

Bu testi ayda bir kez, sabit bir soru listesiyle yapmak yeterli. Soru listesi sabit kalmalı, çünkü değişimi görmek için karşılaştırma noktası gerekiyor. Cevaplar zaman içinde değişiyor ve bu değişim içerik çalışmasının işe yarayıp yaramadığına dair en hızlı geri bildirim.

Somut bir örnek: bir yönetici sektör etkinliğinde markanızı duyuyor, iki hafta sonra bir asistana o alanda çözüm sorduğunda markanız da cevapta çıkıyor, ardından sitenize geliyor. Bu yolculukta atıf tek bir kanala verilemez. Etkinlik olmasa asistan cevabı ilgi çekmeyebilirdi; asistan cevabı olmasa etkinlik hatırlanmayabilirdi.

O yüzden bu kanalı ölçerken doğru soru "kaç fırsat bu kanaldan geldi" değil, "kaç fırsatın yolculuğunda bu kanal geçti". İkinci soru daha zor ölçülür ama daha doğru cevap verir. Kaynak detayı ve atıf kanalı alanlarını ayrı tutmanın bir faydası da bu: aynı fırsat için birden fazla temas noktası kaydedilebilir hale geliyor.

✓  Kaynak alanı özelleştirme: Kaynak ve kaynak detayı alanları seçim listesi olarak tanımlanabilir, zorunluluk ve doğrulama kuralları alan bazında ayarlanabilir.

✓  Müşteri adayı yönetimi: Gelen adayın hangi kanaldan geldiğine göre atama ve önceliklendirme kuralları kurulabilir. Karar aşamasına yakın gelen adayın daha hızlı temas alması bu şekilde sağlanır.

✓  Raporlama: İlk temas kanalı ile atıf kanalı arasındaki farkı gösteren bir rapor kurulabilir. Bu rapor, kanalın gerçek büyüklüğüne dair en güvenilir iç veri kaynağınız oluyor.

✓  Web sitesi tarafındaki ölçüm: Ziyaretçi davranışının sayfa bazında izlenmesi ve dönüşüm noktalarının test edilmesi, hangi sayfaların bu kanaldan trafik aldığını görmenizi sağlar.

•  Aynı araştırmada alıcıların %69'u yapay zekanın yönlendirmesiyle başlangıçta düşündüğünden farklı bir tedarikçiye yöneldiğini söylüyor.

•  Bu trafik analitik tarafında büyük ölçüde doğrudan trafik olarak görünüyor; kanalı görünür kılmanın en güvenilir yolu ziyaretçiye sormak ve cevabı CRM'de tutmak.

•  Kurulumun üç parçası var: kaynak taksonomisine yeni bir değer eklemek, doğru kurgulanmış bir "bizi nasıl buldunuz" alanı ve ilk temas kanalı ile atıf kanalının ayrı tutulması.

•  Kendi verimizde bu kanalın hacmi küçük ama dönüşüm eğilimi diğer kanalların üzerinde; taban küçük olduğu için oran paylaşmıyoruz.

•  Ayda bir kez sabit bir kategori sorusu listesiyle asistanlara sorarak cevapta görünüp görünmediğinizi test edin; asistanın hangi sayfayı kaynak gösterdiği en çok bilgi taşıyan veri.

•  Kanalı tek atıf modeliyle değerlendirmeyin; doğru soru kaç fırsatın yolculuğunda bu kanalın geçtiği.

Bu yazıda kayıt bazlı bir sahiplik tablosu, akış yönü kararı, çakışma çözüm kuralları ve senkron sıklığı üzerine somut bir çerçeve bulacaksınız. Türkiye'de sık karşılaşılan senaryoyu esas aldık: şirkette zaten bir ERP var, CRM ikinci sistem olarak geliyor.

Bunu üç kavramla ayırmak işleri kolaylaştırır:

✓  Sahip sistem: Kaydı oluşturan ve değiştirebilen sistem. O kayıt tipinin doğrusu buradadır.

✓  Kopya taşıyan sistem: Kaydı görebilen ama değiştiremeyen sistem. Kopya sadece okunur.

✓  Paylaşılan alan: İstisnai olarak iki tarafın da yazabildiği alan. Her paylaşılan alan bir çakışma riski demektir, o yüzden sayısı mümkün olduğunca az tutulur.

Pratik kural şu: bir alanı iki tarafın da yazmasına izin veriyorsanız, o alan için hangi tarafın kazandığını yazılı olarak belirlemek zorundasınız. Belirlemediyseniz, kazanan taraf en son çalışan senkron olur ve bu rastgele bir sonuçtur.

Buradaki asıl karar şudur: cari kartı kim açar? İki seçenek var ve ikisi de çalışır, ama karışık kullanılırsa mükerrer kayıt üretir.

•  ERP'de açılır: Satış CRM'de fırsatı kazandığında finansa talep gider, cari kart ERP'de açılır ve kopyası CRM'e döner. Daha temizdir, mükerrer kayıt riski düşüktür, ama satışın hızını finansın yanıt süresine bağlar.

•  CRM'de talep başlatılır: Satış CRM üzerinden bir cari kart açılış talebi oluşturur, onay adımından geçer, ERP'de açılır ve kopya geri döner. Hız kaybı azdır ama iş akışı kurmak gerekir.

Hangisini seçtiğinizden çok, tek bir yolun açık kalması önemlidir. Hem satışın hem finansın ayrı ayrı cari kart açabildiği kurulumlar, mükerrer kayıtla ilgili sorunların büyük kısmının kaynağıdır.

Fiyat listesi ERP'de yaşamalı ve CRM'e tek yönlü akmalıdır. CRM tarafında satış temsilcisinin değiştirebileceği şey fiyat değil, iskonto talebidir. İskonto da onay akışından geçmelidir.

Ancak teklif onaylandığı anda muhasebe nesnesine dönüşme yolundadır. O yüzden akış şudur: teklif CRM'de hazırlanır ve revize edilir, onay alındığında ERP'ye sipariş olarak geçer, sipariş numarası ERP'de üretilir ve CRM'e geri döner. Böylece iki sistemde de aynı işin aynı numarayla izi kalır.

•  Bu alanın doğruluğundan hangi departman sorumlu? Sahip sistem o departmanın çalıştığı sistemdir.

•  Bu alan değiştiğinde diğer sistemde bir karar değişiyor mu? Değişmiyorsa akıtmaya gerek yoktur. Gereksiz senkron, bakım maliyeti ve hata kaynağıdır.

•  Bu alanı diğer tarafın değiştirmesi gerekiyor mu, yoksa görmesi yeterli mi? Görmesi yeterliyse alan okunur olarak açılır.

Üçüncü soru en çok atlanan sorudur. Satış ekibinin stok miktarını görmesi gerekir, değiştirmesi gerekmez. Buna rağmen birçok kurulumda stok alanı CRM tarafında yazılabilir bırakılır ve bir süre sonra kimsenin güvenmediği bir sayıya dönüşür.

Türkiye'de kurumsal müşteri eşleştirmesinde tek güvenilir anahtar vergi kimlik numarasıdır. Unvan üzerinden eşleştirme yapan kurulumlar mutlaka mükerrer kayıt üretir, çünkü aynı şirket şu varyasyonlarla girilir:

•  "ABC Yapı Sanayi ve Ticaret Anonim Şirketi"

•  "ABC Yapı San. ve Tic. A.Ş."

•  "ABC Yapı A.Ş."

•  "Abc Yapı A.Ş."

Bu dördü aynı şirkettir ve hiçbir metin karşılaştırması bunu güvenle çözmez. Vergi numarası ise tektir. Bu yüzden vergi numarası alanı hem CRM hem ERP tarafında zorunlu alan olmalı, mükerrer kontrolü bu alan üzerinden kurulmalı ve unvan yalnızca görüntüleme amaçlı kullanılmalıdır.

Şahıs firmaları ve bireysel müşteriler için aynı işlevi TCKN görür. İhracat yapan şirketlerde yurt dışı müşteride vergi numarası olmayabilir; bu durumda ülke kodu ile birlikte ikinci bir kurumsal kimlik alanı tanımlanır.

•  Müşteri adayı, fırsat ve teklif CRM'de; cari kart, fatura, tahsilat ve stok ERP'de yaşar. Ürün ve fiyat listesi tek yönlü olarak ERP'den CRM'e akar.

•  Kurumsal müşteri eşleştirmesinde tek güvenilir anahtar vergi kimlik numarasıdır; unvan üzerinden eşleştirme mükerrer kayıt üretir.

•  Paylaşılan her alan için kazanan taraf yazılı olarak belirlenmeli, belirlenemeyen durumlar için manuel bir hakem adımı tanımlanmalıdır.

•  Her veri gerçek zamanlı akmak zorunda değildir; stok ve risk limiti dışındaki çoğu veri günlük senkronla yeterli olur.

•  Sahiplik dağılımı yazılmadığında entegrasyon teknik olarak çalışır ama kimse sisteme güvenmez.

Bu testi geçen işler genelde şunlar: kayıt zenginleştirme, toplantı notu çıkarma, gelen talebin sınıflandırılması, veri eksiklerinin tespiti, rutin takip mesajlarının hazırlanması. Testi geçmeyen işler ise fiyat ve iskonto kararı, satış tahmininin sahipliği, ilişki yönetimi, itiraz karşılama ve kapanış konuşması. Ajan bu ikinci gruba yardım eder ama sahip olamaz.

Bu ayrımı yapmak, yapay zeka yatırımının işe yarayıp yaramamasını belirleyen asıl karardır. Aşağıda testin nasıl uygulandığını, hangi işin neden hangi tarafa düştüğünü ve Zoho tarafında bunun pratik karşılığını ele alıyoruz.

Elimizde bu konuda dikkat çekici bir veri var. MIT bünyesindeki NANDA girişimi tarafından 2025 yazında yayımlanan ve geniş şekilde tartışılan bir çalışmada, kurumsal üretken yapay zekâ pilotlarının yaklaşık %95’inin ölçülebilir bir kazanç üretmeden kaldığı raporlandı. Bu rakam, yapay zekânın işe yaramadığını değil; doğru işe, doğru noktada konumlandırılmadığında beklenen sonucu üretmediğini gösteriyor.

Satış tarafındaki gözlemler de benzer yönde. Sektör derlemelerinde bazı şirketlerin SDR ve BDR kadrolarını küçülttüğü, buna karşılık otomatik erişim çalışmalarının ürettiği yanıt oranlarının insan ekiplerinin seviyesinin belirgin biçimde üzerine çıkmadığı aktarılıyor.

Dolayısıyla asıl soru “Ajan kurmalı mıyım?” değil. Asıl soru, ajanı sürecin hangi adımına koymanız ve hangi adımları ona devretmemeniz gerektiği.

Ajan, girdisi belirli bir formda gelen işlerde iyi çalışır. Girdi dağınıksa ajan da dağınık çalışır ve fark edilmesi zor hatalar üretir.

Örnek üzerinden bakalım. "Gelen web formu talebini doğru satış temsilcisine yönlendir" işinde girdi yapılandırılmıştır: form alanları bellidir, sektör ve şehir bilgisi vardır, atama kuralı yazılabilir. Buna karşılık "müşterinin bu görüşmedeki gerçek endişesini tespit et ve buna göre strateji belirle" işinde girdi bir konuşmadır ve içinde söylenmeyenler de vardır. İlki devredilir, ikincisi devredilmez.

Soru 2: Doğru Sonuç Önceden Tanımlanabilir mi?

Bir işi devretmek için doğrunun ne olduğunu söyleyebilmeniz gerekir. Söyleyemiyorsanız ajanın çıktısını denetleyemezsiniz ve denetlenemeyen çıktı zamanla kontrol dışına çıkar.

"Bu kaydın sektör alanı boş, doldur" işinde doğru sonuç tanımlıdır: sektör listesindeki değerlerden biri, doğru olanı. "Bu müşteriye hangi fiyatı vermeliyiz" işinde doğru sonuç tanımlı değildir, çünkü cevap rekabet durumuna, müşterinin stratejik değerine ve o çeyreğin hedefine göre değişir. İlkini ajan yapar, ikincisini yapmaz.

Soru 3: Hata Maliyeti Geri Alınabilir mi?

Bu, en sık atlanan sorudur ve en pahalı sonuçları olan sorudur. Ajanın hata yapacağını varsayın, sonra o hatanın nasıl geri alınacağını sorun.

Yanlış doldurulmuş bir sektör alanı geri alınabilir; kayıt düzeltilir ve iş biter. Müşteriye yanlış gönderilmiş bir fiyat teklifi geri alınamaz, çünkü o rakam artık müşterinin zihnindedir ve pazarlık oradan başlar. Yanlış kapatılmış bir fırsat kaydı geri alınabilir; yanlış tonda gönderilmiş bir ilişki mesajı geri alınamaz.

Kural şu: geri alınamayan işlerde ajan hazırlar, insan gönderir.

✓  Satış tahmininin sahipliği: Ajan tahmin üretebilir ama tahmini savunacak olan satış yöneticisidir. Sahiplenilmeyen tahmin, yönetim toplantısında hiçbir işe yaramaz.

✓  İlişki yönetimi: Karşı taraf insan olduğunu bilerek konuşuyorsa, ilişkiyi ajana devretmek ilişkinin kendisini ortadan kaldırır. B2B'de bu maliyet ölçülmesi zor ama gerçektir.

✓  İtiraz karşılama: Girdi bir konuşmadır ve içinde söylenmeyen kısımlar vardır. Ajan itiraz kalıplarını hatırlatabilir, konuşmayı yürütmez.

✓  Kapanış konuşması: Hem doğru sonuç tanımsızdır hem hata geri alınamaz. Devretmek için en kötü aday.

✓  Şikayet ve kriz iletişimi: Yanlış tonun maliyeti yüksektir ve geri alınamaz. Ajan geçmişi özetler, iletişimi insan kurar.

İlk 30 gün: Veri düzeni. Mükerrer kontrolü, zorunlu alanlar, aşama tanımları. Ajan yok, sadece zemin.

30 ile 60 gün: Tek bir ajan, tek bir iş. Tercihen kayıt zenginleştirme veya talep sınıflandırma. Çıktı insan tarafından örneklem usulü denetlenir.

60 ile 90 gün: Ölçüm. Üç metrik canlı öncesi değerlerle karşılaştırılır. Fark yoksa ajan değiştirilmez, iş değiştirilir.

90 gün sonrası: Sonuç alınan işte kapsam genişletilir. Sonuç alınmayan iş kapatılır ve bu bir başarısızlık değil, eleme testinin çalışması olarak kaydedilir.

Bir aktiviteyi kesmek de bir sonuçtur. Ajanın işe yaramadığı bir adımı ısrarla açık tutmak, hem bütçeyi hem ekibin yapay zekaya olan güvenini tüketir. Testi geçmeyen işi zorlamak yerine testi geçen bir sonraki işe geçmek daha hızlı ilerletir.

Bugünkü tabloda hayır. Ajan, satış temsilcisinin karar vermeye ayırdığı zamanı artırır; kararı kendisi vermez. Fiyat, itiraz karşılama ve kapanış gibi doğru sonucun önceden tanımlanamadığı adımlar insanda kalır. Ajanın devraldığı işler hazırlık işleridir.

Küçük bir şirket için yapay zeka ajanı mantıklı mı?

Veri düzeni kuruluysa evet, çünkü küçük ekiplerde hazırlık işlerinin oransal yükü daha ağırdır. Ancak veri düzeni kurulmadan başlanırsa küçük şirkette de aynı sonuç çıkar: ajan hatayı hızlandırır. Sıra her ölçekte aynıdır, önce veri sonra ajan.

Ajan yanlış bir işlem yaptığında ne olur?

Bu yüzden yetki sınırı dar tutulur. Ajanın hangi modülü okuyabildiği, hangi alanı yazabildiği ve hangi işlemi yapamayacağı kurulumda tanımlanır. Geri alınamayan işlemler, özellikle müşteriye giden iletişim ve fiyat bilgisi, ajanın yazma yetkisi dışında bırakılır.

Ajanı kurmak için CRM verimizin ne kadar düzenli olması gerekiyor?

Dört şey yeterli: mükerrer kontrolü kurulu olması, zorunlu alanların belirlenmiş olması, huni aşamalarının giriş ve çıkış koşullarının yazılı olması, her kaydın bir sahibi bulunması. Bu dördü olmadan kurulan ajan projelerinde sonuç ölçülemez hale geliyor.

Ajanın işe yarayıp yaramadığını nasıl anlarız?

Canlı öncesinde üç metriği kaydederek: ilk yanıt süresi, veri tamlık oranı, aşama geçiş süresi. Üç ay sonra aynı üç sayıya bakılır. Fark yoksa ajan değil ajanın koşulduğu iş değiştirilir.

Zoho tarafında ajan kurmak için ek geliştirme gerekiyor mu?

Hazır ajanlar için gerekmiyor. Kendi sürecinize özel bir ajan için Agent Studio kod yazmadan tanımlama imkanı sunuyor. Karmaşık senaryolarda entegrasyon ve yetki tasarımı danışmanlık gerektirebiliyor.

Bu yazıda fiyat artışının neden bir proje olarak ele alınması gerektiğini, segment bazlı oran belirlemenin nasıl yapıldığını, duyurunun nasıl planlanacağını ve artışın etkisinin nasıl ölçüleceğini ele alıyoruz.

Müşteri kârlılığı: Ciro değil, kâr. Yüksek ciro yapan bir müşteri, aldığı iskonto ve talep ettiği hizmet düzeyi nedeniyle düşük kârlı olabilir. Zam planı ciroya göre yapıldığında, asıl düzeltilmesi gereken müşteriler gözden kaçar.

Fiyat geçmişi: Bu müşteriye en son ne zaman ve hangi oranda zam yapıldı? İki yıldır zam yapılmamış bir müşteriyle her yıl düzenli artış uygulanan müşteri aynı yaklaşımı kaldırmaz.

İlişki derinliği: Müşteri kaç üründen alıyor, kaç yıldır çalışıyor, kaç departmanı sizinle temas hâlinde? Derin ilişki, fiyat hassasiyetini azaltır çünkü değiştirme maliyeti yüksektir.

Sözleşme ve yenileme takvimi: Fiyat artışı sözleşme koşullarına bağlıysa, hangi müşteride ne zaman uygulanabileceği bellidir. Bu takvim çıkarılmadan yapılan duyurular sözleşme ihlaline dönüşebilir.

Bu dört kırılım CRM üzerinde tutuluyorsa zam planı birkaç saatte çıkar. Veriler farklı sistemlere dağılmışsa aynı iş haftalar sürer ve genellikle eksik yapılır.

Bu yaklaşımın koşulu şeffaflıktır. Kademeli planın baştan paylaşılması güven yaratır; gizlenip ikinci kademe sürpriz olarak geldiğinde tam tersi etki doğar.

“Bu oran çok yüksek.” En yaygın itiraz. Cevap, oranı tartışmak yerine değeri konuşmaya geçmek olmalıdır: müşterinin geçen yıl aldığı hizmet hacmi, çözülen talepler, sağlanan tasarruf.

“Rakipten daha uygun teklif aldım.” Burada kritik olan, teklifin gerçekten karşılaştırılabilir olup olmadığını anlamaktır. Çoğu vakada rakip teklifi daha dar kapsamlıdır. Kapsam farkını somut biçimde ortaya koymak, fiyatı savunmaktan daha etkilidir.

“Bütçemiz bunu kaldırmaz.” Bu itiraz genellikle gerçektir ve esneklik gerektirir. Ancak esneklik fiyattan değil kapsamdan verilmelidir: ödeme vadesi, hizmet seviyesi ya da paket içeriği üzerinden bir düzenleme, fiyat indiriminden çok daha az zarar verir.

“Zam yapacaksanız çıkarız.” Bu itirazın ne kadarının gerçek olduğunu portföy verisi gösterir. Değiştirme maliyeti yüksek, derin entegrasyonlu bir müşterinin gerçekten ayrılma olasılığı düşüktür. Yeni ve yüzeysel ilişkideki müşteride ise risk gerçektir.

Önemli bir uyarı: itiraz eden müşteri sayısı, gerçek riskin göstergesi değildir. En riskli müşteriler genellikle itiraz etmez; sessizce alternatif arar ve yenileme döneminde çıkar. Bu nedenle zam sonrası izlenmesi gereken şey itiraz sayısı değil, davranış değişikliğidir.

Hacim değişimi de gözden kaçan bir kalemdir. Müşteri ayrılmamış olabilir ama sipariş sıklığını düşürmüş olabilir. Ciro bazında bakıldığında bu düşüş fark edilmeyebilir; sipariş sayısı ve ortalama sepet takip edilmediğinde gerçek etki gizli kalır.

Ölçüm için zam öncesi ve sonrası dönemin karşılaştırılabilir olması gerekir. Bu nedenle zam tarihinin, mevsimsel dalgalanmanın yüksek olduğu dönemlere denk getirilmemesi ölçümü kolaylaştırır.

Son anda karar vermek: Aceleyle alınan karar segmentasyon yapılmasına imkân vermez ve duyuru için hazırlık süresi bırakmaz.

Satış ekibini hazırlıksız yakalamak: Ekip itirazlara hazır değilse ilk hafta içinde kontrolsüz iskontolar verilir.

Yalnızca itiraz edenleri izlemek: Gerçek risk sessiz müşterilerdedir.

Etkiyi ölçmemek: Ölçülmeyen zam, bir sonraki yıl yine tahminle yapılır.

Değer iletişimini zam anına sıkıştırmak: Yıl boyunca hiç değer iletişimi yapılmayan bir müşteriye zam gününde fayda anlatmak inandırıcı olmaz. Değer hatırlatması yıla yayılmalıdır.

Bu yazıda ramp-up süresinin ne olduğunu, nasıl hesaplandığını, hangi faktörlerin bu süreyi uzattığını ve kısaltmak için neler yapılabileceğini ele alıyoruz.

Buradaki kritik nokta “tam verimlilik” tanımıdır. Bu tanım şirketten şirkete değişir ve net biçimde belirlenmediği sürece ölçüm de yapılamaz. En yaygın kullanılan tanım şudur: temsilcinin, kendi seviyesindeki deneyimli bir temsilcinin kotasını karşılayabilir hâle gelmesi.

Ramp-up bir eğitim süresi değildir. Eğitim genellikle iki hafta sürer; ramp-up ise aylarla ölçülür. İkisini karıştırmak, en sık yapılan planlama hatasıdır. Eğitim bittiğinde temsilci ürünü tanır ama hâlâ doğru müşteriyi seçemez, itirazı yönetemez ve satış döngüsünü tamamlamamıştır.

Adım 1: Tam verimlilik eşiğini tanımlayın. Bu genellikle deneyimli temsilcinin aylık kotasıdır. Bazı şirketlerde ciro yerine kapatılan fırsat sayısı ya da üretilen pipeline tutarı kullanılır.

Adım 2: Başlangıç noktasını belirleyin. Genellikle işe giriş tarihi alınır. Eğitim süresi uzun olan yapılarda eğitimin bittiği tarih de kullanılabilir; önemli olan tutarlı olmaktır.

Adım 3: Eşiğe ulaşılan ayı bulun. Temsilcinin ilk kez tam verimlilik eşiğini karşıladığı ay tespit edilir. Tek seferlik bir sıçramayı ramp-up sayılmamak için genellikle üst üste iki ay şartı aranır.

Adım 4: Ortalamayı alın. Son bir ila iki yılda işe alınan tüm temsilcilerin ramp-up süresi ortalanır.

Basit bir örnek: son iki yılda alınan altı temsilcinin eşiğe ulaşma süreleri 4, 5, 5, 6, 7 ve 9 ay ise, ortalama ramp-up süreniz altı aydır. Ancak burada dağılıma da bakmak gerekir. Dört ay ile dokuz ay arasındaki fark, sürecin kişiye bağlı ilerlediğini ve standart bir yapının olmadığını gösterir.

1. hafta: Ürün ve pazar bilgisi, sistem eğitimi, ilk müşteri kayıtlarının incelenmesi

2. hafta: Deneyimli temsilcinin görüşmelerine katılım, gözlem notları

3. hafta: Rol yapma çalışmaları, itiraz senaryoları, ilk bağımsız görüşme

4. hafta: Kendi portföyünde ilk temaslar, ilk fırsat kayıtları

2. ay: Bağımsız görüşmeler, haftalık koçluk, ilk tekliflerin hazırlanması

3. ay: Pipeline oluşturma hedefi, ilk kapanış denemeleri

Bu planın yazılı olması ve her yeni temsilcide aynı şekilde uygulanması, ramp-up süresindeki dağılımı da daraltır.

Bu iki yönlü yapının belirli bir takvimi olmalıdır; örneğin ilk ay yalnızca izleme, ikinci ay karşılıklı, üçüncü ay bağımsız görüşme ve haftalık kayıt incelemesi.

Hesap üç kalemden oluşur.

Ödenen ama karşılığı alınamayan maaş. Temsilcinin ramp-up dönemindeki toplam maliyetinden, o dönemde ürettiği katkı düşülür. Aylık maliyeti 100 birim olan ve altı ayda tam verime ulaşan bir temsilcide, kısmi verimlilik eğrisine göre bu dönemde ortalama yüzde 40 verim alınıyorsa, yaklaşık 360 birimlik bir karşılıksız maliyet oluşur.

Eğitim ve yönetici eforu. İşe alıştırma sürecinde yöneticinin ve deneyimli temsilcilerin harcadığı zaman, bu kişilerin kendi satışlarından çalınan zamandır. Genellikle hesaba katılmaz ama gerçek bir maliyettir.

Kaçırılan fırsat. Temsilcinin portföyü ramp-up boyunca tam kapasiteyle işlenemez. Bu portföyde bekleyen fırsatların bir kısmı bu süre içinde rakibe gider.

Bu üç kalem toplandığında, ramp-up süresini iki ay kısaltmanın şirkete kazandırdığı tutar çoğu zaman beklenenden yüksek çıkar. Özellikle ekip büyütme dönemlerinde bu hesabın yapılması, işe alıştırma yapısına yatırım yapmayı kolayca gerekçelendirir.

Diyelim ki gelecek yılın üçüncü çeyreğinde ek kapasiteye ihtiyacınız var ve ramp-up süreniz altı ay. Bu durumda işe alımın en geç birinci çeyreğin başında tamamlanmış olması gerekir. İşe alım sürecinin kendisi de ortalama iki ay sürdüğüne göre, ilan bir önceki yılın son çeyreğinde açılmalıdır.

Aynı hesap ayrılmalar için de yapılır. Bir temsilci ayrıldığında kaybedilen şey yalnızca onun cirosu değil, yerine gelen kişinin ramp-up süresi boyunca oluşacak boşluktur. Bu nedenle temsilci devir oranı yüksek olan ekiplerde kapasite hiçbir zaman planlanan seviyeye ulaşmaz.

Bu hesapları yapabilmek için ramp-up süresinin bir tahmin değil, ölçülmüş bir rakam olması gerekir.

Bu yazıda CRM benimsemesinin ne olduğunu, hangi metriklerle ölçüldüğünü, düşük benimsemenin gerçek nedenlerini ve bu tabloyu düzeltmek için izlenmesi gereken yolu ele alıyoruz.

Buradaki kritik ayrım, kullanım ile benimseme arasındadır. Kullanım, sisteme giriş yapmaktır. Benimseme ise işi sistem üzerinden yapmaktır. Bir temsilci her sabah CRM’e giriş yapıp hiçbir kayıt güncellemiyorsa, kullanım vardır ama benimseme yoktur.

Bir örnek üzerinden bakalım. Satış temsilcisi müşteriyle görüşmesini yapar, notlarını telefonuna alır, akşam eve giderken önemli bulduğu iki cümleyi CRM’e yazar. Sistemde bir kayıt oluşmuştur, giriş istatistiği artmıştır, rapor “kullanılıyor” der. Ancak görüşmenin gerçek içeriği, müşterinin itirazı, rakip bilgisi ve bir sonraki adım sistemde yoktur. Bu bilgi temsilcinin zihninde kaldığı sürece şirket ona sahip değildir; temsilci ayrıldığında bilgi de gider.

Benimseme, bu bilginin sisteme akmasıdır. Ölçtüğümüz şey giriş sayısı değil, işin sistemde yaşayıp yaşamadığıdır.

Ölçmek üç şeyi mümkün kılar.

Sorunun yerini bulmak. Düşük benimseme tüm ekipte mi, belirli bir bölgede mi, yoksa belirli bir modülde mi? Bunlar tamamen farklı sorunlardır ve farklı çözümler gerektirir.

Yatırımın karşılığını göstermek. CRM bir maliyet kalemi olarak sorgulandığında, benimseme verisi olmadan savunma yapmak zordur.

Erken müdahale etmek. Benimseme düşüşü yavaş ilerler. Aylık ölçüm yapılmıyorsa sorun ancak veriye güvenilmediği fark edildiğinde, yani çok geç anlaşılır.

Rapor kullanımı ise farklı bir şeyi ölçer: yönetimin sisteme güvenini. Yöneticiler raporlara girmiyor ve hâlâ temsilcileri tek tek arayarak durum soruyorsa, benimseme sorunu üst kademede başlamış demektir.

Giriş sayısı. Sisteme girmek iş yapmak değildir. Otomatik bildirimlerle sistemden haberdar olan bir kullanıcı da giriş yapar.

Toplam kayıt sayısı. Veri tabanındaki kayıt sayısı geçmişin birikimidir, bugünkü davranışı göstermez.

Eğitim tamamlama oranı. Eğitime katılmak öğrenmeyi, öğrenmek de davranış değişimini garanti etmez.

Ekran süresi. Sistemde uzun süre kalmak verimlilik değil, çoğu zaman kullanım zorluğunun göstergesidir.

Gerçek benimseme ölçümü, kullanıcının sistem üzerinde ürettiği anlamlı çıktıya bakar: güncellenen fırsat, işlenen görüşme, kapatılan görev, doldurulmuş kritik alan.

Pratik bir kural: bir temsilcinin bir görüşmeyi sisteme işlemesi iki dakikadan uzun sürüyorsa, o alan tasarımı yeniden ele alınmalıdır.

Ofis içi satış ekiplerinde benimseme genellikle en yüksektir; çünkü bu ekipler zaten bilgisayar başında çalışır ve sistemi kullanmamak onlar için ek iş yaratır. Buradaki sorun kullanım değil, çoğunlukla veri derinliğidir: kayıt açılır ama itiraz, rakip ve karar verici gibi kritik alanlar boş kalır.

Saha ekiplerinde durum tersidir. Ziyaret sırasında sisteme veri girmek fiziksel olarak zordur; not defteri ve telefon galerisi daha hızlıdır. Bu ekiplerde benimsemeyi belirleyen tek şey mobil deneyimin kalitesidir. Mobil uygulamada ziyaret kaydı üç dokunuşla yapılabiliyorsa benimseme yükselir, on alan doldurulması gerekiyorsa ekip günün sonunda toplu ve baştan savma giriş yapar.

Destek ve servis ekiplerinde benimseme genellikle yüksektir çünkü işin kendisi zaten sistem üzerinden akar. Buradaki risk farklıdır: talep kapatma hızını artırmak için kayıtların yüzeysel doldurulması. Bu da raporları bozar.

Yönetim kademesinde benimseme çoğu zaman hiç ölçülmez, oysa en belirleyici olan odur. Yöneticinin panoya değil Excel’e bakması, tüm ekibe sistemin ikincil olduğu mesajını verir.

Bu nedenle benimseme raporu her zaman ekip ve rol kırılımıyla okunmalıdır. Şirket ortalaması bir yönetim rakamıdır; müdahale edilecek yeri ancak kırılım gösterir.

• Benimseme ile veri kalitesi arasındaki ilişki nedir?

İkisi birbirini besleyen bir döngüdür. Düşük benimseme veriyi eksik bırakır, eksik veri sisteme güveni azaltır, güvensizlik kullanımı daha da düşürür. Bu döngü ancak iki taraftan aynı anda müdahaleyle kırılır: girişi kolaylaştırmak ve veriyi temizlemek.

• Yeni işe alınan çalışanlar için ne yapmalıyız?

Yeni kullanıcıların ilk 30 günü ayrı izlenmelidir. İşe giriş sürecine CRM eğitimini standart bir adım olarak yerleştirin ve her ekran için kısa kullanım videoları hazır bulundurun. Aksi hâlde yeni gelenler sistemi mevcut ekipten öğrenir ve varsa kötü alışkanlıklar da devralınır.

• Benimseme ölçümü çalışan takibi anlamına mı geliyor?

Amaç ve iletişim biçimi bunu belirler. Ölçümün amacı kişileri denetlemek değil, sistemin nerede zorluk çıkardığını bulmaktır. Bu çerçeve ekibe açıkça anlatıldığında ve bulgular kişi cezalandırmak yerine süreç düzeltmek için kullanıldığında, ölçüm ekip tarafından da desteklenen bir uygulamaya dönüşür.

Pipeline kirliliği bir anda oluşmaz. Küçük ve masum görünen alışkanlıkların birikimiyle ortaya çıkar.

Kritik nokta şudur: kriterler bizim ne yaptığımızı değil, müşterinin ne yaptığını ölçmelidir. “Teklif gönderdik” bizim yaptığımız bir iştir ve ilerleme kanıtı değildir. “Müşteri teklifi inceleyip revizyon talep etti” ise müşterinin attığı bir adımdır ve gerçek bir sinyaldir.

Örnek bir kriter seti:

Bu toplantının klasik satış toplantısından farkı şudur: amaç fırsatları tek tek dinlemek değil, hattaki anormallikleri yakalamaktır. Toplantı fırsat anlatımıyla geçerse iki saat sürer ve hiçbir şey temizlenmez. Bunun yerine dört filtre üzerinden ilerlemek gerekir.

1. Bayat fırsatlar. Bulunduğu aşamada normalden uzun süredir bekleyen kayıtlar. Her aşama için bir eşik süre belirlenir; eşiği aşan fırsatlar otomatik listelenir. Bu fırsatlar için tek soru sorulur: bir sonraki somut adım nedir ve tarihi var mı? Cevap yoksa fırsat kapatılır.

2. Tarihi geçmiş fırsatlar. Kapanış tarihi geçmiş ama hâlâ açık duran kayıtlar. Bunlar tahmini doğrudan bozar ve her denetimde sıfırlanmalıdır.

3. Tekrar ötelenen fırsatlar. Kapanış tarihi belirli sayıdan fazla ertelenmiş kayıtlar. Üç ötelemeden sonra fırsatın gerçekliği ciddi biçimde sorgulanmalıdır.

4. Aktivitesiz fırsatlar. Üzerinde belirli bir süredir hiçbir görüşme, e-posta veya görev kaydı bulunmayan fırsatlar. Aktivite yoksa ilerleme de yoktur.

Bu dört liste CRM üzerinde önceden tanımlanmış görünümler olarak hazır tutulduğunda, denetim toplantısı hazırlık gerektirmeyen ve kısa süren bir rutine dönüşür.

Her denetimin sonunda her fırsat için üç karardan biri verilmelidir: ilerlet, beklet ya da kapat. Karar verilmeyen fırsat, bir sonraki hafta aynı listede yeniden karşınıza çıkar.

Burada yöneticinin tutumu belirleyicidir. Kaybı kapatmak cezalandırılan bir davranış olarak algılanırsa hiç kimse fırsat kapatmaz. Tersine, dürüst kapanış teşvik edilmelidir; çünkü kaybedilen bir işi zamanında kapatmak, sahte bir umudu aylarca taşımaktan çok daha değerlidir. Kaybedilen işlerin nedenlerini sistematik olarak incelemek istiyorsanız win loss analizi yazımız bu konuda ayrıntılı bir çerçeve sunuyor.

Aşama geçiş süresi ayrıca ayrı bir değer taşır: hangi aşamada tıkanıldığını gösterir. Fırsatlar sürekli “Değerlendirme” aşamasında bekliyorsa bu bir hijyen sorunundan çok bir satış metodolojisi sorunudur ve müdahale edilecek yer orasıdır. 

Bu ölçümün satış hızıyla ilişkisini satış hızı yazımızda ayrıntılı olarak ele almıştık.

Satış temsilcisi kendi fırsatlarının güncelliğinden sorumludur. Bir görüşme yapıldığında kaydın işlenmesi, kapanış tarihinin gerçekçi tutulması ve kaybedilen işin kapatılması onun işidir. Ancak bu sorumluluk ancak veri girişi kolay olduğunda gerçekleşir. Temsilciden on beş alan doldurması beklenirse hiçbiri doğru dolmaz.

Satış yöneticisi denetimi yürütmekten ve kararı vermekten sorumludur. Denetim toplantısında “bu fırsatı kapatıyoruz” demek yöneticinin işidir; temsilciden kendi kaybını ilan etmesini beklemek çoğu zaman sonuçsuz kalır.

Satış operasyonu ya da sistem yöneticisi kuralların sistemde yaşamasından sorumludur. Aşama kriterlerinin zorunlu alanlara dönüştürülmesi, denetim görünümlerinin hazırlanması, otomatik uyarıların kurulması ve metriklerin panolara taşınması bu rolün işidir. Küçük şirketlerde bu rol ayrı bir kişi olmayabilir; o zaman satış yöneticisi bu şapkayı da takar ya da danışmanlık desteği alınır.

Bu üçlüden biri eksik olduğunda ne olduğunu tahmin etmek kolaydır. Temsilci yoksa veri girilmez, yönetici yoksa karar verilmez, sistem tarafı yoksa kurallar unutulur.

Birinci hafta: fotoğraf çekin. Hiçbir şeyi değiştirmeden mevcut durumu ölçün. Kaç fırsat var, kaçının kapanış tarihi geçmiş, kaçında son 30 günde hiç aktivite yok, ortalama öteleme sayısı ne? Bu rakamlar hem başlangıç noktanız hem de sonradan ilerlemeyi gösterecek kanıtınız olur.

İkinci hafta: aşama tanımlarını yazın. Ekiple birlikte oturup her aşamanın ne anlama geldiğini ve o aşamadan çıkmak için hangi kanıtın gerektiğini tek sayfaya yazın. Bu toplantı genellikle beklenenden uzun sürer, çünkü ekip üyelerinin aynı aşamayı farklı anladığı ilk kez burada ortaya çıkar. Bu tartışmanın kendisi değerlidir.

Üçüncü hafta: geçmişi kapatın. Belirlenen eşiği aşan tüm eski fırsatları tek tek gözden geçirip kararınızı verin. Bu tek seferlik bir çalışmadır ve genellikle pipeline’ın önemli bir kısmının kapatılmasıyla sonuçlanır. Rakamın küçülmesi kötü bir haber değil, doğru rakama ulaşmaktır.

Dördüncü hafta: kuralları sisteme gömün ve rutini başlatın. Zorunlu alanları, otomatik uyarıları ve denetim görünümlerini kurun, ilk haftalık denetim toplantısını yapın.

Bu dört haftadan sonra iş bitmez; asıl mesele beşinci haftada aynı toplantının tekrar yapılmasıdır. Hijyeni kalıcı kılan şey temizliğin kendisi değil, tekrarıdır.

Temizliği ceza aracına dönüştürmek. Denetim toplantısı temsilcilerin savunmaya geçtiği bir ortama dönüşürse, bir sonraki denetime kadar veriler daha da makyajlanır.

Yalnızca büyük fırsatlara bakmak. Küçük ve orta ölçekli fırsatlar sayıca çok olduğu için hattı asıl kirletenler genellikle onlardır.

Kuralları yazıp sistemde uygulamamak. Aşama kriterleri yalnızca sunumda kalırsa üç ay içinde unutulur.

Tek seferlik proje gibi ele almak. Pipeline hijyeni bir kampanya değil, süreklilik gerektiren bir rutindir. Bir kez temizlenip bırakılan hat altı ay içinde eski hâline döner.

Veri kalitesi sorunu genellikle yavaş ilerler ve fark edildiğinde büyümüştür. CRM kurulumundan sonraki ilk aylarda veri temizdir, çünkü kayıt sayısı azdır ve herkes dikkatlidir. Zamanla kayıt sayısı artar, farklı kişiler farklı alışkanlıklarla veri girer, entegrasyonlardan otomatik kayıtlar akmaya başlar ve bir noktada kimse rapordaki rakamın doğru olduğundan emin olamaz. Bu yazıda veri kalitesinin hangi boyutlarda ölçüldüğünü, bozulmanın nereden başladığını ve kalıcı bir veri yönetişimi düzeninin nasıl kurulacağını ele alıyoruz.

Zorunlu alanların eksik tanımlanması. Hangi bilginin olmazsa olmaz olduğu tanımlanmadığında, aceleyle açılan kayıtlar boş alanlarla sistemde kalır. Bu kayıtlar bir daha nadiren tamamlanır.

Zorunlu alanların fazla tanımlanması. Ters yönde bir hata da mümkündür. Yeni kayıt açmak için on beş alan doldurmak gereken bir sistemde kullanıcılar ya kayıt açmaktan kaçınır ya da alanları rastgele doldurur. İkisi de veri kalitesini bozar ve ikincisi daha tehlikelidir, çünkü sorun görünmez.

Kontrolsüz veri aktarımı. Web formundan, reklam entegrasyonundan veya toplu Excel yüklemesinden gelen kayıtlar, mükerrer kontrolü yapılmadan sisteme aktarıldığında kısa sürede büyük bir kirlilik oluşur. Otomatik akan her kanal, veri kalitesi açısından ayrı bir risk noktasıdır.

Sahipsiz kayıtlar. Bir kaydın sahibi tanımlı değilse veya sahibi işten ayrılmışsa, o kaydı güncelleme sorumluluğu kimsede değildir. Zamanla bu kayıtlar sistemin ölü bölgesini oluşturur.

Süreç dışı kullanım. CRM’i günlük çalışma aracı olarak kullanmayan, ay sonunda toplu kayıt girmeye çalışan bir ekipte veri hem eksik hem geç girilir. Bu bir veri sorunu gibi görünse de aslında bir benimseme sorunudur ve çözümü de benimseme tarafındadır.

Yalnızca temizlik yapılan bir sistemde veri kalitesi birkaç ay içinde eski seviyesine döner, çünkü kirliliği üreten mekanizmalar yerinde durmaktadır. Bu yüzden her temizlik çalışması, o kirliliği üreten nedenin de kapatılmasıyla birlikte planlanmalıdır. Mükerrer kayıtlar temizleniyorsa, aynı anda mükerrer oluşumunu engelleyen kural da devreye alınmalıdır.

Bir veri yönetişimi düzeni dört unsurdan oluşur.

Veri sahipliği. Her ana veri türü için bir sorumlu tanımlanır. Hesap verisinden kim, ürün verisinden kim, kaynak listesinden kim sorumludur? Sahip belirsizse kural da uygulanmaz.

Alan sözlüğü. Her alanın ne anlama geldiği, hangi durumda nasıl doldurulacağı yazılı olarak tanımlanır. “Müşteri durumu” alanındaki “aktif” seçeneğinin tam olarak neyi ifade ettiği herkesin aynı şekilde anlaması gereken bir tanımdır.

Giriş kuralları. Zorunlu alanlar, seçim listeleri, format kontrolleri ve mükerrer engelleme kuralları sistem düzeyinde tanımlanır. Kural sistemde değil yalnızca eğitim dokümanında yaşıyorsa uygulanmaz.

Periyodik denetim. Belirli aralıklarla veri kalitesi ölçülür ve raporlanır. Ölçülmeyen bir şey yönetilemez; veri kalitesi de bunun istisnası değildir.

Segmentasyon ve kampanya isabetliliği. Sektör, büyüklük veya ürün ilgisi alanları eksik ya da tutarsızsa segment oluşturulamaz. Bu durumda pazarlama ekibi ya herkese aynı mesajı gönderir ve dönüşüm oranı düşer, ya da eksik listelerle çalışır ve hedef kitlenin bir kısmına hiç ulaşamaz.

Satış verimliliği. Yanlış telefon numarası, güncel olmayan yetkili adı veya eksik adres, satış temsilcisinin zamanını doğrudan tüketir. Günde birkaç yanlış aramanın yıllık toplamı, ekip büyüklüğüyle çarpıldığında ciddi bir kapasite kaybına dönüşür.

Tahmin doğruluğu. Fırsat kayıtlarının kapanış tarihi ve tutarı güncellenmiyorsa, satış tahmini gerçeği yansıtmaz. Bu da hem kaynak planlamasını hem nakit akışı öngörüsünü bozar.

Müşteri deneyimi. Mükerrer kayıt yüzünden aynı müşteriye iki farklı temsilcinin ulaşması veya aynı e-postanın iki kez gitmesi, müşteri gözünde profesyonellik kaybıdır. Müşterinin daha önce ilettiği bilgiyi tekrar sorması gereken bir ekip, ilişkiyi her seferinde bir adım geriden başlatır.

Yapay zeka ve otomasyon çıktıları. Bu, son yıllarda en hızlı büyüyen etkidir. Skorlama, tahminleme ve öneri üreten yapay zeka modelleri tamamen mevcut veriden öğrenir. Eksik ve tutarsız veriyle beslenen bir model yanlış öncelik önerir, üstelik bu yanlışlık ikna edici bir arayüzle sunulduğu için fark edilmesi zordur. Otomasyon da aynı mantıkla çalışır: yanlış veriye dayanan bir iş akışı, hatayı elle yapılandan çok daha hızlı ve çok daha geniş ölçekte üretir.

Bu son madde, veri kalitesini artık ertelenebilir bir konu olmaktan çıkarır. Yapay zeka destekli özelliklerden fayda beklemek, öncelikle o özellikleri besleyecek verinin düzgün olmasını gerektirir.

İskonto yönetimi, bu iki uç arasında tanımlı bir orta yol kurma işidir. Amaç iskontoyu tamamen engellemek değil, kimin ne kadar iskonto verebileceğini önceden belirlemek ve bu sınırın ötesindeki taleplerin hızlı bir onay mekanizmasından geçmesini sağlamaktır. Bu yazıda iskonto yetki matrisinin nasıl kurulacağını, onay süreçlerinin satış hızını düşürmeden nasıl tasarlanacağını ve bu yapının CRM üzerinde nasıl otomatikleştirileceğini ele alıyoruz.

İkinci sorun, iskontonun kalıcı hale gelmesidir. Bir müşteriye bir kez verilen özel fiyat, sonraki yenilemede başlangıç noktası olur. Müşteri o fiyatı standart kabul eder ve yeni bir indirim ister. Böylece tek seferlik olarak düşünülen bir taviz, o hesabın ömrü boyunca taşınan bir maliyete dönüşür.

Üçüncü sorun tutarsızlıktır. Aynı büyüklükteki iki müşteriye farklı temsilciler tarafından çok farklı fiyatlar verildiğinde, bu bilgi er ya da geç pazarda dolaşır. Fiyat güvenilirliği zedelendiğinde her müşteri pazarlık yapması gerektiğini düşünür ve satış süreci uzar.

Bu üç sorunun ortak çözümü, iskontoyu yasaklamak değil kurallandırmaktır.

Ürün bazında farklı sınırlar konulabilir. Marjı yüksek ürünlerde daha geniş bir iskonto alanı tanımlanabilirken, marjı dar ürünlerde sınır çok daha sıkı tutulmalıdır. Tek bir genel oran, ürün portföyü çeşitli olan işletmelerde her zaman yanlış sonuç verir.

İskonto dışındaki taviz türleri de matrise girmelidir. Ödeme vadesinin uzatılması, ek hizmetin ücretsiz verilmesi veya sözleşme süresinin kısaltılması da birer tavizdir ve fiyat indirimiyle aynı disiplinle yönetilmelidir. Yalnızca yüzde iskontoyu kontrol eden bir sistem, tavizin bu kanallardan sızmasına izin verir.

Karar süresi hedefi konulmalıdır. Yetki matrisinin en sık başarısız olma nedeni, onayın gecikmesidir. Her onay seviyesi için maksimum yanıt süresi tanımlanmadığında satış temsilcisi süreci baypas etmenin yollarını arar.

Onaysız alanı yeterince geniş tutmak. Anlaşmaların büyük çoğunluğu onay gerektirmeden kapanabilmelidir. Eğer tekliflerin yarısından fazlası onaya düşüyorsa, yetki sınırları gerçekçi değil demektir. Bu durumda çözüm onay sürecini hızlandırmak değil, sınırı yeniden ayarlamaktır.

Onayı sisteme taşımak. E-posta veya telefonla yürütülen onaylar takip edilemez ve kaybolur. Onay talebi sistem üzerinden gittiğinde onaylayan kişiye bildirim düşer, talep kayıt altına alınır ve bekleyen onaylar görünür hale gelir.

Otomatik yönlendirme kurmak. Onayın kime gideceği, iskonto oranına ve anlaşma büyüklüğüne göre otomatik belirlenmelidir. Temsilcinin kime soracağını düşünmesi bile gereksiz bir gecikmedir.

Talebe gerekçe zorunluluğu koymak. İskonto talebinde bulunan temsilcinin nedeni yazması, hem onaylayanın hızlı karar vermesini sağlar hem de zamanla iskonto nedenlerine dair analiz edilebilir bir veri seti oluşturur. Rakip fiyatı, hacim taahhüdü ve bütçe kısıtı gibi nedenlerin dağılımı, fiyatlandırma stratejisinin kendisini gözden geçirmek için değerli bir girdidir.

Ortalama iskonto oranının zaman içindeki seyri, fiyatlandırma gücünüzün artıp azaldığını gösterir. Sürekli yükselen bir ortalama, ya rekabetin sertleştiğine ya da fiyat listesinin pazarın üzerinde kaldığına işaret eder.

Temsilci bazında iskonto dağılımı, kimin fiyatı savunabildiğini ortaya koyar. Bir temsilcinin belirgin biçimde daha yüksek iskonto vermesi eğitim ihtiyacına, belirgin biçimde düşük iskonto vermesi ise fırsat kaybına işaret ediyor olabilir. İkisi de yönetici müdahalesi gerektirir.

İskonto ile kapanma oranı arasındaki ilişki, iskontonun gerçekten işe yarayıp yaramadığını gösterir. Yüksek iskonto verilen anlaşmaların kapanma oranı, düşük iskontolu anlaşmalardan anlamlı ölçüde yüksek değilse, iskonto satışı kazandıran değil sadece kârı azaltan bir alışkanlık haline gelmiş demektir.

İskonto nedenlerinin dağılımı, ürün ve fiyat stratejisi için doğrudan girdi sağlar. Taleplerin çoğu belirli bir rakibin fiyatına dayanıyorsa bu bir konumlandırma sorunudur, tek tek onay kararlarıyla çözülemez.

Bu analizlerin yapılabilmesi için iskonto verisinin anlaşma kaydıyla birlikte tutulması gerekir. Fiyat kararları tekliflerin içinde kalır ve merkezi olarak kayıt altına alınmazsa, bu resmin hiçbir parçası görünmez.

Fiyatı erken konuşmamak. Müşterinin ihtiyacı ve bu ihtiyacın maliyeti netleşmeden fiyat verildiğinde, rakam bir bağlamdan yoksun kalır ve müşteri onu yalnızca rakiplerle karşılaştırarak değerlendirir. İhtiyaç ve mevcut durumun maliyeti önce ortaya konduğunda ise fiyat, bir maliyet kalemi değil bir yatırım karşılığı olarak konumlanır.

Karar kriterlerini önceden öğrenmek. Müşterinin kararı yalnızca fiyata mı bakıyor, yoksa uygulama süresi, destek kalitesi ve entegrasyon kabiliyeti de kriter mi? Bu kriterler görüşmenin başında netleşmezse, süreç sonunda tek karşılaştırma boyutu fiyat olarak kalır.

Değeri müşterinin kendi rakamlarıyla ifade etmek. “Verimliliği artırır” cümlesi iskonto talebini engellemez. “Ayda kırk saat manuel işten tasarruf, bu da yıllık şu tutara denk geliyor” cümlesi ise fiyatı savunulabilir hale getirir. Bu hesabı müşterinin kendi verisiyle yapmak, hazır bir sunum slaytından çok daha etkilidir.

Karşılıklılık ilkesini uygulamak. İskonto verilecekse karşılığında bir şey istenmelidir: daha uzun sözleşme süresi, peşin ödeme, referans olma taahhüdü veya daha geniş kapsam. Karşılıksız verilen her iskonto, müşteriye ilk fiyatın şişirilmiş olduğunu öğretir ve bir sonraki görüşmede daha büyük bir talep olarak geri döner.

İskonto talebini erken tespit etmek. Fiyat baskısının hangi fırsatlarda çıkacağı genellikle önceden bellidir: rakibin de teklif verdiği, bütçesi sınırlı veya karar vericisi satın alma departmanı olan fırsatlar. Bu fırsatlar önceden işaretlendiğinde, satış temsilcisi hazırlığını buna göre yapar ve süreç sonunda savunmasız kalmaz.

Bu davranışların yerleşmesi bir eğitim işidir ve prim planıyla da desteklenmelidir. Ciro üzerinden prim alan bir temsilciden fiyatı savunmasını beklemek, sistemin kendisiyle çelişir.

Standart teklif yapısı üç şeyi garanti eder. Fiyatlar merkezi ürün listesinden gelir, böylece yanlış fiyat yazılması engellenir. İskonto ayrı bir alan olarak görünür, teklifin içine gömülmez ve ölçülebilir kalır. Teklif geçmişi müşteri kaydında birikir, böylece bir sonraki görüşmede hangi fiyatın hangi koşulla verildiği bilinir.

Teklif standardizasyonu ayrıca hız kazandırır. Sıfırdan teklif hazırlamak yerine şablon üzerinden ilerleyen bir temsilci, aynı sürede daha fazla fırsatla ilgilenebilir. Bu da satış hızını doğrudan etkileyen bir kazanımdır.

Onay süreçleri (Approval Process). Belirlenen kriterleri aşan kayıtlar otomatik olarak onaya düşürülür. Kriter, iskonto yüzdesi, anlaşma tutarı, ürün grubu veya bunların birleşimi olabilir. Onaylayan kişi anlaşma kaydını görerek karar verir; karar ve gerekçe kayıt altına alınır. Onay bekleyen kayıtlar ayrı bir listede toplanır, böylece hiçbir talep gözden kaçmaz.

Doğrulama kuralları (Validation Rules). Yetki sınırının üzerindeki bir iskontonun kayda hiç girilememesi isteniyorsa, doğrulama kuralları bunu sistem düzeyinde engeller. Bu, onay sürecinden daha sert bir kontroldür ve genellikle mutlak üst sınırlar için kullanılır.

Fiyat listeleri ve teklif şablonları. Ürün ve fiyat bilgileri merkezi olarak tanımlanır, teklif bu listeden beslenir. Farklı müşteri segmentleri için ayrı fiyat listeleri tanımlanabilir. Teklifler CRM üzerinden hazırlanıp gönderilir ve tüm geçmiş müşteri kaydında saklanır.

Formül alanları ile marj görünürlüğü. Anlaşma kaydına maliyet bilgisi girildiğinde, brüt kâr ve iskonto sonrası marj otomatik hesaplanabilir. Temsilci iskonto oranını değiştirdiğinde marjın ne olduğunu anında görür; bu tek başına iskonto davranışını belirgin şekilde değiştiren bir görünürlüktür.

Blueprint ile süreç disiplini. Teklif hazırlama, onay ve gönderim adımları süreç olarak tanımlanabilir. Böylece bir teklif, gerekli onay alınmadan müşteriye gönderilebilecek bir aşamaya geçemez.

Raporlama. Ortalama iskonto oranı, temsilci ve ürün bazında iskonto dağılımı, onay bekleme süreleri ve iskonto ile kapanma oranı ilişkisi panolarda izlenebilir. Zoho CRM iş akışları ve otomasyon seçenekleri ile onay bildirimleri ve hatırlatmalar otomatikleştirilir.

Cloudyflex olarak yürüttüğümüz kurulumlarda, iskonto onayının CRM üzerine taşınmasının en hızlı geri dönüş veren düzenlemelerden biri olduğunu görüyoruz. Marjın teklif ekranında görünür hale gelmesi bile, hiçbir kural değişmeden ortalama iskonto oranını aşağı çekebiliyor.

Onay süreci satış hızını yavaşlatmaz mı? Yetki sınırları doğru ayarlandığında anlaşmaların büyük çoğunluğu onaya hiç düşmez. Onaya düşenler için de sistem üzerinden otomatik yönlendirme ve bildirim kurulduğunda karar süresi genellikle saatler mertebesinde kalır. Yavaşlama, süreç varlığından değil sürecin manuel yürütülmesinden kaynaklanır.

İskonto yerine hangi araçlar kullanılabilir? Ek hizmet paketi, uzatılmış destek süresi, ücretsiz eğitim veya kademeli fiyatlandırma gibi seçenekler müşteriye değer sunarken liste fiyatını korur. Bu alternatiflerin de yetki matrisinde tanımlı olması, tavizin kontrolsüz kanallara kaymasını engeller.

Küçük ekipler için onay süreci kurmak gerekli mi? Üç dört kişilik bir satış ekibinde formal onay akışı fazla gelebilir, ancak iskonto oranının anlaşma kaydında ayrı bir alan olarak tutulması bu ölçekte bile faydalıdır. Veri biriktiğinde ekip büyüdüğünde kural koymak çok daha kolay olur.

İskonto onayı reddedildiğinde satış temsilcisi ne yapmalı? Reddedilen talep bir kapanma değil, alternatif üretme noktasıdır. Temsilci, iskonto yerine sunulabilecek diğer değer bileşenleriyle görüşmeye devam eder. Bu nedenle onay reddinin gerekçesiyle birlikte iletilmesi ve alternatif önerinin de paylaşılması önemlidir.

Geçmiş iskontolar yenilemede nasıl yönetilir? Yenileme görüşmesine girmeden önce müşteriye verilen tarihsel iskontoların ve bunların gerekçelerinin gözden geçirilmesi gerekir. Gerekçe ortadan kalkmışsa, iskontonun kademeli olarak azaltılması planlanabilir. Bu planın yenileme görüşmesinden aylar önce yapılması, sürprizleri önler.