İK İçin İşe Alım Pipeline’ı ve Mülakat Web Uygulaması Nasıl Oluşturulur

Hedefleri ve hedef kullanıcıları tanımlayın

Ekran tasarlamadan veya teknoloji yığını seçmeden önce kimin için yaptığınızı ve hangi ağrıyı giderdiğinizi netleştirin. İK ekipleri, işe alım uzmanları, işe alım yöneticileri ve mülakatçılar aynı işe alım sürecini çok farklı deneyimlerler—ve “tek beden herkese uyar” bir uygulama çoğu zaman kimseyi memnun etmez.

Sorunu (düz ifadeyle) tanımlayın

Mevcut sürtüşmeyi kısa bir problem ifadesiyle yazın:

• İş nerede tıkanıyor (teslimler, onaylar, eksik geri bildirim)?
• Hangi hatalar oluyor (çift aday kayıtları, kaybolmuş notlar, yanlış aşama)?
• Neler maliyetli (yavaş planlama, tutarsız kararlar, kötü görünürlük)?

Şuna benzer somut bir hedefleyin: “İşe alım yöneticileri adayların nerede olduğunu göremiyor ve görüşmeleri koordine etmek çok uzun sürüyor.”

“Pipeline” ve “mülakat yönetimi” ekipleriniz için ne anlama geliyor netleştirin

“Pipeline” basit bir aşama listesi (Applied → Screen → Onsite → Offer) olabilir veya role ya da lokasyona göre değişen daha detaylı bir iş akışı anlamına gelebilir. Benzer şekilde “mülakat yönetimi” sadece planlamayı içerebilir ya da kim mülakat yapacak, neler kapsanacak, geri bildirim toplama ve nihai kararları da kapsayabilir.

Birkaç gerçek örnekle tanımları yakalayın:

• 2–3 iş ailesi için tipik aşamalar
• Adayları kimlerin aşamalar arasında taşıdığı
• Bir mülakatı neyin tetiklediği (ve “hazır” ne demek olduğu)

İnşa etme mi yoksa satın alma mı karar verin—and ayırıcı özellik

Konfigüre edebileceğiniz bir aday takip sistemiyle karşılaştırın. Özel bir iş akışına, daha sıkı entegrasyonlara veya belli bir şirket boyutu için daha basit bir deneyime ihtiyacınız varsa genelde inşa etmek haklı bir tercihtir.

Eğer inşa ediyorsanız, uygulamanızı anlamlı kılan şeyi yazın (örneğin: “daha az planlama döngüsü” veya “yönetici-odaklı görünürlük”).

Gerçekten takip edeceğiniz başarı metriklerini belirleyin

Günlük işe bağlı 3–5 metrik seçin, örneğin:

• İşe alma süresi ve aşamadaki süre
• Planlama için yapılan mesajlaşma sayısı
• 24 saat içinde tamamlanan mülakat geri bildirim oranı
• Kilit aşamalar arasındaki bırakılma oranı
• Paydaş memnuniyeti (aylık kısa anket)

Bu hedefler daha sonra izinler, planlama ve analiz gibi seçimlere rehberlik eder (bkz. /blog/create-reporting-and-analytics-hr-will-trust).

İşe alım iş akışını ve pipeline aşamalarını haritalayın

Ekran tasarlamadan veya özellik seçmeden önce işe alımın organizasyonunuzda gerçekten nasıl ilerlediğini netleştirin. İyi haritalanmış bir iş akışı “gizemli adımları”, tutarsız aşama adlarını ve tıkanmış adayları önler.

Uçtan uca akışla başlayın

Çoğu ekip şu çekirdek yolu izler: sourcing → screening → interviews → offer. Bu akışı yazın ve her adım için “tamamlandı”nın ne anlama geldiğini tanımlayın (örneğin, “Screening complete” bir telefon taramasının kaydedildiği ve geçme/kalma kararının kaydedildiği anlamına gelebilir).

Aşama adlarını eylem odaklı ve özgül tutun. “Interview” belirsizdir; “Hiring Manager Interview” ve “Panel Interview” daha net ve raporlama için daha uygundur.

Ortak varyasyonları yakalayın (kaosa yol açmadan)

Farklı bölümler farklı adımlar gerektirebilir. Satışta rol oyunu olabilir; mühendislikte ev ödevi; yönetimde ek onaylar gerekebilir.

Tek büyük bir pipeline yerine şunları haritalayın:

• Çoğu rol için kullanılan varsayılan pipeline şablonu
• Birkaç onaylı varyant (örneğin: Engineering, Leadership, High-Volume)

Bu, raporlamayı tutarlı tutarken gerçek iş akışlarına uyum sağlar.

Teslimler, darboğazlar ve sahipliği belirleyin

Her aşama için belgelendirin:

• Sahip: sırada kimin hareket etmesi gerektiği (recruiter, coordinator, hiring manager, interviewer)
• Girdiler: ilerlemek için neye ihtiyaç duydukları (özgeçmiş, notlar, uygunluk, görev sonuçları)
• Çıkış kriterleri: ileri gitmek için neyin kaydedilmesi gerektiği

Adayların takıldığı yerlere dikkat edin—genellikle “screening → scheduling” ve “interviews → decision” arasında olur. Burası ileride otomasyon için öncelikli noktalardır.

Her adım için bildirimler ve hatırlatmalar tanımlayın

Uygulamanın kimin dürtmesi gerektiği anları listeleyin:

• Yeni aday bir recruıter'a atandığında
• Mülakat geri bildirimi 24–48 saat içinde geciktiğinde
• Teklif onayı belirli bir paydaşta beklediğinde

Hatırlatmaları aşama sahipliğine bağlayın ki hiçbir şey hafızaya ya da posta kutusu arşivine kalmasın.

MVP özellikleri ve aşamalı yol haritası belirleyin

Bir İK web uygulaması hızla tam bir aday takip sistemine dönüşebilir. Hızlıca işe yarar bir şey göndermenin en iyi yolu sıkı bir MVP üzerinde anlaşmak ve sonra neyin geleceğini planlamaktır (paydaşların ne bekleyeceğini bilmeleri için).

Tam bir işe alım döngüsünü destekleyecek MVP kapsamı seçin

MVP'niz bir ekibin gerçek bir adayı “applied”ten “hired”e kadar elektronik tablolar olmadan taşımasını sağlamalıdır. Pratik bir temel şunları içerir:

• Aday profili: iletişim bilgileri, özgeçmiş/ekler, başvurulan rol, notlar, etiketler
• Pipeline board: aşamalar, sürükle-bırak hareketi, temel filtreler, etkinlik zaman çizelgesi
• Mülakat planlama: zaman önerme, katılımcıları onaylama, takvim davetleri
• Geri bildirim: puan kartları, yorumlar, karar (ilerlet/reddet), görünürlük kuralları

Bir özellik adayları aşamalar arasında ilerletmiyorsa veya koordinasyon yükünü azaltmıyorsa muhtemelen MVP değildir.

Etki vs. çaba (ve risk) ile önceliklendirin

“aday verimliliği/zaman tasarrufu” ekseninde ve “yapım zorluğu” diğer eksende basit bir matris oluşturun. V1 için olmazsa olmaz kabul edin: güvenilir pipeline durumu, gerçekten işe yarayan planlama ve kolay gönderilen geri bildirim.

Güzel olur öğelerini (otomasyon kuralları, gelişmiş analiz, AI özetleri) sonraya bırakın—özellikle uyum veya veri riski getirenleri.

Nelerin yapılandırılabilir olacağına karar verin

İK ekipleri nadiren aynı şekilde çalışır. İlk günden yöneticilerin yapılandırabileceği öğeleri belirleyin:

• Pipeline aşamaları (isimler, sıra, isteğe bağlı aşama düzeyi gereksinimleri)
• Puan kartları (kriterler, derecelendirme ölçeği, zorunlu alanlar)
• E-posta şablonları (ret, sonraki adımlar, mülakat onayı)

Yapılandırmaları sınırlı tutun ki kullanıcı arayüzü basit ve desteklenebilir kalsın.

Role göre ana kullanıcı hikayelerini belgeleyin

Kısa bir kullanıcı hikayesi seti yazın:

• İK yöneticileri (roller, aşamalar, şablonlar, uyum ayarları oluşturur)
• Recruiter'lar (aday ekler, aşamayı taşır, mülakat planlar, adaylarla mesajlaşır)
• Mülakatçılar (atanmış mülakatları görür, hızlıca puan kartı gönderir)
• İşe alım yöneticileri (pipeline'ı inceler, finalistleri karşılaştırır, kararları onaylar)

Bu hikayeler v1 için kabul kriterleriniz ve v2/v3 için temiz bir yol haritası olur.

Veri modelini ve ilişkileri tasarlayın

Bir işe alım uygulaması veri modeline bağlı kalır. İlişkiler netse, yeni aşamalar, planlama ve raporlama eklerken her şeyi yeniden yazmak zorunda kalmazsınız.

Başlangıç için temel varlıklar

Küçük bir “gerçeğin kaynağı” tablo/kolleksiyon seti planlayın:

• Candidate: kişi düzeyinde profil (isim, e-posta, telefon, lokasyon, bağlantılar)
• Job: işe alınan rol (başlık, departman, hiring manager, durum)
• Application: Candidate ile Job arasındaki ilişki (buna aşağıda daha detaylı bakılacak)
• Stage: pipeline adımları (örneğin: Applied, Screen, Onsite, Offer) genellikle iş başına tanımlanır
• Interview: bir uygulamaya bağlı planlanmış etkinlik (zaman, mülakatçılar, tür)
• Feedback: bir mülakat veya başvuruya bağlı değerlendirme kayıtları
• User: recruiter'lar, mülakatçılar, adminler

Pratikte Application çoğu iş akışı verisi için ana kayıt olur: aşama değişiklikleri, mülakatlar, kararlar ve teklifler burada bağlanır.

Çoklu ilişki gerçeğini modelleyin

Adaylar genellikle birden fazla ilana başvurur ve işler birçok adaya sahiptir. Şunu kullanın:

• Candidate (1) → Application (çok)
• Job (1) → Application (çok)

Bu aday verisini çoğaltmaktan kaçınır ve iş-özgü durum, ücret beklentisi ve karar geçmişini uygulama bazında takip etmenizi sağlar.

Dosyalar, notlar ve iletişim geçmişi

Özgeçmiş ve ekler için meta veriyi veritabanında saklayın (dosya adı, tür, boyut, uploaded_by, zaman damgaları) ve ikili dosyaları obje depolamada tutun.

Notlar ve mesajlar birinci sınıf kayıtlar olmalı:

• Note (application_id, author_id, body, visibility)
• Communication (application_id, channel, direction, subject, body/summary, sent_at)

Bu yapı arama ve raporlama yapmayı kolaylaştırır.

İleride işinize yarayacak audit kayıtları

Erken bir AuditEvent tablosu ekleyin: aşama, teklif ve değerlendirme değişikliklerini kaydedin:

• kim değiştirdi (user_id)
• ne değişti (varlık + alan)
• önce/sonra değerler
• ne zaman oldu

Bu, hesap verebilirlik, hata ayıklama ve “Bu aday neden Rejected oldu?” gibi sorulara güven verir.

Roller, izinler ve erişim kurallarını ayarlayın

İzinler İK uygulamalarının güvenini kazanmasını sağlar ya da kaybettirir. Net bir erişim modeli yanlış paylaşımı (örneğin ücret detayları) önler ve iş birliğini kolaylaştırır.

Temel rolleri tanımlayın

İşe alım kararlarının gerçekte nasıl alındığına uyan küçük bir rol setiyle başlayın:

• HR admin: organizasyon ayarlarını, şablonları, veri saklama ve genel izinleri yönetir
• Recruiter: işler üzerinde sahiplik, adayları aşama atar, adaylarla iletişim kurar
• Hiring manager: kendi rolleri için adayları inceler, mülakat ister, karar verir
• Interviewer: yalnızca mülakat için gerekli olanı görür ve geri bildirim verir
• Viewer: paydaşlar için salt okunur erişim (örneğin: finans partneri veya exec sponsor)

Rolleri tutarlı tutun; onlarca özel rol yaratmak yerine “override”larla ince ayar yapın.

Hassas alanları alan düzeyinde koruyun

Tüm aday verileri herkes tarafından görülmemeli. İzin kurallarını sayfa bazlı değil, kategori/alan bazlı tanımlayın:

• Ücret: mevcut maaş, beklentiler, teklif detayları
• Özel notlar: recruiter notları, referans kontrolleri, iç endişeler
• Çeşitlilik/EEO alanları: ayrı saklayın ve erişimi kısıtlayın

Pratik bir düzen: çoğu kullanıcı aday profilini görebilir, ama sadece belirli roller hassas alanları görebilir veya düzenleyebilir.

Takım düzeyinde erişimi destekleyin (departman, iş, lokasyon)

İşe alım genelde segmentlidir. Erişimi şu şekilde sınırlamak için “scope” ekleyin:

• Departman/ekip (örneğin: Satış vs. Mühendislik)
• İş/ilan (sadece o işe atanmış roller)
• Lokasyon/varlık (çok ülkelik organizasyonlar için önemli)

Bu, bir bölgede çalışan recruiter'ın başka bir bölgedeki adaylara erişmesini engeller.

PDF ile iletmeye gerek bırakmayacak güvenli dahili paylaşım

Paydaşlar profilleri hızlı incelemek isteyeceklerdir. Kontrollü paylaşım sağlayın:

• İç kullanıcıları bir role ile ilana davet edin (viewer/interviewer/manager)
• Giriş gerektiren ve iptal edilebilen salt okunur linkler paylaşın
• Kim görüntüledi/indirdi/yorum yaptı gibi etkinlikleri kaydedin

Bu, aday profillerinin e-posta zincirlerine kopyalanmasını engeller.

Pipeline ve aday görünümleri için UX oluşturun

Bir işe alım uygulaması, yoğun recruiter'ların durumu bir bakışta anlayıp bir sonraki eylemi düşünmeden yapabilmesine bağlıdır. Küçük, tutarlı ekran setleri, öngörülebilir kontroller ve “sonraki adım ne” ipuçları hedefleyin.

Önce tasarlamanız gereken ana ekranlar

Pipeline board (Kanban tarzı): her işin aşamalarını sütunlarda aday kartlarıyla gösterin. Kartlar bir sonraki kararı vermek için gerekenleri göstermeli: isim, mevcut aşama, son etkinlik tarihi, sahip ve 1–2 ana etiket (örneğin: “Needs schedule”, “Strong referral”). Panoyu odaklı tutun—detaylar profil sayfasında olsun.

Aday profili: bu kişi kim, süreçte nerede ve şimdi ne yapmamız gerekiyor sorularına cevap veren tek sayfa. Temiz bir düzen: özet başlık, aşama zaman çizgisi, notlar/etkinlik akışı, dosyalar (özgeçmiş) ve bir “Interviews” bloğu.

İş sayfası: iş detayları, işe alma ekibi, aşama tanımları ve huninin genel sayıları. Aynı zamanda adminlerin aşama isimlerini ve zorunlu geri bildirimi ayarladığı yer.

Mülakat takvimi: mülakatçılar ve recruiter'lar için takvim görünümü; uygunluk, mülakat türü ve video/alan bilgilerine hızlı erişim.

Birincil eylemleri belirgin yapın

Her ekran en önemli 3–5 eylemi vurgulamalı: aşamayı taşı, mülakat planla, geri bildirim iste, mesaj gönder, sahip atama. Her görünümde tek bir birincil buton ve tutarlı yerleşim kullanın (örneğin: sağ üst). Reddedilme/çekilme gibi yıkıcı işlemleri onaylatın.

Toplu işlemler hata olmadan

Toplu reject, tag, veya assign owner yüksek hacimli roller için şarttır. Seçim sayacı, “Geri al” bildirimleri ve “23 adayı reddet” onayları ile hata riskini azaltın; isteğe bağlı sebep şablonları ekleyin.

Erişilebilirlik temelleri

Pipeline panosunda klavye navigasyonu, görünür odak durumları, yeterli kontrast ve okunabilir form etiketleri sunun. Hata mesajlarını spesifik yapın (“Interview time is required”) ve durumu sadece renkle göstermeye güvenmeyin.

Mülakat planlama ve koordinasyonu oluşturun

Mülakat planlama işe alım pipeline'larının yavaşladığı yerdir: çok fazla gidip gelme e-postası, kaçırılan saat dilimleri ve belirsiz sahiplik. Uygulamanız planlamayı rehberli bir iş akışı gibi hissettirmeli, aynı zamanda recruiterların gerektiğinde müdahale etmesine izin vermeli.

Yaygın mülakat türlerini destekleyin

Çoğu ekip için birkaç şablonla başlayın ve sonra adminlerin özelleştirmesine izin verin:

• Telefon taraması (kısa, recruiter liderliğinde)
• Teknik mülakat (kodlama görevi, canlı eşlik veya ev ödevi değerlendirmesi)
• Panel mülakat (birden çok mülakatçının aynı slotta olduğu)
• Case study / sunum (uzun slot ve materyaller)

Her tür varsayılan süre, gereken mülakatçı rolleri, lokasyon (video/yerinde) ve aday hazırlık materyal gerekip gerekmediğini tanımlamalıdır.

Koordinasyon yükünü azaltan planlama akışı

Pratik bir planlama akışı genelde şunları gerektirir:

1. Mülakatçılardan uygunluk topla (ve isteğe bağlı aday), saat dilimi farkına dikkat ederek.
2. Zaman öner çatışmalar, tamponlar ve çalışma saatlerine göre.
3. Onay gönder tüm katılımcılara tek bir gerçeklik kaynağı (mülakat etkinlik sayfası).
4. Yeniden planlamayı yönet bağlamı kaybetmeden: değişiklik geçmişi tutun ve herkesi bilgilendirin.

Köşe durumları tasarlayın: son dakika mülakatçı değişimleri, bölünmüş paneller veya onaylanmazsa süresi dolan “hold” slotlar.

Takvim entegrasyonları (ve manuel yedek)

Entegre ediyorsanız iki şeye odaklanın: çakışma kontrolü ve etkinlik oluşturma.

• Google Calendar ve Microsoft 365 genelde ilk hedeflerdir.
• İki yönlü senkron mi yoksa tek yönlü “sadece etkinlik oluştur” mu gerektiğini erkenden sorun. İki yön daha karmaşıktır ama sürüklenmeyi önler.

Her zaman manuel bir mod ekleyin: recruiter'lar dış bir toplantı linkini yapıştırabilir, etkinliği “scheduled” olarak işaretleyebilir ve entegrasyon olmasa bile katılımı takip edebilir.

Mülakatçılar için briefing paketleri

Tutarsız mülakatları azaltmak için her etkinlik için bir briefing paketi oluşturun. İçerik:

• Rol özeti ve “iyi”nin ne olduğu
• Aday CV/portfolyosu ve ilgili notlar
• Önerilen sorular (veya soru bankası bağlantısı)
• Pratik detaylar: zaman, format, katılımcılar ve görevler

Paketi aday profili ve mülakat etkinliğinden bir tıkla erişilebilir yapın.

Geri bildirim, puan kartları ve karar desteğini uygulayın

Geri bildirim, işe alım pipeline yönetim uygulamasının güven kazanmasını ya da sürtünce yaratmasını belirler. İK ekipleri yapılandırılmış değerlendirmelere ihtiyaç duyar: kolay doldurulabilir, mülakatçılar arasında tutarlı ve sonradan denetlenebilir olmalıdır.

“İyi”nin ne olduğunu standartlaştıran puan kartları oluşturun

Rol ve mülakat türüne göre puan kartları oluşturun (screen, technical, hiring manager, culture add). Her puan kartını kısa tutun, net kriterler ve derecelendirme ölçeği (örneğin 1–4: “kanıt yok / biraz / sağlam / olağanüstü”) ile. “Kanıt” alanı ekleyin ki mülakatçılar gözlemlediklerini yazsın, belirsiz yorumlar yerine.

Bir ATS için puan kartları aranabilir ve raporlanabilir olmalı ki temizlemeye gerek kalmadan İK analiz panosuna veri beslesin.

Özel notlar, paylaşılan geri bildirim ve nihai öneriyi ayırın

Mülakatçılar genellikle bir taslak alana ihtiyaç duyar. Destekleyin:

• Özel notlar (sadece yazara görünür)
• Paylaşılan geri bildirim (panel ve recruiter'lar görür)
• Öneri (hire / no hire / lean / daha fazla veri gerekli)

Bu, istemeden aşırı paylaşımı azaltır ve rol tabanlı erişim kontrolünü destekler: recruiter'lar her şeyi görebilirken çapraz fonksiyonel bir mülakatçı yalnızca ilgili olanı görebilir.

Gecikmiş geri bildirim: hatırlatmalar ve yükseltme kuralları

Geciken puan kartları kararları ve planlamayı geciktirir. Otomatik dürtmeler ekleyin: mülakat sonrası hatırlatma, karar toplantısı öncesi yeniden hatırlatma ve hâlâ eksikse hiring manager'a yükseltme. Son tarihleri aşama bazında yapılandırılabilir yapın.

Karar desteği—önyargıyı artırmadan

Average puanlar, kriterlere göre ortalamalar, güçlü/zayıf yön temaları ve “eksik geri bildirim” uyarılarını özetleyen bir karar görünümü oluşturun. Ankraj önyargını azaltmak için diğerlerinin puanlarını sizin göndermeden gizlemeyi düşünün ve puanlarla birlikte kanıt parçacıkları gösterin.

İyi tasarlanmış bir modül, kararlar için tek gerçeklik kaynağı olur ve sohbet/e-posta trafiğini azaltır.

İletişim, arama ve üretkenlik araçları ekleyin

Mükemmel bir pipeline'a sahip bir uygulama bile recruiter'lar hızlı iletişim kuramıyorsa, doğru adayı bulamıyorsa veya neler olduğunu kaydedemiyorsa yavaş hissedilir. Bu “küçük” araçlar ekiplerin sistemi benimsemesini sağlar.

E-posta şablonları + iletişim geçmişi

Günlük tekrar eden anlar için birkaç düzenlenebilir e-posta şablonu ile başlayın: başvuru onayı, mülakat daveti, takip, uygunluk talebi, ret. Şablonlar rol/ekip bazında düzenlenebilmeli ve hızlı kişiselleştirme alanları (isim, rol, lokasyon) olmalı.

Aynı zamanda her mesajı kaydedin. Aday profiline açık bir gönderilen/alınan zaman çizelgesi ekleyin ki “Onlarla iletişime geçildi mi?” sorusu posta kutularında arama gerektirmesin. Ekleri ve meta verileri (gönderen, zaman, ilgili iş) dahil edin.

Tutarlı (ve insancıl) durum güncellemeleri

Aday durum güncellemelerini kolay ama standartlaştırılmış yapın. Red sebepleri için kontrol listesi sunun (örneğin: “maaş uyumsuzluğu”, “yetenek açığı”, “müsait değil”, “çekildi”) ve isteğe bağlı not alanı verin.

Bu raporlama için faydalıdır ve ekip içindeki dil farklılıklarını azaltır. Dahili-only alanları dış paylaşılacak alanlardan ayırın—ret sebepleri genelde sadece analiz içindir.

Recruiter'ların güvendiği etiketleme, arama ve filtreler

Yetenek, kıdem, diller, güvenlik yetkisi veya kaynak kanalı gibi esnek etiketler ekleyin. Bunu hızlı arama ve filtrelerle eşleştirin:

• Aşama (örneğin: Phone Screen, Onsite)
• Sahip / recruiter
• Lokasyon / uzaktan çalışma uygunluğu
• Yetenekler / etiketler
• Tarih aralıkları (başvuru, son iletişim)

Hem tek bir işte hem de tüm roller arasında “10 saniyede bul” hedefleyin.

Pratik içe/içe dışa aktarma (CSV)

İK ekipleri hala e-tablolarda yaşıyor. Geri doldurma için CSV içe aktarma ve denetimler, ayrıca denetimler veya kısa listeler için CSV dışa aktarma sağlayın. Alan eşleme, doğrulama (çoğaltmalar, eksik e-postalar) ve izinlere saygı gösteren dışa aktarma ekleyin.

Bunlar daha sonra toplu işlemler (toplu e-posta, toplu aşama taşıma) ve günlük operasyonlar için temel olur.

Gizlilik, güvenlik ve uyumluluğu planlayın

İşe alım uygulamaları kimlik bilgileri, özgeçmişler, mülakat notları ve bazen eşitlik veya sağlık bilgileri gibi en hassas verileri tutar. Gizlilik ve güvenliği temel ürün gereksinimi olarak ele alın—lansmanda bir onay kutusu gibi değil.

Uyumluluk kapsamınızı erkenden tanımlayın

Hangi düzenlemelerin uygulandığını ve daha sonra neyi kanıtlamanız gerektiğini belgeleyin. Birçok ekip için bu GDPR / UK GDPR ve yerel iş yasalarını içerir.

Açıkça belirtin:

• İşleme için hukuki dayanak (örneğin: meşru menfaat vs. rıza) ve ne zaman açık rıza gerektiği
• Saklama süreleri (örneğin: X ay sonra sil veya anonimleştir, aday yetenek havuzuna katılmayı kabul etmediyse)
• Verinin nerede saklandığı ve aktarıldığı (örneğin: EU/UK barındırma, alt yükleniciler, yedekler)

Daha az toplayın ve hassas verileri izole edin

Varsayılan olarak toplanan alanları azaltın. Bir bilgi adayı değerlendirmek için gerekmiyorsa sormayın.

Hassas veri gerektiğinde (çeşitlilik takibi, uyum ihtiyaçları gibi) bunu ana işe alım kaydından ayrı tutun ve erişimi sıkı kısıtlayın. Bu istemeden maruziyeti azaltır.

Güvenli depolama, şifreleme ve güvenli indirmeler

En azından veriyi taşınırken (TLS) ve dinlenirken şifreleyin. Ekler (CV, portfolyo, kimlik dokümanları) için özel bir bucket kullanın, kısa ömürlü imzalı URL'ler verin ve herkese açık erişimi engelleyin.

İndirmeleri ve paylaşımı kontrol edin:

• Gerekliyse dışa aktarılan dosyaları watermark/etiketleyin
• “Linke sahip olan herkes” erişimini engelleyin; kimlik doğrulama isteyin
• Bazı roller için indirmeyi engellemeyi, yalnızca önizleme izni vermeyi düşünün

Denetlenebilirlik: loglar ve kullanıcı talepleri

Kimin aday profillerini ve dosyalarını görüntülediğini/aktardığını zaman damgası ile kaydeden bir erişim günlüğü oluşturun. İK ekipleri bunu soruşturma ve denetimler için sıklıkla isteyecektir.

Ayrıca veri sahipliği talepleri için operasyonel akış planlayın:

• Aday verisini dışa aktar okunabilir formatta
• Sil/anonimleştir kayıtlar, ekler ve mümkünse yedeklerde
• Talepleri basit bir iç ticket akışıyla izleyin ve SLA'lar belirleyin

İyi uyumluluk tasarımı uygulamayı daha güvenilir ve denetimlerde savunması daha kolay yapar.

İK'nın güveneceği raporlama ve analiz oluşturun

Raporlama ya güven kazandırır ya da sürekli “bunu kontrol et” mesajlarına yol açar. Doğrulanması kolay, zaman içinde tutarlı ve her sayının ne anlama geldiği konusunda açık analitikler hedefleyin.

İK'nın gerçekten kullandığı metriklerle başlayın

Pipeline sağlığı ve hız etrafında inşa edin:

• Aşama dönüşüm oranları (örneğin: Applied → Screen → Interview → Offer → Hired)
• Aşamadaki süre (medyan ve %75 gibi istatistikler ortalamalardan daha doğru olabilir)
• İşe alma süresi (requisition açılış tarihinden veya ilk aşama girişinden hesaplayın—birini seçin ve tutarlı olun)

Bunları iş bazında gösterin; her rolün gerçekleri farklıdır. Yüksek hacimli bir destek rolü ile kıdemli bir mühendislik rolü aynı kıstasa zorlanmamalıdır.

İş başına panolar + liderlik özetleri

İki seviye görünüm sağlayın:

• İş başına pano: hunıe dönüşüm grafiği, aşama yaşlanma listesi, yaklaşan mülakatlar ve “sıkışmış adaylar” uyarısı
• Ekip/departman özeti: açık toplam roller, bu çeyrekte yapılan işe alımlar, darboğaz aşamaları ve iş yükü göstergeleri (recruiter başına aday)

Filtreleri basit ve öngörülebilir tutun (tarih aralığı, iş, departman, lokasyon, kaynak). Bir filtre bir sayıyı değiştirdiyse bunu açıkça gösterin.

Yanıltıcı grafiklerden kaçınmak için tanımları açık yapın

Çoğu raporlama anlaşmazlığı belirsiz tanımlardan gelir. Küçük bir “Tanımlar” çekmecesi veya araç ipucu ekleyin:

• Bir aşama girişi ne olarak sayılır (ilk sefer mi yoksa her yeniden giriş mi)
• Çekilen ve reddedilen adaylar nasıl ele alınıyor
• “On hold” seçildiğinde aşamadaki süre duruyor mu

Mümkünse HR'ın bir metriğin altındaki aday listesini tıklayarak görmesini sağlayın (“14 günden fazla Onsite olan 12 adayı göster”).

Paydaşlar ve çeyreklik incelemeler için dışa aktarma

Stakeholder iş akışlarına uygun dışa aktarmalar ekleyin: CSV (e-tablolar için), PDF anlık görüntüler (güncellemeler için) ve zamanlanmış e-posta raporları. Dışa aktarma başlığında filtreleri ve tanımları dahil edin, böylece sayıların bağlamı paylaşılırken kaybolmaz.

Kılavuz bir görünüm isterseniz, kayıtlı rapor şablonları olan bir /reports sayfası ekleyin (örneğin: “Quarterly Hiring Review”, “Diversity Funnel (if enabled)”) ki İK tekrar oluşturmak zorunda kalmasın.

Entegrasyonlar, test ve lansman kontrol listesi

Entegrasyonlar ve dağıtım kararları benimsemeyi belirler. Bunları ürün özellikleri gibi ele alın: net kapsam, güvenilir davranış ve sürekli destek için sahiplik.

Günlük sürtüşmeyi azaltan entegrasyonları seçin

Recruiter'ların zaten kullandığı sistemlerle başlayın:

• E-posta (Gmail/Outlook): şablonlu mesajlar gönderin, yanıtları kaydedin ve tam bir denetim izi tutun
• Takvimler (Google/Microsoft): mülakatlar için iki yönlü senkron, katılımcı güncellemeleri ve iptaller
• HRIS (örneğin: Workday, BambooHR): çalışanları/ekipleri içe aktarın, işe alınan adayları itin ve çift kayıtları önleyin
• Arka plan kontrolleri: belirli aşamada kontrolleri tetikleyin ve durum güncellemelerini yakalayın
• E-imza: teklif paketleri oluşturun, tamamlanmayı takip edin ve imzalı belgeleri saklayın

Her veri türü için “gerçeğin kaynağı”nı tanımlayın (aday profili, mülakat etkinlikleri, teklif belgeleri) ki çakışmalar olmasın.

API + webhooks: gelecekteki ortaklar için şimdi tasarlayın

Daha sonra entegre edecekseniz bile şimdi tasarlayın:

• Temel nesneler (candidates, jobs, stages, interviews, feedback) için stabil bir REST API
• Ana olaylar (candidate moved, interview scheduled, offer sent) için webhookler, retry ve imzalama ile
• Net hız sınırlamaları, versiyonlama ve destek için iç “entegrasyon logları” görünümü

Test planı: gerçek dünya kenar durumlarını yakalayın

İK ekiplerini sinirlendiren hatalara odaklanın:

• İzinler: rol tabanlı erişim kontrolü, aşama görünürlüğü, özel notlar
• Planlama: saat dilimleri, yeniden planlamalar, çifte rezervasyon, takvim daveti düzenlemeleri
• Veri migrasyonları: mevcut pipeline'ların içe aktarımı, adayları çoğaltma, zorunlu alan doğrulama

Dağıtım ve lansman kontrol listesi

• Staging + production ortamları, otomatik deploylar ve rollback yolları
• İzleme (hatalar, kuyruk sağlığı, webhook teslimi), yedekler ve geri yükleme tatbikatları
• Aşamalı lansman: pilot ekip → şirket geneli, eğitim ve geri bildirim kanalı ile
• Lansman hazırliği: onboarding kontrol listesi, varsayılan şablonlar ve destek/SLA planı

Pratik bir hızlı inşa seçeneği: Koder.ai ile daha hızlı göndermek

Amacınız iş akışını hızlıca doğrulamaksa (pipeline board, planlama, puan kartları ve izinler) ve büyük bir mühendislik yatırımına girmeden önce çalışır bir dahili uygulamaya ulaşmak istiyorsanız, vibe-coding tarzı bir platform olan Koder.ai size yardımcı olabilir. Sohbette işe alım iş akışınızı tanımlarsınız, ekranları iterasyonla geliştirirsiniz ve altında Go + PostgreSQL olan React tabanlı bir web uygulaması oluşturursunuz—hazır olduğunuzda kaynak kodunu içeri aktarabilirsiniz. Planning mode, snapshot ve rollback gibi özellikler, İK paydaşlarıyla erken MVP varsayımlarını test ederken hızlanmanızı sağlar ve kararlılığı korur.