Etkinlik Biletleri ve Check-In İçin Mobil Uygulama Nasıl Oluşturulur

Hedeflerle, Kullanıcılarla ve Etkinlik Türleriyle Başlayın

Ekran taslağı çizmeye veya bir QR tarayıcı kütüphanesi seçmeye başlamadan önce çözmekte olduğunuz soruyu netleştirin. Etkinlik biletleme uygulamaları genellikle basit nedenlerle başarısız olur: biletler bulunamıyor, girişte kuyruklar yavaş ilerliyor, dolandırıcılık tutarlı şekilde ele alınmıyor veya personel sorun çıktığında koordine olamıyor.

Çözdüğünüz problemi tanımlayın

Günlük dilde en önemli 2–3 sorun noktasını yazın. Örnekler:

• Bilet teslimi güvenilir değil (e-postalar kayboluyor, ekran görüntüleri işe yaramıyor, transferler kafa karıştırıcı)
• Giriş kuyrukları çok yavaş (manuel aramalar, kötü bağlantı, belirsiz görevli rolleri)
• Dolandırıcılık ve çift bilet yaygın (paylaşılan PDF'ler, tekrar kullanılan QR kodları)
• Personelin doğru araçları yok (canlı kapasite görünümü yok, yükseltme yolu yok)

Bu, özellik talepleri birikmeye başladığında ürünü odaklı tutar.

Temel kullanıcılarınızı belirleyin

Çoğu etkinlik biletleme ürünü aslında üç deneyimi bir arada sunar:

• Katılımcılar: biletlere sorunsuz erişim, transfer ve hızlı giriş isterler.
• Görevli tarayıcılar: baskı altında hız, netlik ve güvenilirlik ister.
• Yöneticiler/organizasyon: kontrol (bilet kuralları, personel, raporlama) ve daha az destek talebi ister.

İlk olarak kimi hizmet edeceğinizi açıkça belirtin. Görevli-öncelikli bir MVP, katılımcı-öncelikli olandan çok farklı görünebilir.

Destekleyeceğiniz etkinlik türlerini seçin

Etkinlik türü zamanlamayı, giriş düzenlerini ve doğrulama kurallarını değiştirir:

• Konserler / tek seanslı etkinlikler: tek büyük akın penceresi, tarama hızı önemlidir.
• Konferanslar: çoklu rozet taramaları, oturum erişimi, rol tabanlı giriş.
• Çok günlü festivaller: yeniden giriş kuralları, bileklik vs bilet, çevrimdışı çalışma kritik.

“Başarı”nın neye benzediğini tanımlayın

İzleyebileceğiniz ölçülebilir sonuçları seçin:

• Medyan tarama süresi (örn. 2 saniyenin altında)
• Zirve girişte kuyruk süresi azaltma
• 1.000 katılımcı başına destek talepleri
• Geçersiz/çift tarama oranı

Bu hedefler sonraki her ürün kararını yönlendirecektir.

Biletleme ve Check-In Yolculuğunu Haritalandırın

Özellikleri veya ekranları seçmeden önce gerçek dünyadaki yolculuğu üç açıdan haritalandırın: katılımcı, görevli ve organizatör. Net bir yol haritası "ofiste çalışıyor, kapıda başarısız oluyor" sürprizlerini önler.

Katılımcı akışı: biletten girişe

Katılımcının beklediği en basit yolu düşünün:

Bilet satın al/teslim al → uygulamayı (veya e-postayı/cüzdanı) aç → bileti hızlıca bul → QR kodu göster → içeri alın.

Her el değişimini ve potansiyel gecikmeyi belirtin: hesap oluşturma, e-posta teslimi, düşük pil, sinyal yokluğu ve birinin kuyrukta doğru bileti ne kadar hızlı bulabileceği. Katılımcıların giriş yapmasının zorunlu olup olmadığını veya sihirli link/konuk modu kabul edilebilir mi karar verin.

Görevli akışı: tara, onayla, çöz

Görevliler tekrarlanabilir bir döngüye ihtiyaç duyar:

Tarayıcıyı aç → tara → anında sonuç (geçerli/geçersiz/önceden kullanılmış) → girişi onayla → istisnaları yönet.

Her sonuç için görevlinin gördüklerini haritalandırın. “Geçersiz” nedenini açıklamalı (yanlış gün, yanlış kapı, iptal edildi, bulunamadı) ve sonraki adımı belirtmelidir. Ayrıca tarama başarısız olduğunda ne olacağını planlayın: çatlamış ekranlar, parlama veya lekeli basılı kod gibi durumlar.

Organizatör akışı: yapılandır ve izle

Organizatörler tipik olarak şu yolu izler:

Etkinlik oluştur → bilet türlerini ve kuralları belirle → görevli rollerini/cihazları ata → gerçek zamanda girişleri izle.

Önemli raporlama anlarını dahil edin: beklenen vs. giriş yapan, zirve zamanlar ve olağandışı desenler için uyarılar.

Erken ortaya çıkarılacak uç durumlar

Uç durumları şimdi listeleyin ki sonraki tasarım kararlarınız bunları desteklesin: geç gelişler, yeniden giriş, çok günlük paslar, VIP/basın hatları, misafir listesi girişleri, bilet transferleri ve “telefon kayboldu” kurtarma. Her uç durumun bir sahibi (görevli vs. destek) ve net bir çözüm yolu olmalıdır.

Bilet Modelinizi ve Doğrulama Kurallarını Seçin

Ekranları tasarlamadan veya bir tarayıcı SDK'sı seçmeden önce “geçerli bilet”in etkinliğiniz için ne anlama geldiğine karar verin. Net modeller ve kurallar destek sorunlarını azaltır, girişi hızlandırır ve dolandırıcılığı zorlaştırır.

Bilet formatını seçin

Çoğu etkinlik uygulaması QR kodlu biletler kullanır çünkü gösterimi hızlıdır, modern kameralarla kolay taranır ve çevrimdışı check-in'lerde iyi çalışır.

• 1D barkodlar daha eski tarayıcılar varsa faydalı olabilir, ancak küçük telefon ekranlarında genellikle daha yavaş ve hataya daha açıktır.
• NFC geçişleri (cüzdan tarzı dokunmalar) premium hissi verir ve çok hızlı olabilir, fakat uyumlu cihaz ve daha fazla kurulum gerektirir; mekan donanımını kontrol ettiğinizde veya "dokunarak giriş" deneyimi istediğinizde en iyi seçenektir.

Doğrulamanın nasıl çalışacağını tanımlayın

Gerçeğe uyan en basit kural seti ile başlayın:

• Tek kullanımlık vs. çok kullanımlık (yeniden giriş): Tek kullanımlık “bir kez tara, sonra geçersiz” demektir. Çok kullanımlık yeniden giriş destekler, ancak pas-back'leri azaltmak için “aynı anda bir aktif giriş” veya taramalar arasında bekleme süresi gibi kurallar isteyebilirsiniz.
• Çok günlük etkinlikler: Güne göre geçerlilik ekleyin (örn. sadece 2. Gün geçerli) veya "tüm günler geçerli" flag'i. Tarama sonucu hangi gün(lerin) kaldığını net göstermeli.
• Koltuk bazlı vs. genel kabul: Koltuk bazlı biletler bölüm/sıra/koltuk (ve isteğe bağlı kapı) doğrulaması gerektirir. Genel kabul genelde sadece bilet türü ve zaman penceresini doğrular.

Durum değişikliklerini tutarlı tutun

Biletler durumlar arasında hareket eder—bunları baştan tanımlayın:

• Transfer edildi: orijinal QR anında geçersiz hale geliyor mu ve transferler geri alınabilir mi karar verin.
• İade/iptal: tarama her zaman net bir “geçersiz” sebebi göstermeli.
• İptal edilen sipariş vs. iptal edilen katılımcı: her iki durumu da ele alın ki görevli kapıda doğru mesajı görsün.

Bu kuralları görevli için sade dilde yazın ve uygulamanın tarama yanıtlarında yansıtın.

MVP Özelliklerini Tanımlayın (Katılımcı, Görevli, Yönetici)

Etkinlik biletleme uygulaması için MVP "daha küçük bir uygulama" değildir. Gerçek insanların kapıdan sorunsuz şekilde geçmesini sağlayan en kısa özellik setidir—aynı zamanda organizatörlere sayı ve kontrol konusunda güven verir.

Katılımcı için temel ("biletim" anı)

Katılımcı deneyiminiz üç soruyu hızla yanıtlamalı: Bugün benim biletim nedir? Nereye gitmeliyim? Bugün neye dikkat etmeliyim?

Şunları dahil edin:

• Her bileti net gösteren bir bilet cüzdanı (isim, etkinlik, tarih/saat, giriş bilgileri).
• Etkinlik detayları: mekan adresi, zamanlama, giriş kuralları ve temel yardım/iletişim.
• Apple Wallet / Google Wallet ekleme, böylece katılımcılar giriş yapmayı unutsa bile biletlere erişebilir.

Mümkünse hesap oluşturmayı isteğe bağlı tutun. Pek çok etkinlik için “e-postayı aç → bileti gör” parola oluşturma gereksiniminden iyidir.

Görevli için temel (hız + kesinlik)

Görevlilerin tek amacı: biletleri hızlı ve minimum belirsizlikle doğrulamak.

Öncelik verin:

• Anında açılan adanmış bir tarama ekranı.
• Düşük ışık için flaş düğmesi.
• Büyük durum geri bildirimi (başarılı/geçersiz/önceden kullanılmış durumlar, renk + metin ile).
• Hasarlı ekranlar ve uç durumlar için manuel arama (isim, e-posta, sipariş kodu ile).

Yönetici/yönetim için temel (gerçek zamanda kontrol)

Admin araçları telsiz konuşmalarını ve tahminleri azaltmalı:

• Gerçek zamanlı pano: check-in'ler zaman içinde, kapı bazında, bilet türüne göre.
• Kapasite sayaçları (içeride/dışarıda) güvenlik ve personel kararları için.
• Olay günlüğü (istisna geçişleri: “VIP eşlik”, “yerine bilet”, “cihaz sorunu”).

İyi-olur özellikler (MVP stabil ise)

Giriş güvenilir olduğunda push bildirimleri, haritalar, programlar ve katılımcı/sergileyici listeleri düşünebilirsiniz—yararlı ama ilk gün için kritik değildir.

QR Kod Biletini ve Tarama Deneyimini Tasarlayın

Mükemmel bir check-in uygulaması ani hissi verir: kamerayı tut, net bir cevap al, sıradaki kişiye geç. Bu sadece QR tasarımınız, tarayıcı UI'nız ve doğrulama mantığınız birlikte planlandığında olur.

QR kod ne içermeli?

Genelde iki seçeneğiniz var:

• Rastgele token (önerilen): QR kısa, rastgele görünen bir dize (veya UUID) içerir. Uygulama bunu sunucunuza gönderir (veya önbelleğe alınmış bir listeyi kontrol eder) ve geçerliliğini doğrular.
• Kodlanmış bilet verisi: QR bilet kimliği, etkinlik kimliği, koltuk veya katılımcı bilgisi gibi ayrıntıları içerebilir.

Tokenleri tercih edin çünkü daha güvenlidir ve döndürmesi daha kolaydır. Birisi ekran görüntüsü alıp kodu paylaşırsa, token'ı iptal ederek o ekran görüntüsünün kullanılmasını engelleyebilirsiniz. Kodlanmış veri tamamen çevrimdışı kurulumlar için faydalı olabilir, ama kişisel veri riskini artırır ve iptal etmeyi zorlaştırır—imza doğrulaması ve iptal listeleri iyi yönetilmeli.

Tarama hızlı ve net olmalı

Hız çoğunlukla kamera sürtünmesini ve karar süresini azaltmakla ilgilidir:

• Hızlı otomatik odak ve düşük ışık performansını optimize edin (gerekirse cihaz torch kontrolünü kullanın).
• Tarama görünümünü sade tutun: geniş çerçeve, dağınıklık yok, net talimat (“QR üzerine sabit tutun”).
• Anında, yüksek kontrastlı bir sonuç durumu gösterin: Geçerli (yeşil) vs. Geçersiz (kırmızı) ve kısa bir neden.

Çiftleri nazikçe yönetin

Çiftler olur—paylaşılan ekran görüntüleri, çoklu girişler veya personel hataları. Pratik bir kural:

• İlk tarama = geçerli ve bileti kullanılmış olarak işaretler.
• Daha sonraki taramalar = “Zaten kullanıldı” ve ilk taramanın zamanını ve yerini/kapısını gösterir ki görevli hızlıca çözsün.

Bozuk ekranlar için manuel bir geri dönüş ekleyin

Her QR taranmayabilir. Hızlı bir “Bileti bul” seçeneği oluşturun:

• İsim, e-posta veya sipariş ID ile arama.
• Durum gösteren (kullanılmamış/kullanılmış) minimal bir sonuç kartı ve tek dokunuşla “Check in” eylemi.

Bu, katılımcılar basılı bilet, çatlak telefon veya düşük parlaklık getirdiğinde kuyrukların akmasını sağlar.

Çevrimdışı Check-In'leri ve Güvenilir Senkronizasyonu Destekleyin

Kalabalıklar Wi‑Fi için beklemez. Check-in uygulamanız mükemmel bağlantıya bağımlıysa kuyruklar, karışıklık ve personel çözüm yolları ortaya çıkarırsınız. Çevrimdışı-öncelikli check-in'ler süslü teknoloji değil; tarayıcının ağa gerek duymadan neler yapabildiği ve bağlanınca nasıl "gerçeği söylediği" ile ilgilidir.

Çevrimdışı davranışı kararlaştırın

Cihazın kapılar açılmadan önce ne indirileceğini tanımlayın: katılımcı listesi (veya bilet ID'leri), bilet türleri, doğrulama kuralları (tarih/saat pencereleri, giriş limitleri) ve yasaklı/iadeli biletler.

Ağ koptuğunda uygulama şunları yapabilmeli:

• Önbelleğe alınmış kurallar ile biletleri doğrulamak
• Taramaları zaman damgası + cihaz ID ile yerelde kaydetmek
• “Çevrimdışı olarak giriş yapıldı” gibi açık bir durum göstermek

Senkronizasyon ve çakışma kurallarını tanımlayın

Aynı biletin iki cihazda, her iki cihaz da senkronize olmadan önce taranması çakışma yaratır. Bir politika seçin ve görünür yapın:

• İlk tarama kazanır: en erken zaman damgası geçerli olur; sonraki taramalar “çift” olur.
• Görevli geçersiz kılma: süpervizörlerin istisna işaretlemesine izin verin (VIP transferleri için kullanışlı).

Her durumda, senkronizasyon artımlı ve güvenilir olmalı: otomatik yeniden dene, son senkronizasyon zamanını göster ve yerel tarama geçmişini asla kaybetme.

Personel için cihaz kurulumunu planlayın

Sabah kaosunu azaltmak için kısa bir kurulum akışı oluşturun:

1. Personel girişi (veya PIN)
2. Etkinlik seçimi (veya otomatik atama)
3. Tarama listesi + kuralların indirilmesi ("Çevrimdışı için Hazır"ı doğrula)

“Ağ yok” mesajlaşması ve hızlı kontrol listesi

Muğlâk hatalardan kaçının. Basit mesajlar kullanın: “Bağlantı yok — tarama çevrimdışı devam edecek.” Personel için tek ekranlık bir kontrol listesi ekleyin: uçak modunu kontrol et, mekan Wi‑Fi'sini kontrol et, cihaz saatini doğrula, etkinliği doğrula ve çiftler arttığında bir lideri ara.

Bilet Satışları ve Ödemeler (Gerekliyse) Ekleyin

Her check-in uygulaması bilet satmak zorunda değildir. Etkinlikler zaten bir biletleme platformu kullanıyorsa yalnızca içe aktarma + doğrulama yeterli olabilir. Ancak tam bir biletleme uygulaması yapmak istiyorsanız, ödemeler entegrasyonun ötesinde bir ürün özelliği olur—bu yüzden kapsamı erken belirleyin.

Hedef kitlenize uygun ödeme yöntemlerini seçin

İşe kart ödemeleriyle başlayın; geniş desteklenir ve Stripe, Adyen veya Braintree gibi sağlayıcılarla hızlı uygulanır.

Ardından yerel pazarlar için banka transferleri, cüzdanlar veya bölgeye özgü yöntemler gibi yerel ödeme yöntemlerine ihtiyaç olup olmadığına karar verin. Kullanışlı bir kural: yerel yöntemleri yalnızca operasyon gösterdiğiniz pazarlarda dönüşümü açıkça artırıyorsa ekleyin.

Ödemeyi mümkün olduğunca kısa tutun

Dijital biletler için ödeme akışı bir kahve alır gibi hissettirmeli: az adım, net toplam ve anında onay.

En azından:

• Bilet seçimi (tür + adet)
• Alıcı bilgileri (isim + e-posta; gerekmedikçe daha fazlasını toplamayın)
• Ödeme
• Onay ekranı

Konferanslarda yaygın olan her bilet için katılımcı bilgisi gerekiyorsa, bunları ödeme sonrasında “kayıt tamamlama” adımı olarak toplayın ki ödemeyi engellemesin.

Biletleri anında teslim edin (birden fazla yerde)

Başarılı ödemeden sonra makbuz ve biletleri güvenilir kanallarla gönderin:

• E-posta makbuzu + bilet detayları (kolayca iletilir ve aranır)
• Hızlı erişim için uygulama içi “Biletlerim” cüzdanı
• Kullanıcılar bekliyorsa isteğe bağlı cüzdan geçidi (Apple Wallet / Google Wallet)

QR kodunu katılımcı uygulamasında çevrimdışı kullanılabilir hale getirin ki giriş alım için bağlantıya bağlı olmasın.

Vergi/KDV ve faturalamayı baştan planlayın

Vergiler ve faturalar sonradan düşünüldüğünde destek sorunu yaratır. Şunları karar verin:

• Ödeme sırasında vergi/KDV hesaplayıp göstermeli misiniz
• Hangi fatura alanlarının gerekli olduğu (şirket adı, vergi numarası, adres)
• İade ve kısmi iadelerin faturaları ve makbuzları nasıl etkilediği

Bölgesel işler yapıyorsanız, ödeme sağlayıcınızın vergi özellikleriyle (veya finans sürecinizle) erken uyum sağlayın ki onaylar ve raporlar tutarlı olsun.

Güvenlik, Gizlilik ve Dolandırıcılık Önleme

Biletleme ve check-in uygulaması gerçek değer (ücretli giriş) ve kişisel veri işler. Temelleri baştan doğru yapmak, çift biletler, sızan katılımcı listeleri ve kaotik giriş kuyruklarından sizi kurtarır.

Biletleri sahte yapmayı zorlaştırın

QR kodları e-posta adresi veya düzenlenebilir bilet türü gibi anlamlı veri içermemeli. Bunun yerine sunucunuzun doğrulayabileceği güvenli bir token şifreleyin.

Cihaz çevrimiçiyken sunucu tarafı doğrulamasını tercih edin: tarayıcı uygulama token'ı backend'e gönderir, backend geçerliyse, kullanılmamışsa, iade edilmemişse veya yeniden atanmadıysa onay verir.

Dolandırıcılığı azaltmak için kısa ömürlü imzalar (veya dönen anahtarlar) kullanın; böylece ekran görüntüleri ve kopyalanan QR kodlarının kullanılabilirlik penceresi kısalır. Transferleri desteklemeniz gerekiyorsa yeni bir token verirken eski token'ı geçersiz kılın.

Katılımcı verilerini varsayılan olarak koruyun

Giriş için gerçekten gerekenleri toplayın (çoğu zaman: isim ve bilet durumu). Telefon numarası gerekmedikçe sormayın.

Saklama kuralları belirleyin: katılımcı kayıtlarını, tarama loglarını ve ödeme geçmişini ne kadar süre saklayacağınızı karar verin ve belgeleyin. Admin için dışa aktarma ve silme işlemlerini basit tutun.

Gerçek ekip yapısına uygun rol bazlı erişim

İzinleri ayırın ki:

• Görevli yalnızca birini içeri almak için gerekenleri tarayıp görsün.
• Yöneticiler etkinlik oluşturup/düzenleyip, bilet türlerini yönetip raporları dışa aktarabilsin.

Paylaşılan hesaplardan kaçının. Küçük etkinliklerde bile bireysel girişler denetim izlerini mümkün kılar.

Sistemin düzeyinde kötüye kullanımı önleyin

Hem otomatik saldırıları hem de kazara kötü kullanımı engelleyecek önlemler ekleyin:

• Doğrulama ve giriş uç noktalarında oran sınırlamaları.
• Personel hesapları için cihaz bağlama seçenekleri (ör. etkinlik başına bir tarayıcı cihaz onayı).
• Tarama ve yönetici eylemleri için denetim günlükleri (kim ne yaptı, ne zaman ve hangi cihazda).

Bu önlemler check-in'i yavaşlatmaz, fakat bir sorun çıktığında size hızlıca düzeltme yapma ve olayı anlatma imkanı verir.

Mimari ve Teknoloji Seçimleri (Basit ve Ölçeklenebilir)

Bir biletleme ve check-in uygulaması ilk günde kurumsal seviye bir yığına ihtiyaç duymaz. Önemli olan; zirve giriş sırasında güvenilir kalacak, bakımının kolay olacağı ve tek bir etkinlikten bir sezonluk etkinliklere büyüyebilecek bir yapı kurmaktır.

Yapım yaklaşımınızı seçin

Genelde üç uygulanabilir seçenek vardır:

• Native uygulamalar (iOS/Android): En iyi tarama performansı ve cihaz erişimi, ancak iki kod tabanı.
• Çapraz platform (React Native/Flutter): Yakın-native deneyimle tek kod tabanı. Çoğu ekip için güçlü bir varsayılan.
• Web tabanlı tarama (PWA, tarayıcıda): Hızlı gönderim ve kolay dağıtım, ancak kamera/tarama hızı ve çevrimdışı davranış daha az öngörülebilir.

Tarama hızı ve çevrimdışı mod kritikse native veya çapraz platformu tercih edin.

Hızlı ilerleyen küçük ekipler için admin panosu ve temel akışları (bilet cüzdanı, görevli tarayıcı UI, temel raporlama) sohbet ile prototiplemek üzere Koder.ai gibi bir platform kullanmayı düşünebilirsiniz. Koder.ai modern web uygulamaları (React) ve backend (Go + PostgreSQL) üretebildiği için hızlı bir iç MVP'ye ulaşmak ve sonrasında kod dışa aktarımı ile uzun vadeli sahiplik için pratik bir yol olabilir.

Temiz ve ayrılabilir tutmanız gereken temel servisler

MVP için bile şu yapı bloklarını düşünün:

• Bilet oluşturma: Bilet kaydı oluştur, katılımcıya ata ve bir QR yükü (payload) üret.
• Doğrulama API'si: Bilet durumu (geçerli/kullanıldı/iade) doğrulayan, bir taramayı kaydeden ve net bir sonuç döndüren basit bir uç nokta.
• Etkinlik yönetimi: Etkinlikler, bilet türleri, kapasite, giriş kuralları, görevli rolleri.
• Analitik: Dakikadaki check-in'ler, zirve zamanlar, no-show oranı ve cihaz/personel performansı gibi temel metrikler.

Doğrulamayı etkinlik yönetiminden ayrı tutmak, check-in trafiğini yeniden yazmak zorunda kalmadan ölçeklendirmenizi kolaylaştırır.

Entegrasyonları erken planlayın (göndermeseniz bile)

Bağlantı kurma planınızı düşünün:

• Onaylar ve güncellemeler için CRM/e-posta araçları
• Eğer uygulama içi bilet satacaksanız ödeme sağlayıcıları (örn. Stripe)
• Mevcut biletleme sistemlerine import/export veya API ile bağlantı

Stage ve prod ortamları kullanın

Test etkinlikleri ve personel eğitimi için bir staging ortamı ve canlı etkinlikler için production ortamı oluşturun. Bu, test taramalarının gerçek analitiği kirletmesini engeller ve kapılar açılmadan önce akışı prova etmenizi sağlar.

Check-In'leri Hızlandıran UX Detayları

Hızlı check-in'ler çoğunlukla UX problemidir: en iyi tarayıcı, personelin baskı altında doğru kullanabildiğidir. Dokunma sayısını azaltmaya, durumları açıkça göstermeye ve gerçek dünya koşullarını göz önünde bulundurmaya odaklanın.

Eylemleri belirgin ve erişilebilir yapın

Görevli ekranını hız ve görünürlük için tasarlayın. Büyük birincil butonlar kullanın (örn. Tarama, Ara, Manuel Giriş) ve ikincil eylemleri bir menünün arkasında tutun. Yüksek kontrast, okunabilir yazı ve net ikon etiketleri parlak güneşte ve loş koridorlarda yardımcı olur.

Hata durumları spesifik ve yapılabilir olmalı. “Geçersiz bilet” yerine gösterin:

• Bulunamadı ("Tekrar dene" uyarısı ile)
• Zaten giriş yapıldı (son giriş zamanı ile)
• Yanlış etkinlik/gün (hızlı değişim seçeneği ile)

Dokunuşları ve el hareketini en aza indirin

Hedefiniz “tara → onayla → sonraki” ritmi olmalı. Saniyeler kazandıran desenler:

• Başarılı check-in'den sonra otomatik olarak taramaya dön
• Kamerayı açık tut; ekstra dokunuş gerektiren modal pencerelerden kaçın
• Tek elle kullanım destekle (başparmak erişimli kontroller, büyük hedef alanlar)
• Çok odalı veya çok günlü etkinliklerde hızlı etkinlik geçişi

Gerçek mekanları göz önünde tutarak tasarla

Tarama sıklıkla düşük ışıkta, parlamada veya çatlak ekranlarda olur. Personelin başarı şansını artırmak için:

• Tarama ekranında el feneri düğmesi
• Güçlü kamera odak davranışı ve "daha yaklaştır/daha uzaklaştır" ipuçları
• Basılı biletleri ve takılan yaka kartlarını destekleme (daha büyük tarama kutusu, toleranslı QR algılama)
• Katılımcı telefonlarından tarama için "ekran parlaklığı artır" seçeneği

Lokalizasyonu doğru yapın

Küçük lokalizasyon hataları büyük giriş karışıklıkları yaratır. Temelleri yerelleştirin:

• Uygulama dili (en azından görevli deneyimi için)
• Tarih ve saat formatları
• Etkinlik-özgü zaman dilimi işleme ki “bugün geçerli” ve oturum başlangıç saatleri mekanla uyumlu olsun

Zaman damgası gösteriyorsanız (örn. “9:03'te giriş yapıldı”) zaman dilimini etiketleyin veya cihazlarda mekanın yerel zamanını tutarlı kullanın.

Gerçek Etkinlik Senaryolarıyla Test

Biletleme uygulamanız ofiste mükemmel görünebilir fakat kapıda zorlanabilir. Gerçek etkinlikler dağınıktır: misafirler dalgalar halinde gelir, personel kapılar arasında dolaşır, ekranlar güneşte parlar ve Wi‑Fi en kötü anda kesilir. Testler bu kaosu taklit etmeli ki uygulamaya güvenebilesiniz.

Gerçekçi yüklerle stres testi yapın

Sadece "tarama çalışıyor mu" test etmeyin; "tarama hızlı mı, tekrarlı mı, çoklu cihazlarda" test edin. Zirve giriş dönemlerini yeniden oluşturmak için dakikada çok sayıda tarama yapın ve trafiği birden fazla kapıya bölün. Farklı bilet durumlarını (geçerli, önceden kullanılmış, yanlış gün, iptal, VIP) dahil edin ki mesajlar ve eylemler baskı altında doğrulansın.

Çevrimdışı tarama destekliyorsanız kötü bağlantıyı zorlayın ve uygulamanın öngörülebilir davrandığını doğrulayın: yerel doğrulama, açık çevrimdışı göstergeler ve daha sonra senkronizasyonun çift yaratmadan veya log kaybı olmadan gerçekleşmesi.

Görmemiş personelle bir deneme etkinliği yapın

Bir deneme etkinliği hem yük testi hem personel eğitimi provasıdır. Personellerin kullanacağı tam cihazları kurun, gerçek görevli rolleri ile giriş yapın ve şunları çalıştırın:

• Cihaz kurulumu (kamera izinleri, parlaklık, batarya kontrolleri)
• Kapı atamaları ve kapılar arasında geçiş
• Olay senaryoları (bilet unutma, başkasına ait ekran görüntüsü, isimle arama)

Amaç sürtüşmeleri bulmaktır: belirsiz buton etiketleri, kafa karıştırıcı hata durumları veya kolayca yanlış yapılandırılabilen yönetici ayarları.

Tarama doğruluğu ve doğrulama süresini ölçün

Farklı aydınlatma koşullarında QR taramalarını test edin: parlak güneş, iç mekan düşük ışık, sahne ışıkları ve parlama. İki metriği takip edin:

• Doğrulama süresi: kamera açılmasından "Giriş onaylandı"ya kadar geçen süre
• Doğruluk: geçerli bir biletin ilk denemede tarama başarısı oranı

Bu sayılar derlemeleri karşılaştırmanıza ve tarayıcı, UI veya doğrulama kurallarındaki değişikliklerden sonra regresyonları tespit etmenize yardım eder.

Bir lansman kontrol listesi oluşturun (ve bunu bir kapı gibi ele alın)

Her etkinlik öncesi sürprizleri azaltmak için basit bir kontrol listesi kullanın:

• Personel cihazlarında uygulama sürümlerini doğrulayın (karışık sürümler olmasın)
• Kamera/tarama izinlerini ve OS güncellemelerini kontrol edin
• Her kapıda oturum açma ve rol izinlerini test edin
• Yedek cihazlar ve şarj planları hazırlayın
• Çevrimdışı mod beklentilerini ve senkronizasyon durum göstergelerini doğrulayın

Daha derin bir hazırlık süreci isterseniz bunu Security, Privacy, and Fraud Prevention bölümü ile eşleştirin.

Başlatın, İzleyin ve Her Etkinlikten Sonra İyileştirin

Bir biletleme ve check-in uygulamasını başlatmak bitiş çizgisi değildir—geribildirim döngüsünün başlangıcıdır. En iyi ekipler her etkinliği bir deneme koşusu gibi ele alır, sonra bir sonraki etkinlik öncesi ürünü ve operasyonu iyileştirir.

Etkinlik gününde önemli olanı izleyin

Basit bir pano kurun (saatlik incelenen dışa aktarılan loglar olsa bile) ki şu soruyu cevaplayabilin: “Giriş akıyor mu, akmıyorsa neden?” Şu temel metrikleri takip edin:

• Dakikadaki tarama sayısı (genel ve kapı bazında)
• Zirve giriş zamanları (personel planlarını doğrulamak için)
• Geçersiz tarama nedenleri (süresi dolmuş bilet, zaten kullanıldı, yanlış gün/oturum, tahrif edilmiş kod)

Tarama uygulamanız ret nedenlerini yapısal olarak yakalasın, sadece “geçersiz” demesin. Bu detaylar yol haritanız olur.

Operasyon ekiplerine pratik araçlar verin

Gerçek personel kullanımı başladığında operasyonel ihtiyaçlar çabuk ortaya çıkar. Telsiz konuşmalarını azaltacak araçlar ekleyin:

• Dışa aktarılabilir raporlar (katılım toplamları, bilet türüne göre kullanım, yeniden giriş sayısı)
• Olay notları (örn. “Gate B'de VIP listesi sorunu, 18:10”) zaman ve lokasyon ile bağlanmış
• Personel vardiya takibi (kim ne zaman hangi kapıda taradı)

Bu özellikler bireyleri suçlamadan sonrası için hesap verebilirliği sağlar.

Destek için hazırlık yapın

Destek ürünün bir parçasıdır. Hazırlıklı olun:

• Katılımcılar için kısa bir SSS (biletleri bulma, parlaklık ipuçları, isim değişiklikleri)
• Personel için uygulama içi yardım (yaygın hatalar ve sonraki adımlar)
• Gün içi yükseltme yolu (kim istisna verebilir, kimlik doğrulama nasıl yapılır, senkronizasyon başarısızsa ne yapılır)

Oyun kitabını tek bir yerde belgeleyin ve admin alanından erişilebilir yapın (ör. /help/check-in).

Her etkinlikten sonra yineleyin

24–72 saat içinde hızlı bir retro yapın: çıkan sorunları gözden geçirin, doğrulama kurallarını güncelleyin ve hem görevli hem de yönetici eğitimini iyileştirin. Öncelik verilecek değişiklikler genelde verimi artıran ve insan müdahalesini azaltanlardır—bunlar uygulamanızın daha büyük etkinliklere hazır olduğunun sinyalleridir.