Cuma, akşam 21.40. Web sitenizden Kommo'ya yeni bir talep düşüyor. Sıcacık — kişi tam şu an sizi iki rakiple kıyaslıyor. Ve resmen bir sorumlusu bile var. Yalnız o sorumlu, anlaşmalarla ilgilenmeyen hesap yöneticisi.
Ya da üzerine zaten üç yüz anlaşma yığılmış olan Serkan. Günde yüzlerce bildirim — onlara çoktan bakmayı bıraktı. Bu sırada diğer temsilciler boş bir zille oturuyor. Sonuç aynı: talebi kimse devralmadı. Pazartesi sabahı satış müdürü onu yirmi talebin arasından çıkarıp arıyor — ve kibar bir "teşekkürler, başka bir firmayla anlaştık" cevabı alıyor.
Tanıdık geldi mi? Mesele şu. Bu neredeyse hiçbir zaman tembel bir temsilciyle ilgili değildir. Ve neredeyse hiçbir zaman anlaşmanın "sorumlusu olmamasıyla" da ilgili değildir — neredeyse her zaman bir sorumlusu vardır. Sıkıntı, o sorumlunun yanlış kişi olmasıdır. Talep, ona el atmayacak birinde bekler; cevap verebilecek olanlar ise onun var olduğundan bile haberdar olmaz. Bunun satış ekibinizdeki en pahalı delik olduğunu ve Kommo veya amoCRM'de bunu tek bir akşamda nasıl kapatacağınızı göstereceğim.
Vaktiniz darsa kısa versiyon:
- Bir anlaşmanın neredeyse her zaman bir sorumlusu vardır — sorun, onun yanlış kişi olmasıdır: yönetici ya da gömülmüş tek bir temsilci. Tek istisna, Sınıflandırılmamış/Gelen aşamasıdır.
- Bildirimler sorumluya gider. Yanlış sorumlu → sinyal tepki vermeyecek birine düşer, boştaki temsilciler ise anlaşmayı hiç görmez.
- Lead'leri iş yükünün "adaleti" için değil, yanıt hızı için dağıtırsınız.
- Lead Response Management (Harvard Business Review) verilerine göre ilk 5 dakika içinde cevap vermek, 30 dakikaya kıyasla lead'i nitelendirme olasılığınızı kabaca 21 kat artırır.
- Dağıtmanın iki yolu: vardiyaya göre ve "online" durumuna göre. Birincisi plan, ikincisi gerçek.
- Uzaktan ekipler, esnek vardiyalar ve akşam gelen talepler için bir online yönlendirme widget'ına ihtiyacınız var: Peresmenka.
CRM'de lead'leri neden dağıtmalı ki?
Herhangi bir CRM'de — Kommo olsun amoCRM olsun — her anlaşmanın en çok önem taşıyan bir alanı vardır. Sorumlu. Talebin yapışık olduğu tek bir temsilci. Ve işte temel efsane. İnsanlar, taleplerin "sorumlusu olmadığı" için kaybolduğunu sanır. Neredeyse her zaman bir sorumlusu vardır. Asıl soru, onun kim olduğudur.
İşte nasıl işliyor. Bir CRM'de bildirimler "departmana" gitmez. Sorumluya gider. Yeni lead gelir, sorumlu uyarılır. Müşteri sohbete yazar, yine sorumlu. Bir görevin vakti dolar, bir kez daha sorumlu.
Şimdi de nerede bozulduğuna gelelim. Web sitenizi, sohbetlerinizi veya telefon hattınızı bağladığınızda varsayılan sorumlu çoğu zaman yöneticidir ya da entegrasyonu kuran kişi — yani hesap sahibi. Onlar anlaşmalarla ilgilenmez. Bir yığın talep de sessizce, dokunulmadan üstlerinde birikir. Ya da tüm akış tek bir "nöbetçi temsilciye" yığılır — o kadar derine gömülür ki yüzlerce bildirim arka plan gürültüsüne dönüşür ve onları fark etmeyi bırakır. Bu sırada diğer temsilciler boş bir zille oturur.
Sonuç aynıdır: anlaşma resmen park edilmiştir, ama asıl satıcılar onu görmez. Sinyal yanlış yere gitti. Gerçekten sorumlusu olmayan tek yer, Sınıflandırılmamış/Gelen aşamasıdır — sistemin henüz kimseye bağlamadığı talepler. Dağıtımın başlaması gereken yer tam da burasıdır.
Lead dağıtımı, talebin üzerine anında doğru sorumluyu yerleştiren süreçtir. Yönetici değil, ömür boyu meşgul Serkan değil, şu an hatta olan ve el atacak kişi. Anlaşmayı Sınıflandırılmamış'tan alır (ya da çöplük olmuş varsayılan sorumludan çeker) ve canlı bir temsilciye verir. Bu olmadan CRM'iniz, kimsenin dokunmadığı şirin bir kişi yığınına dönüşür.
Tek bir şeyi unutmayın: Bir CRM'de tepki veren "satış departmanı" değildir, belirli bir sorumludur. O sorumlu varsayılan olarak yönetici ya da gömülmüş tek bir temsilciyse bildirim hiçbir yere gitmez ve boştaki temsilciler anlaşmadan hiç haberdar olmaz. Lead dağıtımı tam olarak tek bir nedenle vardır — her talebe bir saniye içinde doğru sorumluyu vermek, yani hatta olan ve el atacak birini.
Neden bu adalet değil, hız meselesi?
Birçok insan dağıtımın "yükü eşit tutmak için" olduğunu düşünür. Yani Merve üç kişinin işini yaparken Tolga tembellik etmesin diye. Bu faydalıdır, ama yan etkidir. Asıl neden hızdır. Lead Response Management (Harvard Business Review) verilerine göre ilk 5 dakika içinde cevap vermek, 30 dakikaya kıyasla lead'i nitelendirme olasılığınızı kabaca 21 kat artırır.
21 kat. Yüzde 21 değil. Tam yirmi bir misli.
Bunun ne demek olduğunu bir oturup düşünün. Müşterinin sıcak olduğu ve konuşmaya hevesli olduğu pencere dakikalarla ölçülür. Saatlerle değil. Sabaha kadar yanlış kişide bekleyen bir talep, çoktan cesede dönmüş demektir. Reklam platformuna onun için zaten ödediniz ve karşılığında hiçbir şey alamayacaksınız.
Ve işte ikinci tuzak geliyor: insanların talepleri aslında ne zaman bıraktığı sorusu. Blazeo (2026) verilerine göre taleplerin onda dördünden fazlası akşamları ve hafta sonları geliyor. Yani tam ofisin kapalı olduğu ve vardiya çizelgesinin "dokuz-altı" olarak çizildiği saatlerde.
Şimdi en önemli dönüş noktası. LeanData'ya göre yavaş yanıt çoğu zaman bir yönlendirme sorunudur, tembel temsilci sorunu değil. Talep, cevap verebilecek birine basitçe hiç ulaşmamıştır. Onu tam şu an canlı bir insana iletecek bir mekanizma yoktur.
Bu her şeyi değiştirir. Bir satış müdürü hız başarısızlığını görünce refleksle insanları sıkıştırmaya başlar. Toplantıda nutuk, ceza tehditleri. Ama sorun insanlarda değildir. Lead'in aktığı borulardadır. Şoförü değil, boruları düzeltin.
Lead'leri dağıtmanın iki yolu
Esasen iki yol vardır. Aralarındaki fark, bir tren tarifesi ile "geldi / rötarlı" yazan varış panosu arasındaki fark gibidir. Biri nasıl olması gerektiğini gösterir. Öbürü ise aslında nasıl olduğunu. LeanData'ya göre yanıt hızınızın çoğunu yiyen şey tam da plan ile gerçek arasındaki bu boşluktur. İkisini de ele alalım.
Birinci yöntem: vardiya çizelgesine göre
Basit ve net. Kimin hangi saatlerde vardiyada olduğunu önceden yazarsınız. Dokuz-bir arası Merve. Bir-altı arası Tolga. O pencerelerdeki lead'ler, koltuğunda "olması gereken" kişiye uçar. Çoğu zaman bunun üstüne bir de round-robin eklersiniz: talepler sırayla, dönüşümlü gider.
Artısı açıktır: öngörülebilirlik. Kapsamı önceden planlarsınız, çizelgenizi görürsünüz, kimin neyden sorumlu olduğunu bilirsiniz. Düzenli bir ofiste saat gibi işler.
Ama bir tuzak var. Çizelge plandır, gerçek değil. Merve öğle yemeğine gitti. Hastalandı. Büyük bir müşteriyle aramada takıldı kaldı. Lead'ler ise çizelgeye göre üstüne yağmaya devam eder. Ve birikir. Sistem onun koltuğunda olduğunu sanır, oysa değildir. Talepler, fiziksel olarak hattan çıkmış bir kişide birikir.
İkinci yöntem: "online" durumuna göre
Burada mantık tersine döner. Talep, kağıt üzerinde vardiyada "olması gereken" kişiye gitmez. Şu an fiilen hatta olan kişiye gider. CRM'i açarsınız, "Çalışıyorum"a basarsınız ve lead almaya başlarsınız. Dizüstünü kapatıp uzaklaşırsınız, akış da bir anda meslektaşlarınıza kayar.
İşte bizim widget'ımız, Peresmenka. Şu an kimin bağlı olduğunun canlı bir aynasını tutar. Gelen talepleri yalnızca o kişilere ve eşit biçimde dağıtır. Ve en kritik kısmı: bir temsilci çevrimdışı olduğu an, taze lead'leri hatta kalan birine yeniden atanır.
Çıkıp giden birinde sallantıda kalan hiçbir talep olmaz. Lead her zaman onu devralabilecek ellere düşer. Bu, çizelgeye göre değil, gerçeğe göre dağıtımdır.
Vardiya mı online mı: yan yana
Kafamız karışmasın diye iki yöntemi tek bir tabloya koyalım. Fark temeldir: çizelge "kimin çalışması gerektiğini", online "kimin fiilen çalıştığını" yanıtlar. Blazeo (2026) verilerine göre taleplerin %40'tan fazlası standart saatlerin dışında geliyor; yani gerçek kapsam küçük bir ayrıntı değil, sonucun yarısıdır.
| Kriter | Vardiya çizelgesine göre | "Online" durumuna göre |
|---|---|---|
| Mantık | Lead, çizelgeye göre vardiyada olması gereken kişiye gider | Lead, şu an fiilen hatta olan kişiye gider |
| "Devre dışı kalmaya" tepki (öğle, hastalık, izin) | Yok. Lead'ler yokta olan temsilcide birikir ve ölü yük olarak bekler | Anında. Akış online meslektaşlara kayar, lead'ler yeniden atanır |
| Akşam, hafta sonu ve saat dilimleri arası kapsam | Zayıf. Çizelge çizilmemiş her yerde boşluk | Güçlü. Hangi saatte giriş yaparsa yapsın talepleri o kişi yakalar |
| Ekipten beklediği şey | Çizelge disiplini, listeyi tutacak biri | Dürüst "online / offline" durum işaretlemesi |
| Kime uygun | Sabit çalışma saatleri olan küçük bir ofis | Uzaktan ekipler, esnek vardiyalar, yarı zamanlılar, karışık saat dilimleri |
| Başlıca risk | Plan gerçekten ayrıldı, talep yokta olan temsilcide öldü | Bir temsilci durumunu işaretlemeyi unuttu (widget içindeki hatırlatmayla çözülür) |
Hangi yöntem kime uyar?
Evrensel bir cevap yok, seçim ekibinizin nasıl kurulduğuna bağlı. LeanData'ya göre yanıt hızı başarısızlıklarındaki artış neredeyse her zaman daha karmaşık bir departman yapısıyla beraber gider: uzaktan çalışma, karışık saat dilimleri, yarı zaman. Ekip ne kadar karmaşıksa, çizelge online karşısında o kadar fena kaybeder. Türe göre tek tek gidelim.
Sabit saatli küçük bir ofis. Herkes dokuz-altı arası tek bir odada oturur. Burada bir çizelge ya da basit bir round-robin yeterlidir. Talepler sırayla gider, yük eşit kalır ve herkes göz önündedir; biri dışarı çıkarsa yanındaki elle devralır.
Uzaktan çalışma, karışık saat dilimleri, esnek vardiyalar, yarı zamanlılar. Çizelgenin dağıldığı yer burasıdır. Biri Lizbon'da, ikincisi Almatı'da, üçüncüsü akşam birkaç saatliğine giriş yapıyor. Bunu bir liste olarak çizemezsiniz. Online'a ihtiyacınız var; yani lead'leri gerçek varlığa göre dağıtan Peresmenka'ya.
Yüksek hacim ve gece gelen talepler. Burada en iyi çalışan bir melez yapıdır: online artı açık vardiyalar. Vardiyalar bugün geceyi kimin kapaması gerektiğini belirler. Online ise güvenlik ağıdır; lead'leri fiilen giriş yapmış olana verir ve hiçbir zaman boşluğa düşmesine izin vermez.
Ve kavranması gereken kısım şu. Çoğu zaman seçim "ya o ya bu" değildir. Vardiyalar ile online farklı soruları yanıtlar. Çizelge hatta kimin olması gerektiğini söyler. Online ise hatta fiilen kimin olduğunu. Peresmenka ikisini birleştirir: vardiyaları planlarsınız ve planladığınız kişilerden hangilerinin gerçekten çalıştığını anında görürsünüz, lead'ler de yalnızca onlara gider.
Ya hiç kimse vardiyada değilse?
Bu, neredeyse hiç kimsenin kapatmadığı andır. Ve kritiktir: Blazeo (2026) verilerine göre taleplerin %40'tan fazlası akşamları ve hafta sonları geliyor — tam da listede "vardiyada" tek bir canlı ruhun bile olmayabileceği saatlerde. Burada iki senaryo var.
Kötü gittiği hâli. Bir talep gece 23.00'te düşer. Sistem onu çizelgeye göre uslu uslu "nöbetçi temsilciye" atar; o kişi ise çoktan uyuyordur. Bildirim boşluğa uçar. Lead sabaha kadar ölü yük olarak bekler. Sabaha kadar da müşteri çoktan, otuz saniyede otomatik cevap veren bir rakibe siparişini vermiştir.
Gitmesi gereken hâli. Lead boşluğa atanmaz. Bir sıraya girer ve giriş yapan ilk kişiye gider. Ya da bir otomatik yanıt onu hemen yakalar: "Teşekkürler, sabah döneceğiz; bu arada sık sorulan soruların cevapları burada." Müşteri duyulmuş hisseder. Ve kaçmaz.
Ve işte en güçlü hamle. Geceler ve hafta sonları, yapay zekayı devreye sokmanın tam da değdiği yerdir. En azından ilk temas için: bir bot anında cevap verir, birkaç nitelendirme sorusu sorar ve cevapları doğrudan anlaşma kartına yazar. Müşteri memnundur — iki gün sonra değil, saniyeler içinde cevap aldı. Ve sabah temsilci anlaşmayı açar, neyle ilgili olduğunu anında görür ve tam hızla devralır. Lead ne soğuk ne de kayıptır. Buna gerçekten hangi yapay zekanın uyduğunu (ve nerede fazla kaçtığını) Kommo Salesbot mı yapay zeka ajanı mı? yazısında ayrıntısıyla ele alıyoruz.
Kural basit: orada olmayan birine asla lead atamayın. Vardiya boşsa, talep bir sırada beklemeli ve giriş yapan ilk kişiye gitmelidir; uyuyan birinde sallantıda kalmamalı. Peresmenka tam olarak bunu yapar: gelen talepleri sıraya alır ve biri online olur olmaz onlara dağıtır.
Bu, "müşteriyi uyurken kaçırdık" ile "onu ilk biz yakaladık" arasındaki farktır. Ve size doğru yapılandırılmış tek bir widget'a mal olur.
Dağıttınız — şimdi hızı ölçün
Diyelim lead'ler artık doğru kişilere düşüyor. Gerçekten hızlı cevap verdiklerini nereden bileceksiniz? Ölçene kadar bilemezsiniz. "Kendimizi hızlı hissediyoruz" bir sayı değildir. Ve unutmayın: 5 dakikaya karşı 30 dakika, 21 kat demektir.
Yani dağıtımdan sonraki ikinci katman, ilk temas hızını ölçmektir: talebin gelmesinden temsilcinin ilk cevabına kadar geçen süre. Lead başına, temsilci başına, gecikenler işaretlenmiş olarak. O zaman dağıtım artık kör olmaktan çıkar — talebin bir insana ulaşıp ulaşmadığını ve o tam dakikalarda tepki verip vermediğini görürsünüz.
İşte SLA ilk temas kontrolünün yaptığı şey budur — yanıt süresini çalışma saatlerine göre sayar, önleyici uyarılar gönderir ve bir anlaşma bayatlamak üzereyken görev oluşturur. Dağıtım lead'i teslim eder; SLA ise kimsenin onu uyurken kaçırmamasını sağlar.
Peki hangi widget'a ihtiyacınız var?
Buraya kadar okuduysanız, ortalıktaki satış müdürlerinin yarısından fazlasından zaten daha çok şey biliyorsunuz. Varsayılan bir sorumlu sessiz bir deliktir. Hız 21 kat farkla kazanır. Çizelge plandır, online ise gerçektir.
Kommo ve amoCRM'de online dağıtım için Peresmenka'ya ihtiyacınız var. Ekibin canlı bir aynasını tutar, talepleri yalnızca fiilen hatta olanlara dağıtır ve çıkıp giden kişilerde lead'lerin asla takılı kalmasına izin vermez. Yanıt hızını dakikalara çekmek mi istiyorsunuz? Ayrıca ilk temas hızı kontrolüne (SLA) de bakın. Ekibiniz dağıtık çalışıyorsa, Kommo üzerinde uzaktan bir satış departmanı kurmanın da ayrı bir hikayesi var.
Size son bir soru. Şu an, bu satırı okurken, yeni anlaşmalarınız tek bir kişinin üstüne yığılırken ekibin geri kalanı hiç bildirim almadan mı oturuyor?