Aynı Anda Birden Fazla Projeyi Yöneten Satış Ekibi İçin CRM Rehberi

Kısa cevap: Çok projeli satış yönetiminde kırılan şey CRM'in kendisi değil, tek proje varsayımıyla kurulmuş kurallardır. Dört başlığın yeniden tanımlanması gerekir: lead'in hangi projeye ait olduğu, müşterinin kime ait olduğu, kimin hangi projenin stoğunu ve fiyatını görebildiği ve raporların proje bazında mı konsolide mi okunacağı. Bu dördü yazılı hale getirilmeden ikinci projeye geçen ekiplerde çapraz satış fırsatı kaybolur, aynı müşteri iki danışman tarafından aranır ve yönetim hangi projenin gerçekten çalıştığını göremez.

Bu yazı, tek projeden çok projeye geçişte CRM kurgusunun nasıl değişmesi gerektiğini ele alıyor. CRM'e ilk geçiş süreci ayrı bir konu; onu Satış Ofisi Yönetiminde Dijital Dönüşüm: Excel'den CRM'e Geçiş yazısında anlattık.

İkinci projeyle birlikte ne değişir?

Tek projede çalışan bir satış organizasyonunda pek çok kural yazılmamıştır ama işler; çünkü belirsizlik yoktur. Lead tek projeye gelir, stok tektir, herkes aynı fiyat listesine bakar. İkinci proje devreye girdiğinde bu varsayımların tamamı çöker.

Bu tablodaki her satır, ikinci projede küçük bir aksaklık, üçüncü projede yönetilemez bir karmaşa üretir. Bu yüzden düzenlemenin doğru zamanı üçüncü proje değil, ikincisidir.

Ekip modeli: proje bazlı mı, ortak havuz mu?

Projeler birbirinden çok farklıysa (örneğin biri lüks konut, diğeri orta segment veya biri konut, diğeri ticari ünite) proje bazlı ekip genellikle daha iyi sonuç verir. Projeler benzer segmentteyse ortak havuz, kapasiteyi daha verimli kullanır.

Hangi model seçilirse seçilsin, CRM tarafında iki şeyin tanımlı olması gerekir: danışmanın hangi projelerde yetkili olduğu ve lead dağıtımının bu yetkiye göre yapılması.

Çok projeli lead yönetimi

Çok projeli yapıda lead kaydının taşıması gereken ek bilgi, hangi projeye geldiğidir. Bu alan boş kaldığında ne dağıtım doğru yapılabilir ne de reklam performansı proje bazında okunabilir.

Kurulması gereken yapı:

• Proje alanı zorunlu olmalı. Her lead bir projeyle ilişkilendirilir; proje belirsizse "belirlenmedi" gibi geçici bir değer değil, ilk görüşmede netleştirilecek bir görev oluşturulur.
• Kaynak ile proje ayrı tutulmalı. Reklam kampanyası proje bazlı kurgulanmışsa lead geldiği kampanyadan projeyi otomatik alabilir; ancak genel marka kampanyalarında proje sonradan belirlenir.
• Mükerrer kontrolü proje bağımsız yapılmalı. Aynı telefon numarası başka bir projede kayıtlıysa bu bilgi görünmelidir. Aksi halde aynı kişi iki farklı projede iki ayrı müşteri olarak görünür.
• Proje değişikliği kaydedilmeli. Müşteri A projesinden B projesine yöneldiğinde kayıt silinmez; geçiş, geçmişiyle birlikte izlenebilir olmalıdır.

Lead'in hangi kanaldan geldiğinin proje bazında ölçülmesi, bütçe dağılımını doğrudan etkiler: iki projede aynı kanal çok farklı sonuç verebilir. Lead maliyeti tarafı için: Emlak Lead Maliyeti Ne Kadar Olmalı?

Çapraz satış: müşteriyi doğru projeye taşımak

Çok projeli yapının en büyük avantajı, bir projeye uymayan müşteriyi kaybetmek zorunda olmamaktır. Bütçesi yetmeyen alıcı diğer projede uygun bir tip bulabilir; ticari ünite arayan bir müşteri başka projeye yönlendirilebilir.

Ancak bu avantaj kendiliğinden gerçekleşmez. Önündeki üç engel şunlardır:

1. Danışman diğer projeyi bilmiyor. Ortak havuz modelinde bile, danışmanların kendi ana projesi dışındaki stok ve fiyatı bilmemesi yaygındır.
2. Prim kaygısı. Müşteriyi başka projeye yönlendiren danışman, primini kaybedeceğini düşünüyorsa yönlendirmez.
3. Sistem görünürlüğü yok. Danışman diğer projenin uygun dairelerini ekranında göremiyorsa öneri yapamaz.

Çözüm sırası da aynıdır: önce görünürlük, sonra prim kuralı, sonra eğitim. Üçü birden kurulduğunda çapraz satış bir kampanya değil, günlük çalışma biçimi haline gelir.

Kayıp nedeninin kayıtlı olması burada da işe yarar: bütçe nedeniyle kaybedilen müşteriler, yeni bir projenin lansmanında ilk bakılacak listedir. Bu havuzun nasıl çalıştırılacağını ayrı bir yazıda ele aldık: Konut Projesinde Lead Segmentasyonu.

Veri yapısı: proje, etap, bağımsız bölüm, müşteri

Çok projeli kurgunun teknik omurgası, kayıtların birbirine nasıl bağlandığıdır. Yanlış kurulmuş bir hiyerarşi, ilerleyen aylarda raporların neden tutmadığını açıklar.

Doğru işleyen yapı dört katmandan oluşur:

1. Proje. En üst katman. Teslim tarihi, konum, ruhsat bilgisi ve sorumlu ekip bu düzeyde tutulur.
2. Etap / faz. Aynı projenin farklı satış dönemleri. Fiyat listesi ve teslim tarihi çoğu zaman etap düzeyinde değişir.
3. Bağımsız bölüm. Blok, kat, daire; durum, fiyat ve şerefiye bu düzeyde tanımlıdır.
4. Müşteri. Projelerden bağımsız, tek bir kimlik. Müşterinin her projeyle ilişkisi ayrı bir süreç olarak bu kimliğe bağlanır.

Kritik olan dördüncü katmandır. Müşteri kaydı projenin altına yerleştirildiğinde, aynı kişi her projede yeniden oluşturulur ve mükerrer kontrolü ile çapraz satış imkânsız hale gelir. Müşteri projeden bağımsız bir kimlik olmalı, projeyle ilişkisi ayrı bir bağ olarak kurulmalıdır.

Bu ayrımın pratik testi basittir: bir müşterinin kaydını açtığınızda, o kişinin bugüne kadar hangi projelerle ilgilendiğini tek ekranda görebiliyor musunuz? Göremiyorsanız yapı proje merkezli kurulmuş demektir ve çok projeli çalışmaya uygun değildir.

Proje bazlı pipeline ve faz yönetimi

Projelerin satış süreci her zaman aynı değildir. Ön satıştaki bir projede süreç "ilgi → randevu → opsiyon → sözleşme" şeklinde işlerken, teslim aşamasındaki bir projede "randevu → daire gezisi → sözleşme" biçiminde kısalır.

İki yaklaşım vardır:

• Ortak pipeline. Tüm projeler aynı aşamaları kullanır. Raporlama kolaylaşır, karşılaştırma mümkün olur; ancak bazı aşamalar belirli projelerde anlamsız kalır.
• Proje bazlı pipeline. Her projenin kendi aşamaları vardır. Gerçeğe daha yakındır ama konsolide raporlamayı zorlaştırır.

Pratikte en iyi sonucu veren çözüm, ortak bir ana aşama setinin korunup proje özelinde alt aşamaların tanımlanmasıdır. Böylece yönetim aynı tabloyu okuyabilir, ekip kendi sürecini yönetebilir.

Faz yönetimi ayrı bir başlıktır: aynı projenin farklı etapları çoğu zaman farklı fiyat, farklı teslim tarihi ve farklı stok durumu taşır. Etabın proje içinde ayrı bir katman olarak tanımlanması, "hangi etap ne kadar sattı" sorusunun cevaplanmasını sağlar.

Stok görünürlüğü ve fiyat yetkisi

Çok projeli yapıda envanterin en kritik sorusu şudur: kim hangi projenin stoğunu ve fiyatını görebilir?

Çapraz satışın çalışabilmesi için danışmanın diğer projelerde en azından müsaitlik ve fiyat bilgisini görmesi gerekir. Tam kapalı bir yapı, güvenliği artırır ama çapraz satışı imkânsız kılar.

Fiyat tarafında iki şeyin proje bazında ayrı yönetilmesi gerekir: geçerli fiyat listesi versiyonu ve indirim yetkisi. Aynı danışmanın A projesinde farklı, B projesinde farklı indirim yetkisi olması normaldir ve bu farkın sistemde tanımlı olması gerekir. Envanter yapısının kurulumu için: Konut Projesinde Envanter Yönetimi.

Müşteri sahipliği kuralları

Tek projede sahiplik basittir: müşteri, onu ilk karşılayan danışmanındır. Çok projede aynı kural yetmez, çünkü müşteri birden fazla projeyle ilgilenebilir.

Yazılması gereken kurallar:

• Sahiplik müşteri bazlı mı, proje bazlı mı? Müşteri bazlı sahiplikte tüm projelerde aynı danışman ilgilenir; proje bazlı sahiplikte her projede o projenin danışmanı devreye girer. İkisinin de savunulabilir tarafı vardır ama karma bir uygulama en kötüsüdür.
• Geçiş durumu. Müşteri A projesinden B projesine yöneldiğinde kayıt devredilir mi, yoksa iki danışman birlikte mi çalışır?
• Çakışma hakemliği. Aynı müşteri iki projede iki danışman tarafından kaydedilmişse hangi kayıt geçerlidir?
• Eski müşteri önceliği. Daha önce bir projeden satın almış müşteri yeni projede kime düşer?
• Acente kaynaklı müşteri. Kanal ortağının getirdiği müşterinin başka projeye yönelmesi durumunda kanal kaydı geçerliliğini korur mu?

Dördüncü madde ticari olarak en değerlisidir: mevcut alıcılar, yeni projenin en hazır kitlesidir ve bu kitleye kimin, nasıl yaklaşacağının önceden belirlenmesi gerekir.

Raporlama: proje bazlı ve konsolide görünüm

Çok projeli yapıda tek bir rapor yeterli olmaz. Üç katman gerekir:

1. Proje bazlı rapor. Her projenin kendi lead, randevu, satış ve stok tablosu.
2. Konsolide rapor. Tüm projelerin toplamı; şirket düzeyinde satış ve tahsilat görünümü.
3. Karşılaştırmalı rapor. Projelerin aynı metrikte yan yana okunması.

Üçüncüsü, çok projeli yapının asıl kazancıdır. Aynı kanalın iki projedeki dönüşümünü, aynı danışmanın iki projedeki performansını veya iki projenin stok erime hızını karşılaştırmak, tek projede üretilemeyecek bir bilgidir.

Dikkat edilmesi gereken bir nokta var: projelerin birbirinin talebini yediği durumlar. Aynı bölgede, benzer segmentte iki proje satıyorsanız, bir projenin reklamının diğerinin lead'ini azaltıp azaltmadığı ancak karşılaştırmalı okumayla görülebilir. Metrik seti için: Satış Ekibi KPI: Ölçmeniz Gereken 8 Metrik.

Tek satış ofisinden birden fazla proje satmak

Projeler farklı lokasyonlardaysa fiziksel ofis yapısı da bir karar konusudur. Üç yaygın kurgu vardır ve her birinin CRM tarafında karşılığı farklıdır.

Merkezî ofis kurgusunda ziyaretçi kaydının tek bir müşteri altında toplanması, çapraz satışın en doğal biçimde gerçekleştiği yerdir: bir projeye bakmaya gelen müşteri, aynı görüşmede diğer projenin seçeneklerini de görebilir.

Ofisler ayrıysa dikkat edilecek nokta, yönlendirmelerin kaydedilmesidir. Bir ofisten diğerine gönderilen müşteri, kaydı olmadan gönderildiğinde çoğu zaman hiç ulaşmaz.

Lansman ve kampanya takviminin çakışması

Çok projeli yapının en az konuşulan sorunu, projelerin birbirinin zamanını ve bütçesini tüketmesidir. İki projenin lansmanı üst üste geldiğinde satış ekibi, pazarlama bütçesi ve yönetim dikkati bölünür.

Takvim planlamasında dikkate alınacak başlıklar:

• Lansman aralığı. İki projenin yoğun satış dönemleri mümkün olduğunca ayrıştırılmalıdır.
• Reklam çakışması. Aynı bölgede, benzer segmentte iki proje aynı anda reklam veriyorsa maliyetler yükselir ve lead'ler birbirinden çalınır.
• Ekip kapasitesi. Lansman döneminde ekibin ne kadarının hangi projeye ayrılacağı önceden planlanmalıdır.
• Stok dengesi. Bir projenin kalan stoğu eritilmeden yeni projeye geçilmesi, eski projeyi sahipsiz bırakabilir.
• Fiyat konumlandırması. Aynı segmentteki iki projenin fiyatları birbiriyle karşılaştırılacağı için tutarlı olmalıdır.

Karşılaştırmalı raporlar bu çakışmayı fark etmenin başlangıç noktasıdır: bir projenin lead maliyeti diğerinin lansmanıyla aynı dönemde yükseliyorsa bu, araştırılması gereken bir sinyaldir; tek başına iki kampanyanın birbirine rakip olduğunun kanıtı değildir. Sonuca varmadan önce sezonsallık, reklam açık artırmasındaki genel rekabet, hedefleme ve kitle örtüşmesi, kreatif performansındaki değişim ve piyasa koşulları gibi diğer olası nedenler de kontrol edilmelidir. Lansman planlaması için: Konut Projesi Lansman Süreci.

Prim ve komisyonun çok projeli hâli

Prim sistemi, çok projeli yapıda ekibin davranışını doğrudan belirler. Netleştirilmesi gereken sorular:

• Projeler arasında prim oranı farklı mı? Satması zor olan projeye daha yüksek oran veriliyor mu?
• Müşteriyi başka projeye yönlendiren danışman ne alır? Yönlendirme primi var mı?
• İki danışman birlikte çalıştığında prim nasıl paylaşılır?
• Hedefler proje bazlı mı, toplam mı? İkisi birden kullanılıyorsa ağırlıkları nedir?
• Kanal satışıyla iç ekip satışı aynı projede nasıl ayrışır?

İkinci soru çapraz satışın kaderini belirler. Yönlendirme karşılıksızsa danışman müşteriyi kendi projesinde tutmaya çalışır ve şirket hem o satışı hem müşteriyi kaybeder. Prim kurgusu için: Emlak Prim ve Komisyon Sistemi Nasıl Kurulur?

Rol ve yetkilendirme

Çok projeli yapıda yetkilendirme yalnızca bir düzen meselesi değil, aynı zamanda kişisel verilerin korunması açısından da anlam taşır. 6698 sayılı Kanun kapsamındaki veri minimizasyonu ilkesi çerçevesinde, her kullanıcının yalnızca görevini yerine getirmek için ihtiyaç duyduğu verilere erişmesi beklenir.

Pratik karşılığı:

• Danışman, diğer projelerin müşteri listesine ve iletişim geçmişine erişmemelidir.
• Acente ve dış kanal kullanıcıları yalnızca yetkilendirildikleri projeyi ve kendi müşterilerini görmelidir.
• Maliyet, kâr marjı ve yönetim raporları sınırlı role açık olmalıdır.
• Personel değişikliğinde yetkiler zamanında güncellenmelidir.

Ayrıntılı çerçeve: Gayrimenkul Satışında KVKK Uyumluluğu.

Yeni proje açarken kontrol listesi

Yeni bir proje satışa çıkarken CRM tarafında tekrarlanabilir bir kurulum akışı olması, her seferinde sıfırdan karar vermeyi önler.

Bu listenin şablon haline getirilmesi, sonraki projelerde kurulumu daha hızlı ve tekrarlanabilir kılar.

Evon'un canlı modül sayfasında Proje Yönetimi, Proje Faz Yönetimi, Proje Karşılaştırma, Envanter Motoru, Fiyat Listesi Yönetimi, Rol & Yetkilendirme, Lead Kaynak Analizi, Personel Performansı ve Proje Raporları modülleri yer alır. Bu modüllerin kendi kurulumunuzda hangi verileri birlikte kullandığını doğrulamanız gerekir. Modül dökümü için Modüller sayfasına bakabilirsiniz.

Sık yapılan yedi hata

1. Yeni projeyi mevcut yapının içine sıkıştırmak. Proje alanı olmayan bir kurguda ikinci projenin verisi birincininkiyle karışır.
2. Mükerrer kontrolünü proje içinde yapmak. Aynı müşteri iki projede iki ayrı kayıt olur.
3. Çapraz satışı prim kuralı olmadan beklemek. Danışman kendi primini korumayı tercih eder.
4. Tüm projelere tek pipeline dayatmak. Anlamsız aşamalar, doldurulmayan alanlara dönüşür.
5. Diğer projenin stoğunu tamamen kapatmak. Görünürlük olmadan yönlendirme yapılamaz.
6. Sadece konsolide rapora bakmak. Toplam iyi görünürken bir proje ciddi biçimde geri kalıyor olabilir.
7. Yetkileri personel değişikliğinde güncellememek. Ayrılan danışmanın erişimi açık kalır.

Sık sorulan sorular

Her proje için ayrı CRM kurmalı mıyım?

Ayrı sistemler kurulduğunda veri parçalanır; mükerrer kayıt riski artar, çapraz satış ve karşılaştırmalı raporlama zorlaşır. Bu süreçler entegrasyon ve ortak bir veri katmanıyla yine de yönetilebilir, ancak ek kurulum ve bakım yükü doğurur. Tek sistem içinde proje bazlı ayrıştırma ve yetkilendirme, çoğu organizasyon için daha sade bir yapı sunar.

Danışman diğer projenin fiyatlarını görmeli mi?

Çapraz satış bekliyorsanız en azından müsaitlik ve fiyat düzeyinde görmelidir. Müşteri listesi ve iletişim geçmişi ise proje bazında kapalı kalabilir.

Aynı müşteri iki projede kayıtlıysa ne yapmalı?

Kayıtlar birleştirilmeli, müşteri tek bir kimlik altında tutulmalı ve her projeyle ilgisi ayrı bir süreç olarak izlenmelidir. Bunun için mükerrer kontrolünün proje bağımsız çalışması gerekir.

Projeler arasında prim oranı farklı olabilir mi?

Olabilir ve çoğu zaman gerekir. Satışı zor olan projeye daha yüksek oran vermek, ekibin dikkatini dengeler. Önemli olan farkın gerekçesinin ekibe açıklanmasıdır.

Ortak havuz mu, proje bazlı ekip mi daha iyi?

Projeler farklı segmentlerdeyse proje bazlı ekip, benzer segmentteyse ortak havuz genellikle daha iyi çalışır. Hibrit model ikisinin avantajını birleştirir ama kuralların yazılı olmasını gerektirir.

İki projenin lansmanı üst üste gelirse ne olur?

Ekip kapasitesi, pazarlama bütçesi ve yönetim dikkati bölünür. Aynı bölgede benzer segmentteki projeler aynı anda reklam verdiğinde maliyetler yükselir. Yoğun satış dönemlerini mümkün olduğunca ayrıştırmak gerekir.

Kaç projeden sonra bu yapıyı kurmalıyım?

İkinci projeden itibaren. Üçüncü projede kurmaya kalkıldığında, düzeltilmesi gereken bir veri geçmişi de birikmiş olur.

Sonuç

Çok projeli satış yönetimi, tek projeli yapının büyütülmüş hâli değildir; farklı kurallar gerektiren farklı bir düzendir. Kritik olan dört başlık nettir: lead hangi projeye ait, müşteri kime ait, kim neyi görebilir ve raporlar hangi katmanda okunur.

İkinci projeye başlarken ayrılacak birkaç günlük kurgu çalışması, üçüncü projede haftalarca sürecek düzeltme işini ortadan kaldırır. Başlangıç noktası basit: bugün CRM'inizde bir lead'in hangi projeye ait olduğunu tek bir alandan okuyabiliyor musunuz?

İlgili Yazılar

Konut Projesinde Müşteri Memnuniyeti Nasıl Ölçülür? Konutta Sözleşme Devri: Müşteri Daireyi Teslimden Önce Satmak İsterse Ne Olur? Satış Kampanyası Nasıl Kurgulanır? Kapsam, Süre, Bitiş ve Ölçüm