Uçak bileti yazılımı nasıl seçilir? Acenteler için 12 kriterlik kontrol listesi

Uçak bileti yazılımı seçimi çoğu acentede bir demo toplantısıyla başlar ve özellik listelerinin karşılaştırılmasıyla biter. Oysa iki yazılımın arama ekranı birbirine çok benzeyebilir; asıl fark satış sonrası işlemlerde, tedarikçi bağlantılarının derinliğinde, fiyatlandırma esnekliğinde ve yazılımın sizin satış modelinize uyumunda ortaya çıkar. Bu rehberde bir acentenin uçak bileti yazılımı seçerken sorması gereken 12 kriteri, her kriterin nasıl doğrulanacağını ve değerlendirme sürecini adım adım anlatıyoruz. Kriterler belirli bir ürüne göre değil, acente operasyonunun ihtiyaçlarına göre sıralanmıştır.

Uçak bileti yazılımı seçmeden önce neyi bilmelisiniz?

Uçak bileti yazılımı seçmeden önce bilmeniz gereken ilk şey, yazılımın bilet kesme yetkisi vermediğidir: bu yetki IATA akreditasyonundan veya bir konsolidatörle yapılan anlaşmadan gelir. Yazılım, sahip olduğunuz yetkiyi ve tedarikçi anlaşmalarını satışa dönüştüren altyapıdır.

Bu nedenle seçim sürecinden önce üç soruyu cevaplamak gerekir. Birincisi yasal altyapı: Türkiye'de bilet satışı için seyahat acentası işletme belgesi ve TÜRSAB üyeliği gerekir. İkincisi bilet kesme yetkisi: IATA'lı mısınız, yoksa bir konsolidatör üzerinden mi keseceksiniz? Üçüncüsü tedarikçi anlaşmaları: hangi GDS, havayolu veya konsolidatörle çalışıyorsunuz ya da çalışmayı planlıyorsunuz? Bu soruların cevapları yazılımın hangi bağlantıları sunması gerektiğini belirler. Ayrıntılar için uçak bileti satmak için ne gerekir ve IATA olmadan uçak bileti satışı rehberlerine bakabilirsiniz.

Uçak bileti yazılımı seçerken hangi 12 kriter değerlendirilmeli?

Uçak bileti yazılımı seçerken satış kanalları, içerik ve entegrasyonlar, arama ve satış akışı, satış sonrası işlemler, fiyatlandırma, alt acente yönetimi, ödeme ve güvenlik, muhasebe, B2C ve SEO, operasyon araçları, açıklık ve API ile mülkiyet modeli olmak üzere 12 kriter değerlendirilmelidir. Aşağıdaki tablo her kriter için sorulacak soruyu ve doğrulama yolunu özetler.

Satış kanalları ve içerik neden ilk sıradadır?

Satış kanalları ve içerik ilk sıradadır, çünkü yazılımın kimlere ve hangi uçuşları satabileceğini belirler; diğer tüm kriterler bu iki sorunun üzerine kurulur. Yanlış kanal kapsamı veya eksik içerik, sonradan özellik eklenerek kolayca kapatılamaz.

Kanal tarafında temel soru, B2B portal, B2C satış sitesi ve kurumsal portalın aynı rezervasyon motorunu kullanıp kullanmadığıdır. Ortak motor; tedarikçiyi bir kez bağlayıp her kanalda satmayı, kanal bazında farklı kâr uygulamayı ve tüm rezervasyonları tek yerde yönetmeyi sağlar.

İçerik tarafında GDS'ler geniş kapsam, havayolu NDC bağlantıları ise paket ve ek hizmet zenginliği sunar. NDC, IATA'nın geliştirdiği ve havayolunun teklifini ve siparişini doğrudan acente sistemine taşıyan bir dağıtım standardıdır; paketler ve ek hizmetler bu yolla daha zengin gelir. Türkiye pazarında THY, Pegasus ve AJet'in doğrudan bağlantıları bu nedenle önemlidir. Bağlantıların listesine bakarken yalnızca isimleri değil, her bağlantıda hangi işlemlerin desteklendiğini sorun. Karşılaştırma için GDS mi NDC mi rehberine bakabilirsiniz.

Satış sonrası işlemler nasıl değerlendirilir?

Satış sonrası işlemler, her tedarikçi için void, iade, kısmi iptal, değişiklik (reissue) ve tarife değişikliğinin yazılım içinden otomatik mi yoksa operasyon ekibi üzerinden manuel mi yürüdüğü sorularak değerlendirilir. Bu tablo, acentenin kaç operasyon personeline ihtiyaç duyacağını doğrudan belirler.

Demoda yalnızca "iade yapılabiliyor mu" diye sormak yeterli değildir. Aynı yazılımda bir NDC bağlantısında iade otomatik yürürken bir GDS bağlantısında bilet sonrası iptal operasyon kuyruğuna düşebilir. Bu fark bir kusur değil, bağlantının yeteneğidir; önemli olan bunun önceden bilinmesi ve manuel işlemlerin kaybolmadan bir kuyrukta toplanmasıdır. İade ve değişiklik süreçlerinin ayrıntısı için uçak bileti iade süreci rehberine bakabilirsiniz.

Fiyatlandırma ve alt acente yönetiminde nelere bakılmalı?

Fiyatlandırmada markup kurallarının hangi kriterlerle tanımlanabildiğine ve kârın rezervasyon, yolcu, bilet veya bacak başına uygulanıp uygulanamadığına; alt acente yönetiminde ise kredi limiti, katmanlı kâr görünürlüğü ve tedarikçi bazında yetkilendirmeye bakılmalıdır. Kâr marjı bu ayarların esnekliğiyle korunur.

Değerlendirmede şu senaryoları demoda denemenizi öneririz: belirli bir havayoluna dış hatlarda farklı kâr tanımlamak, B2C kanalına B2B'den farklı kâr uygulamak, bir alt acenteye kredi limiti vermek ve bir konsolidatör hesabını yalnızca belirli alt acentelere açmak. Alt acentenin ana acentenin kârını görmemesi de sorulması gereken bir güvenlik ve ticari gizlilik konusudur.

Ödeme, güvenlik ve KVKK nasıl kontrol edilir?

Ödeme tarafında desteklenen sanal POS'lar, 3D Secure, kart BIN'ine göre taksit ve PCI DSS uyumu; güvenlik ve veri tarafında ise barındırma altyapısı, erişim kontrolleri ve KVKK süreçleri kontrol edilmelidir. Kart verisi ve yolcu kimlik verisi, bir acentenin taşıdığı en hassas veridir.

PCI Security Standards Council, PCI DSS'i ödeme hesabı verisini korumak için teknik ve operasyonel gereksinimlerin temelini oluşturan standart olarak tanımlar ve kart kabul eden işyerlerini, ödeme işlemcilerini ve hizmet sağlayıcıları kapsamına alır. Yazılım sağlayıcısına ödeme altyapısının bu standarda uyumunu sormak gerekir.

Yolcu verisi ise 6698 sayılı Kişisel Verilerin Korunması Kanunu kapsamındadır. B2C sitesi için ayrıca Seyahat Acentaları Yönetmeliği, belge numarası ile acenta unvanının online satış kanallarının ilk açılış sayfasında yer almasını zorunlu tutar; bu alanın tema içinde kolayca yönetilebilmesi pratik bir kontrol maddesidir. Sanal POS seçimi için turizm sanal POS seçimi rehberine bakabilirsiniz.

Muhasebe, B2C ve operasyon araçları neden önemlidir?

Muhasebe entegrasyonu, B2C satış sitesinin arama motoru performansı ve operasyon kuyrukları, satış büyüdükçe ölçeklenip ölçeklenemeyeceğinizi belirleyen kriterlerdir. Bunlar ilk ayda fark edilmez, ancak yüzlerce bilette maliyet farkı yaratır.

Muhasebe tarafında kesilen her biletin yolcu bazında, satış ve tedarikçi para birimiyle ayrı aktarılması mutabakatı kolaylaştırır. B2C tarafında şehir, havayolu ve rota açılış sayfaları, yapısal veri ve hızlı sayfa yüklenmesi organik trafiğin temelidir. Operasyon tarafında ise süresi dolan opsiyonlar, başarısız ödemeler ve havayolu tarife değişiklikleri bir kuyrukta toplanmazsa gözden kaçar.

Değerlendirme süreci adım adım nasıl yürütülür?

Değerlendirme süreci; satış modelinin yazılması, kısa liste, senaryo bazlı demo, satış sonrası testi, toplam maliyet hesabı ve referans görüşmesi olmak üzere altı adımda yürütülür. Her adımın çıktısını yazılı tutmak, kararı kişisel izlenimden çıkarıp karşılaştırılabilir hale getirir.

1. Satış modelinizi yazın. Kanallarınızı, müşteri tiplerinizi, hacminizi ve tedarikçi anlaşmalarınızı bir sayfada toplayın.
2. Kısa liste oluşturun. Kanal ve tedarikçi ihtiyacınızı karşılamayanları eleyin.
3. Senaryo bazlı demo isteyin. Kendi rotalarınızla arama, opsiyon, ödeme, iptal ve değişiklik senaryolarını canlı izleyin.
4. Satış sonrasını yazılı teyit edin. Tedarikçi bazında hangi işlemin otomatik olduğunu tablo olarak isteyin.
5. Toplam maliyeti hesaplayın. Kurulum, kira veya lisans, entegrasyon, POS, barındırma ve destek kalemlerini aynı tabloda karşılaştırın. Maliyet kalemleri için uçak bileti yazılımı fiyatları sayfasına bakabilirsiniz.
6. Referansları arayın. Benzer ölçekte acentelerle kurulum süresini ve destek deneyimini konuşun.

Yazılım seçiminde en sık yapılan hatalar nelerdir?

Yazılım seçiminde en sık yapılan hatalar; kararı yalnızca arama ekranına bakarak vermek, tedarikçi bağlantılarının hangi işlemleri desteklediğini sormamak, toplam maliyet yerine yalnızca aylık bedeli karşılaştırmak ve büyüme planını hesaba katmamaktır. Bu hataların bedeli genellikle ilk yoğun sezonda ortaya çıkar.

• Ekran güzelliğine göre seçmek: Arama ekranı her yazılımda benzer görünür; fark iptal, iade ve değişiklik ekranlarındadır.
• Bağlantı listesini isim olarak okumak: Aynı havayolu bağlantısı bir yazılımda yalnızca arama ve biletleme, diğerinde ek hizmet ve iade de destekleyebilir.
• Bugünkü kanala göre seçmek: Bugün yalnızca ofisten satan bir acente, iki yıl sonra alt acente ağı veya B2C sitesi kurmak isteyebilir; yazılımın bu genişlemeyi taşıyıp taşımadığı baştan sorulmalıdır.
• Veri taşımayı unutmak: Mevcut müşteri ve rezervasyon verisinin yeni sisteme nasıl aktarılacağı sözleşme öncesinde konuşulmalıdır.
• Destek modelini sormamak: Gece yarısı ödeme alınıp biletlenmeyen bir rezervasyonda kime, hangi kanaldan ulaşılacağı yazılı olmalıdır.

Kiralama mı, kaynak kodu satın almak mı?

Kiralama, yazılımı aylık veya yıllık bedelle kullanmak ve bakım, güncelleme ve barındırmayı sağlayıcıya bırakmak demektir; kaynak kodu satın alma ise yazılımı varlık olarak edinmek ve geliştirmeyi kendi ekibinizle sürdürebilmek demektir. Doğru seçim teknik ekibinize, bütçenize ve ürünü ne kadar özelleştirmek istediğinize bağlıdır.

Kendi yazılım ekibi olmayan ve hızlı satışa başlamak isteyen acenteler için kiralama genellikle daha az risklidir. Ürünü farklılaştırmak, kendi altyapısında çalıştırmak veya uzun vadede bağımsız olmak isteyen büyük yapılar için kaynak kodu satın alma anlamlı olabilir. İki modelin ayrıntılı karşılaştırması SaaS mı kaynak kod mu rehberindedir.

DIJI.TECH bu kriterlere nasıl yanıt verir?

DIJI.TECH'in uçak bileti yazılımı, 2019'dan beri 50'den fazla acentenin kullandığı; B2B portal, B2C satış sitesi ve kurumsal portalı aynı rezervasyon motorunda çalıştıran bir altyapıdır. GDS ve konsolidatörler üzerinden 950'den fazla havayolunun biletini satabilme imkânı ve 100'den fazla entegrasyon sunar.

Yukarıdaki kriterler açısından öne çıkan noktalar şunlardır: THY, Pegasus ve AJet NDC bağlantıları; tedarikçi bazında tanımlı void politikası ve iki adımlı iptal; Travelport ve THY'de reissue; rota, tedarikçi, havayolu, kanal, kabin ve yolcu tipi gibi kriterlerle tanımlanan katmanlı markup; 20 sanal POS ve ödeme adaptörü ile PCI DSS uyumlu ödeme; Paraşüt, Luca, Logo Netsis, Arkman ve SYS muhasebe aktarımı; AWS ve Cloudflare üzerinde barındırma; OpenAPI 3.1 ile belgelenmiş kendi REST API'si. Kurulum ortalama 2 hafta sürer; yazılım kiralama veya kaynak kodu satın alma seçenekleriyle sunulur ve fiyat kapsam belirlendikten sonra teklifle verilir. Kendi senaryolarınızla değerlendirmek için demo talep edebilirsiniz.