Süre ve ev sahibi havuzu: randevuyu müsait olana dağıtmak

Perşembe sabahı 09:40. Kurumsal bir yazılım ekibinde rezervasyon sayfasına yeni bir demo talebi düşüyor. Sayfa müşteriye o hafta için yalnız üç saat gösteriyor ve üçü de aynı danışmanın takviminden geliyor. Oysa ekipte dört ev sahibi var; ikisinin haftası neredeyse boş. Müşteri gösterilen en yakın saati seçiyor: gelecek salı 15:00. Talebin geldiği an ile görüşmenin yapılacağı an arasında beş gün duruyor ve bu beş günün tek sebebi, sistemin müsaitliği tek bir kişinin takvimi sanması. Ekip meşgul değildi; ekibin müsaitliği yanlış tanımlanmıştı.

Bu yazı randevu dağıtımını bir takvim görüntüsü olarak değil, bir kapasite ve kuyruk kararı olarak ele alıyor. Önce sürenin nereden geldiğini, sonra ev sahibi havuzunun hangi kurala göre kurulduğunu, ardından müsaitliğin nasıl gerçeğe yaklaştırıldığını konuşacağız. Sonraki bölümler slot listesini daraltan kuralları, havuz büyüdükçe müşteri tarafında neyin değiştiğini, dağıtımın işleyip işlemediğini gösteren sayıları, gelmeyen randevuların havuz kararını nasıl bozduğunu ve üç haftaya yayılmış bir kurulum planını içeriyor.

Randevu dağıtımı neden bir takvim sorunu değil, bir kuyruk sorunudur?

Takvim bir görüntüdür: kimin nerede olduğunu gösterir. Dağıtım ise bir karardır: gelen talebi kimin karşılayacağını söyler. İki işi tek ekranda birleştirdiğinizde genellikle karar tarafı kaybolur, çünkü ekran zaten dolu görünür. Talep sayısı ekip kapasitesinin altındayken bu fark önemsizdir. Talep dalgalanmaya başladığı anda, aynı hafta içinde biri günde beş görüşme yaparken diğerinin bir görüşmeyle kaldığı bir tablo çıkar ortaya ve kimse bunu kasten yapmamıştır.

Kuyruk mantığıyla bakınca soru netleşir: elinizde bir talep akışı, bir hizmet süresi ve birden fazla hizmet noktası var. Bekleme süresi, hizmet noktalarının sayısından çok, taleplerin bu noktalara nasıl atandığına bağlıdır. Tek kuyruk çok gişe modeli, bankada ve havalimanında yıllardır aynı sebeple kullanılır: müşteri hangi gişenin hızlı olduğunu tahmin etmek zorunda kalmaz, sistem onun yerine yönlendirir. Randevuda müşteriden istenen tahmin ise daha da zordur; müşteri kimin boş olduğunu bilmez, yalnız kendisine gösterilen listeyi görür.

Bu yüzden randevu dağıtımı bir arka plan detayı değil, deneyimin ilk temas noktasıdır. Müşterinin markayla kurduğu ilk somut ilişki çoğu zaman bir slot listesidir ve o liste, ekibin işini nasıl organize ettiğini müşteriye anlatmadan gösterir. Konuya daha geniş çerçeveden bakmak isterseniz müşteri deneyiminin hangi anlarda kurulduğunu ele alan yazımız bu ilk temas noktalarının neden orantısız ağırlık taşıdığını açıklıyor.

Toplantı süresini kim belirlemeli: toplantının türü mü, ev sahibi mi?

Süreyi ev sahibine bıraktığınızda ekip içinde sessiz bir standart kayması başlar. Aynı işi biri kırk beş dakikada, diğeri yirmi dakikada yapar; ikisi de haklıdır, çünkü kimse ortak bir tanım koymamıştır. Sonuç, dışarıdan bakınca tutarsız bir hizmet: aynı markadan iki kişiyle konuşan müşteri iki farklı deneyim yaşar. Süreyi toplantının türüne bağladığınızda ise tanım işin kendisinden gelir. Keşif görüşmesi otuz dakikadır çünkü içinde beş soru ve bir sonraki adım kararı vardır; teknik demo altmış dakikadır çünkü ekran paylaşımı ve soru turu içerir.

Türe bağlı süre ayrıca ölçmeyi mümkün kılar. Otuz dakikalık keşif görüşmelerinin sistematik olarak kırk dakika sürdüğünü görürseniz, elinizde bir disiplin sorunu değil bir tasarım sorunu vardır: görüşmenin kapsamı süreye sığmıyordur. O zaman ya kapsamı bölersiniz ya da süreyi resmen büyütürsünüz. Süre kişiye bağlıyken bu sinyali hiç göremezsiniz, çünkü sapma kişisel tarz gibi görünür.

Rocketly tarafında bu tanım Süre & Ev Sahibi Havuzu ayarında yaşar: toplantı sürelerini ve o türü karşılayabilecek ev sahibi havuzunu birlikte tanımlarsınız, randevu da havuzdaki en az yüklü müsait kişiye düşer. Yani süre bir kişinin alışkanlığı olmaktan çıkıp toplantı türünün özelliği haline gelir; havuzdaki herkes aynı sözü verir.

Tampon süreyi neden sürenin parçası saymalısınız?

Otuz dakikalık bir görüşme nadiren otuz dakika tutar. Notun yazılması, kaydın güncellenmesi, bir sonraki adımın planlanması genellikle beş ila on dakika daha ister. Bu süreyi takvimde tanımlamazsanız, ekip onu bir sonraki görüşmeden çalar ve gecikme gün boyunca birikir. Saat 16:00 randevusuna 16:12'de bağlanan bir ev sahibi, sabah 09:00'da doğru başlamış olabilir; arada sekiz görüşme ve sekiz küçük gecikme vardır.

Ev sahibi havuzunda hangi dağıtım kuralı işe yarar?

Havuz kurmak, "herkes her işi alır" demek değildir. Dağıtım kuralı, havuzun içindeki sırayı belirler ve seçtiğiniz kural doğrudan hangi sorunu çözmek istediğinizi söyler. Dört yaygın kural vardır ve her birinin bedeli farklıdır.

Dağıtım kuralı	Nasıl çalışır	Ne zaman doğru seçim	Bedeli
Sıralı (round robin)	Havuzdaki kişiler sırayla randevu alır	Ekip homojen, işler birbirine benziyor	Yarı zamanlı çalışanlar hızla dolar
En az yüklü	O gün veya hafta en az randevusu olan kişiye düşer	Ekip üyelerinin kapasitesi farklı	Yükün doğru sayılması gerekir
Beceri veya dil bazlı	Havuz konuya göre daraltılır	Ürün hattı veya dil ayrımı gerçek	Dar havuzlarda bekleme uzar
Sahiplik öncelikli	Mevcut müşteri kendi temsilcisine gider, boşsa havuza	İlişki sürekliliği satıştan önemli	Temsilci yoğunken müşteri bekler

Pratikte çoğu ekip bu kuralları katmanlar: önce sahiplik kontrol edilir, sonra beceri filtresi uygulanır, kalan havuzda en az yüklü kişi seçilir. Katmanlı kurgunun tek şartı, her katmanın bir sonrakine düşme koşulunun yazılı olmasıdır. "Temsilci üç gün içinde müsait değilse havuza düşer" cümlesi kurulmadıysa, sahiplik kuralı zamanla bir bekleme makinesine dönüşür.

Havuzu kurarken kimin hangi müşteriyi hangi evrede karşılayacağı sorusu da gündeme gelir. Bu, dağıtımdan çok ilişki tasarımıdır ve müşteri yaşam döngüsünü evre evre haritalayan bir çalışma ile netleşir: ilk temas, kurulum, büyütme ve yenileme görüşmeleri çoğu zaman farklı havuzlara aittir.

Gösterilen müsaitlik gerçekten müsaitlik mi?

Slot listesinin güvenilirliği tek bir soruya bakar: bu saat gerçekten boş mu? Ev sahibinin kişisel takviminde bir veli toplantısı, bir doktor randevusu veya başka bir sistemde açılmış bir görüşme varsa ve bu bilgi rezervasyon sayfasına ulaşmıyorsa, sayfa boş görünen ama aslında dolu olan saatler satıyor demektir. Bunun bedelini müşteri öder: onaylanan randevu bir saat sonra iptal edilir.

Çift yönlü takvim senkronu bu boşluğu kapatır. Google Calendar Sync ve Outlook Takvim Entegrasyonu iki yönde de çalışır: Rocketly'de açılan randevu bağlı takvime düşer, takvimde meşgul işaretlenen zaman ise rezervasyon sayfasında slot olarak gösterilmez. Tek yönlü senkron çoğu zaman daha kötüdür, çünkü sistemin doğru çalıştığı hissini verirken tam da çakışmayı yaratacak yönü boş bırakır.

İzin ve tatil de aynı kategoridedir. Ekip Takvimi tarafında bir ev sahibi izinliyken onun slotları rezervasyona açılmaz; bu, havuzun o gün otomatik olarak daraldığı anlamına gelir. Havuzu tasarlarken kritik soru şudur: iki kişilik bir havuzda biri izne çıktığında kalan kapasiteyle gelen talebi karşılayabiliyor musunuz? Cevap hayırsa havuz iki kişilik değil, aslında bir kişiliktir.

Slot listesini daraltan kurallar nelerdir?

Boş bir takvim, iyi bir rezervasyon sayfası değildir. Müşteriye açılan liste, ekibin gerçekten kabul edebileceği randevuları göstermelidir. Dört kural bu listeyi şekillendirir: randevular arası tampon, günlük üst sınır, ne kadar öncesine kadar rezervasyon alınabileceği ve minimum ön-süre. Rezervasyon Kuralları tarafında slotlar doğrudan bu kurallara göre üretilir, yani liste bir tercih değil bir sonuçtur.

Minimum ön-süre çoğu ekibin geç fark ettiği ayardır. On beş dakika sonrasına randevu alınabiliyorsa, ev sahibi hazırlıksız yakalanır ve görüşmenin kalitesi düşer. İki saatlik bir ön-süre, hazırlık için yeterli olduğu kadar müşteriyi de kaybetmeyecek kadar kısadır. Diğer uçta, kırk gün ötesine açılan takvimler gelmeyen randevu oranını yükseltir; insanlar bir ay sonrasına verdikleri sözü unutur.

Günlük üst sınır ise kaliteyi koruyan settir. Bir ev sahibinin günde altı demo yapabildiğini biliyorsanız, yedincisini sistemin kabul etmemesi gerekir. Aksi halde takvim dolar, hazırlık düşer ve müşteri farkı hisseder. Bu tür sınırların ürünü gerçekten kullandırmakla doğrudan ilişkisi vardır; müşteri benimsemesini konu alan yazımızda kalabalık ama yüzeysel görüşmelerin neden kullanım alışkanlığına dönüşmediğini ayrıntılı ele alıyoruz.

Havuz büyüdükçe müşteri tarafında ne değişir?

Havuz mantığının müşteri için bir bedeli vardır: karşısına kimin çıkacağını önceden bilmez. Bu, ilk temas için genellikle sorun değildir; müşteri hızlı bir saat arıyordur, isim ikincildir. Ancak ilişki ilerledikçe beklenti değişir. Üçüncü görüşmede geçmişi bilmeyen yeni bir isimle karşılaşmak, müşteriye baştan anlatma yükü bindirir ve bu yük görünmez bir memnuniyetsizlik üretir.

Çözüm havuzu kaldırmak değil, havuza bir hafıza vermektir. Randevu bir kişi kaydına bağlıysa, ev sahibi görüşmeye girmeden önce geçmiş görüşmeleri, açık talepleri ve son notları görebilir. Bu, kişiselleştirmenin en sade biçimidir ve kişiselleştirmeyi segmentten bireye indiren yaklaşımla aynı mantığı paylaşır: müşteriye özel davranmak için onu tanıyan tek bir kişiye değil, tanıyan bir kayda ihtiyaç vardır.

İkinci düzeltme, seçim hakkını müşteriye kısmen geri vermektir. Sayfada "ilk müsait kişi" ile "belirli bir ev sahibi" arasında seçim sunmak, aceleci müşteriyi hızlandırırken ilişki isteyen müşteriyi de memnun eder. Özel Rezervasyon Adresi tam bu ihtiyaca karşılık gelir: ekip için ortak bir rezervasyon adresi tutarken her ev sahibine kendi adresini tanımlayabilir, kaydederken sistemin çakışan adresi kabul etmediğini bilirsiniz. Müşteri bir kez aldığı bağlantıyı yıllarca kullanır.

Müşterinin kendi kayıtlarına ve geçmiş randevularına erişebildiği bir alan da bu yükü hafifletir. Self-servis portalın ne kadarını müşteriye açmak gerektiğini tartıştığımız yazı, randevu geçmişinin portalda görünmesinin destek trafiğini nasıl azalttığını örnekliyor.

Dağıtımın işlediğini hangi sayılar gösterir?

Havuz kurulduktan sonra ölçmeniz gereken şey doluluk değil, dengedir. Doluluk yüksek olabilir ve dağıtım yine de bozuk olabilir; tek bir kişi doldurduğunda ortalama iyi görünür. Bakılması gereken dört sayı vardır: talep ile görüşme arasındaki ortalama gün sayısı, ev sahibi başına haftalık randevu sayısının dağılımı, hiç talep almayan slotların oranı ve iptal ile gelmeyen randevuların toplamdaki payı.

Rezervasyon Analitiği bu soruların çoğunu doğrudan yanıtlar: hangi gün ve saat dilimlerinin dolduğunu, hangi slotların hiç talep almadığını ve rezervasyonların ne kadarının iptalle bittiğini gösterir. Buradaki asıl kazanç, müsaitliği tahminle değil gerçek talebe bakarak ayarlamaktır. Cuma öğleden sonrası üç haftadır hiç dolmuyorsa o saatleri kapatmak kapasite kaybı değil, ekibe geri kazandırılan zamandır.

Bu sayıların yanına müşteriye sorulan tek bir soru eklemek tabloyu tamamlar. Görüşme sonrası "randevu almak ne kadar kolaydı?" sorusu, slot listesinin gerçekte ne hissettirdiğini ölçer. Soruyu yazarken dikkat gerekir; ölçen soru ile ölçmeyen soru arasındaki farkı ele aldığımız yazı, yönlendirici ifadelerin cevabı nasıl bozduğunu gösteriyor.

Havuz dengesini haftalık mı aylık mı ölçmeli?

Haftalık bakmak dalgalanmayı abartır, aylık bakmak sorunu geç fark ettirir. Pratik bir orta yol, dört haftalık kayan ortalamaya bakıp haftalık uçları not etmektir. Bir ev sahibinin dört hafta üst üste havuz ortalamasının belirgin biçimde üzerinde kalması, dağıtım kuralının değil kapasite tanımının yanlış olduğunu söyler.

Gelmeyen randevular havuz kararlarını nasıl değiştirir?

Gelmeyen randevu yalnız bir boş saat değildir; havuzdaki sıranın da bozulmasıdır. Sıralı dağıtımda randevusu iptal olan kişi sıradaki randevuyu almaz, çünkü sistem onu zaten yüklenmiş sayar. Bu yüzden yükü planlanan randevuya göre değil, gerçekleşen randevuya göre saymak daha adil bir dağıtım üretir.

No-show Takibi müşterinin geçmiş no-show sayısını toplam randevusuyla birlikte gösterir; riskli randevuyu planlarken bunu görürsünüz. Üç randevudan ikisine gelmemiş bir müşteri için altmış dakikalık bir slot ayırmak yerine kısa bir teyit görüşmesi kurmak, havuzun kapasitesini korur. Bu bir cezalandırma değil, kapasiteyi gerçeğe göre planlamaktır.

Hatırlatmalar ise en ucuz müdahaledir. Otomatik Hatırlatma randevudan 24 saat ve 1 saat önce ilgili kişiye bildirim ve e-posta gönderir; Misafire Hatırlatma E-postası aynı işi rezervasyon sayfasından gelen misafirler için yapar ve tek anahtarla kapatılabilir. Tek Tık Onay ve İptal ile müşteri hatırlatmadaki imzalı bağlantıdan randevusunu üye olmadan onaylar, erteler ya da iptal eder. Erken gelen bir iptal, gelmeyen bir randevudan çok daha iyidir: saat havuza geri döner.

İptal edilen randevunun ardından ne yapıldığı da ayrı bir konudur. Sessizce kapatmak yerine kısa bir yeniden planlama teklifi göndermek, ilişkiyi kurtaran adımdır; sorun büyümeden müşteriye ulaşmayı anlatan yazımızda bu tür temasların zamanlaması ayrıntılı ele alınıyor.

Havuzu üç haftada nasıl kurarsınız?

Havuz kurulumu büyük bir proje değildir, ama sırası önemlidir. İlk hafta tanımlara ayrılır: hangi toplantı türleri var, her birinin süresi ne, hangi türü kimler karşılayabiliyor. Bu üç sorunun yanıtı yazıya dökülmeden hiçbir ayar anlamlı olmaz. Çoğu ekip burada beş türle başlayıp ikiye iner, çünkü aradaki üçü aslında aynı görüşmenin farklı isimleridir.

İkinci hafta kurallar ve senkron için ayrılır: takvimler bağlanır, tampon süre, günlük üst sınır ve minimum ön-süre girilir, izin günleri işaretlenir. Bu hafta sonunda rezervasyon sayfası iç ekiple test edilir; ekipten üç kişi kendi telefonlarından randevu alır ve gördükleri saatleri kendi takvimleriyle karşılaştırır. Bu basit test, senkron yönü eksik kurulmuş sistemlerin çoğunu yakalar.

Üçüncü hafta dar bir kitleyle canlıya çıkmaya ayrılır. Sayfayı önce mevcut müşterilerle paylaşın, yeni taleplerle değil; hata çıkarsa maliyeti düşük olur. İlk iki haftanın verisiyle günlük sınırları ve müsaitlik pencerelerini bir kez daraltın. Gelen rezervasyonun doğrudan takvime yazılmasını istemiyorsanız Rezervasyon Onay Akışı ile talepler "onay bekliyor" durumunda düşer, siz kabul edene kadar slot kesinleşmez; reddettiğinizde saat yeniden rezervasyona açılır.

Kurulum sonrası ilk aksaklık kaçınılmazdır: bir çakışma, bir yanlış atama, bir geç bildirim yaşanır. Bu anların nasıl telafi edildiği, sistemin kendisinden daha çok iz bırakır; kötü bir deneyimi sadakate çeviren telafi yaklaşımı burada doğrudan uygulanabilir.

Havuzu bozan yaygın hatalar hangileri?

En sık görülen hata, havuzu kurup dağıtım kuralını hiç gözden geçirmemektir. Ekip değişir, biri yarı zamanlıya geçer, biri yeni bir ürün hattı öğrenir; havuz tanımı altı ay önceki ekibi tarif etmeye devam eder. Çeyrekte bir yapılan on beş dakikalık bir gözden geçirme bu kaymayı önler.

İkinci hata, tüm randevu türlerini tek havuza toplamaktır. Satış görüşmesi ile kurulum görüşmesi aynı havuzda olduğunda, acil satış talepleri kurulum takvimini tıkar. Satış sonrası tarafındaki görüşmeleri ayrı bir havuzda tutmanın gerekçelerini satış sonrası hizmet yönetimini ele aldığımız yazıda bulabilirsiniz.

Üçüncü hata, önceliği hiç tanımlamamaktır. Tüm talepler eşit muamele görürse, en değerli müşteri en uzun bekleyen olabilir. Havuza küçük bir öncelik katmanı eklemek için müşteri segmentlerini bilmek gerekir; RFM analiziyle segmentleri veriden çıkaran yöntem bu katmanı kurmanın en sade yoludur.

Sonuç: müsaitliği bir vaat gibi yönetmek

Rezervasyon sayfasında gösterilen her saat bir vaattir. O saati gösterdiğinizde, hazırlıklı bir kişinin o saatte orada olacağını söylüyorsunuz. Süre tanımı bu vaadin kapsamını, ev sahibi havuzu kimin tutacağını, kurallar da hangi saatlerin gerçekten verilebileceğini belirler. Üçü birlikte çalıştığında müşteri daha erken bir saat görür, ekip daha dengeli bir hafta yaşar ve kimse kimin randevuyu alacağını konuşmak için mesaj atmak zorunda kalmaz.

Başlamak için çok şey gerekmez: iki toplantı türü, iki ev sahibi ve üç kural yeter. Rocketly hesabınızı ücretsiz açıp süre ve ev sahibi havuzunu kendi ekibinizle deneyebilirsiniz.

Sıkça sorulan sorular

Ev sahibi havuzu kaç kişiyle anlamlı olur?

İki kişiden itibaren anlamlıdır, ama gerçek faydası üç kişiden sonra başlar. İki kişilik havuzda biri izne çıktığında kapasite yarıya iner; üç kişide dalgalanma yumuşar. Havuzun büyüklüğünden çok, üyelerin aynı toplantı türünü gerçekten karşılayabilmesi önemlidir.

En az yüklü kişiye dağıtım, kıdemli ekip üyelerini dezavantajlı kılar mı?

Yükü ham randevu sayısıyla ölçerseniz evet. Kıdemli kişiler genellikle daha uzun ve daha karmaşık görüşmeler alır. Çözüm, yükü randevu sayısıyla değil toplam randevu süresiyle saymak veya kıdemli üyeler için günlük üst sınırı düşük tutmaktır.

Müşteri belirli bir kişiyi seçmek isterse ne olur?

Her ev sahibi için ayrı bir rezervasyon adresi tanımlayıp bu bağlantıyı ilişki sahibi kişiye verirsiniz. Ortak havuz adresi yeni taleplere, kişisel adres mevcut müşterilere hizmet eder. İki adres aynı kural setini kullandığı sürece çakışma yaşanmaz.

Havuz kurduktan sonra ilk neyi ölçmeliyim?

Talep ile görüşme arasındaki ortalama gün sayısını. Bu sayı düşüyorsa havuz işini yapıyordur. Ardından ev sahibi başına haftalık randevu dağılımına bakın; ortalama iyi görünse bile uçlar açıksa dağıtım kuralı henüz oturmamıştır.