Kurumsal bir İK ekibi tek bir şirket için işe alım yapar. Danışmanlık firması aynı anda beş, on, bazen yirmi müşteri için çalışır — ve bu, yazılımın çözmesi gereken problemi kökten değiştirir.
Klasik aday takip sistemleri tek şirket varsayımıyla tasarlandı. Müşteri kavramı ya yoktur ya sonradan eklenmiş bir etiket olarak durur. Danışmanlıkta bu, kısa sürede sürtünmeye dönüşür.
Altı temel yetenek
1. Müşteri, pozisyon ve aday ayrı katmanlar olmalı
Bir ATS'de hiyerarşi genelde şöyledir: pozisyon → aday. Danışmanlıkta üç katman gerekir: müşteri → pozisyon → aday.
Bunun pratik sonucu: bir müşterinin tüm pozisyonlarını, bir pozisyonun tüm adaylarını, ve bir adayın hangi müşterilere sunulduğunu ayrı ayrı görebilmeniz.
Bu üçüncüsü kritik. Aynı adayı iki müşteriye aynı anda sunuyorsanız bunu bilmeniz gerekir.
2. Aynı aday birden çok süreçte olabilmeli
Klasik ATS'lerin en sık takıldığı yer. Aday bir pozisyona bağlıdır; ikinci pozisyona eklemek için kopyalamak gerekir ve iki kayıt oluşur.
Danışmanlıkta bir aday üç farklı müşteriye üç farklı pozisyon için sunulabilmeli, üç süreç bağımsız yürümeli, ama aday kaydı tek kalmalı. Geçmişi, notları, temas kayıtları o tek kayıtta birikmeli.
3. Müşteriler arası veri ayrımı
Bir müşterinin adayları diğerinin ekranında görünmemeli. Bu, basit bir yetkilendirme ayarından fazlası — sistemin mimarisinde olması gerekir.
Test etmenin yolu: demo sırasında iki farklı müşteri hesabı oluşturmalarını ve birinden diğerinin verisine erişmeye çalışmalarını isteyin.
4. Müşteri erişimi ve geri bildirim
Müşteriniz kısa listeyi nasıl görüyor? Üç seçenek var ve aralarında büyük fark var:
- PDF gönderiyorsunuz. En yaygın, en zahmetli. Geri bildirim e-postadan gelir ve sistem dışında kalır.
- Paylaşılan bir bağlantı. Müşteri adayları görür ama yorum yazamaz.
- Müşteri portalı. Müşteri kendi pozisyonlarını görür, aday üzerine yorum yazar, aşama ilerletir. Geri bildirim sistemde kalır.
Üçüncüsü hem operasyonel yükü azaltır hem de süreç verinizi tamamlar. En az bulunan seviye de bu.
5. Kendi markanızla sunabilmek
Müşteriye ve adaya giden ekranlarda başka bir şirketin markası görünüyorsa, hizmetiniz "bir yazılımın acentesi" gibi algılanır. Ayrıca müşterinizin o araca doğrudan gitme ihtimali doğar.
White-label desteğinin hangi seviyeye kadar olduğunu netleştirmek gerekiyor — logo değiştirmekten kendi alan adınıza kadar beş farklı seviye var. Bunu ayrı bir yazıda ele aldık.
6. Aday havuzunun aranabilirliği
Danışmanlık firmasının en değerli varlığı arşividir. Beş yıllık birikim, aranabilir değilse yok hükmündedir.
Sorulacak somut şey: "İstanbul'da, fintech deneyimli, son 18 ayda temas edilmemiş" gibi bir sorgu çalışıyor mu? Serbest metin araması yeterli değil — yapılandırılmış filtreleme gerekiyor.
Ticari taraf
Danışmanlıkta yazılımın kapsaması gereken bir de gelir tarafı var: yerleştirme başına komisyon, garanti süresi, fatura durumu, müşteri başına gelir raporu.
Bunlar her üründe yok. Yoksa muhasebeyle ayrı bir tabloda takip edersiniz — ki bu işe yarar ama iki sistem arasında tutarsızlık üretir.
En azından şunu sorun: müşteri başına ve danışman başına süreç raporu alabiliyor musunuz?
KVKK: zincir daha uzun
Danışmanlıkta veri sorumluluğu zinciri kurumsal işe alımdan uzundur:
Pozisyonu açan müşteri veri sorumlusudur. Siz onun adına işleyen konumdasınız. Yazılım sağlayıcısı sizin alt işleyeniniz. Bu zincirin sözleşmelerle kurulmuş olması gerekir.
Pratik sonuçları: adaya verisinin hangi şirkete iletileceğinin açıklanması, kendi havuzunuzda tuttuğunuz veri ile müşteri için işlediğiniz verinin farklı amaçlara tabi olduğunun bilinmesi, ve silme talebinde veriyi hem sizde hem müşteride bulabilmek.
Çok müşterili yapıda dağınık veri, tek müşterili yapıdan daha risklidir — çünkü aynı adayın verisi birden fazla yerde çoğalır.
Değerlendirme yaparken
Demo sırasında en bilgilendirici senaryo şu: iki müşteri, üç pozisyon, ve iki pozisyona birden uyan bir aday. Bu kurulumu canlı yapmalarını isteyin.
Klasik bir ATS bu senaryoda ya çuvallar ya da çirkin bir geçici çözüm gösterir. Danışmanlık için tasarlanmış bir ürün doğal olarak yürütür.
Headhunting özelinde ATS ile CRM ayrımını ayrı bir yazıda ele aldık.