Aşamaları, formları, adil puanlamayı ve işe alım kararlarını tek bir basit uygulamada eşleştiren bir mülakat puan kartı iş akışı nasıl kurulur öğrenin.
İşe alım geri bildirimi genellikle son karar verilmeden önce dağılır. Bir mülakatçı notları bir tabloda bırakır, başka biri e-postayla yanıt verir, bir başkası düşüncelerini sohbete atar. Ekip bir araya geldiğinde, tüm resim çok fazla yerde parçalanmıştır.
Bu basit bir soruna, pahalı sonuçlar ekler: artık herkes aynı bilgiye tepki vermiyor. Bir yönetici güçlü bir mülakatı hatırlar. Diğeri bir endişeyi hatırlar. İşe alımcı, ana kayda hiç geçmemiş yazılı geri bildirimi hâlâ bekler.
Gecikmiş geri bildirim her şeyi daha kötü yapar. Notlar bir-iki gün sonra gelirse ayrıntılar bulanıklaşır. Küçük işaretler olduğundan daha büyük görünmeye başlar ve güçlü adaylar ekip ne olduğunu tekrar birleştirmeye çalışırken gereğinden uzun bekletilir.
Tutarlılık başka bir zayıf nokta. Mülakatçılar aynı standardı kullandıklarını düşünseler bile genellikle farklı şeylere odaklanır. Biri iletişime önem verirken, diğeri teknik derinliğe, bir başkası ekip uyumuna bakar. Paylaşılan bir aday değerlendirme formu yoksa her mülakat kendi özel testi olur.
Bu da adayları adil karşılaştırmayı zorlaştırır. Katı bir değerlendiriciyle görüşen biri kağıt üzerinde daha zayıf görünebilir; daha cömert birisiyle görüşen biri daha güçlü görünebilir. Net bir mülakat puan kartı iş akışı olmadığında, puanlar ve yorumlar aday kalitesinden çok kişisel alışkanlıkları yansıtır.
Son sorun kolay kaçırılır: zayıf karar kayıtları. Ekip bir adayın neden ilerletildiğini, reddedildiğini veya beklemeye alındığını net açıklayamıyorsa, gelecekteki işe alımlar zorlaşır. İşe alımcılar kalıpları fark edemez, yöneticiler geçmiş seçimleri gözden geçiremez ve şirket kararların nasıl alındığına dair kullanışlı bir kaybı kaçırır.
Dağınık geri bildirim sadece can sıkıcı değildir. İşe alımı yavaşlatır, yargıyı bulandırır ve iyi kararları gereksiz yere zorlaştırır.
Kullanışlı bir süreç, kimse puan vermeden önce başlar. Ekip bir adayın işe alım akışında nerede olduğunu net değilse, geri bildirim yanlış adıma iliştirilir, değerlendirmeler atlanır ve nihai kararlar olması gerekenden daha karmaşık hissettirir.
Başlamak için adayın ilerleyebileceği her aşamayı adlandırın: başvurudan son karara kadar. Birçok ekip için bu, başvuru incelemesi, işe alımcı taraması, işe alım müdürü mülakatı, yetenek kontrolü, ekip mülakatı, referans kontrolü, teklif ve işe alım veya reddedilme anlamına gelir. İsimlerin tamı o kadar önemli değil; basit ve tutarlı olmaları önemlidir.
Her aşama için iki kural gerekir: aday ne zaman o aşamaya girer ve ayrılmadan önce ne olması gerekir. Örneğin, biri "İşe Alım Müdürü Mülakatı"na yalnızca işe alımcı taramasını geçtikten sonra girer. O aşamadan yalnızca mülakat formu gönderildiğinde ve bir sonraki adım seçildiğinde ayrılır.
Kısa durum isimleri taramayı kolaylaştırır. Aşağıdaki etiketler iyi çalışır:
Her adımın bir sahibi olmalı. Bir kişi adayı ilerletmekten, geri göndermekten veya aşamayı kapatmaktan sorumlu olmalı. Net sahiplik yoksa, herkesin bir başkasının hallettiğini varsayması yüzünden adaylar beklemede kalır.
Yan yolları unutmayın. "On Hold", "Rejected" ve "Reopened" durumlarının nereye ait olduğunu belirleyin. "On Hold" önceki geri bildirimi kaybetmeden adayı duraklatmalı. "Reopened" adayı belirsiz bir aktif havuza değil, belirli bir aşamaya geri göndermeli.
Bunu dahili bir araca dönüştürmeyi planlıyorsanız, önce bu aşama kurallarını haritalayın. AppMaster gibi no-code bir platformda bunlar uygulamanın omurgası olabilir; formlar, puanlama ve onayları yönetmek çok daha kolay olur.
İyi bir form, insanların hızlıca faydalı geri bildirim vermesine yardımcı olur. Kötü bir form belirsiz yorumlara, eksik puanlara ve uzun gecikmelere davetiye çıkarır. Çoğu durumda kısa formlar daha iyi veri üretir.
Role göre başlayın, genel bir şablonla değil. Destek pozisyonu yazılı iletişim, baskı altında sakinlik ve ürün yargısı isteyebilir. Bir backend rolü farklı şeyler ister. Bir soru, adayın işi yapıp yapamayacağını göstermiyorsa onu çıkarın.
Her öğeyi taraması kolay tutun. İnsanların hemen anlayacağı kısa etiketler kullanın: "Problem solving", "Customer empathy" veya "SQL basics" gibi. Her birinin altında mülakatçıların neyi puanladığını bilmesi için tek bir yönlendirici ekleyin.
Basit bir yapı genellikle yeterlidir:
Kanıt alanı birçok ekip için sandıklarından daha önemlidir. Mülakatçılardan bir veya iki belirli örnek isteyin; "zeki görünüyor" veya "iyi kültür uyumu" gibi geniş izlenimler yerine. "Kızgın bir müşteriyi nasıl ele aldığını ve net sonraki adımları nasıl sunduğunu açıkladı" ekibe çok daha fazla bilgi verir.
Bazı rollere birkaç zorunlu kontrol ekleyin, ancak bunları gerçekten vazgeçilmez olanlarla sınırlayın: çalışma izni, hafta sonu çalışabilme veya zorunlu bir sertifika gibi. Çok fazla geçme/kalma alanı puan kartını sadece kutu işaretleme egzersizine çevirir.
Zamanlama da kaliteyi etkiler. Geri bildirim iki gün sonra gelirse hafıza zayıflar ve önyargı artar. Her mülakatçının formu mülakatın hemen ardından, ideali aynı gün, göndermesini kural olarak belirleyin.
Puanlama ölçeği yalnızca mülakatçılar onu hızlı ve aynı şekilde kullandığında işe yarar. Bir tur 1–5, başka bir tur 1–10, bir başkası ise "strong hire" gibi etiketler kullanıyorsa karşılaştırmalar hızla karışır.
Tüm mülakat turları boyunca tek bir ölçek kullanın. Çoğu ekip için 4 veya 5 puan yeterlidir. Daha fazla seçenek daha hassas hissettirebilir, ama genellikle insanları tahminde bulunmaya iter.
Sayıdan çok, arkasındaki anlam önemlidir. Her puanın düz tanımını yazın ki mülakatçılar kendi yorumlarını yaratmak zorunda kalmasın.
Örneğin:
Basit ifadeler işe yarar. "Beklentileri karşılıyor" gibi net ifadeler belirsiz etiketlerden daha kullanışlıdır.
Bazen derinlemesine ele alınmamış konular olabilir; bu yüzden "yeterli kanıt yok" seçeneğini eklemek de faydalıdır. Mülakatta bir konu yeterince ele alınmadıysa zorlayarak bir sayı vermek yanlış kesinlik üretir ve değerlendirmeyi zayıflatır.
Ayrıca bazı kriterlerin diğerlerinden daha önemli olup olmayacağına erken karar verin. Bir destek pozisyonu için iletişim ve sorun çözme ürün bilgisinden daha fazla ağırlık taşıyabilir; ürün bilgisi sonradan öğretilebilir. Seçtiğiniz model ne olursa olsun, aynı rolde her aday için aynı kuralları kullanın.
Puan verirken herkes tereddüt ediyorsa ölçek fazla karmaşıktır. Puanlama adımı bariz, hızlı ve gözden geçirmesi kolay hissetmelidir.
Adil bir süreç, tek bir aşırı katı ya da aşırı cömert değerlendiricinin her şeyi belirlemesine izin vermemelidir. Çözüm basittir: her puanı aynı aralığa çevirin, aynı rol için aynı ağırlık kurallarını kullanın ve diğerlerinden çok uzak olan değerlendirmeleri işaretleyin.
Ortak 0–100 ölçeği iyi çalışır çünkü okunması kolaydır. 5 üzerinden 4, 80 olur. 5 üzerinden 3, 60 olur. Bir kez puanlar aynı formata çevrildiğinde karşılaştırmaları yapmak çok daha kolaydır.
Bundan sonra, rola göre ağırlıkları tutarlı kılın. Bir destek pozisyonunda iletişim ve sorun çözme ürün bilgisinden daha fazla ağırlık taşıyabilir. Önemli olan tutarlılıktır: aynı roldeki her aday aynı kurallarla değerlendirilmeli.
Kriterleri iki gruba ayırmak da yardımcı olur: must-haves (zorunluluklar) ve nice-to-haves (ekstra yetenekler). Zorunluluklar, adayın gerçekten eksik olmaması gereken şeylerdir; örneğin net iletişim veya vardiya uygunluğu. Nice-to-haves değer katar ama temel bir eksikliği gizlememelidir.
Aykırı puanlar otomatik veto yerine ikinci bir bakışı hak eder. Dört mülakatçı adayı 72–84 arasında puanlarken biri 35 verdiyse, ekip son kararı vermeden önce yorumları okumalıdır. Bazen düşük puan gerçek bir sorunu açığa çıkarır; bazen de sorunun farklı yorumlanmasından veya daha katı puanlama alışkanlığından kaynaklanır.
Paylaşılan kayıtta iki sayıyı yan yana gösterin: ortalama puan ve yayılma. Ortalama genel sonucu gösterir. Yayılma ise ne kadar anlaşma olduğunu gösterir.
Örneğin, adayın normalize edilmiş puanları 78, 80, 82 ve 52 olsun. Ortalama hâlâ kabul edilebilir olabilir, ama yayılma geniştir. Bu, nihai kararı vermeden önce kanıt notlarını okumak için bir işarettir.
Geri bildirim çok fazla yerde yaşadığında işe alım bozulur. Bir mülakatçı not bırakır, diğeri bir tabloyu günceller ve son karar sohbet içinde verilir. Tek bir aday kaydı karar takibini ilk görüşten nihai sonuca kadar net tutar.
Her adayın süreç boyunca takip edilen tek bir ortak kaydı olmalı. Bu kayıt mevcut aşamayı, gönderilmiş mülakat formlarını, toplam puanları, yazılı yorumları, takip notlarını ve nihai kararı içermelidir. Her şey bir arada olduğunda ekip güncellemelerin peşinden koşmadan tam resme bakabilir.
Çoğu ekip için birkaç temel alan yeterlidir:
Nihai karar alanı açık olmalı. Bunu sayfanın altına gömmeyin. Hire, Hold, Reject veya Needs another interview gibi bir durum kullanın. Bu raporlamayı kolaylaştırır ve birisi kaydı daha sonra kontrol ettiğinde karışıklığı engeller.
Ayrıca kararı kim onayladı ve ne zaman onayladığı kaydedilmeli. Bir yönetici bir adayı Hold'dan Hire'a değiştirirse, bu değişiklik görünür olmalı. Net bir zaman çizelgesi devri kolaylaştırır ve haftalar sonra sorular çıktığında güvenilir bir kayıt sağlar.
Sebebi kısa ama spesifik tutun. "Güçlü müşteri empatisi, sağlam yazma becerisi, sınırlı teknik derinlik" gibi ifade, "iyi aday"dan çok daha faydalıdır.
Küçük başlayın. Bir mülakat puan kartı iş akışı, onu devasa bir İK sistemi gibi değil, basit bir işe alım haritası gibi ele aldığınızda daha kolay kurulur.
Aday kaydıyla başlayın. Ekip her zaman ihtiyaç duyduğu alanları ekleyin: ad, rol, kaynak, işe alımcı, mevcut aşama, mülakat tarihleri, genel tavsiye ve nihai karar. Sonra Applied, Recruiter Screen, Hiring Manager Interview, Team Interview, Reference Check, Offer ve Rejected gibi net aşama durumları oluşturun.
Aşamalar sabitlendikten sonra her mülakat türü için ayrı bir form oluşturun. Bir işe alımcı taraması aynı soruları teknik mülakattan veya ekip uyumu sohbetinden sormamalı. Her form dört ila altı soruyla odaklı olmalı, kısa bir puanlama ölçeği ve bir not alanı içermelidir.
Pratik bir kurulum sırası şöyle olabilir:
Otomasyon birçok ekip için beklenenden daha önemlidir. Bir aday işe alım müdürü mülakatını bitirdiğinde, sistem bir sonraki mülakatçıyı bilgilendirebilir, doğru değerlendirme formunu oluşturabilir ve kaydı geri bildirim bekliyor olarak işaretleyebilir. Formlar 24 saat sonra hâlâ eksikse gecikme görünür olmalıdır.
Pano yalnızca üç soruyu cevaplamalı: Bu aday şu anda nerede? Puanlar ne söylüyor? Hâlâ ne eksik? Ekip bu soruları hızlıca yanıtlayabiliyorsa süreç çok daha iyi haldedir.
Bunu dahili olarak kuruyorsanız, AppMaster veri modelini, aşama mantığını, formları ve onay kurallarını tek bir yerde oluşturmak için bir seçenek sunar.
Bir aday, Maya'yı düşünün; müşteri destek rolüne başvuruyor. Kaydı beş aşamadan geçiyor: Applied, Recruiter Screen, Scenario Interview, Team Interview ve Offer Review. Süreç baştan daha takip edilebilir çünkü kimsenin onun nerede olduğunu veya hangi geri bildirimin eksik olduğunu tahmin etmesine gerek yok.
İşe alımcı ilk geçişi kaydeder: takvim uyumu, iletişim ve maaş aralığı. Maya ilerler. İşe alım müdürü gerçek bir destek kaydına dayalı bir senaryo mülakatı yapar ve ilerideki bir ekip üyesi kısa bir eş mülakatında günlük iş birliğini test eder.
Her mülakatçı aynı kısa formu kullanır: iletişim, problem çözme, empati ve görev uygunluğu. Her puanın altında bir kısa kanıt notu zorunludur.
Ham puanları şöyle olsun:
0–100 ölçeğine çevrildiğinde bunlar 90, 60 ve 80 olur.
İlk bakışta, işe alım müdürü diğerlerinden çok daha az olumlu görünüyor. Bu, Maya'nın o turda kötü performans gösterdiği anlamına gelmez. Bu, ekibin yorumları okumalarını ve puanlama kalıplarına bakmalarını gerektiğini gösterir. Eğer o müdür genelde daha katı puan veriyorsa, ekip zaman içinde bu eğilimi kalibre edebilir; tek bir sert puanın kararı domine etmesine izin vermek yerine.
Nihai paylaşılan kayıtta ekip açık bir özet kaydeder: Karar: Teklif değerlendirmesine ilerlet. Sebep: Güçlü müşteri iletişimi, baskı altında sakinlik ve net ticket yönetimi. Ürün faturalandırma bilgisinde boşluk var, ancak eğitilebilir.
İlk denemeden sonra ekip iki şeyi değiştirir. Formu sekiz sorudan dörde kısaltırlar çünkü mülakatçılar alanları atlıyordu. Ayrıca kanıt kutusunu zorunlu hale getirirler; bu, debriefleri hızlandırır ve "iyi uyum" veya "emin değilim" gibi belirsiz yorumları azaltır.
İşte kullanışlı bir işe alım uygulamasının yaptığı: yolu göstermek, puanları karşılaştırılabilir kılmak ve nihai karar için net bir sebep bırakmak.
İyi planlanmış bir süreç bile puanlama sistemi çok gevşekse başarısız olabilir.
Yaygın hatalardan biri aynı anda çok fazla şeyi puanlamaktır. Bir formda 12–15 kriter varsa mülakatçılar dikkatli yargılar vermeyi bırakır ve sadece tıklamaya başlar. Çoğu ekip, işle ilgili kısa bir kontrol setiyle daha iyi iş yapar.
Başka bir hata sadece serbest metin notlarına güvenmektir. Notlar önemlidir, ama adaylar arasında karşılaştırılması zordur. Bir mülakatçı üç paragraf detaylı yazarken başka biri sadece "iyi iletişimci" yazar. Yapılandırılmış alanlar yoksa son değerlendirme tahmine dönüşür.
Puanlama ölçeğini işe alım ortasında değiştirmek de gürültü yaratır. Bazı adaylar 1–5, sonra 1–10 ile puanlandırıldıysa sayılar aynı şeyi ifade etmez. Küçük değişiklikler bile (ör. "3"ün anlamını yeniden tanımlamak) sonuçları saptırabilir.
Zamanlama önemlidir. Geri bildirim günler sonra gelirse hafıza boşlukları doldurur. İnsanlar gördükleri görüşmeyi değil, hatırladıkları hikâyeyi puanlamaya başlar. Aynı gün geri bildirim almak kaliteyi artırmanın en kolay yollarından biridir.
Son olarak, gerçek iş becerilerini belirsiz kişisel izlenimlerle karıştırmayın. "Takasları net açıklıyor" test edilebilir ve faydalıdır. "Kültür uyumuna benziyor" ise test etmesi daha zor ve önyargıya açıktır. Bir puan adayın söylediği, yaptığı veya gösterdiği bir şeye bağlanamıyorsa o puanın ağırlığı düşük olmalıdır.
Hızlı bir kontrol çoğu problemi yakalar:
Ekip gerçek adaylarla süreci kullanmadan önce kısa bir test yapın ve insanların nerede tereddüt ettiğini, alanları atladığını veya farklı varsayımlar yaptığını gözleyin.
Önce sahipliğe bakın. Her aşamanın adayı ilerletmekten, geri bildirim istekleri göndermekten veya süreci kapatmaktan sorumlu tek bir kişisi olmalı. İki kişi birbirinin sorumluluğunu üstlendiğini düşünürse süreç çok hızlı yavaşlar.
Formlara bakın. Çoğu mülakatçı formun birkaç dakika içinde tamamlanabildiğinde daha iyi geri bildirim verir. Uzun, belirsiz veya tekrarlayıcı hissediyorsa insanlar onu aceleyle doldurur ve aday değerlendirme formunun değeri düşer.
Kısa bir ön lansman kontrolü yardımcı olur:
Puan testi yapmaya değer. Üç sahte veya geçmiş aday örneğini alıp süreçten geçirerek puan normalizasyonunun pratikte çalışıp çalışmadığını görün; yoksa bir katı değerlendirici hâlâ çok fazla etkiye sahip olabilir.
Karar düzenleme kuralları da önemlidir. Bir işe alım tavsiyesi gönderildikten sonra herkes onu yeniden yazmamalı. Düzenleme haklarını doğru kişilerle sınırlayın ve değişikliklerin görünür bir kaydını tutun.
Bir rol ile başlayın, tüm şirketle değil. Sıklıkla gerçekleşen ve net bir sahibinin olduğu bir işe alım akışını seçin; örneğin bir destek uzmanı veya satış koordinatörü rolü. İlk sürüm için bir ekip yeterlidir.
İş akışını küçük bir aday grubuyla çalıştırın. Bu, insanların nerede takıldığını, hangi alanları atlattığını veya aynı özelliği farklı şekilde nasıl puanladıklarını gösterir. Kağıt üzerinde net görünen süreç gerçek mülakatlar başladığında genellikle birkaç düzeltme gerektirir.
İlk birkaç haftadan sonra insanları yavaşlatan noktaları gözden geçirin. Çok uzun süren formlar, örtüşen aşamalar, eksik notlar veya karşılaştırılamayan puanlar gibi kalıplara bakın. İncelemenizi pratik tutun ve mülakatçılara gerçekten hangi alanları kullandıklarını, hangilerini görmezden geldiklerini sorun.
Basit bir yaygınlaştırma genellikle şöyle görünür:
Akış artık her gün değişmeyi bıraktığında bunu basit bir araca dönüştürün. Uygulama aday aşamasını, mülakat formlarını, normalize edilmiş puanları, yorumları ve nihai karar durumunu tek bir yerde göstermeli. Bu, ekibe dağınık notlar ve sohbet mesajları yerine tek bir paylaşılan kayıt verir.
No-code bir yol arıyorsanız, AppMaster veri modeli, arka uç mantığı, web ve mobil görünümleri tek platformda destekleyerek işe alımcıların, işe alım yöneticilerinin ve mülakatçıların aynı işe alım sürecinin farklı görünümlerine erişmesini kolaylaştırabilir.
İlk sürümü küçük tutun. Ekip gerçekten kullandığı açık bir uygulama, okunmayan alanlarla dolu daha büyük bir sistemden daha iyidir.
Neden işe alım ekiplerinin bir mülakat puan kartı iş akışına ihtiyacı var?Herkesin aynı kaynaktan çalışmasını sağlar. Aşamalar, puanlar, yorumlar ve kararlar tek yerde olduğunda işe alım daha hızlı ilerler ve adayları adil şekilde karşılaştırmak kolaylaşır.
Kaç tane aday aşaması olmalı?Ekiplerin gerçekten kullandığı aşamalar kadarına yer verin. Basit bir akış: Applied, Screen, Interview, Offer, Hired gibi olabilir; önemli olan her aşamanın net giriş ve çıkış kuralları ile bir sahibinin olmasıdır.
Bir mülakatçı geri bildirim formunda neler olmalı?Kısa ve role özgü tutun. Çoğu form için birkaç işle ilgili kriter, bir puan ve adayın ne söylediğini veya yaptığı işi açıklayan kısa bir kanıt notu yeterlidir.
Mülakatlar için hangi puanlama ölçeği en iyisidir?Tüm süreç boyunca aynı ölçeği kullanın. 4 veya 5 puanlı bir ölçek genellikle en kolay olandır; asıl önemli olan her puanın net bir tanımının olmasıdır.
Her mülakatçının aynı puanlama ölçeğini kullanması gerekiyor mu?Evet. Farklı turlarda farklı ölçekler kullanılırsa karşılaştırmalar hızla karışır. Tek bir paylaşılan ölçek puanların incelenmesini, normalizasyonunu ve açıklanmasını kolaylaştırır.
Çok sert ya da çok cömert bir değerlendiriciyle nasıl başa çıkılır?Tek bir sıra dışı puanın sonucu tek başına belirlemesine izin vermeyin. Puanları aynı aralığa çevirin, diğerleriyle karşılaştırın ve nihai karar vermeden önce kanıt notlarını okuyun.
Mülakatçılar geri bildirimi ne zaman göndermeli?Varsayılan en iyi uygulama aynı gündür. Hızlı geri bildirim genellikle daha doğrudur; geciken notlar ise daha belirsiz ve önyargıya daha açık olur.
Paylaşılan aday kaydında neler saklanmalı?Her adayın süreci boyunca izlenecek tek bir ortak kayıt olmalı: mevcut aşama, gönderilmiş formlar, puanlar, yorumlar, son durum ve kararı onaylayan kişiler. Bu, ekip için dağınık notlar yerine net bir geçmiş sağlar.
Tüm kullanıma açmadan önce iş akışını nasıl test etmeliyiz?Önce bir rol ve küçük bir ekiple başlayın. Birkaç örnek adayla akışı test edin, insanların takıldığı yerleri gözlemleyin ve daha geniş kullanıma sunmadan önce form veya kuralları basitleştirin.
Bu işe alım sürecini kod yazmadan bir iç uygulamaya dönüştürebilir miyiz?Evet. AppMaster gibi no-code platformlar aday veritabanı, aşama mantığı, formlar, panolar ve onay kurallarını sıfırdan kod yazmadan kurmanıza yardımcı olabilir.
10 Mar 2026
8 dk
08 Mar 20267 dk
07 Mar 20268 dkÜcretsiz planla AppMaster ile denemeler yapın.
Hazır olduğunuzda uygun aboneliği seçebilirsiniz.
