Müşteri kurs kayıtlarını, ilerlemeyi ve tamamlamayı izleyen bir web uygulaması nasıl planlanır, tasarlanır ve oluşturulur — ayrıca hatırlatmalar, raporlar ve sertifikalar hakkında bilgi edinin.
Eğitim tamamlanma takibi sadece bir kontrol listesi değildir—temel bir operasyonel soruya cevap verir: kim hangi eğitimi tamamladı, ne zaman ve hangi sonuçla. Eğer ekibiniz bu cevaba güvenemiyorsa, müşteri oryantasyon eğitimi yavaşlar, yenilemeler riskli hale gelir ve uyumluluk görüşmeleri stresli olur.
En azından, öğrenme ilerleme web uygulamanızın şunu kolaylaştırması gerekir:
Bu, özellikle birden fazla ekip (CS, Destek, Satış, Uyumluluk) aynı cevabı ihtiyaç duyduğunda sizin için "gerçek veri kaynağı" olur.
“Müşteri eğitimi” farklı hedef kitleleri ifade edebilir:
Hedef kitleyi erken netleştirmek her şeyi etkiler: zorunlu mu yoksa isteğe bağlı mı kurslar, hatırlatma sıklığı ve “tamamlanma”nın gerçekte ne anlama geldiği.
Pratik bir eğitim tamamlanma panosu genelde şunlara ihtiyaç duyar:
“Çalışıyor”un ötesinde başarıyı tanımlayın:
Bu metrikler neyi önce inşa edeceğinizi ve neyi daha sonra bırakabileceğinizi yönlendirir.
Bir eğitim-tamamlanma uygulaması, birinin kim olduğunu (rolü) kime ait olduğunu (müşteri hesabı) ayırdığınızda yönetmesi çok daha kolay olur. Bu, raporlamayı doğru tutar, istem dışı veri açıklamalarını önler ve izinleri öngörülebilir kılar.
Learner
Öğrenenler en basit deneyime sahip olmalı: atanmış kursları görmeli, eğitimi başlatmalı/devam ettirmeli ve kendi ilerlemelerini ve tamamlama durumunu görmeliler. Aynı müşteri içinde olsa bile başkalarının verilerini görmemeliler.
Customer Admin
Müşteri yöneticisi kuruluşları için eğitimi yönetir: öğrenen davet eder, kurs atar, takımları için tamamlama görür ve denetimler için raporlar dışa aktarır. Kullanıcı niteliklerini (isim, takım, durum) düzenleyebilirler ama global kurs içeriğini değiştirmemelidirler—müşteri-özel kursları açıkça desteklemiyorsanız.
Internal Admin (ekibiniz)
İç yöneticiler müşteriler üzerinde görünürlük ister: hesapları yönetmek, erişimi düzeltmek, kayıtları düzeltmek ve global raporlar çalıştırmak. Bu rol ayrıca kullanıcı silme, hesap birleştirme veya fatura ile ilgili alanları değiştirme gibi hassas eylemleri kontrol etmelidir.
Instructor / İçerik Yöneticisi (isteğe bağlı)
Canlı oturumlar düzenliyorsanız veya kurs materyallerini güncelleyen personeliniz varsa, bu rol kurs oluşturma/düzenleme, oturum yönetimi ve öğrenen aktivitesini gözden geçirme yapabilir. Genelde müşteri fatura verilerini veya müşteri-üstü analitiği görmemelidirler, gerekmedikçe.
Çoğu B2B uygulaması basit bir hiyerarşi ile en iyi çalışır:
Takımlar günlük yönetimde yardımcı olur; kohortlar raporlama ve son tarihler için faydalıdır.
Her müşteri kuruluşunu kendi güvenli konteyneri olarak ele alın. En azından:
Rolleri ve tenant sınırlarını erken tasarlamak, raporlama, hatırlatmalar ve entegrasyonlar eklediğinizde acı veren yeniden yazımları önler.
Net bir veri modeli, daha sonra ortaya çıkan çoğu “neden bu kullanıcı eksik görünüyor?” sorununu önler. Ne atandığını, ne olduğunu ve neden tamamlandığını saklamayı hedefleyin—tahmin etmeden.
İçeriği teslim ettiğiniz şekilde modelleyerek başlayın:
MVP'niz sadece “kurslar” içerse bile, modüller/dersler için tasarım yapmak gelecekte yapısal eklemelerde göç gerektirmez.
Tamamlama açık olmalı, ima edilmemeli. Yaygın kurallar şunlardır:
Kurs düzeyinde, tamamlamanın tüm gerekli dersleri, tüm gerekli modülleri veya N of M öğeyi gerektirip gerektirmediğini tanımlayın. Kullandığınız kuralın sürümünü saklayın, böylece kuralları değiştirdiğinizde raporlama tutarlı kalır.
Her öğrenen ve öğe için bir ilerleme kaydı tutun. Faydalı alanlar:
started_at, last_activity_at, completed_atexpires_at (yıllık yenilemeler veya uyumluluk döngüleri için)Bu, hatırlatmaları (“7 gündür etkin değil”), yenileme raporlamasını ve denetim izlerini destekler.
Her tamamlamada saklayacağınız kanıtları belirleyin:
Kanıtı hafif tutun: uygulamanızda tanımlayıcılar ve özetler saklayın, ham artefaktlara (quiz cevapları, video logları) yalnızca uyumluluk için gerçekten ihtiyaç varsa bağlayın.
Kimlik doğrulama ve kayıt akışlarını doğru yapmak, uygulamayı öğrenenler için zahmetsiz ve yöneticiler için kontrol edilebilir kılar. Amaç, sürtüşmeyi azaltmak ama kim, hangi müşteri hesabı adına neyi tamamladığını kaybetmemektir.
Bir MVP için bir ana oturum açma seçeneği ve bir yedek seçin:
Daha büyük müşteriler istedikçe SSO (SAML/OIDC) ekleyebilirsiniz. Şimdi kimlikleri esnek tutarak tasarlayın: bir kullanıcı aynı profile bağlı birden fazla kimlik doğrulama yöntemi bağlayabilsin.
Çoğu eğitim uygulaması üç kayıt yoluna ihtiyaç duyar:
Pratik bir kural: kayıt her zaman kimin öğreneni kaydettiğini, ne zaman ve hangi müşteri hesabı altında kaydetmelidir.
Yeniden kaydolma ve tekrarlar: yöneticilerin ilerlemeyi sıfırlamasına veya yeni bir deneme oluşturmasına izin verin. Geçmişi saklayın, böylece raporlama “en son deneme” vs “tüm denemeler” olarak gösterilebilir.
Kurs sürüm güncellemeleri: içerik değiştiğinde tamamlamaların geçerli kalıp kalmayacağına karar verin. Yaygın seçenekler:
Şifre kullanıyorsanız, e-posta ile kısa ömürlü tokenlar, oran sınırlamaları ve net mesajlaşma ile “şifremi unuttum” destekleyin. Magic link kullanıyorsanız bile e-posta değişiklikleri gibi durumlar için kurtarma gerekir—genelde yönetici desteği veya doğrulanmış e-posta değişikliği akışı ile çözülür.
En iyi test: bir öğrenen bir davetten kursa bir dakika içinde katılabiliyor mu ve bir yönetici (yanlış e-posta, yanlış kurs, tekrar) mühendislik yardımı olmadan düzeltme yapabiliyor mu?
Bir eğitim takipçisi, öğrenenlerin bir sonraki adımı hızlıca anlayabildiklerinde işe yarar—menülerde dolaşmadan veya "tamam"ın ne demek olduğunu tahmin etmeden. Öğrenen deneyimini kararları azaltacak ve momentum sağlayacak şekilde tasarlayın.
Tek bir ana ekranla üç soruyu yanıtlayın: Bana ne atandı? Ne zaman teslim? Ne kadar ilerledim?
Atanmış eğitimleri kartlar veya satırlar halinde gösterin:
Uyumluluk ihtiyaçlarınız varsa, "Overdue" veya "3 gün kaldı" gibi net bir durum etiketi ekleyin ama panik yaratacak bir UI'dan kaçının.
Çoğu müşteri eğitimleri toplantılar arasında, telefonlarda veya kısa oturumlarda yapar. Oynatıcıyı "devam" odaklı yapın: son bitmemiş adımda açılmalı ve gezinme belirgin olmalı.
Pratik gereklilikler:
Kursun üst kısmında (ve gerekirse her adımda) tamamlanma gereksinimlerini gösterin: örn. “Tüm dersleri tamamla”, “Quiz (%80+ geçiş)”, “Videoyu %90 izle”. Sonra ne kaldığını gösterin: “2 ders kaldı” veya “Quiz denenmedi”.
Öğrenenler bitirdiğinde bunu hemen bir tamamlanma ekranı ile onaylayın ve sertifikalar veya geçmişe bağlantı verin (ör. /certificates).
İlk günden itibaren birkaç temel erişilebilirlik özelliğini uygulayın: oynatıcı için klavye gezinimi, görünür odak durumları, iyi renk kontrastı, video için altyazılar/transkriptler ve net hata mesajları. Bu iyileştirmeler destek taleplerini ve bırakmayı azaltır.
Yönetici panonuz hemen şu soruyu yanıtlamalı: “Müşterilerimiz gerçekten eğitimi bitiriyor mu?” En iyi panolar bunu beş ekran tıklamaya gerek kalmadan yapar ve veriyi anlamak için dışa aktarma gerektirmez.
Bir hesap seçici (veya hesap değiştirici) ile başlayın ki yönetici hangi müşteriyi görüntülediğini her zaman bilsin. Her hesap içinde, kayıtlı öğrenenlerin özünü gösteren okunaklı bir tablo gösterin:
Tablonun üstünde küçük bir “sağlık özeti” yöneticilerin hızlı tarama yapmasına yardımcı olur: toplam kayıtlı, tamamlama oranı ve kaç kişinin durduğu (örn. 14 gündür etkinlik yok).
Yöneticiler genellikle “Kurs A'yı kim başlatmadı?” veya “Destek takımı nasıl gidiyor?” gibi sorular sorar. Filtreleri belirgin ve hızlı yapın:
Sonuçları son aktivite, durum ve tamamlama tarihine göre anında sıralanabilir yapın. Bu, panoyu günlük bir çalışma aracına dönüştürür.
Tamamlanma takibi, yöneticiler hemen eylem alabildiğinde değer kazanır. Sonuç listesinde doğrudan toplu eylemler ekleyin:
Toplu eylemler filtreleri göz önünde bulundurmalı. Yönetici “In progress → Kurs B → Takım: Oryantasyon” filtresindeyse, dışa aktar tam olarak o kohortu içermelidir.
Tablodaki herhangi bir satırdan yönetici bir öğrenen detay görünümüne tıklayabilmeli. Anahtar nokta, birinin neden takıldığını açıklayan okunaklı bir zaman çizelgesidir:
Bu ayrıntı, yöneticilerin müşterilerle sürekli gidip gelmesini azaltır (“Yemin ediyorum bitirdim”) çünkü yöneticiler ne olduğunu ve ne zaman olduğunu görebilir.
Raporlar, eğitim tamamlanma takibini eyleme dönüştüren ve denetim veya yenileme sırasında kanıtlayabileceğiniz şey haline getirir.
Küçük bir rapor setiyle başlayın, bunlar yaygın kararlarla örtüşsün:
Her raporu detaylandırılabilir yapın: bir grafikten altta yatan öğrenen listesine inebilme, yöneticilerin hızlıca takip etmesini sağlar.
Birçok ekip elektronik tablolarda çalışır; bu yüzden CSV dışa aktarım varsayılan olmalıdır. Stabil kolonlar ekleyin: müşteri hesabı, öğrenen e-posta, kurs adı, kayıt tarihi, tamamlama tarihi, durum ve puan (varsa).
Uyumluluk veya müşteri incelemeleri için PDF özet isteğe bağlı olabilir: müşteri hesabı veya kurs başına bir sayfa ile toplamlar ve tarih damgalı anlık görüntü. MVP'nizi kusursuz PDF formatlamaya takmayın—önce CSV'yi gönderin.
Sertifika üretimi genelde basittir:
/verify/<certificate_id>Doğrulama sayfası öğreneni, kursu ve veriliş tarihini doğrulamalı, ekstra kişisel bilgileri ifşa etmemelidir.
Tamamlama geçmişi hızla büyür. Şunları erkenden belirleyin:
Saklamayı müşteri hesabı bazında yapılandırılabilir yapın ki farklı uyumluluk gereksinimlerini destekleyebilesiniz.
Bildirimler, “eğitimi atadık” ile “insanlar gerçekten bitirdi” arasındaki farktır. Amaç rahatsız etmek değil—müşterilerin geride kalmasını önleyen nazik, öngörülebilir bir sistem kurmaktır.
Çoğu durumu kapsayan küçük bir tetik setiyle başlayın:
Tetiklerin kurs veya müşteri hesabı bazında ayarlanabilir olmasını sağlayın; uyumluluk eğitimleri ile ürün oryantasyonu çok farklı aciliyet toleranslarına sahiptir.
E-posta çoğu eğitim takibi için birincil kanaldır çünkü giriş yapmamış öğrenenlere ulaşır. Uygulama içi bildirimler ise uygulamada zaten aktif olanlar için pekiştirme amaçlıdır; ana teslimat mekanizması olmamalıdır.
Her ikisini ekliyorsanız, aynı planı paylaşmalarını sağlayın ki öğrenen çifte ping almasın.
Yöneticilere basit kontroller verin:
Bu, hatırlatmaları müşteri oryantasyon tarzına uyumlu tutar ve spam şikayetlerini azaltır.
Her gönderim denemesi için bir bildirim geçmişi kaydı saklayın: tetik türü, kanal, şablon sürümü, alıcı, zaman damgası ve sonuç (gönderildi, bounce, bastırıldı). Bu, kopya gönderimleri önler, eğitim uyumluluk raporlamasını destekler ve müşterilerin "neden bu e-postayı aldım?" sorusunu açıklar.
Entegrasyonlar, bir eğitim takipçiyi "güncellenmesi gereken başka bir araç" olmaktan çıkarıp ekibinizin güvenebileceği bir sisteme dönüştürür. Amaç basittir: müşteri hesapları, öğrenenler ve tamamlanma durumu mevcut kullandığınız araçlarla tutarlı olsun.
Kimliği ve iş akışlarını zaten tanımlayan sistemlerle başlayın:
Çakışmaları önlemek için her varlık için bir “kayıt sistemi” seçin:
Arayüzü küçük ve stabil tutun:
POST /api/users (external_id veya e-posta ile oluştur/güncelle)POST /api/enrollments (kullanıcıyı kursa kaydet)POST /api/completions (tamamlama durumu + completed_at kaydet)GET /api/courses (harici sistemlerin kurs ID'lerini eşleştirmesi için)Müşterilerinizin güvenebileceği bir çekirdek webhook dokümante edin:
course.completedaccount_id, user_id, course_id, completed_at, score (isteğe bağlı)Daha sonra (enrolled, overdue, certificate issued gibi) daha fazla event eklerseniz, aynı konvansiyonları koruyun ki entegrasyonlar öngörülebilir kalsın.
Tamamlanma verisi zararsız görünse de—gerçek kişiler, müşteri hesapları, sertifikalar ve denetim geçmişi ile ilişkilendirildiğinde riskli hale gelir. Pratik bir MVP, gizlilik ve güvenliği ürün özelliği olarak ele almalıdır.
Saklamayı planladığınız kişisel verilerin (isim, e-posta, unvan, eğitim geçmişi, sertifika ID'leri) bir listesini yapın. Tamamlamayı kanıtlamak veya kaydı yönetmek için ihtiyaç yoksa toplamayın.
Denetimler desteklenecekse, genelde değiştirilemez zaman damgaları (enrolled, started, completed), değişikliği yapan ve neyin değiştiği gerekir.
Öğrenenler AB/İngiltere veya benzeri yargı bölgelerindeyse, işleme için açık bir hukuki dayanak gerekebilir veya bazen rıza. Rıza gerekmediğinde bile şeffaf olun: basit bir gizlilik bildirimi sağlayın ve yöneticilerin neyi görebileceğini açıklayın. Düşünün: /privacy gibi bir sayfa.
En az ayrıcalık ilkesi ile:
“Her şeyi dışa aktar” ve “kullanıcı sil” gibi eylemleri yüksek riskli sayın—bunları yükseltilmiş rollerin arkasına alın.
Verileri taşıma halinde şifreleyin (HTTPS) ve oturumları koruyun (güvenli çerezler, kısa ömürlü tokenlar, şifre değişiminde çıkış). Giriş ve davet akışlarına oran sınırlamaları ekleyin.
Şifreleri güçlü hashing ile saklayın (örn. bcrypt/argon2) ve sırları asla loglamayın.
Şunlar için plan yapın:
Bu temeller, daha sonra ortaya çıkan “kanıtlayamıyoruz” ve “bunu kim değiştirdi?” sorunlarını önler.
MVP'niz teslim hızı ve sahiplik netliği için optimize olmalı: kursları kim yönetiyor, ilerlemeyi kim görüyor ve tamamlama nasıl kaydediliyor. "En iyi" teknoloji, ekibinizin gelecek 12–24 ay boyunca destekleyebileceği olandır.
Özel uygulama hesap tabanlı erişim, özel raporlama veya markalı öğrenen portalı gerektiğinde idealdir. Rollerde, sertifikalarda ve entegrasyonlarda kontrol verir—ama bakım sizde olur.
Low-code (ör. dahili araçlar + veritabanı) gereksinimler basitse ve çoğunlukla kontrol listesi ve katılım takibi ise işe yarayabilir. İzinler, dışa aktarma ve denetim geçmişi konularında sınırlamalara dikkat edin.
Mevcut LMS + portal quizler, SCORM veya zengin içerik oluşturma gerekiyorsa en hızlısıdır. Uygulamanız ince bir müşteri portalı ve raporlama katmanı olur; tamamlamayı LMS'den çekersiniz.
Mimariyi sade tutun: bir web uygulaması + bir API + bir veritabanı MVP için yeterlidir.
Ana kısıt teslim hızıysa (uzun vadeli farklılaşma değil), Koder.ai gibi bir vibe-coding platformu ilk sürümü daha hızlı göndermenize yardımcı olabilir. Sohbette akışlarınızı tarif edebilir—çok kiracılı müşteri hesapları, kayıt, kurs ilerlemesi, yönetici tabloları, CSV dışa aktarma gibi—ve modern bir stack (React frontend, Go + PostgreSQL backend) ile çalışan bir temel üretebilirsiniz.
MVP için iki pratik avantaj:
Erken üç ortam planlayın: dev (hızlı yineleme), staging (gerçekçi veri ile güvenli test), production (kısıtlı erişim, yedekler, izleme). Operasyon işini azaltmak için yönetilen barındırma (AWS/GCP/Render/Fly) kullanın.
MVP (haftalar): kimlik + müşteri hesapları, kurs kaydı, ilerleme/tamamlamayı takip, temel yönetici panosu, CSV dışa aktar.
Sonradan eklenebilecekler: şablonlu sertifikalar, gelişmiş analitik, ince izinler, LMS/CRM senkronizasyonu, otomatik hatırlatma yolculukları, denetim günlükleri.
Bir eğitim tamamlanma uygulaması, sıkıcı ama güvenilir olduğunda başarılı olur: öğrenenler bitirebilmeli, yöneticiler doğrulayabilmeli ve herkes sayılara güvenmeli. En hızlı yol dar bir MVP göndermek, gerçek müşterilerle doğrulamak ve sonra genişletmektir.
Uçtan uca “tamamlanma kanıtı” sunan minimum ekranlar ve yetenekleri seçin:
Tamamlama kurallarını şimdi belirleyin (örn. “tüm modüller görüntülendi” vs “quiz geçti”) ve bunları kabul kriterleri olarak yazın.
Tüm ekip paylaşacağı tek bir kontrol listesi tutun:
Koder.ai kullanıyorsanız, bu kontrol listesi sohbet içinde temiz bir "spec"e dönüşür ve paydaşlarla hızlıca doğrulanabilir.
Müşterilerin nasıl kullanacağını yansıtan gerçekçi testleri çalıştırın:
2–3 hafta boyunca bir müşteri hesabı ile pilot yapın. İlk tamamlama süresini, düşüş noktalarını ve yönetici sorularını izleyin. Geri bildirimi bir sonraki yineleme önceliklendirmesi olarak kullanın: sertifikalar, hatırlatıcılar, entegrasyonlar ve daha zengin analitik.
Yardımcı olmamı isterseniz MVP kapsamını belirlemede ve hızlıca göndermede destek almak için /contact ile iletişime geçin.
Operasyonel soruyla başlayın: kim hangi eğitimi ne zaman ve hangi sonuçla tamamladı. MVP'niz güvenilir şekilde şunları yakalamalıdır:
started_at, last_activity_at, completed_atBu alanlar güvenilirse, panolar, dışa aktarımlar ve uyumluluk görüşmeleri basitleşir.
Tamamlanma kurallarını açıkça tanımlayın ve bunları (ve sürümlerini) depolayın; tıklamalardan çıkarım yapmayın.
Yaygın kural türleri:
Kurs seviyesinde, tamamlamanın tüm gerekli öğeler mi yoksa N of M şeklinde mi olacağını belirleyin ve kural sürümünü saklayın; böylece içerik değiştiğinde eski tamamlamalar denetlenebilir kalır.
Çoğu B2B eğitim takipçisinde, tenant sınırlarını basit tutun:
Bunun üzerine roller ekleyin:
Çoğu iş akışını kapsayan asgari set:
Her zaman kayıt üzerinde , ve bilgilerini saklayın; böylece "nasıl dahil oldu" soruları ortadan kalkar.
Magic linkler şifre sürtüşmesini azaltır ve yükü düşürür, ancak hâlâ şunlara ihtiyaç vardır:
Şifreler beklenen bir pratikse kullanılabilir, ama sıfırlamalar, kilitlenmeler ve güvenlik sertleştirme için vakit ayırın. Yaygın yol: önce magic link, daha sonra büyük müşteriler isterse SSO (SAML/OIDC) ekleyin.
Ne yapılması gerektiğini açıkça gösterin ve bitiş çizgisini görünür kılın:
/certificates)Öğrenenler neyin kaldığını göremezse, takılırlar—takip sistemi mükemmel olsa bile.
Başlangıç için aşağıdakileri gösteren bir tablo yeterlidir:
Yönetici aradığı yerde eylem yapabilmeli:
Böylece pano günlük bir çalışma aracına dönüşür, çeyreklik rapor olmaktan çıkar.
Denemeleri birincil veri olarak izleyin; alanları üzerine yazmayın.
Pratik yaklaşım:
Bu, "3. denemede geçti" gibi dürüst raporlama sağlar ve anlaşmazlıkları azaltır.
İçerik değişikliklerini bir sürümleme sorunu olarak ele alın.
Seçenekler:
Kayıtlar/tamamlamalar üzerinde saklayın ki raporlar içerik güncellemelerinde geriye dönük değişmesin.
Kimlik ve iş akışlarını sabitleyen sistemlerle başlayın:
API'yi minimal tutun:
Bu, veri sızıntısını önler ve raporlamayı güvenilir kılar.
enrolled_byenrolled_atorganization_idcourse_version_idPOST /api/usersPOST /api/enrollmentsPOST /api/completionsGET /api/coursesMüşterilerin güvenebileceği tek bir webhook ekleyin (ör. course.completed) ve imzalama, yeniden deneme, idempotentlik gibi özellikleri sağlayın; böylece downstream sistemler tutarlı kalır.