Aynı Alıcı Üç Kez Sayıldığında: İnşaat Projelerinde Mükerrer Lead'lerin Raporlara, Bütçeye ve Ekip İçi Güvene Gizli Maliyeti

İnşaat ve konut projelerinde satış toplantılarının çoğu aynı cümleyle başlar: "Bu ay şu kadar lead geldi." Rakam büyük görünür, pazarlama ekibi memnundur, satış ekibi ise içten içe huzursuzdur. Çünkü sahada konuşulan kişi sayısı, rapordaki sayıyla örtüşmez. Aradaki farkın önemli bir kısmı, aynı alıcının farklı kanallardan, farklı tarihlerde ve farklı yazımlarla sisteme birden fazla kez girmesinden doğar.

Mükerrer kayıt konusu genellikle bir "veri temizliği" işi olarak ele alınır: eşleştirme kuralları yazılır, kayıtlar birleştirilir, iş biter. Ben bu yazıda konuya başka bir yerden bakmak istiyorum. Lead yönetimi ve CRM mimarisi üzerine yaptığım çalışmalarda gördüğüm şu: mükerrer kaydın asıl zararı veritabanında değil, kararlarda ortaya çıkar. Yanlış sayılan alıcı, yanlış ölçülen reklam kanalı, yanlış dağıtılan prim ve birbirine güvenini kaybeden ekipler demektir. Bu yazı, mükerrer lead'in bu dört gizli maliyetini ve her biri için yöneticinin alabileceği somut önlemleri anlatıyor.

Mükerrer lead inşaat projelerinde neden bu kadar sık oluşur?

Konut alıcısının karar süreci uzundur. Bir aile aynı projeye önce bir ilan portalından bakar, birkaç hafta sonra sosyal medya reklamındaki formu doldurur, ardından satış ofisini arar, sonra da fuar standında kartvizit bırakır. Her temas, ayrı bir sistemde ya da aynı sistemin farklı bir girişinde iz bırakır.

Kayıtları çoğaltan tipik kaynaklar

• Telefon numarası biçim farkları: Aynı numara bir yerde ülke koduyla, bir yerde başında sıfırla, bir başka yerde boşluklu yazılır. Sistem bunları üç farklı kişi sanar.

• Aile içi çoklu başvuru: Eşlerden biri formu doldurur, diğeri ofisi arar. Satın alma kararı tek bir hanede verilir ama CRM'de iki ayrı fırsat açılır.

• Kanal başına ayrı entegrasyon: Her reklam platformu ve ilan sitesi ayrı bir bağlantıyla kayıt açar; hiçbiri önce "bu kişi zaten var mı?" diye sormaz.

• Elle girilen kayıtlar: Satış ofisine gelen ziyaretçiyi temsilci kendisi açar; acele içinde isim kısaltılır, e-posta boş bırakılır.

• Proje bazlı ayrı listeler: Aynı alıcı firmanın iki farklı projesiyle ilgilendiğinde iki ayrı listeye girer ve iki ayrı temsilciye atanabilir.

Bu kaynakların hiçbiri hata değildir; hepsi gerçek alıcı davranışının doğal sonucudur. Sorun, sistemin bu davranışı tek bir insan hikâyesi olarak birleştirememesidir.

Birinci gizli maliyet: Şişirilmiş raporlar ve yanlış başarı hissi

Bir aylık raporda 600 lead göründüğünü, ama bunların gerçekte 450 farklı haneye ait olduğunu düşünün. Bu durumda dönüşüm oranı olduğundan düşük, lead başına maliyet olduğundan iyi görünür. Yönetim "lead geliyor ama satış ekibi kapatamıyor" sonucuna varır. Oysa sorun kısmen sayımdadır.

Bu yanılgı zincirleme kararlar doğurur. Satış ekibine "daha çok arayın" baskısı gelir, temsilciler aynı aileyi farklı kayıtlar üzerinden tekrar tekrar arar ve alıcı rahatsız olur. Raporlardaki şişkinlik, sahada gerçek bir müşteri deneyimi sorununa dönüşür.

Ne yapılmalı?

Raporlarda "lead sayısı" yerine iki ayrı metrik izlemeyi öneriyorum: toplam başvuru ve tekil alıcı (hane). İkisi arasındaki oran, veri kalitesinin en basit göstergesidir. Bu oranı her ay aynı tabloda göstermek, toplantılardaki tartışmayı da sakinleştirir; çünkü herkes aynı gerçeğe bakar.

İkinci gizli maliyet: Yanlış ölçülen reklam kanalları

Mükerrer kaydın en pahalı etkisi bütçe kararlarında görülür. Aynı alıcı önce ilan portalından, sonra sosyal medya reklamından gelmişse ve iki kayıt ayrı ayrı sayılıyorsa, iki kanal da o satışın sahibi gibi görünebilir. Ya da tam tersi: satış, sonradan açılan kayda bağlanır ve alıcıyı ilk getiren kanal hiç ödüllendirilmez.

Bunun sonucu, gerçekte alıcıyı ilk tanıştıran kanalın bütçesinin kısılması ve son temas noktasının olduğundan değerli görünmesidir. Konut gibi uzun karar süreçlerinde bu, bir sonraki dönemin talebini sessizce kurutabilir.

Ne yapılmalı?

Kayıtlar birleştirilirken kaynak bilgisini silmeyin; temas geçmişi olarak saklayın. Birleşmiş tek kayıtta "ilk kaynak", "son kaynak" ve aradaki tüm temaslar görünmelidir. Böylece bütçe toplantısında "hangi kanal satış getirdi?" sorusu yerine "hangi kanal alıcıyı tanıştırdı, hangisi kararı hızlandırdı?" sorusu sorulabilir. Bu ikinci soru çok daha faydalıdır.

Üçüncü gizli maliyet: Temsilci sahipliği ve prim çatışmaları

Sahada en çok gerginlik yaratan konu budur. Aynı aile iki farklı kayıtla iki farklı temsilciye düştüğünde, satış gerçekleştiği gün "bu müşteri kimin?" tartışması başlar. Bir temsilci aileyi aylarca takip etmiştir, diğeri ise satış ofisinde son görüşmeyi yapmıştır. Net bir kural yoksa karar yöneticinin keyfine kalır ve ekip içinde güven aşınır.

Daha sinsi bir etki de vardır: Temsilciler, sahiplik kaybetme korkusuyla kayıtları CRM'e geç girmeye ya da kendi defterlerinde tutmaya başlar. Böylece mükerrer sorunu çözülmez, tam tersine görünmez hâle gelir.

Ne yapılmalı?

• Sahiplik kuralını önceden yazın: Örneğin "alıcıyla ilk anlamlı görüşmeyi yapan ve bunu CRM'e not eden temsilci sahiptir" gibi tek cümlelik, herkesin bildiği bir kural.

• Sahiplik süresini tanımlayın: Belirli bir süre boyunca hiç temas kurulmamış kayıt serbest kalır. Bu, kayıtları "rezerve edip unutma" davranışını önler.

• Ortak satış kuralı koyun: İki temsilcinin gerçekten emek verdiği durumlar için önceden belirlenmiş bir paylaşım oranı, tartışmayı satış gününden önceye taşır.

• Erken giriş ödüllendirilsin: Kaydı ilk giren kişinin sahipliği korunduğunda, temsilciler kayıtları beklemeden sisteme girer.

Dördüncü gizli maliyet: Alıcı gözünde güven kaybı

Bir aile aynı gün iki farklı temsilciden aranır, ertesi gün üçüncü bir kişiden aynı broşürü WhatsApp üzerinden alırsa, firma hakkında ilk izlenimi "düzensiz" olur. Konut gibi yüksek tutarlı ve uzun vadeli bir satın almada alıcı, firmanın teslim sürecini de bu ilk deneyime bakarak tahmin eder. İletişimi koordine edemeyen bir firmanın inşaatı da koordine edemeyeceğini düşünmesi çok doğaldır.

Ne yapılmalı?

Her alıcı için tek bir sorumlu kişi ve tek bir iletişim zaman çizelgesi olmalıdır. Otomatik mesajlar, kişiye o hafta başka bir kanaldan zaten ulaşılıp ulaşılmadığını kontrol etmeden gönderilmemelidir. Bu kontrol, mükerrer kayıtlar birleştirilmeden yapılamaz; dolayısıyla veri temizliği burada doğrudan müşteri deneyimine hizmet eder.

Yönetici için pratik bir çerçeve: Önleme, yakalama, birleştirme

Mükerrer kaydı tamamen ortadan kaldırmak mümkün değildir; amaç onu küçük ve görünür tutmaktır. Bunun için üç katmanlı düşünmeyi öneriyorum.

1. Önleme: Kayıt açılmadan önce sor

Her entegrasyon ve her manuel giriş ekranı, yeni kayıt açmadan önce telefon numarasını standart biçime çevirip mevcut kayıtlarda aramalıdır. Eşleşme varsa yeni kayıt yerine mevcut kayda yeni bir temas notu eklenir. Bu tek kural, sorunun büyük kısmını kaynağında keser.

2. Yakalama: Haftalık şüpheli eşleşme listesi

Önleme her şeyi yakalamaz. İsim benzerliği, aynı e-posta alan adı ya da aynı haneye işaret eden adres gibi zayıf sinyaller için haftalık bir "olası mükerrer" listesi çıkarılmalı ve bir kişi tarafından gözden geçirilmelidir. Burada yapay zekâ destekli benzerlik puanlaması yardımcı olabilir, ancak birleştirme kararını insan vermelidir; çünkü yanlış birleştirilmiş iki farklı alıcı, mükerrer kayıttan daha zararlıdır.

3. Birleştirme: Geçmişi koruyarak tek kayda indir

Birleştirilen kayıtta tüm notlar, tüm kaynaklar ve tüm temaslar korunmalı; sahiplik ise önceden yazılmış kurala göre belirlenmelidir. Birleştirme işleminin kendisi de kayıt altına alınmalı ki ileride "bu kayıt neden değişti?" sorusunun cevabı olsun.

Hangi göstergeler izlenmeli?

• Tekil alıcı oranı: Tekil hane sayısının toplam başvuruya oranı.

• Kaynakta engellenen mükerrer sayısı: Önleme katmanının ne kadar iş yaptığını gösterir.

• Haftalık şüpheli listede kalan kayıt: Liste büyüyorsa yakalama katmanı yetişemiyor demektir.

• Sahiplik itirazı sayısı: Ekip içi çatışmanın en somut ölçüsüdür; sıfıra yaklaşması kuralların işlediğini gösterir.

• Aynı alıcıya aynı gün birden fazla temas: Müşteri deneyimi tarafındaki zararın erken uyarısıdır.

Küçük bir senaryo: Rakamlar düzelince değişen karar

Varsayımsal bir örnek düşünelim. Bir konut projesinde aylık raporda kanallardan biri en çok lead getiren kanal olarak görünüyor ve yönetim bütçeyi o kanala kaydırmayı planlıyor. Kayıtlar tekil haneye indirildiğinde, bu kanaldan gelenlerin önemli bir kısmının aslında başka bir kanal üzerinden zaten tanışılmış aileler olduğu ortaya çıkıyor. Yani kanal yeni alıcı getirmekten çok mevcut alıcıların ikinci temas noktası işlevi görüyor. Bütçe kararı tamamen değişiyor: Yeni alıcı getiren kanal korunuyor, ikinci kanal ise hatırlatma rolüne göre yeniden kurgulanıyor. Bu örnek, mükerrer temizliğinin neden bir teknik iş değil, bir yönetim işi olduğunu iyi anlatıyor.

Sıkça Sorulan Sorular

Mükerrer lead oranı ne kadar olursa normal kabul edilir?

Tek bir doğru oran yoktur; kanal sayısı ve karar süresi arttıkça oran da artar. Önemli olan oranın her ay ölçülmesi ve önleme katmanı kurulduktan sonra düşüş eğilimi göstermesidir.

Kayıtları birleştirirsem reklam kanallarının performans verisi kaybolur mu?

Birleştirme doğru yapılırsa kaybolmaz. Kaynak bilgisi silinmek yerine temas geçmişi olarak saklanır; böylece hem ilk hem son temas kanalı görünür kalır.

Aynı ailenin iki üyesini tek kayıt mı yapmalıyım?

Kişileri ayrı kişi kaydı olarak tutup tek bir satış fırsatına bağlamak genellikle en sağlıklı yoldur. Böylece iletişim bilgileri korunur, ama pipeline'da tek bir hane ve tek bir sorumlu temsilci görünür.

Yapay zekâ mükerrer kayıtları otomatik birleştirebilir mi?

Benzerlik tespiti ve önceliklendirme için çok faydalıdır. Ancak yanlış birleştirmenin maliyeti yüksek olduğu için, özellikle zayıf eşleşmelerde son kararı bir insanın vermesini öneriyorum.

Temsilciler arasındaki sahiplik tartışmalarını nasıl bitiririm?

Kuralı satıştan önce yazarak. İlk anlamlı görüşme, sahiplik süresi ve ortak satış paylaşımı gibi kurallar ekipçe bilindiğinde, tartışma satış gününde değil, kural yazılırken bir kez yapılır.

Yazar: Koray Yalçın — lead yönetimi, CRM mimarisi, dijital pazarlama, yapay zekâ ve gayrimenkul teknolojileri (PropTech) üzerine çalışıyor.