Kayıtları, bilet satışlarını, katılımcıları, e-postaları ve giriş işlemlerini yönetmeye yardımcı bir web uygulamasını planlama, tasarlama ve yayına alma konusunda pratik bir rehber.

Ö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.
Öncelikle birincil müşterinizi isimlendirin; çünkü her tip farklı çıktılara odaklanır:
Ç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.”
Ü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.
İş akışlarına bağlı birkaç ölçülebilir sonuç seçin:
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.
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.
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.
İlk etapta basit tutun, sonra genişletin:
Pratik bir kural: biri para ile ilgili alanları veya etkinlik görünürlüğünü değiştirebiliyorsa, bunun ayrı bir izin olması gerekir.
Çekirdek navigasyonu erken taslaklayın ki özellikler rastgele uç noktalara dönüşmesin:
Bir oturuşta doğrulayabileceğiniz kısa hikâyeler yazın:
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.
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.
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.
Bir Event zamanlama, limitler ve yayınlama ile ilgili olmalı:
Bu yapı, taslak etkinlikleri gizleme, kapasite dolduğunda satışları kapatma ve doğru yerel saatleri gösterme gibi ortak ihtiyaçları destekler.
Bir TicketType teklifi tanımlar:
Ticareti iki katmana ayırın:
İ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.
Bir Attendee (veya TicketInstance) şunları içermeli:
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.
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.
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.
Yaygın ve denenmiş bir kombinasyon şöyle görünebilir:
Trend olduğu için araç seçmekten kaçının. "Sıkıcı" seçenek genellikle çağrı alındığında kazanır.
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.
Etkinlik görselleri, oluşturulan faturalar ve PDF biletler gibi varlıkları nerede saklayacağınızı planlayın:
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.
local, staging ve production ortamlarını erken kurun; her biri için ayrı:
Bu, kazara ücretlendirmeleri ve gerçek testlerin yanlış ortamda çalışmasını engeller.
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.
İ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.
Basit, tekrarlanabilir bir yol tasarlayın: etkinlik sayfası → bilet seçimi → checkout → onay. Her adım bir soruyu yanıtlamalı:
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.
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:
Birden fazla bilet satıldığında, alıcı bilgilerini (makbuz, ödeme) ve katılımcı bilgilerini (isimler, check-in) net ayırın.
Ö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'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.
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.
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.
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:
İzinleri order.refund, attendee.update gibi açık olarak tanımlayın; belirsiz “admin” mantığına bağlı kalmayın.
Ayrı bir Check-in rolü oluşturun; bu rol şunları yapabilmeli:
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.
İ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 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.
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_idcustomer_id (opsiyonel)receipt_url (opsiyonel)Bu, sistemi basitleştirir ve uyumluluk riskini düşürür.
Sipariş/ödeme durumlarını baştan tanımlayın ki destek, raporlama ve e-postalar tutarlı olsun. Yaygın durumlar:
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 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ı.
İ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.
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, 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.
İlk etapta birkaç transactional şablonla başlayın:
Konu satırlarını spesifik tutun (“{EventName} için biletleriniz”) ve teslimatı etkileyebilecek ağır pazarlama dilinden kaçının.
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.
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:
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.
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?”
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:
Ç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.
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.
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.
Tarama/arama anında gösterilecekler:
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.
İ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.
Küçük, yüksek güvenilirlikte rapor setiyle başlayın:
Sayıları sipariş makbuzları ve ödeme özetleriyle tutarlı tutun.
Raporları daha değerli kılmak için birkaç standart filtre ekleyin:
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.
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).
İç yönetici panelinizi hız odaklı yapın:
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 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.
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.
Her alanı güvensiz kabul edin: etkinlik açıklamaları, katılımcı isimleri, özel sorular ve kupon kodları dahil.
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.
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.
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 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.
Parayı ve giriş hakkını doğrudan etkileyen akışlara odaklanın. Testleri yüksek değerli ve tekrarlanabilir tutun:
Ö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.
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.
Canlıya geçmeden önce doğrulayın:
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.