Yeni çalışanların daha hızlı adapte olması için görevler, eğitimler, formlar ve destek içeren bir mobil uygulamayı nasıl planlayacağınızı, tasarlayacağınızı, geliştireceğinizi ve başlatacağınızı öğrenin.

Bir mobil çalışan onboarding uygulaması, onboarding sürecini dağınık e-posta, PDF ve hatırlatmalardan, yeni çalışanların her yerde tamamlayabileceği rehberli bir akışa dönüştürür. İnsanların doğru dosyayı bulmasını veya bir sonraki adımı hatırlamasını ummak yerine, uygulama tam olarak ne yapılması gerektiğini gösterebilir—ve bunun yapıldığını doğrulayabilir.
Onboarding birçok araç arasında yürüdüğünde küçük boşluklar birikir:
İyi tasarlanmış bir uygulama kontrol listeleri, hatırlatmalar ve net sahiplikle (kimin neyi onayladığı ve ne zamana kadar) bir İK onboarding iş akışını destekler.
Pratik hedefler belirleyin: 1. günde “bunu nerede bulurum…” sorularının azalması, daha hızlı verimlilik süresi, artan eğitim tamamlama oranları ve daha az onboarding istisnası gibi.
Mobil uygulama, dağıtık ekipler, dizüstü bilgisayar olmayan ön saha rolleri, yüksek hacimli işe alımlar veya onboarding haftalara yayıldığında iyi bir tercihtir.
Eğer temel sorununuz “zaten araçlarımız var ama kimse kullanmıyor” ise, önce mevcut süreçleri basitleştirerek (daha az adım, net sahipler) daha hızlı kazanımlar elde edebilirsiniz—sonra deneyimi sürtünmesiz hale getirmek için mobile ekleyin.
Özelliklerden veya teknolojiden konuşmadan önce, uygulamanın kimler için olduğunu ve şirketinizde “iyi onboarding”ın ne anlama geldiğini netleştirin. Bir mobil onboarding uygulaması en sık herkes için aynı akışı sunmaya çalışırken başarısız olur.
İlk birkaç hafta içinde her birinin neye ihtiyacı olduğunu listeleyerek birincil kullanıcı gruplarını belirleyin:
Her kullanıcı için 2–3 temel senaryo yazın (ör. “Yeni çalışan trenle giderken ön boarding evraklarını tamamlar” veya “Yönetici 1. günden önce ekipmanların hazır olduğunu onaylar”). Bu senaryolar sonraki kararları yönlendirir.
Onboarding'i aşamalara ayırın ki uygulama doğru içeriği doğru zamanda sunabilsin:
Her aşama için olmazsa olmaz görevleri ve bilgileri listeleyin. Görevleri spesifik ve doğrulanabilir tutun (ör. “Davranış kurallarını imzala” yerine “Politikaları oku” demekten kaçının; örneklerde olduğu gibi kesin ifadeler kullanın).
Başarıyı nasıl ölçeceğinizi en baştan tanımlayın:
Bu metrikler pilotlar ve sürekli iyileştirmeler için başlangıç noktası olur. Basit bir yapıya ihtiyacınız varsa, çalışan onboarding kontrol listesi uygulaması formatını uyarlayın ve İK onboarding iş akışınızla hizalayın (bkz. /blog/onboarding-checklist).
Bir onboarding uygulaması çabucak “İK'nın istediği her şey” haline gelebilir. MVP için, bir yeni çalışanı teklif kabulünden 1. haftada verimli hale gelene kadar götürecek minimum özellik setine odaklanın, fazladan karmaşıklık olmadan.
“Yeni çalışanlar evrakları ve 1. haftadaki eğitimleri 3. güne kadar tamamlasın” veya “yöneticiler onboarding ilerlemesini tek bir ekranda takip edebilsin” gibi ölçülebilir bir sonuç seçin. Bu, özellik kararlarını somut tutar ve kapsam kaymasını önler.
İlk sürüm genellikle şu yapı taşlarını kapsamalıdır:
Sohbet, sosyal akışlar, karmaşık iş akışları, özel role göre yolculuklar, derin analitik panolar gibi gelişmiş özellikleri doğrulamadan sonra saklayın. Erken metrik ihtiyacınız varsa sadece birkaçını takip edin: kontrol listesi tamamlama oranı, tamamlama süresi ve eğitim tamamlama.
İyi bir MVP küçük hissetmeli ama yeni çalışanın ilk haftaları için tamamlanmış hissettirmeli.
Bir mobil çalışan onboarding uygulaması nadiren tek başına yaşar. Birçok “gerçek” veri zaten diğer araçlarda bulunur (çalışan kayıtları, organizasyon yapısı, politikalar, eğitim durumu). İyi bir mimari veriyi güvenilir tutar, İK için manuel işi azaltır ve çelişkili bilgileri önler.
Uygulamanızın görüntülemesi veya toplaması gerekenleri listeleyerek başlayın (ör. kişisel bilgiler, başlangıç tarihi, yönetici, gerekli eğitimler, ekipman talepleri). Her öğe için hangi sistemin kayıt kaynağı olduğunu karar verin:
Basit bir kural: hassas veya sık değişen veriyi çoğaltmayın; açık bir neden yoksa API'ler üzerinden gerektiğinde çekin ve uygulamanın benzersiz olarak sahip olduğu (onboarding görev durumu, onaylar, kontrol listeleri) veriyi saklayın.
Uygulama içi depolamayı şu alanlarla sınırlayın:
Hassas alanlar için (SSN, banka hesabı) mevcut güvenli akışlara derin bağlantılar veya el ile yönlendirme tercih edin; bunları yeniden inşa etmeyin.
Yeni çalışanlar uygulamayı yolculukta veya zayıf bağlantılı binalarda kullanabilir. 1. gün ajandası, ofis haritası, kilit kişiler ve daha önce açılmış belgeler gibi temel öğeleri önbelleğe alın. Eylemleri sıraya alın (ör. kontrol listesi güncellemeleri) ve bağlantı geri geldiğinde senkronize edin.
Erken dönemde dev, staging ve production ortamlarını kurun. Staging, SSO, HRIS senkronu ve bildirimler gibi üretim entegrasyonlarını yansıtmalı; böylece gerçek çalışan verilerine dokunmadan test yapabilirsiniz. Bu pilot programlarını daha güvenli ve hızlı yinelemeye yardımcı olur.
Mobil onboarding, insanların telefonu nasıl kullandığını gözettiğinde en iyi işe yarar: toplantılar arasında, yolculuklarda veya BT erişimi beklerken yapılan hızlı, sık kontroller. Tasarım hedefiniz sürtünmeyi azaltmak ve kullanıcı uygulamayı her açtığında ilerleme hissettirmektir.
Her zaman kolay erişilebilen küçük bir ana hedef seti hedefleyin:
Tutarlı bir alt gezinme ve belirgin bir “Kaldığım yerden devam et” deseni, kullanıcıların kaybolmasını önler.
Yeni işe başlayanlar kısaltmalarınızı, ekip isimlerini veya araç lakaplarını bilmez. Görevleri, kişinin ne yapması gerektiği şeklinde etiketleyin, İK'nın ne dediğiyle değil. Örneğin, “Çalışma e-postanızı kurun” “O365 sağlaması” gibi dahili terimlerden daha açıktır. Bağlam önemliyse görev başlıklarının altına kısa açıklamalar ekleyin.
Okunabilir yazı tipi boyutları, güçlü kontrast ve büyük dokunma hedefleri kullanın. Videolar için altyazı sağlayın ve anlamı yalnızca renkle iletmekten kaçının (ör. “Süresi geçmiş” için renk + ikon + metin kombinasyonu). Erişilebilirlik iyileştirmeleri genellikle uygulamayı herkes için daha kolay kullanılır kılar.
Her çalışana her kontrol listesini göstermeyin. Görevleri ve içeriği rol, lokasyon, başlangıç tarihi, istihdam türü ve departman bazında filtreleyin. Uygulama rehberli bir yolculuk gibi hissettirmeli, bilgi çöplüğü değil.
Eğitimi küçük modüllere bölün, formlarda kaydet-devam özelliği sağlayın ve mümkünse çevrimdışı okunabilir içerik sunun. Her ekran bir soruyu yanıtlamalı: Bir sonraki ne yapmalıyım ve ne kadar sürecek?
Bir mobil onboarding uygulaması, içerik güncel kalmadıkça işe yaramaz. Amaç, İK'nın politikaları, eğitimleri ve kontrol listelerini kolayca güncelleyebilmesi; her değişimi bir ürün sürümü haline getirmemektir.
İK ve yöneticilerin onboarding şablonları oluşturup otomatik atayabileceği bir yönetici alanı planlayın (çoğunlukla web tabanlı olur). En azından şablonları şu kriterlerle destekleyin:
Bu, hiçbirine uymayan tek bir devasa onboarding yolundan kaçınmanıza yardımcı olur.
Yeni çalışanlar genellikle küçük parçalar halinde öğrenir. Aşağıyı destekleyin:
Her öğe “okundu/izlendi” olarak işaretlenebilmeli; gerektiğinde basit bir onay (“Anladım”) eklemeyi düşünün.
Politikalar değişir. Eğitiminiz güncellenir. Uygulama şunları takip etmelidir:
Ayrıca içerik güncellenirken mevcut onboarding sürecindeki yeni çalışanlara otomatik olarak en yeni sürüm mü verileceği yoksa atanan sürümün korunup korunmayacağına karar verin.
Bölgelere yayılan operasyonlarınız varsa yerelleştirmeyi baştan planlayın:
İçeriğin çürümemesini sağlayacak basit bir model belirleyin:
Her modül için net bir içerik sahibi atayın ve gözden geçirme takvimi belirleyin (eğitimler için üç aylık, politika değişiklikleri için anlık).
Bir mobil onboarding uygulaması için en iyi teknoloji, trendden çok İK ekibinin sorunsuzca yönetebileceği, güvenli ve düşük bakım gerektiren bir çözüm olanağına dayanır.
En kusursuz, platforma özgü deneyimi (veya yoğun cihaz özellikleri kullanımı) istiyorsanız native uygulamalar (iOS için Swift, Android için Kotlin) güvenli bir seçenektir—ama iki kod tabanını sürdürürsünüz.
Çoğu onboarding kullanım senaryosu için (kontrol listeleri, içerik, formlar, basit medya, bildirimler) çapraz platform genellikle daha hızlıdır:
Pratik bir kural: ekibiniz zaten JavaScript biliyorsa React Native devreye almayı hızlandırır; tek bir araç setiyle sıkı kontrol istiyorsanız Flutter genelde daha basittir.
Özel bir backend (API + veritabanı) entegrasyonlar, analitik ve uzun vadeli ölçek için esneklik sağlar. Onboarding'in HRIS, kimlik sistemleri ve uyumluluk raporlamasıyla senkron olması gerektiğinde idealdir.
Düşük kod/iş akışı aracı erken sürümleri hızlandırabilir, özellikle onaylar, görev yönlendirme ve basit formlar için uygundur. Takas, karmaşık entegrasyon ve veri modellemede daha az kontrol sağlamasıdır.
Hızla ilerleyip sahiplikten vazgeçmek istemiyorsanız, orta yol da mümkündür—hızlı prototip için platformlar kullanıp daha sonra tam kontrol için genişleyebilirsiniz. Örneğin, Koder.ai gibi platformlar ekiplerin bir onboarding MVP'sini sohbet üzerinden prototipleyip göndermesine yardımcı olabilir; gerekirse kaynak kodu dışa aktarabilirsiniz.
Kimlik doğrulamayı erken planlayın; çünkü bu kullanıcı kurulumunu ve güvenlik incelemelerini etkiler:
Günlük hatırlatmalar yerine yüksek değerli anlarda bildirim kullanın: 1. gün hatırlatmaları, eksik belgeler, yönetici onayları ve zaman hassasiyeti olan eğitimler. Kullanıcılara sıklığı kontrol etme imkanı verin (günlük özet vs anlık).
Satın almayı düşünün (veya bir platformla başlamayı) eğer hızlı lansman, yerleşik içerik yönetimi, standart İK onboarding iş akışları ve öngörülebilir maliyetler istiyorsanız.
Özel geliştirin eğer özel süreçler, derin entegrasyonlar, özel raporlama veya marka odaklı deneyim gerekiyorsa.
Birçok ekip pratikte ilk pilot için hızlı bir yapı seçer—sonra MVP'yi kurumsal bir ürüne dönüştürmeye karar verir.
Onboarding uygulaması hızla kimlik bilgileri, istihdam belgeleri, politika onayları ve bazen bordro/yardım verileri gibi hassas verilerin konteyneri olur. Güvenlik ve gizliliği ürün gereksinimi olarak baştan ele alın.
Veri minimizasyonu ile başlayın: sadece onboarding'i tamamlamak ve hukuki/kurumsal yükümlülükleri karşılamak için gerekenleri toplayın. Her alanın neden var olduğunu açıkça belirtin.
Saklama kurallarını erken tanımlayın:
Onboarding farklı izleyiciler içerir; net roller ve izinler belirleyin:
“İK'daki herkes her şeyi görebilir” yaklaşımından kaçının; team, lokasyon veya çalışan grubu bazlı kısıtlama uygulayın.
En azından:
Aşağıdaki gibi önemli eylemler için denetim izleri oluşturun:
Denetim günlükleri soruşturmalar, uyumluluk incelemeleri ve iç hesap verebilirlik için faydalıdır.
Gereksinimler şirkete, ülkeye ve sektöre göre değişir. Hukuk/BT ile gözden geçirin:
Hızlı uygulamak isterseniz, pilot öncesinde sürüm kontrol listesine "Güvenlik ve uyumluluk incelemesi" kapısı ekleyin.
Pilot, onboarding uygulamanızın ekran setinden çıkıp gerçek yeni çalışanları destekleyip destekleyemeyeceğini kanıtladığı yerdir. Amaç mükemmellik değil—küçük, gerçekçi bir grupla en önemli görevleri uçtan uca doğrulamaktır.
Bir departman, rol türü veya lokasyonla başlayın. Küçük bir pilot, neyin kafa karıştırdığını, nerede ayrıldıklarını ve hangi içeriğin alakasız olduğunu gözlemlemeyi kolaylaştırır. Çeşitli yöneticiler, vardiya düzenleri ve teknoloji rahatlığı seviyelerini temsil eden katılımcılar seçin. En az bir İK yöneticisini pilot ekibine dahil edin ki içerik yönetimi ve sorun yanıtı gerçekçi olsun.
Pilot sırasında güveni sarsacak “olmazsa olmaz” akışlara öncelik verin:
Bu akışları demo olarak değil gerçek senaryolar gibi çalıştırın. Örneğin: “Kötü bağlantıda evden ilk hafta kontrol listesini tamamla.”
Şirkette yaygın olan telefonlar ve OS sürümleri üzerinde test yapın (hala kullanımda olan eski cihazları da dahil edin). Dikkat edin:
Uygulama içi istemleri doğal anlarda (bir kontrol listesini bitirdikten veya bir eğitim modülünü tamamladıktan sonra) kullanın ve anketleri kısa tutun. Nitel geri bildirim (“hangi kısım belirsizdi?”) ile basit metrikleri (tamamlama süresi, hata oranları) birleştirin. Kullanılabilirlik sorunlarını düzeltin ve içeriği genişletmeden önce pilotu iyileştirin.
Harika bir onboarding uygulaması ancak yeni çalışanlar, yöneticiler ve İK tarafından gerçekten kullanılırsa işe yarar. Lansmanı değişim yönetimi projesi gibi ele alın: net mesajlaşma, kolay ilk adımlar ve devam eden hatırlatmalar.
Uygulamayı nasıl dağıtacağınız şirket politikası ve cihaz stratejisine bağlıdır.
Hangi yolu seçerseniz seçin, kurulumu sürtünmesiz yapın: tek bir link, minimum adım ve basit ilk giriş akışı.
Tek bir e-posta yerine kısa bir kampanya koordine edin:
Yeni çalışanlar genellikle kiminle iletişime geçeceklerini bilmez. Uygulamaya şunları ekleyin:
Şablonlar, yayımlama iş akışları ve temel raporlama hakkında kısa bir eğitim oturumu düzenleyin. Amaç: İK içerik güncellemesi ve ilerleme takibini geliştirici beklemeden yapabilsin.
Tamamlamayı artırmak için küçük, zamanlı tetikleyiciler kullanın:
Bildirimleri amaçlı tutun—çok fazlaysa insanlar kapatır.
Onboarding'i ölçmüyorsanız “iyi”nun ne olduğunu tahmin edersiniz. Mobil onboarding uygulaması yeni çalışanların nerede takıldığını, hangi içeriğin gerçekten yardımcı olduğunu ve İK ekiplerinin hangi işleri durdurabileceğini görmeyi sağlar.
Onboarding yolculuğunuzu yansıtan basit bir huni ile başlayın:
Davet kabul edildi → ilk giriş → görevler tamamlandı → onboarding tamamlandı
En büyük terk noktalarını bulun.
Sadece tamamlama yanıltıcı olabilir. İçeriğin tüketildiğini ve anlaşıldığını gösteren sinyalleri izleyin:
Bunu eğitimleri kısaltmak, sık tekrar edilen politikaları yeniden yazmak ve sınavları doğru bilgiyi pekiştirecek şekilde ayarlamak için kullanın.
İyi bir onboarding akışı geri dönüşümlü ortama düşürmelidir. İzlenecekler:
Hâlâ çok fazla “nasıl yaparım…?” bileti görüyorsanız, daha fazla görev eklemek yerine kısa bir SSS modülü veya uygulama içi aramayı geliştirin.
Rakamlar nerede sorun olduğunu gösterir; insanlar nedenini açıklar. Kilit anlarda kısa pulse anketleri ekleyin (1. günün sonunda, 1. hafta sonunda, onboarding sonunda) ve yöneticilere hazırlık ve eksikler hakkında 1–2 soru sorun.
Çalışan onboarding kontrol listesi uygulamanızı yaşayan bir ürün gibi yönetin:
Bu ritim İK onboarding iş akışınızı doğru tutar ve her yeni kohort için deneyimi kademeli olarak iyileştirir.
İyi tasarlanmış onboarding uygulamaları bile, sürüme öncelik verip insanların nasıl gerçekten onboard olduğu göz ardı edilirse başarısız olabilir. Bunlar yaygın tuzaklar ve pratik kaçınma yolları.
Mobil uygulama çok içerik yayınlamayı kolaylaştırır, fakat bu yeni çalışanların hepsini hemen tüketmesi gerektiği anlamına gelmez.
Bunu önlemek için onboarding'i zamanlanmış bir yolculuğa bölün: 1. gün öncelikleri (erişim, güvenlik, kilit kişiler), 1. hafta (ekip bağlamı, rol temelleri), 1. ay (daha derin eğitim). Kısa modüller, tahmini tamamlanma süreleri ve kaydet-devam seçenekleri kullanın. Uygulama destekliyorsa, ilk oturumda tüm kütüphaneyi sunmak yerine hatırlatmalı planlama yapın.
Genel kontrol listeleri çalışanları (“alakasız”), yöneticileri (“neden bunu görüyorum?”) ve İK'yı (“neden kimse tamamlamıyor?”) sinirlendirir.
Bunu role ve lokasyona göre özelleştirilmiş yollarla önleyin. Küçük bir şablon setiyle başlayın (ör. ofis vs uzaktan; mühendislik vs satış) ve basit kurallarla kişiselleştirin: departman, ülke, istihdam türü, başlangıç tarihi ve gerekli uyumluluk öğeleri. Kısa bir evrensel çekirdek tutun, sonra koşullu görevler ekleyin.
Uygulama HRIS veya bordro sisteminizde zaten olan bilgileri tekrar soruyorsa, kullanıcılar uygulamayı terk eder ve İK veriye güvenmez.
Bunu önlemek için uygulamanın kayıt kaynağı olduğu şeyleri erken belirleyin. Profilleri mevcut sistemlerden önden doldurun ve sadece eksik olanı toplayın. Entegrasyonları gerçek onboarding senaryolarında test edin (isim değişikliği, uluslararası adresler, yönetici atama) lansmandan önce.
Birçok onboarding sonucu yöneticiye bağlıdır: 1. hafta planı, tanışmalar, ekipman hazırlığı ve erken geri bildirim.
Bunu yöneticiye özel bir kontrol listesi, hatırlatmalar ve yeni çalışanın ilerlemesine görünürlük vererek önleyin. Ana anları açık hale getirin (1:1 planla, bir buddy ata, erişimi onayla). Yöneticiler uygulamayı kullanmazsa benimseme genellikle durur.
Güncel olmayan politikalar ve bozuk linkler güvenilirliği hızla yok eder.
Bunu içerik sahipliği ve gözden geçirme ritimleri ile önleyin. Her politika/modül için bir sahibi ve gözden geçirme tarihi atayın; uygulamada "son güncelleme" bilgisini gösterin ki kullanıcılar okuduklarının güncel olduğuna güvensin.
Mobil bir onboarding uygulaması genellikle onboarding birkaç haftaya yayılıyorsa, işe alım hacmi yüksekse, iş gücünüz dağıtık/ön saflarda yer alıyorsa veya yeni çalışanların 1. günde güvenilir şekilde dizüstü bilgisayarı yoksa işe değer katar.
Mevcut araçların düşük benimsenmesi temel sorun ise, önce süreci basitleştirerek (daha az adım, net sahiplik) hızlı kazanımlar elde edin; sonra mobil ekleyin ve deneyimi sürtünmesiz hâle getirin.
İlk sürüm için tek ölçülebilir bir hedef belirleyin, örneğin:
Her MVP özelliğini bu hedefle ilişkilendirerek kapsam kaymasını önleyin.
Pratik bir MVP genellikle şunları içerir:
İlk hafta için eksiksiz hissettirmeli; "HR'ın istediği her şey" olmamalı.
Her veri türü için hangi sistemin gerçek kaynak olduğunu belirleyin:
Sık değişen veya hassas verileri çoğaltmaktan kaçının; uygulama yalnızca benzersiz olarak sahip olduğu (görev ilerlemesi, onaylar, zaman damgaları) bilgileri saklasın.
Gerekli bilgileri önbelleğe alın (gündem, kilit kişiler, daha önce açılmış dokümanlar) ve eylemleri sıraya alıp ağ geri geldiğinde senkronize edin.
Yaygın çevrimdışı dostu desenler:
Pilot sırasında düşük bağlantı senaryolarını test edin, lansmandan sonra değil.
Rol ve lokasyon bazlı şablonlar oluşturun ve içeriği telefon için uygun tutun.
Pratik CMS/yönetici özellikleri:
Onboarding için genellikle çapraz platform yeterlidir (kontrol listeleri, formlar, içerik, bildirimler).
Çok platforma özgü davranışlar veya yoğun cihaz entegrasyonları gerektiğinde native düşünün.
Asgari güvenlik tabanı:
Ayrıca veri minimizasyonu uygulayın: mümkünse bordro/SSN gibi alanları depolamayın, mevcut güvenli sistemlere yönlendirin.
Pilotı küçük tutun ama gerçekçi senaryolarla uçtan uca akışları doğrulayın:
Birden fazla cihaz/işletim sistemi test edin ve en az bir İK yöneticisini pilot ekibine dahil edin.
Basit bir huniyi ve operasyonel metrikleri takip edin:
Bulgularla kafa karıştıran içeriği kısaltın, şablonları iyileştirin ve ölçeklemeden önce en büyük düşüşleri düzeltin.
Bu, kimseye uymayan tek bir şişkin kontrol listesinin önüne geçer.