yazan Simon Bodych
Güncellendi 02 Eyl 2026
12 dk. okuma
Aday takip sistemi, yani ATS, artık kurumsal işe alımın omurgası. Büyük şirketlerde zaten standarttı, son birkaç yılda orta ölçekli firmalar da hızla bu tarafa geçti. Bunun temel nedeni çok açık, ilan sayısı arttı, başvuru hacmi büyüdü, uzaktan ve hibrit işe alım kalıcı hale geldi. Elle Excel takip etmek, mail kutusunda CV aramak, notları farklı araçlarda tutmak sürdürülebilir değil.
İş arayanlar ATS’yi genelde tek bir açıdan tanıyor, “CV’mi sistem okuyabiliyor mu?” Oysa işe alım ekipleri için ATS çok daha fazlası. Bu sistem, aynı anda veri tabanı, süreç motoru, arama ekranı, raporlama aracı, onay mekanizması ve uyum kaydı tutan bir yapı. İyi kurulmuş bir ATS yoksa işe alım ekibi dağılır, aday deneyimi bozulur, yöneticiye doğru rapor çıkmaz.
Bu yazıda ATS’nin gerçekten nasıl çalıştığını sade ama teknik yönü güçlü bir çerçeveyle anlatacağım. Mimari katmanlardan CV ayrıştırmaya, aday puanlamadan Boolean aramaya, ilan yayından teklif aşamasına kadar tüm akışı ele alacağız. Hem İK profesyonelleri hem recruiter’lar hem de sistemi daha bilinçli kullanmak isteyen adaylar için pratik bir rehber olsun istedim.
ATS, başvuruları toplamak ve takip etmek için kullanılan bir yazılım değildir sadece. Aslında daha doğru tanım şu olur, işe alım süreçlerini tek yerde yöneten merkezi bir aday veri tabanı ve iş akışı platformu. İlan açarsınız, ilanı farklı kanallara dağıtırsınız, başvuruları toplarsınız, CV’leri işler, filtreler, görüşme aşamalarını takip eder, teklif ve ret süreçlerini kaydedersiniz. Bunların hepsi aynı sistemde yürür.
Piyasadaki çoğu ATS farklı arayüz ve özellik setlerine sahip olsa da temel mantık benzer. Greenhouse, Lever, Workday Recruiting, SmartRecruiters, iCIMS, Teamtailor ya da Türkiye’de kullanılan yerel çözümler, hepsi aşağı yukarı aynı omurga üzerinde çalışır. Farkı yaratan şey kullanım kolaylığı, entegrasyon kalitesi, raporlama gücü ve otomasyon esnekliğidir.
Tipik bir ATS’de şu modüller bulunur:
Orta ölçekli bir şirket bile 2-3 yılda on binlerce aday kaydı biriktirebilir. Perakende, çağrı merkezi, üretim, teknoloji gibi yüksek hacimli sektörlerde bu sayı yüz binleri rahat görür. Bu yüzden ATS aslında sadece bir form toplama aracı değil, ciddi ölçekte veri işleyen bir SaaS ürünüdür.
Basitleştirerek anlatırsak ATS, satış ekiplerinin kullandığı CRM mantığının işe alıma uyarlanmış halidir. Müşteri yerine aday, satış fırsatı yerine açık pozisyon, teklif aşaması yerine mülakat aşaması vardır. Fakat bu benzetme tek başına yetmez. Çünkü ATS aynı zamanda belge yönetir, arama yapar, otomatik aksiyon tetikler ve hukuki kayıt tutar.
Çoğu modern ATS şu teknik katmanlardan oluşur:
Aday verisi sisteme tek kanaldan gelmez. Kariyer sitesi başvuruları, kariyer portalları, LinkedIn Easy Apply, çalışan yönlendirme formları, recruiter’ın manuel yüklediği CV’ler, hatta fuar veya toplu işe alım etkinliklerinden alınan listeler sisteme düşebilir.
Yaygın giriş kanalları şunlardır:
Teknik tarafta bu akış çoğu zaman API üzerinden çalışır. İlan platformu adayın adını, iletişim bilgilerini, başvurduğu pozisyonu, özgeçmiş dosyasını ve bazı ek sorulara verdiği yanıtları yapılandırılmış veri olarak ATS’ye iletir. Sistem de bunları tekil bir aday kaydına bağlar.
Sisteme PDF ya da Word dosyası girdiğinde ATS, bunu sadece ek olarak saklamaz. Önce içeriği okur, sonra metni anlamlı alanlara bölmeye çalışır. İsim, telefon, e-posta, çalışılan şirketler, görev unvanları, tarih aralıkları, eğitim bilgisi, beceriler, sertifikalar gibi alanlar çıkarılır. Buna CV parsing, yani CV ayrıştırma denir.
Buradaki amaç recruiter’ın yüzlerce dosyayı tek tek açmasını azaltmaktır. Veriler yapılandırılmış hale gelirse filtreleme yapılabilir. Mesela son 3 yılda SAP kullanmış, İstanbul’da yaşayan, İngilizce seviyesi iyi olan adaylar birkaç saniyede listelenebilir.
Ayrıştırılan bilgiler veri tabanında belirli alanlara yazılır. Her adayın benzersiz bir ID’si olur. Aynı kişi farklı pozisyonlara başvurduysa sistem bunu çoğu zaman tek profil altında birleştirir ya da eşleştirme önerir. İyi bir ATS’nin en kritik işi burada başlar, yinelenen kayıtları azaltmak ve aday geçmişini korumak.
Saklanan tipik alanlar şunlardır:
Teknik tarafta ilişkisel veri tabanı kullanımı yaygındır. PostgreSQL, MySQL veya benzeri çözümler sık görülür. Hızlı arama için bunlara ek olarak Elasticsearch ya da OpenSearch gibi indeksleme motorları devreye girer. Çünkü recruiter saniyeler içinde sonuç bekler, özellikle veri havuzu yüz binlerce profile ulaştığında bu şarttır.
Recruiter ekranında gördüğünüz filtreler, anahtar kelime aramaları ve aday sıralamaları bu katmanda oluşur. Aynı veri tabanındaki iki adayı sistem neden farklı sırada gösteriyor, cevap burada. Bazı sistemler son başvuru tarihine göre sıralar, bazıları ilana uygunluk puanı üretir, bazıları recruiter’ın daha önce benzer pozisyonlarda tercih ettiği profilleri öne çıkarır.
Adaylar bir boru hattı içinde ilerler. Başvurdu, ön elemeden geçti, yönetici görüşmesi, teknik mülakat, teklif, işe alındı ya da reddedildi. Bu aşamaların her biri sistemde hareket olarak kaydedilir. Kimin hangi tarihte hangi kararı verdiği görülebilir. Bu kayıtlar sadece operasyon için değil, denetim ve raporlama için de gereklidir.
Teoriyi bir kenara bırakıp tek bir açık pozisyon üzerinden düşünelim. Örneğin İstanbul’da hibrit çalışan bir kıdemli veri analisti aranıyor. İşin ATS içindeki yolculuğu çoğunlukla şu sırayla ilerler:
İlk adım ilan değil, requisition kaydıdır. Yani pozisyonun sistemde resmi olarak açılması. Departman, bağlı yönetici, bütçe, ücret aralığı, lokasyon, tam zamanlı veya sözleşmeli çalışma tipi, açılma nedeni gibi bilgiler girilir. Büyük şirketlerde bu kayıt çoğu zaman onay sürecine tabidir. Finans bütçeyi onaylar, İK norm kadroyu kontrol eder, üst yönetici işe alım izni verir.
Bu adım zayıfsa süreç baştan dağılır. Çünkü hangi rolün neden açıldığı, kaç kişinin alınacağı, maaş bandı ve kritik yetkinlikler net olmaz. ATS burada sadece kayıt tutmaz, disiplini de dayatır. Bu iyi bir şeydir.
Onay sonrası recruiter ilan metnini sisteme yükler. ATS, bu ilanı şirket kariyer sayfasında yayınlar ve bağlı kanallara dağıtır. Tek bir girişle birçok platforma çıkmak burada büyük zaman kazandırır. Ancak iyi recruiter’lar şunu bilir, her kanal aynı metinle yönetilmez. Teknoloji rolü için farklı, saha satış rolü için farklı kanal stratejisi gerekir.
İlanın gidebileceği kanallar arasında şunlar vardır:
Aday başvurduğunda ATS bir başvuru kaydı üretir. Eğer aday daha önce sistemde varsa aynı profille ilişkilendirmeye çalışır. Yoksa yeni bir profil açılır. Özgeçmiş dosyası, ön yazı, başvuru soruları, ücret beklentisi, çalışma izni bilgisi, askerlik durumu gibi alanlar kaydedilebilir. Türkiye’de özellikle saha ve operasyon rollerinde vardiya uygunluğu, sürücü belgesi, seyahat engeli gibi sorular da sık kullanılır.
Başvuru geldikten sonra sistem CV’yi metne dönüştürür. Ardından bu metinden veri çıkarmaya başlar. Örneğin “Veri Analisti, ABC Teknoloji, 2022-2024” ifadesini iş deneyimi olarak, “Power BI” ifadesini beceri olarak işaretler. Çıkarılan alanlar sadece profile yazılmaz, arama indeksine de eklenir. Bu sayede recruiter “SQL”, “Tableau”, “müşteri analitiği” gibi kelimelerle tarama yapabilir.
Basit bir örnek düşünelim:
Recruiter’ın gördüğü şey artık bir dosya yığını değil, sorgulanabilir veridir. Fark tam olarak burada ortaya çıkar.
Sistem genelde bazı adayları öne çıkarır. Ama burada çok önemli bir uyarı yapmak gerekir. ATS karar vermez, önceliklendirme yapar. İyi ekiplerde recruiter puana bakar, sonra profil okur, sonra kısa liste çıkarır. Sadece sistem skoruyla ilerlemek kötü işe alımın kısa yoludur.
Ön elemede kullanılan kriterler genelde şunlardır:
Kısa liste sonrası ATS, mülakat organizasyonunun merkezi haline gelir. Recruiter telefon ekranı planlar, hiring manager’a aday gönderir, teknik görüşme paneli atar, takvim entegrasyonu ile davet yollar. Değerlendirme formları sistemde doldurulur. Bu sayede “Ben notu mailde atmıştım” kaosu ortadan kalkar.
İyi kurgulanmış bir süreçte her aşamanın net amacı vardır. İlk görüşme motivasyon ve temel uygunluk içindir, teknik görüşme beceri derinliğini ölçer, son görüşme ekip uyumu ve karar kalitesi sağlar. ATS bu ayrımı görünür kılar.
Son aşamada teklif bilgileri sisteme girilir. Kabul, ret, karşı teklif, işe başlama tarihi gibi alanlar işlenir. İşe alınan aday, bazı sistemlerde doğrudan HRIS veya onboarding yazılımına aktarılır. Reddedilen aday ise ileride değerlendirilebilmesi için yetenek havuzunda tutulabilir, tabii veri saklama izni ve şirket politikasına uygun şekilde.
ATS’lerin en çok yanlış anlaşılan tarafı burası. Birçok aday, sistemin CV’yi “insan gibi” okuduğunu düşünüyor. Aslında olan şu, sistem belgeyi önce metne çevirir, sonra belirli kalıpları, başlıkları ve bağlamları kullanarak veriyi alanlara ayırır. Bazı gelişmiş çözümler makine öğrenmesi ve doğal dil işleme kullanır ama yine de kusursuz değildir.
Başlıca yöntemler şöyle çalışır:
Telefon numarası, e-posta adresi, tarih aralığı gibi yapılar belirli kalıplara uyar. Sistem bunları regex benzeri yöntemlerle yakalar. Örneğin 05xx ile başlayan numaralar, +90 ile yazılmış formatlar, ay-yıl kombinasyonları bu şekilde bulunabilir.
Bu noktada model, metindeki ifadelerin ne olduğunu tahmin eder. “Koç Üniversitesi” eğitim kurumu olabilir, “kıdemli yazılım mühendisi” unvan olabilir, “Docker” teknik beceri olabilir. Burada bağlam çok önemlidir. “Oracle” hem şirket adı olabilir hem veritabanı teknolojisi. Model bağlama göre karar vermeye çalışır.
CV’de “Deneyim”, “Eğitim”, “Yetenekler”, “Projeler” gibi başlıklar varsa iş kolaylaşır. Sistem hangi bilginin hangi bölümde olduğunu anlar. Karmaşık tasarımlı, iki sütunlu, ikon dolu, görsel ağırlıklı CV’ler bu yüzden sık hata verir. İnsan gözü için şık olabilir ama parsing motoru için dağınık bir yapıdır.
Gelişmiş ATS’ler aynı anlama gelen becerileri tek etikette toplar. “MS Excel”, “Microsoft Excel”, “ileri excel” ifadeleri aynı beceri kümesine bağlanabilir. Aynı durum unvanlar için de geçerlidir. “İnsan Kaynakları Uzmanı” ile “HR Specialist” eşleştirilebilir. Bu standardizasyon, arama kalitesini ciddi biçimde artırır.
Bunun suçu her zaman adayda değil. Sistemlerin de sınırları var. Yine de en sık sorun kaynakları belli:
Şunu net söyleyeyim, “ATS uyumlu CV” demek anahtar kelime doldurmak demek değildir. Bu yaklaşım hem itici görünür hem de recruiter gözünde güven kaybettirir. Doğru olan şey sade yapı, net başlıklar, ölçülebilir deneyim ve rol ile uyumlu becerileri açık biçimde yazmaktır.
ATS içindeki puanlama modelleri şirketten şirkete değişir. Bazı sistemlerde çok basit kural setleri vardır, bazıları daha gelişmiş ağırlıklandırma uygular. Temel mantık aynı, pozisyon için önemli görülen sinyallere puan verilir.
Örnek bir model şöyle olabilir:
Örneğin bir veri analisti rolünde adayın SQL ve Power BI bilgisi yüksekse ama sektör deneyimi zayıfsa toplam puanı yine iyi çıkabilir. Diyelim ki sistem şu alt puanları verdi:
Ağırlıklandırılmış toplam skor 83 olabilir. Güzel görünüyor, fakat tek başına yeterli değil. Çünkü puanlama modeli çoğu zaman bağlamı tam yakalayamaz. Adayın gerçek etkisi, ekip büyüklüğü, proje karmaşıklığı, terfi hızı veya motivasyonu bu skora tam yansımaz. Deneyimli recruiter bu yüzden puanı başlangıç noktası olarak kullanır, karar noktası olarak değil.
Yapay zeka destekli arama özellikleri artsa da iyi recruiter’ın elinde Boolean arama hâlâ çok güçlüdür. Çünkü veri tabanında neyi aradığınızı net tarif etmenizi sağlar. Özellikle eski aday havuzlarında tekrar tarama yaparken büyük fark yaratır.
Basit bir örnek:
(“veri analisti” OR “iş analisti”) AND SQL AND Python NOT stajyer
Bu sorgu, veri analisti veya iş analisti geçmişi olan, SQL ve Python geçen, ama stajyer profilleri dışarıda bırakan adayları getirir. Aynı mantık satış, finans, üretim veya İK rolleri için de uygulanır.
Etkili arama için recruiter’ların genelde şu operatörleri iyi bilmesi gerekir:
Burada sık yapılan hata şu, recruiter pozisyonu birebir tarif eden tek bir sorguya takılıp kalıyor. Oysa iyi arama iteratif yapılır. Önce geniş başlarsınız, sonuçları inceler, sonra daraltırsınız. ATS ne kadar iyi olursa olsun bu iş biraz zanaattır.
ATS tek başına yaşayan bir sistem değildir. Şirketin teknoloji yığını içindeki yerini doğru kurmak gerekir. Yoksa veri tekrar girilir, süreç uzar, hata artar. En yaygın entegrasyonlar şunlardır:
İdeal senaryo şudur, aday işe alındığında aynı veriler onboarding sürecine otomatik aksın. Teklif kabul edildiğinde sistem insan müdahalesi olmadan personel kaydını başlatsın, ekipman talebi açılsın, işe giriş evrak listesi oluşsun. Bunu kuran şirketler gerçekten hız kazanır. Kurmayanlar ise son aşamada yine manuel dosya taşır.
Bir ATS’nin değeri sadece operasyonel kolaylıkta değil, ölçüm gücündedir. İyi bir sistem size şu soruların cevabını verir: Hangi kanal daha kaliteli aday getiriyor? Hangi hiring manager süreci en çok uzatıyor? Hangi aşamada aday kaybı artıyor? Teklif kabul oranı kaç? Pozisyon kapanma süresi ne?
En çok takip edilen metrikler şunlardır:
Örneğin bir şirket 90 günde kapanan satış pozisyonlarını 55 güne indirdiyse, bunun hangi adımda gerçekleştiğini ATS verisiyle görebilir. Belki telefon ekranı süresi kısalmıştır, belki hiring manager geri dönüş SLA’i iyileşmiştir, belki de en iyi kaynak çalışan referansı çıkmıştır. Veri yoksa bunlar tahmindir. Veri varsa yönetim kararıdır.
ATS’nin göz ardı edilen ama çok önemli bir görevi de uyum yönetimidir. Özellikle kişisel verilerin saklanması, aday rızası, erişim yetkileri, ret gerekçelerinin tutarlılığı gibi başlıklar burada kritik hale gelir. Türkiye’de KVKK açısından aday verisini ne kadar süre tuttuğunuz, kimin eriştiği, hangi amaçla işlediğiniz açık olmalıdır.
Sağlıklı bir ATS kurulumunda şu kontroller bulunmalıdır:
Bu konu sadece hukuk için değil, işveren markası için de önemlidir. Adaylar verilerinin nasıl kullanıldığını önemsiyor. Özellikle nitelikli beyaz yaka adaylarda bu hassasiyet giderek artıyor.
Sistem satın almak kolay, doğru kullanmak zor. Yıllardır gördüğüm yaygın hatalar benzer:
ATS ne kadar güçlü olursa olsun süreç tasarımı kötüyse sonuç kötü olur. Kötü ilan metni, belirsiz değerlendirme kriteri ve geç geri dönüş sorununu yazılım tek başına çözmez. Ama iyi kurgulanmış süreci çok iyi hızlandırır.
Aday tarafında da gereksiz korkular var. “ATS beni eliyor” cümlesi kısmen doğru, kısmen abartı. Evet, bazı ön eleme soruları otomatik diskalifiye yaratabilir. Örneğin çalışma izni yoksa, zorunlu vardiyaya uygun değilse ya da belirli bir lisans şartı kritikse sistem sizi listeden düşürebilir. Ama çoğu durumda ATS sadece verinizi düzenler ve recruiter’a öncelik sinyali verir. Son kararı hâlâ insan verir.
Aday için en faydalı pratikler şunlar:
Bu kadar. Mesele sistemi kandırmak değil, hem insanın hem yazılımın rahat okuyacağı net bir profil sunmak.
Aday takip sistemlerini sadece “CV tarayan yazılım” diye görmek büyük eksiklik olur. Gerçekte ATS, işe alımın uçtan uca işletim sistemi gibi çalışır. İlanı açar, başvuruyu toplar, veriyi işler, arama yapılmasını sağlar, mülakat sürecini kaydeder, rapor üretir ve uyum tarafını güvenceye alır.
İyi kullanıldığında recruiter’ın hızını artırır, hiring manager’ı disipline eder, aday deneyimini düzeltir ve işe alım kararlarını veriye dayalı hale getirir. Kötü kurulduğunda ise sadece pahalı bir arşiv programına döner. Farkı yazılımın kendisi değil, süreç tasarımı ve kullanım olgunluğu yaratır.
Kısacası ATS’nin çalışma mantığını anlamak artık sadece İK ekipleri için değil, adaylar için de avantaj. Çünkü sistemin nasıl düşündüğünü bilirseniz daha iyi ilan yazarsınız, daha doğru arama yaparsınız, daha sağlıklı kısa liste çıkarırsınız ve daha okunur başvuru hazırlarsınız. İşe alım hızlandıkça bu bilgi lüks olmaktan çıktı, temel yetkinlik haline geldi.
Paylaş:
No comments yet. Be the first to share your thoughts!
25 dk. okuma
17 dk. okuma
17 dk. okuma