Biletler ve Katılımcılar için Etkinlik Düzenleyici Web Uygulaması Oluşturun

Hedefleri, Kullanıcıları ve Kapsamı Netleştirin

Özellikleri ya da teknoloji yığını seçmeden önce, kimin için inşa ettiğinizi ve “başarı”nın ne olduğunu çok net hale getirin. Bu, bir biletleme platformunun yarım kalmış araç yığınına dönüşmesini engeller.

Kullanıcıları ve temel yapılacak işi tanımlayın

Öncelikle birincil müşterinizi isimlendirin; çünkü her tip farklı çıktılara odaklanır:

• Solo düzenleyiciler hız ister: bir etkinlik oluşturmak, bilet satmak ve destek yüküne boğulmamak.
• Mekanlar tekrarlanabilir kurulumlar, kapasite kontrolü ve hızlı sahadaki operasyonlarla ilgilenir.
• Ajanslar çoklu etkinlik yönetimi, müşteri erişimi ve temiz raporlama ister.

Çekirdek işi bir cümlede yazın; örneğin: “Düzenleyicilerin bilet satmasına ve katılımcıları minimum çabayla ve hatasız şekilde giriş yaptırmasına yardımcı olun.”

Temel iş akışlarını (baştan sona) çıkarın

Ürünü tanımlayan “mutlaka çalışması gereken” yolları listeleyin:

Oluştur etkinlik → bilet türlerini/fiyatlandırmayı ayarla → yayına al → katılımcı kayıt olur → ödeme → bilet verilir → QR ile giriş → dışa aktarma/raporlama.

Her adım eksik ya da kırılgansa, uygulama çok fazla ekstra özellikle olsa bile eksik hissedilir.

Gerçekçi başarı metrikleri belirleyin

İş akışlarına bağlı birkaç ölçülebilir sonuç seçin:

• Checkout dönüşüm oranı (kayıt → tamamlanmış sipariş)
• Ortalama check-in süresi ve hata oranı (QR tarama sorunları)
• İade/transfer süresi (talep → çözülme)
• Etkinlik başına destek hacmi (ve başlıca sebepler)

MVP mı v1 mi karar verin

MVP “birinci günde kullanışlı” olmalı: etkinlik oluşturma, bilet satışı, onaylar, temel check-in ve basit dışa aktarmalar. Daha gelişmiş öğeleri (indirim kuralları, oturma planları, karmaşık vergi mantığı) talebi doğruladıktan sonra v1’e saklayın.

Kısıtları erken belirleyin

Bütçe, zaman çizelgesi ve takım yetenekleri konusunda net olun—bunlar her şeyi sıfırdan mı yapacağınızı yoksa mevcut hizmetlere mi dayanacağınızı belirler. Ayrıca uyumluluk ihtiyaçlarını (fatura, GDPR/CCPA beklentileri, ödeme kuralları) not edin, böylece daha sonra baskı altında tasarımı yeniden yapmak zorunda kalmazsınız.

Temel Özellikler ve Kullanıcı Hikâyeleri

Ekranları veya veritabanlarını seçmeden önce, uygulamanın insanlara ne yapma izni vermesi gerektiğini ve bu “insanların” kim olduğunu tanımlayın. İyi bir etkinlik yönetimi web uygulaması genellikle farklı izinler ve beklentilerle birkaç ayrı rol içerir.

Roller ve izinler (kim ne yapabilir)

İlk etapta basit tutun, sonra genişletin:

• Organizer: etkinlik oluşturur, biletleri yayımlar, ayarları yönetir, iade/iptal yapabilir.
• Staff: katılımcı listelerini görür, QR kod ile check-in yapar, sınırlı düzenleme hakları.
• Finance: siparişleri, ödemeleri, faturaları/gider pusulalarını görür, chargeback ve iadelerle ilgilenir.
• Attendee: kayıt olur, öder, bilet alır, kendi sipariş detaylarını yönetir.

Pratik bir kural: biri para ile ilgili alanları veya etkinlik görünürlüğünü değiştirebiliyorsa, bunun ayrı bir izin olması gerekir.

Planlanacak ana sayfalar ("mutlu yol")

Çekirdek navigasyonu erken taslaklayın ki özellikler rastgele uç noktalara dönüşmesin:

• Etkinlik kurulumu (isim, mekan/çevrimiçi detaylar, tarih/saat dilimi, kapasite, politikalar)
• Bilet oluşturucu (türler, fiyat, satış penceresi, limitler, promosyon kodları gerekliyse)
• Checkout + onay (kayıt formu, ödeme, makbuz, bilet teslimi)
• Sipariş detayları (durum, ödeme, iade geçmişi, katılımcı atamaları)
• Katılımcı listesi + check-in (ara, filtrele, QR tara, check-in kaydı)
• Organizer panosu (satış özeti, kapasite, uyarılar, son etkinlikler)

Test edilebilir kabul kriterleriyle kullanıcı hikâyeleri

Bir oturuşta doğrulayabileceğiniz kısa hikâyeler yazın:

• Organizer biletleri yayımlar: Bir etkinlik taslak halinde iken, “General Admission” adlı bir bilet fiyat ve satış tarihleriyle eklediğimde, bilet kamu kayıt sayfasında görünür ve bitiş tarihinden sonra satış durur.
• Attendee bilet satın alır: Ödeme başarılı olduğunda, bir sipariş oluşturulur, benzersiz bir bilet/QR kodu verilir ve 2 dakika içinde onay e-postası gönderilir.
• Staff katılımcıyı girişe alır: Geçerli QR kodunu taradığımda, katılımcı “checked in” olarak işaretlenir, zaman damgası atanır ve aynı QR başka bir yerde kullanılamaz (ta ki override izni olan biri müdahale edene kadar).

Erken planlanması gereken kenar durumlar

Sonradan yamalarla uğraşmamak için bunları baştan planlayın: tükendi, tekrarlı siparişler, kısmi iadeler, chargeback, iptal/yeniden planlanan etkinlikler, başarısız e-posta teslimi, çevrimdışı check-in ve transfer/posta değişimi.

İş akışı başına saklanması gereken veriler

En azından: etkinlik durumu ve kapasite, bilet türü kuralları (limitler, pencereler), sipariş/ödeme durumu, katılımcı kimlik alanları, QR kod/token ve eklemeye dayalı bir check-in kayıt defteri (kim kimde, ne zaman, hangi cihazla check-in yaptı). Bu "kağıt izi" anlaşmazlıklarda çok önemli olur.

Etkinlikler, Biletler, Siparişler ve Katılımcılar için Veri Modeli

Temiz bir veri modeli, evrimi kolay bir biletleme platformu ile sürekli geçiş yollarına ihtiyaç duyan bir kayıt sistemi arasındaki farktır. Önce saklayacağınız “nesneleri” (etkinlikler, bilet türleri, siparişler, katılımcılar) ve bunların ilişkilerini tanımlayın.

Etkinlik: gerçek bilgi kaynağı

Bir Event zamanlama, limitler ve yayınlama ile ilgili olmalı:

• Temel: title, description, organizer_id
• Tarihler: start_at, end_at, timezone (zaman damgalarını UTC olarak saklayın, gösterimi etkinlik zaman dilimini kullanarak yapın)
• Mekan: venue_name, address, city, country (veya tekrar kullanılacaksa ayrı bir Venue tablosu)
• Kapasite: total_capacity (ve isteğe bağlı olarak bilet başına caps)
• Durum: draft, published, canceled, ended

Bu yapı, taslak etkinlikleri gizleme, kapasite dolduğunda satışları kapatma ve doğru yerel saatleri gösterme gibi ortak ihtiyaçları destekler.

Bilet türleri: ne satılıyor

Bir TicketType teklifi tanımlar:

• name, description, price, currency
• quantity_available (ve quantity_sold)
• sales_window: sales_start_at, sales_end_at
• vergiler/ücretler: tax_rate (veya tax_id), fee_flat/fee_percent, “fees_included” flag
• eklentiler: ayrı TicketTypes veya TicketType ile ilişkili bir AddOn tablosu olarak modellenebilir
• indirim kodları: DiscountCode tablosu (code, type percent/fixed, amount, usage_limit, valid window) Event'e ve isteğe bağlı olarak belirli TicketType'lara bağlanır

Siparişler ve ödemeler: finansal olaylar

Ticareti iki katmana ayırın:

• Order: order_number, event_id, buyer_email, subtotal, taxes, fees, total, order_status (pending/confirmed/canceled)
• Payment: provider (Stripe, vs.), provider_payment_id, payment_status (requires_action/paid/failed/refunded), amount, captured_at

İadeler ayrı kayıtlar (Refund tablosu) olarak tutmak, kısmi iadeler ve temiz bir denetim izi için en iyisidir. Fatura/makbuz alanlarını (billing_name, billing_address, vat_id) Order üzerinde saklayın.

Katılımcılar: bilet sahipleri

Bir Attendee (veya TicketInstance) şunları içermeli:

• event_id, ticket_type_id, order_id
• katılımcı alanları (isim, e-posta, özel form yanıtları)
• bilet atama + transfer: assigned_to_email, transfer_token, transferred_at
• check-in: check_in_state (not_checked_in/checked_in), checked_in_at, checked_in_by
• personel için etiketler/notlar (VIP, erişilebilirlik talepleri gibi)

İçe/dışa aktarmalar ve operasyonel alanlar

CSV dışa aktarmalarını erken planlayın: tutarlı alan adları (order_number, ticket_type, attendee_name, checked_in_at) kullanın ve rozet basma alanlarını dahil edin.

İleride entegrasyon bekliyorsanız, admin panelinin güvenli şekilde dışa bildirim tetiklemesini sağlamak için hafif bir “webhook events” veya outbox tablosu ekleyin.

Teknoloji Yığını ve Mimari Kararlar

En iyi “yığın”, takımınızın sorunsuzca inşa edip, yayınlayıp ve destekleyebildiği yığıntır. Etkinlik yönetimi uygulamaları için yineleme hızı teorik mükemmellikten daha önemlidir—özellikle gerçek trafik desenlerini bilmeden önce.

Basit başlayın: önce monolit

Tek kod tabanı (monolit) genellikle doğru başlangıçtır. Dağıtım, hata ayıklama ve veri erişimini basit tutar—bilet türleri, promosyon kodları ve organizer iş akışlarını doğrularken önemlidir.

Ayırma yapma gerekçeniz olduğunda (bağımsız ölçeklenme, ekiplerin çakışması veya riskli dağıtımlar) servislere bölün. O zamana kadar monolit içinde modülerleştirme (klasör/paket ayrımı) genellikle yeterlidir.

Pratik bir yığın seçin

Yaygın ve denenmiş bir kombinasyon şöyle görünebilir:

• Frontend: React (Next.js) veya Vue (Nuxt) — hızlı UI geliştirme ve SEO dostu etkinlik sayfaları için.
• Backend: Node.js (NestJS/Express) veya Python (Django/FastAPI). Takımınızın zaten bildiğini seçin.
• Veritabanı: PostgreSQL — ilişkisel veri (etkinlikler, siparişler, katılımcılar) ve güvenli işlemler için.
• Barındırma: Yönetilen platform (Render/Fly.io/Heroku tarzı) veya bulut PaaS. Yönetilen veritabanları değer katar.

Trend olduğu için araç seçmekten kaçının. "Sıkıcı" seçenek genellikle çağrı alındığında kazanır.

Koder.ai ile uygulamayı hızlandırma (isteğe bağlı)

MVP'yi (etkinlik kurulumu, checkout, bilet verme, QR check-in ve dışa aktarma) hızlı yayınlamak önceliğinizse, sohbet odaklı bir yapım süreci sunan Koder.ai gibi bir platform, tasarımdan çalışan bir uygulamaya hızla geçmenize yardımcı olabilir.

Koder.ai bu tür bir ürüne uygundur çünkü varsayılan yığını tipik biletleme ihtiyaçlarına iyi uyar—frontend'de React, backend'de Go + PostgreSQL—ve Planning Mode, snapshots/rollback, source code export gibi özelliklerle sürümlerde güvenle yineleme yapmanızı sağlar.

Depolama ve e-posta: birinci sınıf bağımlılıklar olarak ele alın

Etkinlik görselleri, oluşturulan faturalar ve PDF biletler gibi varlıkları nerede saklayacağınızı planlayın:

• Obje depolama (S3 uyumlu) yüklemeler ve oluşturulan dosyalar için.
• Gerektiğinde daha hızlı küresel dağıtım için bir CDN.

E-posta onayları ve hatırlatmaları için SendGrid, Postmark, SES gibi özel bir sağlayıcı kullanın. Teslimat başarı oranını artırır ve katılımcıların “biletimi almadım” dediklerinde log sağlar.

Ortamlar ve anahtarlar

local, staging ve production ortamlarını erken kurun; her biri için ayrı:

• Ödeme anahtarları, e-posta kimlik bilgileri ve webhook sırları
• Veritabanları (prod verisini dev'e kopyalamayın)
• Base URL ve callback URL

Bu, kazara ücretlendirmeleri ve gerçek testlerin yanlış ortamda çalışmasını engeller.

Standartlar ve sürümler

Biçimlendirme (Prettier/Black), linting, commit konvansiyonları ve basit bir release akışı (özellik dalları + kod incelemesi + CI kontrolleri) üzerinde anlaşın. Küçük disiplinler, checkout ve bilet teslimindeki hataları azaltır—hataların en pahalı olduğu yerler bunlardır.

UX ve UI: Kayıt, Checkout ve Organizer Panosu

İyi bir UX, belirsizliği azaltmaktır: katılımcılar ne satın aldıklarını bilmek ister, düzenleyiciler ise satışların ve check-in'lerin kontrol altında olduğuna güvenmek ister.

Katılımcı akışı (tahmin edilebilir tutun)

Basit, tekrarlanabilir bir yol tasarlayın: etkinlik sayfası → bilet seçimi → checkout → onay. Her adım bir soruyu yanıtlamalı:

• Etkinlik sayfası: “Bu benim için doğru etkinlik mi?”
• Bilet seçimi: “Hangi bileti almalıyım ve halen mevcut mu?”
• Checkout: “Hızlı ve güvenli ödeyebilir miyim?”
• Onay: “Sonraki adım ne ve nasıl girerim?”

Bilet seçimi aşamasında uygunluk ve kuralları açık gösterin. Kalan biletleri, satış başlangıç/bitiş zamanlarını (açık zaman dilimleriyle) ve biletler tükendiğinde ne olacağını (bekleme listesi, satış yok veya organizatöre ulaş) gösterin.

Promosyon kodlarını destekliyorsanız, alanı gizlemeyin ama ana eylemlerle aynı görsel ağırlıkta yapmayın.

Formlar: varsayılan olarak kısa, gerektiğinde detaylı

Checkout sürtünmesi kayıt düşüşlerinin kaynağıdır. İlk formu minimum tutun (isim, e-posta, ödeme) ve ek soruları aşamalı açıklama ile gösterin.

İyi çalışan örnekler:

• “Fatura almanız gerekiyor mu?” sorusu → evet ise fatura alanlarını göster
• “Başkasına mı alıyorsunuz?” → her bilet için katılımcı detaylarını aç
• “Herhangi bir erişilebilirlik ihtiyacı?” → kısa yardımcı satırla isteğe bağlı

Birden fazla bilet satıldığında, alıcı bilgilerini (makbuz, ödeme) ve katılımcı bilgilerini (isimler, check-in) net ayırın.

Destek taleplerini azaltan onay

Ödemeden sonra onay; etkinlik bilgilerini, bilet özetini, QR kod erişimini (veya “biletler eklendi” notunu) ve net bir sonraki adımı içermelidir (“Takvime ekle”, “Siparişimi yönet”). /orders/{id} gibi hafif bir sipariş yönetim sayfasına yönlendirme ekleyin.

Organizer panosu: bir bakışta cevap verin

Organizer'lar genellikle panoyu açtıklarında üç rakama bakar: satılan bilet, gelir ve check-inler. Bunları üstte koyun, ardından hızlı filtreler (tarih, bilet türü, durum, iade) ekleyin.

Check-in personeli için mobil öncelikli arayüz zorunludur: büyük dokunmatik hedefler, yüksek kontrast ve belirgin bir “Tarama” / “Katılımcı ara” anahtarı. Kapıda yavaş ya da sıkışık bir arayüz sıra oluşturur.

Hesaplar, Roller ve İzinler

Biletleme uygulaması hızla paylaşılan bir çalışma alanı haline gelir: düzenleyiciler etkinlik oluşturur, finans ekipleri iadelerle ilgilenir ve kapı personeli sadece tarama yapmak ister. Açık hesaplar ve izinler deneyimi sorunsuz tutar—ve mali hataları azaltır.

Güvenli ve basit kimlik doğrulama

Organizer ve staff girişleri için e-posta + parola desteği sağlayın; gerekiyorsa MFA opsiyonel olarak sunun.

Parola sıfırlamalarda parolayı e-posta ile göndermeyin. 15–60 dakika gibi zaman sınırlı tek kullanımlık sıfırlama bağlantıları kullanın, parolaları sadece hashlenmiş şekilde saklayın ve sıfırlama tokenlarını kullanımdan sonra geçersiz kılın. Giriş, sıfırlama ve “ticket resend” gibi işlemlere oran sınırlaması ve “aynı yanıt” mesajlaşması ekleyin ki saldırganlar bir e-postanın var olup olmadığını tahmin edemesin.

Rol tabanlı erişim kontrolü (RBAC)

Rolleri tanımlayın, sonra bunları etkinlik düzeyinde uygulayın. Birçok ekip birden çok etkinlik yönetir; bir kullanıcı bir etkinlikte “finance” iken diğerinde “viewer” olabilir.

Yaygın izin kümeleri:

• View: katılımcıları, siparişleri ve temel raporları salt okunur görme
• Edit: etkinlik detaylarını, bilet türlerini, komps’u ve katılımcı düzenlemelerini yönetme
• Finance: iadeler, ödemeler, vergi ayarları ve ödeme ile ilgili dışa aktarmalar

İzinleri order.refund, attendee.update gibi açık olarak tanımlayın; belirsiz “admin” mantığına bağlı kalmayın.

Check-in personeli (mobil-dostu, sınırlı erişim)

Ayrı bir Check-in rolü oluşturun; bu rol şunları yapabilmeli:

• QR kod tarama
• isim/e-posta ile katılımcı arama
• katılımı işaretleme ve kurallar içinde geri alma

Ancak gelir görme, iade verme veya bilet fiyatlarını düzenleme yetkisi olmamalı. Böylece geçici personele telefon verildiğinde güvenli olur.

Hassas işlemler için denetim kayıtları

İade, komps verme, katılımcı bilgisi değiştirme veya katılımcı listesi dışa aktarma gibi eylemler için kim, ne ve ne zaman yaptığını kaydedin. Kayıtlarda etkinlik ID, işlem yapan hesap, zaman damgası ve önce/sonra değerler olsun. Denetim kayıtları anlaşmazlıklarda ekibinizi korur ve destek işini kolaylaştırır.

Ödemeler, Bilet Verme ve QR Kodları

Ödemeler uygulamayı “gerçek” kıldığı yerdir: para hareket eder, beklentiler yükselir ve hatalar pahalı olur. Checkout ve bilet verme tek, sıkı kontrol edilen bir iş akışı olarak ele alınmalı ve net durum izleriyle desteklenmelidir.

Bir ödeme sağlayıcısı seçin (kart verisini saklamayın)

Webhook ve iade destekleyen bir sağlayıcı kullanın (örn. Stripe, Adyen, PayPal). Veritabanınız asla ham kart numarası veya CVV saklamamalı. Bunun yerine sadece sağlayıcının ürettiği referansları saklayın, örn:

• payment_intent_id / charge_id
• customer_id (opsiyonel)
• receipt_url (opsiyonel)

Bu, sistemi basitleştirir ve uyumluluk riskini düşürür.

Checkout'u bir durum makinesi olarak modelleyin

Sipariş/ödeme durumlarını baştan tanımlayın ki destek, raporlama ve e-postalar tutarlı olsun. Yaygın durumlar:

• pending (sipariş oluşturuldu, ödeme onayı bekleniyor)
• paid (sağlayıcı ödemeyi onayladı; biletler verilebilir)
• failed (ödeme reddedildi)
• expired (checkout oturumu zaman aşımına uğradı)
• refunded ve partially_refunded (iade edilen miktarı ve nedeni takip edin)

Sağlayıcı webhooks'larını “paid” ve “refunded” geçişleri için kaynak olarak kullanın ve izlenebilirlik için değiştirilemez bir event logu (ör. order_events tablosu) tutun.

Biletleri verin: benzersiz kodlar + QR kodlar

Biletleri sadece bir sipariş paid durumuna geldiğinde (veya organizatör açıkça komps verdiğinde) oluşturun. Her bilet kaydına bağlı benzersiz bir bilet kodu yaratın ve bu tanımlayıcıyı bir QR kod içinde kodlayın.

Pratik kural: QR veri yükü kendi başına anlamlı olmamalı (ör. rastgele bir token veya imzalanmış bir string) ve sunucu giriş onayını doğrulamalı.

İndirimler, ücretsiz biletler ve komps

İndirim kodlarını geçerlilik penceresi, kullanım limitleri, uygun bilet türleri ve yığılma kuralları gibi açık kurallarla uygulayın. Ücretsiz biletler ve komps yine de bir sipariş kaydı (total = 0) oluşturmalı ki raporlama ve katılımcı geçmişi doğru kalsın.

Makbuzlar ve onaylar için tek gerçek kaynak

Makbuz ve onay e-postalarını sipariş kaydına dayanarak gönderin, UI “başarılı” ekranlarına değil. Ödeme onaylandıktan sonra sistem biletleri oluşturmalı, kalıcı hale getirmeli ve biletleri gösteren e-postayı (ör. /orders/{id} görünümüne yönlendiren) göndermelidir.

E-posta Bildirimleri ve İletişim

E-posta, kayıt sisteminizin omurgasıdır: alıcıları güvenceye alır, biletleri teslim eder ve destek taleplerini azaltır. Bunu bir ürün özelliği olarak ele alın, sonradan düşünülmüş bir şey gibi değil.

Temel şablonlar (ve içermeleri gerekenler)

İlk etapta birkaç transactional şablonla başlayın:

• Sipariş onayı: etkinlik adı, tarih/saat, mekan (veya “çevrimiçi”), sipariş özeti, ödeme durumu ve net “Siparişi görüntüle” çağrısı.
• Bilet teslimi: her bilet/katılımcı adı, bilet türü, QR kodu (veya güvenli check-in linki) ve temel check-in talimatları.
• Hatırlatmalar: önemli lojistik (kapı açılış, park/giriş kuralları) ve biletleri tekrar alma yolu.
• İade/iptal bildirimi: iade edilen öğeler, tutar, zaman çizelgesi ve organizatör ile iletişim bilgisi.

Konu satırlarını spesifik tutun (“{EventName} için biletleriniz”) ve teslimatı etkileyebilecek ağır pazarlama dilinden kaçının.

Organizör marka erişimi ve teslimat güvenliği

Organizatörlerin logo, vurgu rengi ve kısa bir footer eklemesine izin verin; ancak tutarlı bir HTML yapı kullanın ve “brand slot”larla sınırlayın. Tamamen özel HTML yerine sabit bir düzen kullanmak kırık render ve spam sinyallerini azaltır.

Gönderen adresini [email protected] gibi sabit bir adreste tutun ve organizatör için “Reply-To” kullanın (veya doğrulanmış bir gönderici kimliği). Bu, alıcıya tanıdık bir gönderen sunar ve konuşma başlamasına izin verir.

Takip ve destek dostu araçlar

En azından her mesaj için durum saklayın: queued, sent, delivered (sağlayıcı bildiriyorsa), bounced, complaint. Bu, organizatöre zaman çizelgesi sağlar ve destek ekibinin sorunları hızlıca teşhis etmesine yardımcı olur.

Organizer panosunda iki kritik self-servis aksiyon ekleyin:

1. Biletleri yeniden gönder (oran sınırlamaları ve denetim kaydı ile).
2. Katılımcı e-postasını güncelle ve teslimi yeniden yap—orijinal ödeme/sipariş kaydını değiştirmeden.

Opsiyonel SMS (izin bazlı)

SMS sadece net bir ihtiyaç varsa ekleyin (ör. son dakika mekan değişiklikleri). İzin bazlı yapın, her katılımcıdan rıza alın ve mesajları sadece bilgilendirici, kısa tutup kolay bir vazgeçme yolu sunun.

Sahada Check-In ve Katılımcı Arama

Sahadaki check-in akışı uygulamanızın saniyeler içinde değerlendirildiği yerdir. Personel anında yüklenen, kalabalık mekanlarda çalışan ve tek soruyu yanıtlayan bir ekran ister: “Bu kişi içeri alınabilir mi?”

Hızlı bir check-in ekranı

Organizer panosundan ayrı, özel bir “Check-In” görünümü tasarlayın. Hız ve büyük dokunmatik hedefleri önceliklendirin.

İki giriş modu bulundurun:

• Arama: isim, e-posta, sipariş numarası veya bilet kodu ile; yazarken sonuç gösterme.
• QR tarama: cihaz kamerasını kullanarak doğrudan bir ticket/attendee kaydına çözümleme.

Çevrimdışı çalışabilmesi için belirli bir etkinliğin katılımcı listesini (giriş için gerekli minimum veriyle) cihazda önbelleğe alın. Bağlantı kesilse bile uygulama yerelde bilet doğrulayabilir ve senkronize edilmek üzere değişiklikleri kuyruğa alır.

Çifte girişin önlenmesi (kontrollü override ile)

Her biletin net bir durumu olmalı: Not checked in → Checked in. Zaten kullanılmış bir bileti tarayınca belirgin bir uyarı gösterin; zaman damgası ve personel bilgisi varsa gösterin.

Override yalnızca belirli izne sahip kullanıcılar için açık olsun (örn. “Check-in manager”). Override gerekçesi için bir not zorunlu kılın ki anlaşmazlıklar sonra çözülebilsin.

Grup siparişleri ve kısmi check-in desteği

Bir siparişte birden fazla bilet varsa, birer birer check-in yapılabilmeli. UI kalan biletleri ve bilet türlerini (örn. “4 biletten 2'si giriş yaptı”) göstermeli. Bu, gruplar ayrı ayrı geldiğinde tümünün aynı anda girilmesini zorunlu kılmaz.

Yararlı bağlam gösterin

Tarama/arama anında gösterilecekler:

• Bilet türü ve erişim seviyesi (VIP, atölye eklentisi)
• Katılımcı notları (diyet, özel talimatlar)
• Erişilebilirlik ihtiyaçları (sadece toplandıysa, ve az tutun)

Her check-in'i kaydedin

Bir check-in olay kaydı tutun (tarama/arama, cihaz/kullanıcı, zaman, sonuç, override nedeni). Bu loglar sonrası raporlama ve anlaşmazlıklarda kullanılır.

Raporlama, Dışa Aktarma ve Yönetici Araçları

İyi raporlama, uygulamanızı “bilet satılan bir yer”den planlama, etkinlik günü ve sonrası için güvenilir bir araca dönüştürür.

Organizer'ların beklediği raporlar

Küçük, yüksek güvenilirlikte rapor setiyle başlayın:

• Bilet türüne göre satış: satılan birimler, kalan (limitliyse), brüt vs net.
• Gelir dökümü: ara toplam, indirimler, ücretler, vergiler ve ödeme çıktıları.
• Sipariş durumu: paid, pending, canceled, refunded, chargeback (uygunsa).
• Katılım oranı: check-in yapanlar vs verilen biletler, bilet türüne göre ayrım.

Sayıları sipariş makbuzları ve ödeme özetleriyle tutarlı tutun.

Filtreler ve işe yarar dışa aktarmalar

Raporları daha değerli kılmak için birkaç standart filtre ekleyin:

• Tarih aralığı (sipariş oluşturma, ödeme tarihi veya check-in zamanı)
• Bilet türü
• Sipariş/katılımcı durumu (paid/refunded, checked-in/not)

CSV (ve isteğe bağlı XLSX) formatında dışa aktarma sunun. Her dışa aktarmada ne olduğunu açıkça belirtin: order ID, alıcı bilgileri, katılımcı bilgileri, bilet türü, fiyat, vergiler/ücretler, indirim kodları ve check-in zamanları.

Ayrıca dışa aktarımların KİŞİSEL VERİ içerip içermediğini açıklayın ve partnerlerle paylaşmak için “minimal” dışa aktarma seçeneği sunun.

Funnel metrikleri (hafif, yüksek etki)

Etkinlik başına basit bir funnel izleyin: etkinlik sayfası görüntüleri → checkout başlatıldı → ödeme tamamlandı. Temel sayılar bile organizer'ların sorunları fark etmesine yardımcı olur (örn. çok fazla checkout başlatma ama az ödeme).

Destek ve operasyon için yönetici araçları

İç yönetici panelinizi hız odaklı yapın:

• Sipariş ID, alıcı e-posta, katılımcı adı veya son 4 rakam ile arama
• Tam sipariş zaman çizelgesini görüntüleme (oluşturuldu, ödendi, e-postalar gönderildi, iadeler)
• Onay e-postasını yeniden gönder ve biletleri yeniden çıkar
• Ödeme sağlayıcıdan iade başlatma ve sonucu kaydetme

Veri saklama ve dışa aktarma politikası

Siparişler, katılımcı kayıtları ve logların ne kadar süre saklandığını ve saklama süresi dolduktan sonra ne olduğunu belgeleyin. Bunu yardım dökümanlarınızda görünür kılın (örn. /help/data-retention) ve dışa aktarma diyaloglarında belirtin ki organizer'lar ne indirdiklerini ve ne sakladıklarını bilsinler.

Güvenlik, Gizlilik ve Güvenilirlik Temelleri

Güvenlik ve güvenilirlik biletleme uygulamaları için “sonra” işi değildir. İsimler, e-postalar ve çoğunlukla ödeme ile ilgili meta veriler saklanır—bu yüzden bazı temel seçimleri erken yapmak, sancılı yeniden yazımları önler.

Katılımcı verilerini koruyun (en az ayrıcalık + şifreleme)

En az ayrıcalık ilkesiyle başlayın: organizatörler sadece sahip oldukları etkinlikleri görmeli, personel yalnızca check-in için gerekenleri görmeli ve adminler sıkı sınırlandırılmalı. Bu kontrolleri arka uçta (sadece gizli UI değil) uygulayın.

HTTPS ile veri aktarımını her yerde zorunlu kılın; webhook ve dahili servisler dahil. Sırlar (API anahtarları, webhook imzalama sırları, veritabanı kimlik bilgileri) yönetilen bir secret store veya bulut sağlayıcısının secret manager'ında saklanmalı—asla repoya koymayın.

Girdi doğrulama ve yaygın saldırıları engelleme

Her alanı güvensiz kabul edin: etkinlik açıklamaları, katılımcı isimleri, özel sorular ve kupon kodları dahil.

• Parametreli sorgular/ORM korumaları ile injection'ı engelleyin.
• Kullanıcı tarafından oluşturulan içeriği kaçırarak XSS'i önleyin ve sıkı bir Content Security Policy uygulayın.
• Durum değiştirici isteklerde CSRF koruması uygulayın (özellikle cookie kullanıyorsanız).
• Giriş, parola sıfırlama ve “bilet yeniden gönder” gibi işlemlere oran sınırlaması ekleyin.

Kullanıcılara açıklayabileceğiniz gizlilik temelleri

Sadece gerekeni toplayın (örn. bir bilet için isim ve e-posta) ve isteğe bağlı alanları açıkça etiketleyin. "Transactional" e-postaları (makbuz, bilet, program değişiklikleri) pazarlamadan ayırın.

Pazarlama izinleri alıyorsanız, açık rızayı saklayın ve kolay abonelikten çıkma bağlantısı sağlayın.

Gerçek test edilmiş yedeklemeler + kurtarma

Yedeklemeler gerçekse kurtarmaları da çalışır. Veritabanı yedeklerini otomatikleştirin, farklı saklama pencereleri tutun ve restore testlerini staging ortamına planlı olarak yapın.

Basit bir kurtarma kontrol listesi yazın: kim restore eder, nereye restore edilir ve check-in taramalarının hala çalıştığını nasıl doğrularız.

Sorunları erken yakalayan izleme

Backend ve frontend için hata takibi, ana uç noktalar (checkout, webhook handler, check-in API) için uptime kontrolleri ve yavaş sorgular için uyarılar ekleyin. Az ama eyleme geçirilebilir uyarı, gürültülü panolardan iyidir.

Test, Lansman ve İterasyon Planı

Test ve lansman, biletleme uygulamalarının güvenini kazandığı aşamalardır. Checkout veya QR doğrulamada küçük bir hata sadece kullanıcıyı rahatsız etmez—kapıda insanları engelleyebilir. Bu aşamayı ürünün bir parçası olarak görün.

Kritik yollar için otomatik testler

Parayı ve giriş hakkını doğrudan etkileyen akışlara odaklanın. Testleri yüksek değerli ve tekrarlanabilir tutun:

• Checkout: başarılı ödeme, iptal edilen ödeme, başarısız ödeme, promosyon kodu kenar durumları.
• Bilet verme: satın alma başına bir bilet oluşturma, doğru bilet türü, e-posta gönderimi, PDF/PKPass linkinin geçerliliği (destekliyorsanız).
• Check-in: QR tarama geçerli bileti kabul eder, zaten kullanılmış bileti reddeder, çevrimdışı/gecikme durumlarını düzgün yönetir.
• İadeler/iptaller: durum güncellemeleri, bilet geçersizleştirme, e-postalar ve denetim kayıtları.

Ödeme sağlayıcınızın webhook'ları etrafında birkaç “contract test” ekleyin ki payload değişiklikleri sessizce sipariş durumunu bozmasın.

Kamuya açılmadan önce staging pilotu

Küçük bir etkinlikle pilot yürütün (hatta dahili bir meetup). Organizörlere ve kapı personeline staging uygulamasını gerçek prova için verin: etkinlik oluştur, birkaç bilet sat, insanları tara, iade yap, biletleri yeniden gönder.

Geri bildirimi basit bir formda toplayın ve personelin duraksadığı noktaları kaydedin—buralar öncelikli UI düzeltmeleridir.

Lansman kontrol listesi ve operasyonel hazır bulunuşluk

Canlıya geçmeden önce doğrulayın:

• Domain + SSL, yönlendirme kuralları, hata sayfaları
• E-posta gönderen ayarları (SPF/DKIM/DMARC) ve teslimat kontrolleri
• Canlı ödeme anahtarları ve webhook uç noktaları
• Loglama, uyarılar ve başarısız işler için inceleme yolu (e-posta gönderimi, bilet üretimi)

Destek iş akışları ve yineleme

Uyuşmazlıklar, iadeler ve bilet yeniden gönderme talepleri için hazır cevaplar ve dahili adımlar hazırlayın.

Lansmandan sonra küçük parçalar halinde yineleyin—bekleme listeleri, oturma, entegrasyonlar (CRM/e-posta) ve çoklu etkinlik hesapları—gerçek destek biletleri ve organizatör geri bildirimleriyle yönlendirin.