Headhunting Firmaları için Yazılım Seçimi: ATS mi, CRM mi?

Headhunting Firmaları için Yazılım Seçimi: ATS mi, CRM mi?

Aday takip sistemleri, kurumsal işe alım için tasarlandı: bir şirket, kendi pozisyonlarına gelen başvuruları yönetiyor. Süreç ilanla başlar, başvuruyla devam eder.

Headhunting firmasının işi bunun tersidir. İlan yoktur, başvuru yoktur. Aday aranır — çoğu zaman iş aramayan birinden söz ediyoruz. Ve bir müşteri kavramı vardır, ki klasik ATS'de bunun karşılığı yoktur.

Bu yapısal fark, yazılım seçimini de değiştiriyor.

Dört temel fark

İlişki uzunluğu. Kurumsal işe alımda aday ilişkisi haftalarla ölçülür. Headhunting'de yıllarla. Bugün ilgilenmeyen bir aday iki yıl sonra doğru pozisyon için doğru kişi olabilir. Yazılımın bunu hatırlaması gerekir.

Çift taraflı süreç. Sadece adayları değil müşterileri de yönetiyorsunuz. Hangi müşteriye hangi pozisyon için hangi adayı sunduğunuz, hangi aşamada olduğu, sözleşme koşulları — bunlar ATS'lerde ya yoktur ya sonradan eklenmiş bir alan olarak durur.

Gizlilik. Aynı adayın iki farklı müşteriye sunulmaması, bir müşterinin diğerinin adaylarını görmemesi gerekir. Bu, rol bazlı yetkilendirmenin ötesinde bir ayrım.

Gelir bağlantısı. Yerleştirme başına komisyon, garanti süresi, fatura takibi. Klasik ATS'de gelir kavramı yoktur.

"Recruitment CRM" ne demek

Bu ihtiyaçlara cevap veren ürünler genelde "recruitment CRM" ya da "staffing software" diye anılıyor. Farkı, merkeze süreci değil ilişkiyi koyması.

Somut karşılığı şu: bir ATS'de bir aday bir pozisyona bağlıdır ve pozisyon kapandığında aday arşive gider. Bir recruitment CRM'de aday bağımsız bir kayıttır; pozisyonlar onun etrafında gelir geçer. Son temas ne zamandı, ne konuşuldu, ne bekliyor, hangi müşterilere sunuldu — bunlar adayın kendi geçmişidir.

Seçerken bakılacak yedi şey

1. Aday havuzu aranabilir mi? Headhunting firmasının en değerli varlığı arşividir. 5.000 adaylık bir havuzda "İstanbul'da, fintech deneyimli, son 18 ayda temas edilmemiş" gibi bir sorgu çalışıyor mu?

2. Müşteri tarafı var mı? Müşteri, o müşteriye ait pozisyonlar, sunulan adaylar ve aşamalar ayrı ayrı yönetilebiliyor mu?

3. Aynı aday birden çok süreçte olabiliyor mu? Klasik ATS'lerin sık takıldığı yer. Bir aday üç farklı müşteriye üç farklı pozisyon için sunulabilmeli ve bunlar birbirine karışmamalı.

4. Temas geçmişi tutuluyor mu? E-posta, telefon, LinkedIn mesajı. Ekip arkadaşınızın altı ay önce bu adayla konuştuğunu görebiliyor musunuz?

5. Pasif aday bulma desteği var mı? İlan yayımlamıyorsanız adayı bir yerden bulmanız gerekiyor. Sistem bu tarafta ne sunuyor?

6. Müşteriye sunum nasıl yapılıyor? Kısa liste müşteriye nasıl gidiyor — PDF mi, paylaşılan bir bağlantı mı? Müşteri geri bildirimini sisteme girebiliyor mu, yoksa e-postadan mı geliyor?

7. Kendi markanızla sunabiliyor musunuz? Müşteriye giden ekranların sizin markanızı taşıması, danışmanlık firmaları için önemli bir ayrımdır. White-label desteği olup olmadığını netleştirin.

KVKK tarafı headhunting'de daha keskin

Kurumsal işe alımda aday size başvurur; bu, işlemenin dayanağını büyük ölçüde kolaylaştırır. Headhunting'de aday başvurmaz, siz onu bulursunuz. Bu, veriyi hangi dayanakla topladığınız sorusunu daha görünür hâle getirir.

Ayrıca aday verisini bir üçüncü tarafa — müşterinize — iletiyorsunuz. Bu aktarımın adaya açıklanmış ve dayanağının kurulmuş olması gerekir.

Pratik sonuçları: rıza kaydının kimin neye ne zaman rıza verdiğini gösterecek şekilde tutulması, saklama süresinin tanımlı olması ve süre dolduğunda gerçekten bir şey olması, adayın silme talebinde tüm kayıtların bulunabilmesi. Dağınık bir arşivde bunların hiçbiri yapılamaz.

Karar çerçevesi

Şu üç soruya evet diyorsanız klasik bir ATS muhtemelen size dar gelir:

  1. Birden fazla müşteri için işe alım yapıyor musunuz?
  2. Adaylarınızın çoğu aktif başvuran değil, sizin bulduğunuz kişiler mi?
  3. Aynı adayı zaman içinde birden fazla pozisyon için değerlendiriyor musunuz?

Üçüne de hayırsa, bir ATS yeter ve daha basit olduğu için daha iyi çalışır.


Jobbar.AI'nin headhunter ve İK danışmanlıkları tarafındaki yaklaşımı — aday havuzu yönetimi, white-label kullanım ve aday karşılaştırma — için ana sayfadaki SSS bölümüne bakabilirsiniz.

Bu Yazıyı Paylaş