Proje vitrini hazırlanıyorPreparing project showcaseПодготавливаем витрину проекта

Verimlilik

İzin ve tatil dönemlerinde satış sürekliliği planı

Bir temsilcinin bir haftalık izni, iki aylık emeği silebilir. Devir dosyası, vekâlet modeli ve otomasyon ayarlarıyla tatilde de ilerleyen bir akış kurun.

Rocketly · 2026-09-02

Bayram tatilinin başlamasına iki gün var. İki aydır üzerinde çalışılan bir işte müşterinin yönetimi nihayet onayı çıkarıyor ve satın alma sorumlusu perşembe günü saat 16.40'ta yazıyor: revize teklifi bugün gönderirseniz cuma sabahı imzaya girebiliriz. Teklifi hazırlayan temsilci öğlen izne çıkmış; otomatik yanıtı dokuz gün sonrasını gösteriyor, telefonu kapalı. Fiyatın neden öyle kurulduğunu, hangi kalemde pazarlık payı bırakıldığını bilen tek kişi o. Ekipten iki kişi kayda giriyor, son teklifin taslağını bulamıyor ve müşteriye dönüşte ilgileneceğiz diye yazıyor. Dokuz gün sonra gelen cevap tek satır: başka bir tedarikçiyle ilerledik.

İzin ve tatil dönemi sürekliliği, kimsenin çalışmadığı günlerde satış yapmakla ilgili değildir; o günlerde açılan kapıların kapanmadan görülmesiyle ilgilidir. Aşağıda tatilde kaybedilen satışın gerçek sebebini, izin öncesi risk taramasının nasıl yapıldığını, devir dosyasında nelerin bulunması gerektiğini, vekâlet modellerinin hangi durumda hangisinin çalıştığını, müşteriye ne zaman ne söyleneceğini, otomatik yanıtın neden çoğu zaman zarar verdiğini, bildirim ve otomasyonların izinde nasıl ayarlanacağını, izindeki kişiyi aramanın kuralını, tatil dönemi hedef ve tahmininin nasıl kurulacağını ve dönüşteki devrin neden en kritik adım olduğunu ele alıyoruz.

1İzin takvimi2Risk taraması3Devir dosyası4Vekâlet5Dönüş devri
İzin sürekliliğinin beş adımı ve her adımın izin başlamadan önce tamamlanması gereken çıktısı.

Tatilde kaybedilen satışın sebebi yokluk değildir

İzne çıkan temsilcinin masasındaki işler kendiliğinden durmaz; yalnızca görünmez olur. Kaybın büyük kısmı çalışılmayan günlerden değil, o günlerde kimsenin göremediği kayıtlardan gelir. Müşteri sizin takviminizi beklemez, kendi takvimine göre ilerler ve karar penceresi açıldığında yanıt verebilen tarafa döner. Sürekliliğin sorusu bu yüzden kaç kişi çalışıyor değil, hangi kararlar görünür durumda sorusudur.

Bu ayrım küçük ekiplerde daha da keskindir. On kişilik bir satış ekibinde bir kişinin yokluğu portföyün onda birini değil, o kişinin taşıdığı bilginin tamamını kapatır. Fırsatın hangi aşamada olduğu sistemde yazsa bile, müşterinin neden tereddüt ettiği, hangi kişinin projeye direndiği ve teklifte nerede esneklik kaldığı çoğu zaman yalnızca temsilcinin kafasındadır. Paylaşılan görünürlüğün ve temiz devrin nasıl kurulduğunu CRM ile ekip işbirliği yazısında ayrıntılı ele alıyoruz.

İzin öncesi risk taraması: hangi kayıtlara bakılır?

Devredilecek işlerin listesini temsilcinin hafızasından çıkarmak yerine, izin başlamadan bir hafta önce sistemden çekilen dört sorguyla kurmak çok daha güvenilirdir. Birincisi, tahmini kapanış tarihi izin dönemine düşen fırsatlar. İkincisi, son on dört günde hareket görmüş açık fırsatlar; hareket, kararın yaklaştığının en iyi göstergesidir. Üçüncüsü, izin dönemine denk gelen teklif geçerlilik süreleri ve sözleşme yenilemeleri. Dördüncüsü, açık destek talepleri ve vadesi gelen tahsilat hatırlatmaları.

Bu dört listeden çıkan her kayıt üç kutudan birine düşer: devredilecek, bekletilecek, kapatılacak. Kapatılacaklar en çok atlanan kutudur; oysa izin öncesi son hafta, aylardır hareket etmeyen fırsatları dürüstçe kapatmak için doğal bir andır ve devredilecek yığını gözle görülür biçimde küçültür. Neyin gerçekten açık olduğunu belirlemenin kontrol listesini pipeline temizliği yazısında bulabilirsiniz.

Taramanın sonunda çıkan sayı çoğu ekibi şaşırtır: bir haftalık izinde gerçekten devredilmesi gereken kayıt sayısı genellikle beşi geçmez. Geri kalan her şey bekleyebilir. Bu sayıyı önceden bilmek, devir toplantısını yarım saatlik bir işe indirir; bilmemek ise ya her şeyi devretmeye ya da hiçbir şeyi devretmemeye yol açar.

Devir dosyasında ne bulunmalı?

Devir toplantısı yapıp not almamak, devir yapmamakla neredeyse aynı şeydir; konuşulanlar iki gün içinde buharlaşır. Devir dosyası ayrı bir belge değil, fırsatın kendi kaydında, vekilin bakacağı yerde durmalıdır. İçeriği şu yedi başlıkla sınırlı kalırsa hem yazılır hem okunur.

  • Karar haritası: Müşteri tarafında kimin onay verdiği, kimin bütçeyi tuttuğu ve kimin projeyi içeriden savunduğu; unvan listesi değil, tavırlar yazılır.
  • Son teklifin gerekçesi: Fiyatın nasıl kurulduğu, hangi kalemin esneyebileceği ve hangisinin neden sabit olduğu. Bu bilgi olmadan vekil ya hiç cesaret edemez ya da gereğinden fazlasını verir.
  • Sıradaki adım ve tarihi: Bir sonraki temasın ne olacağı ve ne zaman yapılacağı. Belirsiz bir takipteyiz notu, devralan kişiye hiçbir şey söylemez.
  • Kırmızı çizgiler: Vekilin kendi başına verebileceği taviz sınırı ve hangi kararın mutlaka beklemesi gerektiği. Sınır yazılı değilse ya iş durur ya da geri alınamaz bir söz verilir.
  • Açık taahhütler: Müşteriye verilmiş ve henüz yerine getirilmemiş sözler, tarihleriyle. Unutulan küçük bir söz, tatil dönüşünün en pahalı konuşmasıdır.
  • İletişim tercihi: Müşterinin hangi kanaldan, hangi saatte ve hangi tonda konuşulmayı beklediği. Yanlış kanal, doğru mesajı bile geciktirir.
  • Kırılgan nokta: Bu ilişkide şu anda en riskli olan şey; rakiple yeni bir temas, memnuniyetsiz bir kullanıcı ya da geciken bir teslimat olabilir.

Bu dosyayı her seferinde sıfırdan yazmak yerine bir şablona bağlamak gerekir. Şablon yoksa devir kalitesi kişiye göre değişir ve deneyim gösterir ki en dağınık devir, en kritik hesapta yaşanır. Kişiye bağlı bilgiyi paylaşılan standarda çevirmenin yöntemini süreç dokümantasyonu ve SOP yazısında anlatıyoruz; izin devri bu yaklaşımın en kısa ve en somut uygulamasıdır.

Vekâlet modelleri: yedek mi, havuz mu, yalnızca izleme mi?

Devrin kime yapılacağı, dosyanın içeriğinden daha çok tartışılır ve genellikle yanlış soruyla başlar. Doğru soru kim müsait değil, bu hesapta bir hafta içinde hangi karar çıkabilir sorusudur. Karar çıkma ihtimali yüksekse yetki verilmiş biri gerekir; düşükse yalnızca izleyen biri yeterlidir. Aşağıdaki beş model çoğu ekibin ihtiyacını karşılar ve her birinin kendi kırılma noktası vardır.

ModelEn iyi çalıştığı durumKırılma noktası
Birebir yedekAz sayıda büyük ve kişiye bağlı hesapYedek de aynı hafta izne çıkarsa
Havuz nöbetiÇok sayıda benzer ve küçük fırsatHerkes bakar, kimse ilerletmez
Yönetici üstlenirKısa izinler ve kritik anlaşmalarYöneticinin kuyruğu büyür, kendi işi durur
Yalnızca izlemeUzun döngülü, hareketsiz fırsatlarAciliyet çıkarsa karar verecek kimse yok
Bilinçli bekletmeSektörün de kapalı olduğu dönemlerMüşteri önceden bilgilendirilmemişse güven kaybı

Model seçildikten sonra teknik tarafta tek bir iş kalır: vekilin gerçekten görebilmesi ve yazabilmesi. Görme yetkisi olmayan bir vekil, devir dosyasını okusa bile fırsatı ilerletemez; not ekleyemez, teklifi yeniden gönderemez, müşteriye kayıt üzerinden yazamaz. İzin dönemi için geçici yetki verme ve dönüşte geri alma alışkanlığı rol ve yetki yönetimi tarafında yazılı bir kurala bağlanmalıdır; her izinde yöneticiye tek tek sorulan bir iyilik olmamalıdır.

Müşteriye ne, ne zaman söylenir?

Sürekliliğin en ucuz parçası, müşteriye zamanında yapılan tek bir bildirimdir ve en çok atlanan parça da odur. İzin başlamadan önce açık işi olan her müşteriye kısa bir mesaj gider: şu tarihler arasında yerimde olmayacağım, işinizle ilgilenecek kişi şu, kendisi dosyanızı biliyor, acil bir durumda şu numaradan ulaşabilirsiniz. Üç cümledir ve tatil boyunca çıkacak sorunların çoğunu peşinen çözer.

Bildirim yalnızca tarih vermekle yetinmemeli. Bekleyen bir karar varsa ne zaman sonuçlanacağı, gecikecekse yeni tarihi açıkça söylenmelidir; müşteriyi rahatsız eden şey gecikme değil, gecikmeyi kendisinin fark etmesidir. Söz verirken ve sözü tutarken kurulan dilin nasıl çalıştığını beklenti yönetimi yazısında ele alıyoruz; tatil dönemi bu dilin en çok sınandığı zamandır.

Otomatik yanıt neden çoğu zaman zarar verir?

Yaygın tavsiye basittir: izne çıkarken otomatik yanıt kurun. Uygulamada çoğu otomatik yanıt fayda değil zarar üretir, çünkü müşteriye tek bir şey söyler: dokuz gün boyunca burada kimse yok. Karar penceresi açık olan bir alıcı bu mesajı okuduğunda beklemez; alternatif arar ya da işi rafa kaldırır. Sorun otomatik yanıtın kendisinde değil, içeriğindedir.

Zarar veren yanıt yokluğu anlatır. İşe yarayan yanıt yolu anlatır: konunun kime düştüğünü, hangi kanaldan ne kadar sürede dönüleceğini ve acil durumun nasıl tanımlandığını söyler. WhatsApp gibi anlık kanallarda bu daha da kritiktir, çünkü oradaki bekleme toleransı e-postadakinin çok altındadır; yanıt saat bazında çalışmalı ve insana devir eşiğini net vermelidir. Kurulum ayrıntılarını WhatsApp otomatik yanıt yazısında bulabilirsiniz.

Yokluğu değil, yolu anlatın

Pratik bir ölçü var: otomatik yanıtınızda dönüş tarihiniz, vekilin adından önce geçiyorsa yanlış yazılmıştır. Müşteri sizin ne zaman döneceğinizi değil, kendi işinin ne zaman ilerleyeceğini merak eder. Aynı kural iç yazışmalarda da geçerlidir; ekibe giden mesaj izindeyim biçiminde değil, şu üç hesapta karar çıkarsa şu kişiye gidin biçiminde yazılmalıdır. İkinci cümle bir bilgi, birincisi yalnızca bir mazerettir.

Bildirimler ve otomasyonlar izinde ne yapar?

İzin dönemi, otomasyonların sessizce bozulduğu dönemdir. İzindeki kişiye görev atayan kurallar çalışmaya devam eder, hatırlatmalar birikir ve dönüşte iki yüz bildirimlik bir yığın karşılar; o yığının içinde gerçekten acil olan üç kayıt kaybolur. Daha kötüsü, müşteriye giden otomatik akışların bir kısmı cevapsız kalır: sistem randevu önerir, dönen cevabı kimse görmez ve müşteri kendisine bir robotun yazdığını anlar.

Ayarlanması gereken üç şey var. Birincisi, izin dönemine düşen görevlerin atama kuralı: görev kişiye değil role atanıyorsa devir kendiliğinden çalışır. İkincisi, müşteriye giden akışların tatil takvimine göre duraklatılması ya da yanıt kanalının vekile yönlendirilmesi. Üçüncüsü, dönüş gününe konumlandırılmış tek bir toparlama görevi; bu görev olmadan dönüş günü gelen kutusunda geçer. Görevleri şablonla ve otomatik olarak üretmenin mantığını görev şablonları yazısında anlatıyoruz.

İzindeki kişi hangi durumda aranır?

İzin planı kimin yokluğunu değil, hangi kararın sizi beklemeyeceğini planlar.

Her ekipte bu konuda yazılı olmayan bir kural vardır ve tam olarak yazılı olmadığı için işlemez: kimse rahatsız etmek istemez, sonuçta ya kimse aramaz ya da her küçük şey için herkes arar. Kuralı somutlaştırın: hangi büyüklükteki, hangi aşamadaki ve hangi müşteri sınıfındaki bir gelişme izindeki kişiye ulaşmayı hak eder, hangi kanaldan ulaşılır, ne kadar sürede yanıt beklenir. Geri kalan her şey bekler ya da vekil karar verir.

Kural yazılıysa iki taraf da rahatlar. Vekil, aramanın meşru olduğu durumu bildiği için tereddüt etmez ve gereksiz yere beklemez; izindeki kişi de telefonu her titrediğinde işe dönmek zorunda kalmaz. Aynı mantığı sistem üzerinde kurmak isterseniz yükseltme otomasyonu yaklaşımı, kimin ne zaman devreye gireceğini el yordamı olmaktan çıkarır.

Tatil dönemi hedefi ve tahmini nasıl kurulur?

İlk refleks hedefi düşürmektir. Bu çoğu ekipte kendini gerçekleştiren bir kehanete dönüşür: ay ölü ilan edilir, ekip de öyle davranır ve ay gerçekten ölü geçer. Daha iyisi hedefi değil takvimi kaydırmaktır. İzin dönemine giren haftaların aktivite yükü öne çekilir, kapanış beklentisi dönem sonrasına taşınır ve çeyrek toplamı korunur. Ekip böylece boş bir aya değil, sıkıştırılmış bir aya hazırlanır.

Burada beklenmedik ama savunulabilir bir tercih var: izinleri ekibe yaymak yerine yoğunlaştırmak çoğu zaman daha az maliyetlidir. Altı hafta boyunca yarı kadroyla çalışmak, bir hafta boyunca tamamen kapalı olmaktan daha çok fırsat kaybettirir; çünkü yarı kadro dönemi ne şirketin ne müşterinin planlayabildiği bir belirsizlik üretir ve kimse hangi işin gerçekten yürüdüğünü bilmez. Sektörün de yavaşladığı tek bir haftayı seçip herkesi aynı anda izne çıkarmak, müşterinin önceden planlayabileceği tek bir kapalı pencere yaratır.

Tahmin tarafında ayrı bir düzeltme gerekir. İzin dönemine denk gelen fırsatların kapanış tarihleri toplu olarak ötelenmezse çeyrek tahmini şişer ve dönem sonunda kaçınılmaz bir sapma tartışması yaşanır. Kapanış tarihlerini gerçeğe çekmek, hedefi düşürmekle aynı şey değildir; biri tahmini dürüstleştirir, diğeri beklentiyi düşürür.

Dönüş devri ve planı kalıcı kılmak

En çok atlanan adım dönüştür. Giderken yapılan devir bir toplantıyla yapılır, dönüşte yapılan devir ise genellikle hiç yapılmaz; temsilci gelen kutusuna dalar ve vekilin bir hafta boyunca ne yaptığını günler içinde parça parça öğrenir. Oysa dönüş devri daha kritiktir, çünkü müşteriye verilmiş yeni sözler, değişen aşamalar ve yeni öğrenilen bilgiler oradadır.

Pratik kural şudur: dönüş gününün ilk iki saati müşteri temasına değil, devir okumasına ayrılır. Vekil izin süresince yaptığı her temas için tek satırlık not bırakmışsa bu iki saat fazlasıyla yeter; bırakmamışsa iki gün de yetmez. Not bırakma alışkanlığını devir dosyasının bir parçası olarak tanımlamak, dönüşü kolaylaştıran en ucuz yatırımdır.

Planı kalıcı kılmak için son adım, her izin sonrası üç soruluk kısa bir değerlendirmedir: hangi iş bekleyemezdi ama beklemek zorunda kaldı, hangi bilgi dosyada yoktu, hangi bildirim gereksizdi. Üç cevap şablona işlenir ve bir sonraki izinde plan kendiliğinden iyileşir. Aynı mantığın kilit kişi riski ve daha büyük kesintiler tarafındaki karşılığını iş sürekliliği planı yazısında ele alıyoruz.

Bir uyarı da tersten gelmeli: sürekliliği tek kişinin fedakârlığıyla kuran ekipler, izni yalnızca kâğıt üzerinde vermiş olur. Tatilde telefonu açık bırakan temsilci dinlenmez, dönüşünde daha yavaş çalışır ve bunun faturası çeyreğin ortasında gelir. Yüksek tempoda motivasyonun nasıl korunduğunu satış ekibinde tükenmişlik yazısında ayrıca anlatıyoruz; iyi kurulmuş bir izin planı aslında bu sorunun en ucuz önlemidir.

İzin dönemi sürekliliği, özünde bilginin kişide değil kayıtta durmasıyla ilgilidir. Rocketly'de fırsat notları, devir bilgileri, görev şablonları, yetki ayarları ve müşteri iletişimi aynı kayıt üzerinde durduğu için vekil bir hesabı devraldığında sıfırdan başlamaz; ücretsiz hesap açarak kendi izin planınızı kurup deneyebilirsiniz.