Bayi ağı büyütmenin cazibesi basit bir varsayıma dayanır: satış noktası sayısı arttıkça ciro artar, ciro arttıkça kâr artar. İlk yarısı genellikle doğru çıkar. İkinci yarısı çıkmaz. Ciro büyürken tahsilatın yavaşladığı, hangi bayide ne kadar marj kaldığının raporlardan okunamadığı ve ay sonu mutabakatının her seferinde birkaç gün sürüklendiği bir tabloya varılır. Bu noktada çoğu acente sorunu "raporlama eksikliği" sanır. Değildir. Sorun, birbirinden bağımsız üç kararın tek karar sanılmasıdır: bayiye hangi fiyatı vereceğiniz, ona hangi komisyonu hangi taban üzerinden ödeyeceğiniz ve ne kadar açık pozisyon taşımasına izin vereceğiniz.
Zincirin her halkası kendi yüzdesini ham maliyete değil, bir önceki halkanın çıktısına uygular. Toplama mantığıyla kurulan her bayi anlaşması, bu yüzden hesaplanandan pahalıya çıkar.
Bu üç karar farklı birimlere aittir, farklı kişilerce verilmelidir ve farklı sıklıkta gözden geçirilir. Fiyat kuralı bir ticaret kararıdır ve rekabete göre haftalar içinde değişir. Komisyon tabanı bir sözleşme kararıdır ve yılda bir kez, muhasebe ile birlikte tanımlanır. Cari limit bir risk kararıdır ve bayinin ödeme davranışına göre aylık güncellenir. Üçü tek bir "bayi anlaşması" belgesine sıkıştırıldığında, birini değiştirmek diğer ikisini sessizce bozar.
Aşağıdaki bölümler bu üç kararı ayırıyor ve her birine somut bir hesap, eşik ya da kontrol kuralı bağlıyor. Anlatılanların büyük kısmı hangi yazılımı kullandığınızdan bağımsızdır; Excel ile bayi yöneten bir acente de aynı matematikle karşı karşıyadır. Bağlam için bir ölçek notu: TÜİK'in 2025 verisine göre Türkiye'nin turizm geliri 65,23 milyar dolar oldu ve bunun 18,2 milyar doları — toplam turist harcamasının %28,2'si — paket tur harcamasıydı. Paket tur, tanımı gereği aracılı satıştır; yani bu tutarın önemli bölümü bir bayi zincirinden geçerek oluşur.
1. Aynı ürün, farklı alıcı, farklı fiyat: B2B fiyatlamanın kırılma noktası
Son tüketiciye satış yapan bir sitede fiyat tektir. Arama sonucu üretilirken fiyat hesaplanır, ekrana basılır, sepete o rakamla girer. B2B'de bu model çalışmaz, çünkü aynı uçuşu aynı anda sorgulayan iki bayi farklı fiyat görmek zorundadır.
Bunun operasyonel sonucu çoğu ekibin fark ettiğinden daha keskindir: fiyatı arama anında sabitlerseniz bayi bazlı fiyat veremezsiniz. Doğru mimari, tedarikçiden gelen ham net fiyatı olduğu gibi saklamak ve fiyat kuralı ile kur çevrimini her okuyucu için ayrı ayrı uygulamaktır. Kendi B2B platformumuzda arama oturumu ham tedarikçi fiyatını tutar; kural zinciri ve kur çevrimi sonucu okuyan acenteye göre çalışır.
Bu ayrımın pratik testi şudur: aynı uçuşu iki farklı bayi hesabıyla aynı dakikada sorgulayın. İki farklı rakam görmüyorsanız, sistem size bayi bazlı fiyatlama vaat etmiş olsa bile fiyatı arama anında sabitliyordur ve ilerideki her bayi anlaşmasını elle yönetmek zorunda kalırsınız.
Karar kuralı
Yeni bir modül veya tedarikçi açarken tek soru sorun: bu kaynağın fiyatı kim için hesaplanıyor? Cevap "arama yapan için" ise sorun yok; "sistem için" ise o kaynakta bayi farklılaştırması yapamayacaksınız demektir ve bunu anlaşma öncesinde bilmeniz gerekir.
2. Zincir uzadıkça marj bileşik erir
Fiyat kuralları katman katman uygulanır: operatör kuralı, sonra GSA kuralı, sonra acente kuralı, sonra alt acente kuralı. Her katman kendi yüzdesini ham maliyete değil, bir önceki katmanın çıktısına uygular. "Herkese %5 verelim, toplam %20 eder" cümlesi bu yüzden yanlıştır.
| Katman başına oran | 2 katman | 3 katman | 4 katman |
|---|---|---|---|
| %3 | +%6,09 | +%9,27 | +%12,55 |
| %5 | +%10,25 | +%15,76 | +%21,55 |
| %8 | +%16,64 | +%25,97 | +%36,05 |
| %10 | +%21,00 | +%33,10 | +%46,41 |
Tabloyu okumanın doğru yolu, satırları değil sütunları karşılaştırmaktır. %8 oranıyla çalışan bir zincirde bir katmanı çıkarmak son fiyatı 10,08 puan ucuzlatır (%36,05 → %25,97). Aynı zincirde oranı %8'den %5'e çekmek 14,50 puan kazandırır. Yani her iki kaldıraç da işe yarar, ama katman kaldırmak çoğu zaman daha kolaydır: oran indirimi bayiyle müzakere gerektirir, katman kaldırmak yapısal bir karardır.
Uygulanabilir kural
Zincir uzunluğunu üç katmanla sınırlayın. Dördüncü bir katman eklemeniz gerekiyorsa (örneğin bölgesel bir GSA), o katmanın oranını diğerlerinden bağımsız ve daha düşük tutun; aksi halde son fiyatınız doğrudan satan rakiplerinizin altını göremez. Zincirin toplam etkisini yılda en az iki kez, gerçek satış verisiyle ölçün: en çok satan 20 üründe ham net fiyat ile bayinin gördüğü fiyat arasındaki farkı yüzde olarak çıkarın ve %25'i aşan kalemleri gözden geçirin.
3. Kural neye bağlanır: sekiz kriter ve seçim rehberi
Bir fiyat kuralı motorunda kuralı "genel" bırakmak en kolay ama en pahalı seçenektir; her satışa aynı yüzdeyi uygular ve düşük fiyatlı üründe kâr bırakmaz, yüksek fiyatlıda ise sizi rekabet dışına iter. Kendi motorumuzda kural sekiz farklı kritere bağlanabiliyor.
Kuralın hangi kritere bağlandığı, ekranda hangi sekmede tanımlandığıyla birebir örtüşür. Bir kuralı yanlış sekmede tanımlamak, onu beklediğinizden çok daha geniş bir satış kümesine uygular.
| Kriter | Ne zaman kullanılır |
|---|---|
| Genel | Yalnız taban kural olarak; tek başına asla |
| Tedarikçi | Bir kaynağın maliyeti diğerlerinden yapısal olarak farklıysa |
| Tedarikçi + havayolu | Aynı kaynakta havayolu bazında komisyon farkı varsa |
| Tedarikçi hesabı | Aynı tedarikçide iki sözleşmeniz varsa (ör. farklı komisyon oranlı) |
| Tedarikçi hesabı + havayolu | En dar kapsam; istisna yönetimi için |
| Tüm ülkeler | Yurt dışı satışına tek seferde farklı oran uygulamak için |
| Seçili ülkeler | Belirli kalkış/varış pazarında rekabet baskısı varsa |
| Fiyat aralığı | Düşük ve yüksek fiyatlı bileti farklı mantıkla fiyatlamak için |
Seçim rehberi tek cümleye indirgenebilir: kuralı, farkın gerçekten doğduğu en dar kritere bağlayın. Havayolu bazında komisyon farkınız yoksa havayolu kriteri kullanmayın — her kural, ileride açıklanması ve bakımı gereken bir borçtur. Pratikte sağlıklı bir kurulumda toplam kural sayısı bayi sayısının iki katını geçmez; geçiyorsa istisnaları kural olarak yönetiyorsunuzdur.
4. Yüzde mi sabit tutar mı: eşiği hesaplayın
Yüzde kural, ucuz üründe yetersiz, pahalı üründe fazla gelir. Sabit tutar tam tersini yapar. Doğru cevap ikisini birlikte kullanmak ve geçiş eşiğini hesaplamaktır:
Eşik fiyat = sabit tutar ÷ yüzde oranı
8 EUR sabit tutar ile %3 oran, 8 ÷ 0,03 = 266,67 EUR'da eşitlenir. Yani "0–267 EUR arası sabit 8 EUR, üstü %3" kuralı fiyat ekseninde kırılma yaratmadan çalışır. Eşiği hesaplamadan bant tanımlarsanız fiyat eğrisinde sıçrama olur ve bayi bunu er ya da geç fark eder.
| Bilet fiyatı | Sabit 8 EUR | %3 | Uygulanan |
|---|---|---|---|
| 100 EUR | 8,00 (%8,0) | 3,00 | 8,00 |
| 267 EUR | 8,00 (%3,0) | 8,01 | 8,00 |
| 600 EUR | 8,00 (%1,3) | 18,00 | 18,00 |
Sabit tutarlı kuralda para birimi zorunludur ve bu bir risk kararıdır. Sabit tutarı tedarikçinin para biriminde tanımlarsanız kur riski bayiye geçer; kendi para biriminizde tanımlarsanız risk sizde kalır. Kural şudur: bayinizin tahsilatı hangi para biriminde yapılıyorsa sabit tutarı o para biriminde tanımlayın. Aksi halde kur hareketi doğrudan sizin marjınızı yer ve bunu ancak ay sonunda görürsünüz.
5. Fiyat izi: hangi kuralın kaç lira eklediğini görmek
Bayi "fiyatınız yüksek" dediğinde elinizde iki şey olabilir: bir açıklama ya da bir kayıt. Fiyat izi, zincirin her adımında hangi kuralın ne kadar eklediğini satır satır tutan kayıttır. Bizim motorumuzda uygulanan her adım arama sonucunda iz olarak görünür, böylece personel de rakamı savunabilir.
Fiyat itirazı prosedürü — dört adım
- Ham net fiyatı doğrulayın. İtiraz çoğu zaman markup'a değil, tedarikçiden gelen fiyata aittir. Aynı sorguyu ham fiyatla tekrarlayın.
- İzi okuyun ve katman katman ayırın. Farkın hangi katmandan geldiğini tespit edin. Genelde tek bir katman baskındır.
- O katmanın kuralını kriteriyle birlikte kontrol edin. Sık görülen hata: dar bir istisna için tanımlanan kuralın "genel" kritere kaydedilmiş olması.
- Kararı yazın. Kuralı değiştirdiyseniz gerekçeyi ve tarihi kayda geçirin; değiştirmediyseniz bayiye verilen açıklamayı kayda geçirin.
Bayinin gördüğü iz ile sizin gördüğünüz iz aynı olmamalıdır. Bayiye, kendi katmanının ne eklediği gösterilebilir; üst katmanların kırılımı gösterilmez. Bunu baştan tanımlamazsanız ilk itirazda ya çok fazla bilgi açarsınız ya da hiçbir şey açamayıp güven kaybedersiniz.
6. Marjı göstermeden belge paylaşmak
Bayi, sattığı bilete ait belgeyi kendi müşterisine iletir. O belgede sizin marjınız görünüyorsa bayi ağınız birkaç ay içinde çözülür. Çözüm, belgenin iki modda üretilmesidir: acente görünümünde servis bedeli ayrı bir satırdır, müşteri görünümünde baz fiyata gömülüdür. Bu, kozmetik bir tercih değil sözleşmesel bir gerekliliktir; bayi sözleşmenize "müşteriye iletilen belgede aracı marjı ayrıştırılmaz" maddesini yazın.
Burada dikkat edilecek bir tuzak var. Birçok sistemde belgedeki "servis" satırı bağımsız bir kalem değil, markup tutarından türetilmiş bir görünümdür — bizim uçak bileti belgemizde de durum budur; markup'tan ayrı, sabit bir servis bedeli alanı tanımlanamıyor. Pratik sonucu şudur: markup'ı sıfırladığınızda servis satırı da sıfırlanır. Sabit bir servis bedeli tahsil etmek istiyorsanız (örneğin sıfır komisyonlu biletlerde), bunu yazılım seçerken ayrıca sorun; "belgede servis satırı var" cevabı yeterli değildir, "markup'tan bağımsız tanımlanabiliyor mu" diye sorun.
7. Komisyon tabanı: brüt satış mı, satış eksi maliyet mi?
Bu, bu yazıdaki en pahalı tek hatadır ve neredeyse hiç konuşulmaz. Komisyon "%10" diye anlaşılır, ama %10'un neyin üzerinden hesaplandığı yazılmaz.
Aynı satış, aynı oran, iki farklı taban. Aradaki fark 6,7 kat ve ikisi de tek bir "komisyon" sütununda toplanabiliyor.
| Taban A: brüt satış | Taban B: satış − maliyet | |
|---|---|---|
| Hesap | 1.000 × %10 | 150 × %10 |
| Komisyon | 100 | 15 |
| Maliyet artarsa | değişmez | düşer |
| Riski taşıyan | siz | bayi |
Bu iki tanımın aynı kurumda yan yana yaşaması sanıldığından yaygındır. Kendi tur modülümüzde ölçtüğümüz durum tam olarak budur: panel üzerinden ilerleyen satışta komisyon oranı brüt satış üzerinden uygulanıyor, operatörün elle girdiği satışta ise komisyon satış eksi tedarikçi maliyeti farkı olarak hesaplanıyor. İki tanım aynı raporda toplandığında çıkan sayı hiçbir şey ifade etmez — ne bayiye ödenecek tutarı, ne kurumun komisyon giderini doğru verir.
Sözleşmeye yazılacak tanım şablonu
"Komisyon, [brüt satış tutarı / satış tutarı eksi tedarikçi net maliyeti] üzerinden hesaplanır. Tedarikçi net maliyeti, satış anında sistemde kayıtlı olan ham tedarikçi fiyatıdır; sonradan oluşan iade, ceza ve kur farkları komisyon tabanını değiştirmez."
İkinci cümle ilkinden daha önemlidir. Taban tanımlansa bile "sonradan ne olursa taban değişir mi" sorusu cevaplanmazsa, her iade ve her kur hareketi yeni bir mutabakat tartışması doğurur.
Sabit oranlara dikkat
Bazı hak ediş oranları sözleşmeye göre değil, sisteme gömülü olarak çalışır. Kendi transfer modülümüzde şoför hak ediş komisyonu sabit %20'dir ve kiracı, şoför ya da araç sözleşmesine göre ayarlanamaz. Bu kendi başına bir kusur değil — sabit oran, yönetimi basitleştirdiği için bilinçli bir tercih olabilir. Kusur, bunu bilmeden farklı oranlı bir sözleşme imzalamaktır. Yazılım seçerken her hak ediş kaleminin yapılandırılabilir mi yoksa sabit mi olduğunu tek tek sorun.
8. Cari bakiye, kredi limiti, kullanılabilir bakiye: üç ayrı sayı
Bu üçü sürekli birbirine karıştırılır. Bakiye bayinin bugünkü durumudur, limit ona tanıdığınız açık pozisyon tavanıdır, kullanılabilir bakiye ise satışı fiilen durduran sayıdır.
Limit dolduğunda satışın tamamen durması gerekmez. Cari yol kapanır, kart yolu açık kalır — böylece risk yönetilirken satış kaybedilmez.
Limit belirleme formülü
Limiti "hissiyatla" vermek en sık yapılan hatadır. Ölçülebilir bir taban kullanın:
Limit = (aylık ortalama satış ÷ 30) × (vade günü + ortalama gecikme günü) × risk katsayısı
Çalışan bir örnek: bayi aylık ortalama 900.000 TL satıyor, yani günlük 30.000 TL. Vadesi 7 gün, son altı ayda ortalama 4 gün geç ödüyor. Maruziyet penceresi 11 gün, ham maruziyet 330.000 TL.
| Bayi profili | Risk katsayısı | Limit |
|---|---|---|
| Yeni bayi (0–6 ay) | 0,5 | 165.000 TL |
| Düzenli ödeyen (12 ay+) | 1,0 | 330.000 TL |
| Teminatlı / senetli | 1,3 | 429.000 TL |
Formülün değeri kesin rakam vermesinde değil, limiti bayinin ödeme davranışına bağlamasındadır. Ortalama gecikme büyüdükçe limit otomatik olarak yukarı çıkmamalı; tam tersine gecikme eşiği aşıldığında katsayıyı düşürün. İkinci bir iç kural olarak konsantrasyon sınırı koymanızı öneririm: tek bir bayinin limiti, toplam açık cari alacağınızın belirli bir yüzdesini geçmesin. Bu oranı kendi sermaye yapınıza göre belirleyin, ama belirleyin — en büyük bayinin batması işletmeyi taşıyamaz hale getirmemeli.
Manuel bakiye hareketinin denetim izi
Satıştan doğan cari hareketler değiştirilemez olmalıdır; yalnız manuel girişler işaretlenerek geri alınabilmelidir. Her manuel hareket kim, ne zaman, hangi IP'den bilgisiyle kayda geçmelidir — kendi platformumuzda bakiye yükleme ve düşme işlemleri bu üç alanla birlikte saklanır. Bunun neden önemli olduğunu bir kez yaşamadan anlamak zordur: manuel bakiye girişi, bir bayi ağındaki en yüksek riskli tek işlemdir ve iz bırakmadığı kurulumlarda ay sonu farkının kaynağı asla bulunamaz.
9. BSP takvimi 2026'da değişti: bayi vadeniz artık bağımsız değil
IATA'nın Yolcu Acente Konferansı, Kasım 2025'te Resolution 812'yi değiştirdi. Haftalık remittance uygulanan pazarlarda, havayolları adına tahsil edilen tutarların satış/faturalama döneminin kapanışından sonra beş iş günü veya en geç yedi takvim günü içinde aktarılması gerekiyor. Değişiklik Haziran 2026'da yürürlüğe girdi ve Section 6.5.3.7(b)'nin kaldırılmasıyla remittance dönemleri tüm pazarlarda standartlaştı.
Nakit ömrü satışın dönem içindeki gününe göre değişir. Bayi vadesi sabit verildiğinde açık pozisyon dönem sonuna doğru satılan biletlerde en büyük olur.
IATA'nın gerekçesi, sabit ve öngörülebilir bir haftalık takvimin risk altındaki satış gün sayısını azalttığı, bunun da akredite acentelerin sunması gereken finansal teminat seviyesini düşürdüğü yönünde. Sektörün tepkisi tek yönlü olmadı: UFTAA, kısalan ve katılaşan remittance dönemlerinin acentelerin likidite maliyetini artıracağı gerekçesiyle standartlaştırmaya açıkça karşı çıktı.
Acente açısından asıl mesele, kimin haklı olduğu değil, takvimin artık sabit olması. Bunun bayi ağınız için doğrudan bir sonucu var:
| Biletin satıldığı gün | Aktarım son günü | Nakit ömrü |
|---|---|---|
| Dönemin 1. günü | Gün 14 | 13 gün |
| Dönemin 4. günü | Gün 14 | 10 gün |
| Dönemin 7. günü | Gün 14 | 7 gün |
Karar kuralı: bayinize verdiğiniz vade, kendi aktarım yükümlülüğünüzün ortalama nakit ömründen uzun olamaz. Yukarıdaki tabloda ortalama nakit ömrü 10 gündür. Bayiye 15 gün vade veriyorsanız, dönemin son günü satılan bir bilette 8 gün boyunca parayı kendi sermayenizden finanse ediyorsunuz demektir. Bu fark küçük hacimlerde görünmez, ciro büyüdükçe kalıcı bir işletme sermayesi ihtiyacına dönüşür — ve büyüyen bayi ağlarında nakit sıkışmasının en sık nedeni budur.
Akreditasyon modeliniz de bu denklemin parçası. Antravia'nın açıklamasına göre IATA'nın GoLite modeli finansal teminat bonosu istemez ama acentenin nakdi yüzdürmesine izin vermez; biletler IATA EasyPay cüzdanı veya kurumsal kartla anında ödenir. GoStandard modeli ise "Remittance Holding Capacity" adı verilen bir kredi limiti tanır — önce keser, sonra ödersiniz — ama bunun için finansal değerlendirmeden geçmek gerekir. Aynı kaynağın uyarısı net: tahsilat öncesinde bu nakit işletme giderlerini finanse etmek için kullanılırsa, BSP parayı çağırdığında acente temerrüde düşme riski taşır.
10. Modül bazında yetki: yeni bayiyi kademeli açın
Yeni bayiye ilk gün her modülü, tam limiti ve iptal yetkisini birlikte vermek, ağdaki en yaygın operasyonel hatadır. Modül izinleri acente bazında açılıp kapatılabiliyorsa bunu kademeli bir takvime bağlayın.
| Aşama | Modüller | Limit | İptal yetkisi |
|---|---|---|---|
| Gün 0 | En çok satacağı tek modül | 0 (ön ödemeli) | Kapalı |
| ~30. gün | + ikinci modül | Formülün %50'si | Kapalı |
| ~90. gün | Tam yelpaze | Formülün %100'ü | Kişi bazında, sınırlı |
İptal yetkisini modül seviyesinde değil, kişi seviyesinde devredin. Bir bayinin iptal yapabilmesi ile o bayideki her kullanıcının iptal yapabilmesi arasında ciddi fark vardır; ikincisi, ceza doğuran işlemleri eğitimsiz personele açar. Alt acente kapatıldığında arama ve rezervasyon erişiminin zincirleme kesildiğini de doğrulayın — kapatılan bayinin oturumu açık kaldığı sürece risk devam eder.
11. Ay sonu mutabakat rutini: yedi kontrol
Bu listeyi ayda bir kez, aynı gün, aynı sırayla çalıştırın. Otuz dakikadan uzun sürmemeli; sürüyorsa bir önceki maddede sorun var demektir.
- Komisyon tabanı tutarlılığı. Panel satışı ile elle girilen satışın komisyonu aynı tabandan mı hesaplanmış? Farklıysa iki rakamı ayrı sütunda raporlayın, toplamayın.
- Limit aşımı yapan bayiler. Ay içinde kaç kez, kimin onayıyla aşıldı? Aynı bayi ikiden fazla kez çıkıyorsa limit yanlış, kural değil.
- Manuel bakiye hareketleri. Kim, ne zaman, hangi IP, hangi gerekçe? Gerekçesiz tek bir satır bile kalmamalı.
- Fiyat uzlaştırma farkları. Kesilen bilet tutarı ile tahsil edilen tutar arasındaki farkı para birimi kırılımında okuyun; belirlediğiniz eşiğin üstündekileri operatör kararına taşıyın.
- İptal yetkisi kullanımı. Kaç iptal, hangi kullanıcı, ne kadar ceza? Ceza toplamı komisyon gelirinizin anlamlı bir oranına yaklaşıyorsa yetki dağılımını daraltın.
- Kur çevrim tarihleri. Sabit tutarlı kurallarda hangi kur, hangi tarihte uygulandı? Tanımlı bir kur tarihi politikanız yoksa bu satır her ay tartışma çıkarır.
- Aktarım takvimi uyumu. Bayilerden ortalama tahsilat gününüz, kendi aktarım yükümlülüğünüzün nakit ömründen uzun mu? Uzunsa aradaki farkı ve finansman maliyetini yazın.
12. Yazılım seçerken kalem kalem sorulacaklar
Aşağıdaki maddeler, bir bayi ağı yönetim sisteminde varlığı sanılan ama sıklıkla bulunmayan yeteneklerdir. Kendi platformumuzda ölçtüğümüz eksikleri de içeriyor; amaç bir ürünü savunmak değil, size doğru soruyu vermek. Demoda "var mı?" diye değil, "gösterebilir misiniz?" diye sorun.
- Komisyon özeti tüm modülleri kapsıyor mu? Kendi sistemimizde komisyon özeti şu an yalnız uçak bileti satışlarından hesaplanıyor; diğer modüllerin komisyon dökümü boş çıkar. Çok modüllü bir ağ işletiyorsanız çapraz-modül komisyon faturasını demo verisinde görmeden kabul etmeyin.
- Markup zinciri her modülde çalışıyor mu? Bizim grup rezervasyon modülümüzde grup teklifinin satış fiyatı elle giriliyor; çok katmanlı markup zinciri bu modüle uygulanmıyor. Aynı şekilde araç kiralama aramasında acente bazlı kâr kuralı tanımlanabiliyor ama arama sonuçlarına yansımıyor. Her modül için ayrı ayrı doğrulayın.
- Cari bağlantısı her modülde var mı? Grup modülümüzde tahsilat satırları modül içinde elle kaydediliyor, acente cari hesabına otomatik hareket yazılmıyor. Cari entegrasyonu olmayan modül, ay sonu mutabakatınızın dışında kalır.
- Servis bedeli markup'tan bağımsız tanımlanabiliyor mu? (Bölüm 6.)
- Hak ediş oranları yapılandırılabilir mi, sabit mi? (Bölüm 7.)
- Manuel bakiye hareketi kim/ne zaman/hangi IP iziyle saklanıyor mu, satış hareketleri değiştirilemez mi?
Yarın sabah yapabileceğiniz beş şey
- Zincirinizi sayın. Ham net fiyattan bayinin gördüğü fiyata kaç katman var? Dörtten fazlaysa hangisini kaldırabileceğinizi bugün belirleyin.
- En çok satan 20 ürününüzde toplam markup yüzdesini hesaplayın. %25'i aşanları işaretleyin; bunlar rekabet kaybettiğiniz kalemlerdir.
- Komisyon tabanınızı tek cümleyle yazın ve muhasebeye gönderip "bizim raporda da böyle mi?" diye sorun. Cevap gecikirse cevabınız zaten "hayır"dır.
- Üç bayiniz için limit formülünü çalıştırın. Mevcut limitle formülün verdiği rakam arasındaki farkı görün; en büyük sapmayı bu ay düzeltin.
- Aktarım takviminizi bayi vadenizle yan yana koyun. Bayi vadesi daha uzunsa, aradaki gün sayısını ve o günlerin size maliyetini hesaplayın.
Sıkça Sorulan Sorular
Alt acenteye yüzde mi sabit tutar mı markup vermeliyim?
İkisini birlikte kullanın ve geçiş eşiğini hesaplayın. Eşik fiyat, sabit tutarın yüzde oranına bölünmesiyle bulunur; örneğin 8 EUR sabit ile %3 oran 266,67 EUR'da eşitlenir. Bu eşiğin altında sabit tutar, üstünde yüzde uygulayın. Böylece düşük fiyatlı üründe kârsız kalmaz, yüksek fiyatlıda rekabet dışına düşmezsiniz.
Fiyat kuralı zincirinde kaç katman olmalı?
Üçü hedefleyin, dördü sınır kabul edin. Her katman kendi yüzdesini bir öncekinin çıktısına uyguladığı için etki bileşiktir: katman başına %8 ile dört katman toplamda %36,05 fark üretir, %32 değil. Aynı zincirde bir katmanı kaldırmak son fiyatı 10,08 puan ucuzlatır.
Komisyonu brüt satıştan mı, kârdan mı hesaplamalıyım?
Hangisini seçtiğiniz kadar, seçtiğinizi yazmanız önemli. 1.000 birimlik bir satışta 850 birim maliyetle %10 komisyon, brüt satış tabanında 100 birim, satış eksi maliyet tabanında 15 birim çıkar — 6,7 kat fark. Sözleşmeye tabanı ve "sonradan oluşan iade, ceza, kur farkı tabanı değiştirmez" cümlesini birlikte yazın.
Alt acenteye kredi limitini nasıl belirlerim?
Günlük ortalama satışını, maruziyet penceresiyle ve bir risk katsayısıyla çarpın: (aylık satış ÷ 30) × (vade günü + ortalama gecikme) × katsayı. Yeni bayide katsayıyı 0,5 civarında tutun, düzenli ödeyende 1,0'a çıkarın. Gecikme büyüdükçe katsayıyı düşürün, limiti değil.
Limit dolduğunda satış tamamen durmalı mı?
Hayır. Doğru davranış cari yolu kapatıp kart yolunu açık bırakmaktır; böylece risk yönetilirken satış kaybedilmez. Limit aşımı sık tekrarlıyorsa sorun kuralda değil limit seviyesindedir — ay sonu mutabakatında aynı bayi ikiden fazla kez çıkıyorsa limiti yeniden hesaplayın.
BSP tahsilat takvimi 2026'da nasıl değişti?
IATA'nın Yolcu Acente Konferansı Kasım 2025'te Resolution 812'yi değiştirdi; haftalık remittance uygulanan pazarlarda tahsil edilen tutarlar satış döneminin kapanışından sonra beş iş günü veya en geç yedi takvim günü içinde aktarılıyor. Değişiklik Haziran 2026'da yürürlüğe girdi. IATA'ya göre sabit takvim risk altındaki satış gün sayısını azalttığı için istenen finansal teminat seviyesini de düşürüyor; UFTAA ise likidite maliyeti gerekçesiyle karşı çıktı.
Bayime kendi marjımı göstermeden belge nasıl iletirim?
Belgeyi iki modda üretin: acente görünümünde servis bedeli ayrı satır, müşteri görünümünde baz fiyata gömülü. Bayi sözleşmesine "müşteriye iletilen belgede aracı marjı ayrıştırılmaz" maddesini ekleyin. Sistemi seçerken servis satırının markup'tan türetilip türetilmediğini sorun — türetiliyorsa markup'ı sıfırladığınızda servis satırı da sıfırlanır.
Aynı tedarikçide iki sözleşmem varsa farklı fiyat verebilir miyim?
Evet, bunun için tedarikçi hesabı (credential) kriteri kullanılır. Kuralı tedarikçi seviyesinde değil hesap seviyesinde tanımlarsanız, aynı kaynaktaki iki sözleşmenin farklı komisyon oranını fiyata doğru şekilde yansıtabilirsiniz. Havayolu bazında da farklılaşma varsa hesap + havayolu kriterine inin.
Kaynaklar
- IATA — Recent changes to BSP remittance rules (14 Ocak 2026): iata.org
- IATA — Passenger Agency Conference Resolutions Manual, Resolution 812: iata.org
- Open Jaw — IATA Move Could Force Earlier BSP Payments from Agents (7 Ocak 2026): openjaw.com
- Voyager's World — UFTAA Strongly Opposes IATA's Move to Globally Standardise BSP Remittance Periods (12 Ocak 2026): voyagersworld.in
- Antravia Advisory — IATA, BSP & ARC Explained: Airline Risk, Cash Flow and Accreditation: antravia.com
- TÜİK 2025 turizm geliri verisi (Anadolu Ajansı aktarımı, 30 Ocak 2026): aa.com.tr