26 Eyl 2025·8 dk
Olay Bildirimine Yönelik Mobil Uygulama Nasıl Oluşturulur: Adım Adım
Olay bildirim mobil uygulamasını planlama, tasarlama ve oluşturma: temel özellikler, çevrimdışı yakalama, iş akışları, güvenlik, test ve yayına alma ipuçları.
Olay bildirim mobil uygulamasını planlama, tasarlama ve oluşturma: temel özellikler, çevrimdışı yakalama, iş akışları, güvenlik, test ve yayına alma ipuçları.
Ekran tasarlamaya ya da gereksinim yazmaya başlamadan önce kuruluşunuzun “olay” ile neyi kastettiğine dair net olun. Farklı ekipler aynı kelimeyi çok farklı olayları tanımlamak için kullanabilir; bu belirsizlik daha sonra dağınık formlar, yanlış yönlendirilmiş uyarılar ve yavaş takip olarak geri döner.
Basit bir tanım ve birkaç somut örnekle başlayın. Örneğin:
Ayrıca kapsam dışı olanları da tanımlayın (ör. rutin bakım talepleri veya anonim ipuçları), yoksa kimseyi tatmin etmeyen bir her şeye uygun araç inşa edersiniz.
Uygulamayla etkileşime girecek rolleri ve ihtiyaçlarını listeleyin:
Burada hafif bir “hızlı rapor” ile daha ayrıntılı bir “yönetici raporu” gibi birden çok raporlama moduna ihtiyaç olup olmadığına karar verirsiniz.
İşinize değer katan birkaç hedef üzerinde anlaşın. Yaygın metrikler:
Her metriğin bir iş hedefine bağlandığından emin olun; örneğin yanıt süresini azaltmak veya denetim hazırlığını iyileştirmek.
Raporların nereye gitmesi gerektiğini netleştirin: bir ekip gelen kutusu, nöbetçi rotası, bir güvenlik yöneticisi veya lokasyona göre farklı kuyruklar.
Son olarak sadece raporlama (yakalama + bildirim) ile tam vaka yönetimi (soruşturma, düzeltici eylemler, onaylar) arasında bir sınır belirleyin. Bu kararı doğru almak yeniden işi önler ve ilk sürümü odaklanmış tutar.
İyi bir olay bildirim uygulaması sadece dijital bir formdan daha fazlasıdır. Bir sorunu “bir şey oldu” aşamasından “halledildi” aşamasına sorumluluğu açık olarak taşıyan yönlendirilmiş bir süreçtir. Ekranları tasarlamadan önce kuruluşunuzun gerçekte kullandığı (veya kullanması gereken) iş akışını adım adım haritalandırın.
Tam sıralamayı sade dille yazın ve kullanacak kişilerle doğrulayın:
Report → triage → assign → investigate → resolve → close.
Her aşama için hangi bilgilerin gerektiğini, sırada kim olduğunu ve “tamam”ın ne anlama geldiğini not edin. Bu, veriyi toplamakla kalıp takip desteği sağlamayan bir uygulama inşa etmenizi önler.
Durumlar işi ilerletir ve raporlamayı ölçülebilir kılar. Basit ve net tutun (örnek: New, In Review, Assigned, In Progress, Waiting, Resolved, Closed).
Her durum için tanımlayın:
Eskalasyon, pek çok olay bildirim uygulamasının başarılı veya başarısız olduğu noktadır. Aşağıdaki kuralları belgeleyin:
Bu, triyaj mantığının, olaylar için push bildirimlerinin ve hizmet seviyesi beklentilerinin temelini oluşturur.
Her rapor her alanı gerektirmez. Evrensel birkaç soruyu (ne/nerede/ne zaman) tanımlayın, sonra türe göre zorunlu alanlar ekleyin—ör. yaralanma raporları vücut bölgesi ve tedavi gerektirebilir, ekipman hasarı varlık kimliği ve duruş tahmini isteyebilir.
Olay bildirim uygulamasının konuşması gereken sistemleri listeleyin: e-posta, biletleme araçları, sohbet kanalları, İK veya EHS sistemleri. Buradaki erken kararlar kimlikler, veri formatları ve uygulama canlıya geçince kimin “gerçek kaynak” olacağını belirler.
Bir olay bildirim uygulamasının başarısını belirleyen tek şey: insanların bir dakikadan kısa sürede eksiksiz bir rapor gönderebilmesi mi, yoksa amirlerin harekete geçmesi için yeterli ayrıntı var mı. Hile, önce minimum hayati gerçekleri toplamak, sonra soruşturma kalitesini artıracak isteğe bağlı alanlar sunmaktır.
İlk ekranın yalnızca triyajı başlatmak için gerekenleri yakaladığından emin olacak şekilde formunuzu tasarlayın:
Bu, işyeri güvenliği raporlamasını tutarlı kılar ve olay yönetimi iş akışınızı otomatikleştirmeyi kolaylaştırır.
Kanıt doğruluğu artırır, ama zorlamak raporlamayı azaltabilir. Tek dokunuşla seçenekler sunun:
Bir saha raporlama uygulaması inşa ediyorsanız, hızlı kamera erişimini önceliklendirin ve “sonra ekle” seçeneği verin ki rapor güvenli ve hızlı bir şekilde gönderilebilsin.
Akıllı varsayılanlar çevrimdışı mobil raporlamayı zahmetsiz hissettirir:
Otomatik yakalama hataları azaltır ve mobil uygulama geliştirme kapsamını hız odaklı tutar.
Bazı bilgiler acil durum sakinleştikten sonra toplanmalıdır. Bunları bir takip adımına veya amir görünümüne koyun:
Bu yapı, bir yönetici daha fazla detaya ihtiyaç duyduğunda push bildirimlerini destekler.
Uygulamanız, sık sürüm gerektirmeden iş akışını adapte edebilmek için yönetici özellikleri içermeli:
Sınırlar koyun: çok fazla özel alan raporlamayı yavaşlatır, veri kalitesini düşürür ve uygulama güvenliği ile uyumluluk incelemelerini karmaşıklaştırır.
İnsanlar rapor göndermekten çekiniyorsa olaylar kaçırılır (veya geç bildirilir), bu da güvenliği, uyumluluğu ve yanıt süresini olumsuz etkiler. Amaç, özellikle meşgul, stresli veya eldivenli saha ekipleri için raporlamanın mesaj göndermek kadar kolay hissettirmesidir.
En yaygın vakalar için kısa bir yol tasarlayın: “Bir şey oldu, şimdi kaydetmem gerek.” Özü şu olsun: olay türü, konum, zaman (şimdiye ayarlı) ve 1–2 satır olay özeti.
Kullanıcının hemen bir fotoğraf ekleyip göndermesine izin verin—sonra gönderimden sonra isteğe bağlı “detay ekle” ekranı sunun.
İyi bir model: Quick Report → Submit → Follow-up. Bu, olay taze iken kaydedilmesini sağlar, raporlayan kişi hemen daha uzun formu dolduramayacak olsa bile.
İç terimler yerine günlük dil kullanın. “Yaralanma şiddeti sınıflandırması” yerine “Kimse yaralandı mı?” ve “Çevresel tehlike” yerine “Dökülme, takılma tehlikesi veya güvensiz alan” gibi ifadeler kullanın.
Ekranları odaklı tutun, her adımda 1–3 soru olsun ve kullanıcıya hızlı biteceğini gösterin. Daha fazla ayrıntı gerektiğinde (uyumluluk veya soruşturma için), yalnızca ilgili olduğunda görünen koşullu sorular kullanın. Kullanıcı “Araç olayı” seçerse araç kimliği sorulur; aksi halde gösterilmez.
Telefonla yazmak yavaştır. Mümkün olduğunca açılır menüler, geçişler, tarih/saat seçicileri ve “dokunarak seç” listeleri kullanın. Yardımcı varsayılanlar büyük fark yaratır:
Ayrıca açıklama alanı için sesle yazma seçeneğini düşünün, ama zorunlu kılmayın.
Doğrulama kullanılmaz raporları önlemeli, ceza gibi hissettirmemelidir. İşe yarayan örnekler:
Açılır pencere hataları yerine satır içi ipuçları (“Ne gördünüz? Sonra ne oldu?”) kullanın.
Pek çok kullanıcı kötü ışıkta, gürültülü sahalarda veya hareket halindeyken rapor verir. Dokunma hedeflerini büyük tutun, güçlü kontrast sağlayın ve her girdinin ekran okuyucular için net bir etiketi olsun.
Durumu yalnızca renkle iletmekten kaçının ve bir el ile ulaşılabilecek şekilde birincil “Gönder” eylemini görünür kılın.
Olaylar nadiren kusursuz Wi‑Fi yanında gerçekleşir. Bir bodrumda, uzak saha şantiyesinde veya ağ kesintisinde raporlama başarısız olursa insanlar uygulamaya güvenmeyi bırakır—ve tekrar kağıda veya SMS’e dönerler.
Uygulamayı sıfır bağlantıda bile tam bir rapor yakalayacak şekilde tasarlayın. Önce her şeyi yerelde kaydedin (metin, seçimler, fotoğraflar, konum, zaman damgaları), sonra mümkün olduğunda eşitleyin.
Pratik bir model yerel kuyruklamadır: her gönderim cihazda saklanan bir “senkronizasyon işi” olur. Uygulama ağ geri geldiğinde arka plan eşitleme denemesi yapabilir, kullanıcıyı uygulamayı açık tutmaya zorlamadan.
Bağlantı yükleme sırasında kesilebilir; bu kısmi veri ve kafa karışıklığına yol açar. Öngörülebilir kurallar oluşturun:
Çift gönderimleri önlemek için idempotency anahtarları kullanın: her rapora benzersiz bir token verin, sunucu aynı token ile gelen tekrarları aynı istek olarak ele alsın.
Fotoğraflar ve videolar genellikle eşitleme sorunlarının en büyük kaynağıdır. Yüklemeleri hızlı ve şeffaf tutun:
Her rapor anında tamamlanamayabilir. Taslak raporları otomatik olarak saklayın (ekler dahil) ki kullanıcılar daha sonra geri gelip eksikleri tamamlayıp gönderesin.
Çevrimdışı mobil raporlama iyi çalıştığında uygulama sakin ve güvenilir hisseder—tam da insanların bir olay sırasında ihtiyaç duyduğu şey.
Teknoloji yığını, ne kadar hızlı yayına almanız gerektiği, ekibinizin hangi cihazları kullandığı, hangi entegrasyonlara ihtiyacınız olduğu ve uygulamayı kimin sürdüreceği gibi kısıtlarla uyumlu olmalıdır.
Genellikle iki iyi seçenek vardır:
Kullanıcılarınız karışık cihazlarda ise (saha ekiplerinde yaygın), çapraz platform sürümleri yayımlamaları ve tutarlılığı korumaları açısından basitleştirir.
Basit bir olay bildirim uygulaması bile genellikle raporları depolamak, yönlendirmek ve yöneticileri desteklemek için bir arka uç gerektirir. Planlayın:
Tüm altyapınızı yeniden inşa etmek istemiyorsanız, bir prototip oluşturmak (ve çoğu zaman üretime taşıyabilecek) araçlar hız kazandırabilir. Örneğin Koder.ai sohbetten yapı üretebilen bir prototip/ürünleştirme desteği sunabilir: React tabanlı web admin, Go API ve PostgreSQL veri modeli gibi.
Pratik bir başlangıç veri modeli şunları içerir:
Bu sizi kilitlemez—ancak triyaj ve takip eklediğinizde sürprizleri önler.
Form alanları, olay kategorileri ve şiddet seviyelerinin nerede yönetileceğine erken karar verin:
Ekranları oluşturmadan önce ana eylemler için istek/yanıt şekillerini yazın (olay oluşturma, medya yükleme, durum değiştirme, çevrimdışı değişiklikleri eşitleme). Basit bir API sözleşmesi mobil ve arka uç işini hizalar, yeniden işi azaltır ve test etmeyi kolaylaştırır.
Olay raporları çoğunlukla kişisel ayrıntılar, tıbbi notlar, fotoğraflar ve hassas konum bilgileri içerir. Uygulama güvenliği ve uyumluluğunu baştan bir özellik olarak ele alın—sonradan eklenecek bir şey olarak değil. Bu aynı zamanda raporlama oranlarını doğrudan etkileyen güveni de oluşturur.
Oturum açma yöntemini uygulamanın nerede ve nasıl kullanılacağına göre seçin:
Çoğu uygulama en az dört role ihtiyaç duyar:
İzinleri granüler yapın. Örneğin amirler özet detayları görebilir ama tıbbi ekler yalnızca açıkça yetkilendirildiyse görülebilir.
Metin ve ekleri güvenli hale getirin:
Olaylar İK veya hukuki meseleye dönüşebilir. Değişmez bir olay geçmişi tutun: raporu kim oluşturdu, kim hangi alanları düzenledi, kim durumu değiştirdi ve ne zaman. Bu uygulamada okunabilir ve uyumluluk için dışa aktarılabilir olmalı.
Gizlilik kuralları değişir. Yaygın seçenekler: anonim raporlama, kırpma araçları (yüzleri/plakaları bulanıklaştırma, isimleri gizleme) ve saklama politikaları (belirli bir süreden sonra otomatik silme). Bu gereksinimleri tanıtımdan önce hukuk ve güvenlik liderleriyle kesinleştirin.
İyi bir olay bildirim uygulaması “gönder” ile bitmez. Raporlar gelmeye başladığında, ekiplerin bunları sıralaması, harekete geçmesi ve süreci kapatması gerekir—acil olana hakim olmadan kaybolmadan.
Güvenlik veya operasyon liderlerinin yeni ve devam eden olayları hızlıca inceleyebileceği merkezi bir gelen kutusu oluşturun. Filtreleri basit ve pratik tutun: konum, olay türü, şiddet, durum ve tarih aralığı.
Hızlı triyaj görünümü genellikle kısa bir özet (kim/nerede/ne zaman), şiddet etiketi ve fotoğraf/konum gibi kanıt var mı bilgisi içerir.
Olaylar “biri halleder” belirsizliğinde kalmamalı. Amirlerin şunları yapmasını kolaylaştıran atama araçları ekleyin:
Net bir “sahip” alanı ve basit bir durum akışı hedefleyin (New → In Review → Actioned → Closed) ki herkes bir bakışta ne olduğunu görebilsin.
Çoğu ekip iki paralel ileti dizisine ihtiyaç duyar:
Bu, gizliliği korurken rapor edenin bilgilendirilmesini sağlar; bu da güveni ve gelecekteki raporlamayı artırır.
Hafif ağırlıklı SLA ve eskalasyon kuralları tanımlayın: yüksek şiddetli bir olay gönderildiğinde doğru grubu hemen uyarın; bir son tarih kaçırılırsa amire eskale edin. Bu bildirimler push veya e-posta olabilir—ekibinizin gerçekten kontrol ettiği yöntem neyse onu kullanın.
Basit raporlama çok yol kat eder. Özetler için CSV ve PDF dışa aktarma, ayrıca tür, konum, şiddet ve zaman dilimine göre sayımlar gösteren küçük bir pano destekleyin. Bu, ekiplerin tekrar eden sorunları görmesini ve paydaşlara ilerlemeyi göstermesini kolaylaştırır.
Bir raporlama uygulaması demo’da mükemmel görünebilir ama saha koşullarında başarısız olabilir. Gürültü, eldiven, zayıf sinyal ve zaman baskısı gerçek sınavlardır—uygulamanın gerçekten kullanılabilir olup olmadığını bunlar gösterir.
Ekiplerin gerçekten taşıdığı telefonlarda başlatın. Kamera çekimini (düşük ışık dahil), GPS doğruluğunu ve izinler reddedildiğinde/sonradan değiştirildiğinde uygulamanın davranışını doğrulayın.
Ayrıca arka plan davranışını test edin: kullanıcı fotoğraf çekip ekran kilitlediğinde yükleme devam edecek mi? Uygulama işletim sistemi tarafından öldürüldüğünde taslaklar yeniden açıldığında kurtarılıyor mu?
Olay bildirimi genellikle cihazların zorlandığı anlarda olur. Kenar durum testleri yapın:
Hedef: saha raporlama uygulaması raporu asla kaybetmesin, gönderemese bile güvenli şekilde saklasın.
Form doğrulaması kullanılmaz raporları engelleyecek kadar katı, kullanıcıyı terk ettirmeyecek kadar esnek olmalıdır. Gerekli alanları, tarih/saat mantığını ve “diğer” metin girişlerini test edin.
Veri bütünlüğü kontrolleri de yapın: fotoğrafların ve konumun doğru olaya bağlı kaldığını ve düzenlemelerin eşitleme sırasında çoğaltma yaratmadığını doğrulayın.
Hiçbir pilot öncesi, erişim kurallarının beklendiği gibi çalıştığını doğrulayın (kim neyi görüntüleyebilir, düzenleyebilir veya dışa aktarabilir). Dosya yükleme güvenliğini (tip/boyut sınırları, gerektiğinde kötü amaçlı yazılım taraması) test edin ve kötüye kullanımı azaltmak için temel oran sınırlaması uygulayın.
Kısa bir pilot, tahmin edemeyeceğiniz sürtünceleri ortaya çıkarır. İnsanların nerede durduğunu, taslağı terk ettiğini veya alanları atladığını gözlemleyin. Bu düşüşlere göre ifadeleri, varsayılanları ve alan sırasını iyileştirin, sonra daha geniş bir dağıtımdan önce yeniden test edin.
Başarılı bir olay bildirim uygulaması lansmanı büyük bir sürüm gününden çok yeni alışkanlıklar oluşturmakla ilgilidir. Riskleri azaltan, kullanıcıları destekleyen ve erken geri bildirimi sürekli iyileştirmeye dönüştüren bir dağıtım planlayın.
Gerçek kullanım vakalarını temsil eden bir pilot grupla başlayın: birkaç site, rollerde karışım (saha personeli, amirler, güvenlik ekibi) ve farklı telefon tipleri.
Pilotu kısa tutun (ör. 2–4 hafta) ve net hedefler koyun: “kıl payı raporlamayı artırmak” veya “gönderme süresini azaltmak” gibi.
Pilot sonrası aşamalı bir sürüme geçin—site site veya departman departman—böylece herkesi etkilemeden önce sorunları düzeltebilirsiniz.
Eğitim 60 saniyelik yolu öğretmeye odaklansın: uygulamayı aç, kategori seç, kısa bir açıklama ekle, fotoğraf/konum ekle (gerekliyse) ve gönder.
Bir sayfalık hızlı başlangıç rehberi ve kısa bir video sağlayın. Rehberi uygulama içinde erişilebilir yapın (ör. Yardım altında) ki kullanıcılar e-postaları aramak zorunda kalmasın.
Kullanıcılar uygulama sorununda (giriş, senkronizasyon takıldı, kamera çalışmıyor) nereye gideceklerini bilmelidir. Adına özel bir destek yolu kurun—örneğin Yardım düğmesi bir destek formu açsın veya /support metnine yönlendirsin.
Açık olun: uygulama sorunları desteğe, güvenlik olayları rapor formuna gitmelidir.
Birkaç basit metriği takip edin:
Kategorileri ayarlayın, ifadeleri iyileştirin ve hangi alanların zorunlu olduğuna dair kararları öğrenimlere göre yeniden gözden geçirin. Değişikliklerin ne ve neden yapıldığını kullanıcılara bildirin (“Raporlamayı hızlandırmak için açıklama isteğini kısalttık”). Bu şeffaflık güven oluşturur—ve zamanla daha fazla rapor gelmesini sağlar.
Hızla yineleyen bir ekip iseniz, yapı–ölç–öğren döngüsünü kısaltan araçları düşünün. Örneğin, Koder.ai anlık görüntüler ve geri alma desteği sunarak pilot sırasında iş akışı değişikliklerini güvenle test etmeyi kolaylaştırabilir.
Temel olay yönetimi iş akışınız istikrarlı hale geldikten sonra, uygulamayı göze batmadan daha faydalı kılacak birkaç odaklı yükseltme ekleyebilirsiniz.
Push bildirimleri döngüyü kapatmaya yardımcı olur: rapor edenler durum güncellemeleri alır, amirler atamaları görür ve herkes zaman hassas değişiklikleri görür.
Hangi durumların bildirim tetikleyeceğini net kurallar halinde belirleyin (örn. “size atandı”, “daha fazla bilgi istendi”, “çözüldü”) ve gece/mesai dışı için sessiz saatler ekleyin ki gece vardiyaları veya ofis personeli gereksiz yere rahatsız edilmesin.
Birden fazla siteyi destekliyorsanız kullanıcıların hangi lokasyonlar için bildirim alacaklarını seçmelerine izin verin.
Olayların bilinen tesislerde veya şantiyelerde gerçekleştiği durumlarda coğrafi alan belirleme (geofencing) hataları azaltabilir. Kullanıcı bir site sınırı içindeyken site adı otomatik doldurulsun ve doğru form seçenekleri gösterilsin.
Bunu isteğe bağlı tutun: GPS iç mekanlarda hatalı olabilir ve bazı kuruluşlar gizlilik nedeniyle manuel seçimi tercih eder.
Ekipman veya araç olayları için barkod/QR tarama zaman kazandırır ve doğruluğu artırır. Bir tarama varlık kimliğini, modelini, bakım durumunu veya sahip departmanı çekebilir—böylece kullanıcı detaylarını bilmese bile rapor tam olur.
İş gücünüz çok dilli ise, sahada gerçekte kullanılan dilleri destekleyin. Öncelik verilecekler:
Küçük bir “Yardıma mı ihtiyacınız var?” alanı ekleyin ve iç kaynaklara, politikalara ve eğitime bağlayın—URL’leri ortamlar arasında çalışsın diye relatif tutun (ör. /blog rehber makaleleri için veya /pricing plan detayları için).
Bu iyileştirmeler tek tek ve dikkatle eklenmeli; her birinin raporlama süresini kısaltıp kısaltmadığını, tamamlama oranlarını artırıp artırmadığını veya takip hızını iyileştirip iyileştirmediğini ölçün.
Herkesin üzerinde anlaştığı bir tanımla (ve kapsam dışı kalanlar) başlayın, sonra iş akışını haritalandırın: Report → Triage → Assign → Investigate → Resolve → Close. Minimum uygulanabilir bilgiyi güvenilir şekilde yakalayan en küçük sürümü oluşturun ve bunları doğru kişiye yönlendirin.
Erken sürümlerde, geniş vaka yönetimine geçmeden önce yakalama + bildirim üzerine odaklanın.
Triyajı başlatmak için en azından şu bilgileri toplayın:
Diğer her şeyi isteğe bağlı veya takip adımı olarak bırakın ki çoğu kullanıcı bir dakikadan kısa sürede gönderebilsin.
Çevrimdışı durumu varsayılan kabul edin: önce yerelde kaydet, sonra eşitle.
Uygulayın:
Dinamik formlar kullanın: evrensel küçük bir alan seti (ne/nerede/ne zaman) ve tür-tabanlı gereksinimler.
Örnekler:
Bu, veri kalitesini iyileştirirken yaygın raporları yavaşlatmaz.
Hızlı Rapor → Gönder → Takip akışını tasarlayın.
Hızlı yolun esaslarını tutun (tür, konum, zaman, 1–2 satır). Ardından tanıklar, tehlikeler, düzeltici eylemler ve ekler gibi ayrıntıları toplamak için isteğe bağlı bir ekran sunun—böylece anlık durum kaydedilirken detaylar sonradan eklenebilir.
Bir dokunuşla fotoğraf/video, ses notu ve ek alınmasını sağlayın, ancak kanıtı tüm olaylar için zorunlu hale getirmeyin.
Belirli türler için kanıt gerekiyorsa (ör. maddi hasar), nedenini basit bir dille açıklayın ve güvenli olduğunda “sonra ekle” seçeneği verin.
Basit, net durumlar seçin ve her adımda sahipliği tanımlayın.
Uygulanabilir bir set:
Her durum için şunları belgeleyin:
Açıklanabilir ve test edilebilir yönlendirme kurallarıyla başlayın:
Yönlendirme ürüne dahildir: bildirimleri, triyaj yükünü ve yanıt sürelerini doğrudan etkiler.
Çoğu uygulamanın en az şunlara ihtiyacı vardır:
Ayrıca bir (değişmez olay geçmişi) ekleyin ve medyayı erişim kontrolleri ile, zaman sınırlı URL’lerle koruyun.
Ekiplerin gerçekten kullandığı gerçek koşullarda pilot yapın (eldiven, gürültü, zayıf sinyal) ve sürtünmeyi ölçün.
İzlenecekler:
Aşamalı dağıtım uygulayın ve uygulama sorunları ile olayları ayrı tutacak net bir destek yolu hazırlayın (ör. uygulama Yardım düğmesi ).
/support