İK ekipleri için işe alım aşamalarını, mülakatları, geri bildirimleri, izinleri, entegrasyonları ve raporlamayı yönetmek üzere bir web uygulaması nasıl planlanır, tasarlanır ve inşa edilir öğrenin.
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.
Mevcut sürtüşmeyi kısa bir problem ifadesiyle yazın:
Ş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” 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:
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”).
Günlük işe bağlı 3–5 metrik seçin, örneğin:
Bu hedefler daha sonra izinler, planlama ve analiz gibi seçimlere rehberlik eder (bkz. /blog/create-reporting-and-analytics-hr-will-trust).
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.
Ç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.
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:
Bu, raporlamayı tutarlı tutarken gerçek iş akışlarına uyum sağlar.
Her aşama için belgelendirin:
Adayların takıldığı yerlere dikkat edin—genellikle “screening → scheduling” ve “interviews → decision” arasında olur. Burası ileride otomasyon için öncelikli noktalardır.
Uygulamanın kimin dürtmesi gerektiği anları listeleyin:
Hatırlatmaları aşama sahipliğine bağlayın ki hiçbir şey hafızaya ya da posta kutusu arşivine kalmasın.
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).
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:
Bir özellik adayları aşamalar arasında ilerletmiyorsa veya koordinasyon yükünü azaltmıyorsa muhtemelen MVP değildir.
“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.
İK ekipleri nadiren aynı şekilde çalışır. İlk günden yöneticilerin yapılandırabileceği öğeleri belirleyin:
Yapılandırmaları sınırlı tutun ki kullanıcı arayüzü basit ve desteklenebilir kalsın.
Kısa bir kullanıcı hikayesi seti yazın:
Bu hikayeler v1 için kabul kriterleriniz ve v2/v3 için temiz bir yol haritası olur.
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.
Küçük bir “gerçeğin kaynağı” tablo/kolleksiyon seti planlayın:
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.
Adaylar genellikle birden fazla ilana başvurur ve işler birçok adaya sahiptir. Şunu kullanın:
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.
Ö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ı:
Bu yapı arama ve raporlama yapmayı kolaylaştırır.
Erken bir AuditEvent tablosu ekleyin: aşama, teklif ve değerlendirme değişikliklerini kaydedin:
Bu, hesap verebilirlik, hata ayıklama ve “Bu aday neden Rejected oldu?” gibi sorulara güven verir.
İ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.
İşe alım kararlarının gerçekte nasıl alındığına uyan küçük bir rol setiyle başlayın:
Rolleri tutarlı tutun; onlarca özel rol yaratmak yerine “override”larla ince ayar yapın.
Tüm aday verileri herkes tarafından görülmemeli. İzin kurallarını sayfa bazlı değil, kategori/alan bazlı tanımlayın:
Pratik bir düzen: çoğu kullanıcı aday profilini görebilir, ama sadece belirli roller hassas alanları görebilir veya düzenleyebilir.
İşe alım genelde segmentlidir. Erişimi şu şekilde sınırlamak için “scope” ekleyin:
Bu, bir bölgede çalışan recruiter'ın başka bir bölgedeki adaylara erişmesini engeller.
Paydaşlar profilleri hızlı incelemek isteyeceklerdir. Kontrollü paylaşım sağlayın:
Bu, aday profillerinin e-posta zincirlerine kopyalanmasını engeller.
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.
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.
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 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.
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 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.
Çoğu ekip için birkaç şablonla başlayın ve sonra adminlerin özelleştirmesine izin verin:
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.
Pratik bir planlama akışı genelde şunları gerektirir:
Köşe durumları tasarlayın: son dakika mülakatçı değişimleri, bölünmüş paneller veya onaylanmazsa süresi dolan “hold” slotlar.
Entegre ediyorsanız iki şeye odaklanın: çakışma kontrolü ve etkinlik oluşturma.
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.
Tutarsız mülakatları azaltmak için her etkinlik için bir briefing paketi oluşturun. İçerik:
Paketi aday profili ve mülakat etkinliğinden bir tıkla erişilebilir yapı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.
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.
Mülakatçılar genellikle bir taslak alana ihtiyaç duyar. Destekleyin:
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.
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.
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.
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.
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.
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.
Yetenek, kıdem, diller, güvenlik yetkisi veya kaynak kanalı gibi esnek etiketler ekleyin. Bunu hızlı arama ve filtrelerle eşleştirin:
Hem tek bir işte hem de tüm roller arasında “10 saniyede bul” hedefleyin.
İ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.
İş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.
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:
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.
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:
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:
İyi uyumluluk tasarımı uygulamayı daha güvenilir ve denetimlerde savunması daha kolay yapar.
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.
Pipeline sağlığı ve hız etrafında inşa edin:
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.
İki seviye görünüm sağlayın:
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.
Çoğu raporlama anlaşmazlığı belirsiz tanımlardan gelir. Küçük bir “Tanımlar” çekmecesi veya araç ipucu ekleyin:
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”).
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 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.
Recruiter'ların zaten kullandığı sistemlerle başlayı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.
Daha sonra entegre edecekseniz bile şimdi tasarlayın:
İK ekiplerini sinirlendiren hatalara odaklanın:
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.
Start by naming 2–4 primary user groups (HR admins, recruiters, hiring managers, interviewers) and write one concrete pain per group.
Then draft a one-sentence problem statement you can test with stakeholders, like: “Hiring managers can’t see candidate status and interviews take too long to coordinate.”
Write down:
This prevents “mystery steps,” inconsistent stage names, and stalled candidates.
Create:
Keep stage names action-oriented (e.g., “Hiring Manager Interview” instead of “Interview”) so reporting stays consistent.
Pick 3–5 metrics tied to daily behavior, not vanity charts:
Use these metrics to guide later decisions about permissions, scheduling, and analytics.
A practical MVP supports a full hiring loop without spreadsheets:
Defer advanced automation and AI features until the core loop is reliable.
Model Candidate and Job as separate entities, and use Application as the workflow anchor.
This handles the many-to-many reality (one candidate can apply to multiple jobs) while keeping job-specific stage history, interviews, and decisions tied to the right application.
Start with a small, consistent role set:
Add field-level protections for sensitive data (compensation, private notes, EEO/diversity data) and support access scopes by department/job/location to avoid overexposure.
Use a guided flow:
Integrate Google/Microsoft calendars for conflict checks and event creation, but keep a manual fallback for teams without integrations.
Use short, role- and interview-type-specific scorecards with clear criteria and a simple rating scale.
Separate:
Add reminders and escalation when feedback is overdue, and consider hiding others’ ratings until submission to reduce anchoring bias.
Make every metric clickable down to the underlying candidate list and publish definitions for key calculations (stage entry rules, handling withdrawn/rejected, on-hold timing).
Support practical exports (CSV/PDF) and saved report templates so stakeholders can reuse consistent views. For more detail on analytics design, see /blog/create-reporting-and-analytics-hr-will-trust.
