Aracı Bir Duvara Dönüştüğünde
Bir gezgin yakın zamanda AirAsia MOVE platformu üzerinden bir IndiGo uçuşu rezerve etti. Planlar değişince seyahati iptal etmeyi talep etti. Havayolu şirketi kabul etti. Hikayenin burada bitmesi gerekiyordu. Bunun yerine, platformun kendisi iptal işlemini gerçekleştirmeyi reddederek yolcuyu iki şirket arasındaki boşlukta çaresiz bıraktı. Yaşadığı hayal kırıklığını kamuoyuna duyurdu ve sistemi işe yaramaz ve aptalca olarak nitelendirdi. Öfkesi ham olsa da, hayatlarını kolaylaştırmak için toplayıcılara (aggregators) güvenen milyonlarca gezgini etkileyen bir soruna işaret ediyordu.
Bu olay, çevrimiçi seyahat dünyasının devasa çarkları içinde küçük bir olay olsa da, gürültülü bir uyarı taşıyor. Havayolu web siteleri, ödeme ağ geçitleri ve onay kodları arasında mekik dokumaktan kaçınmak için bu uygulamaları indiriyoruz. Aracının çarkları kilitlemesini değil, yağlamasını bekliyoruz. Bir platform, havayolunun halihazırda onayladığı bir iptal işlemini gerçekleştiremediğinde, tek gerçek görevinde başarısız olmuş demektir: bilgiyi kullanıcıdan hizmet sağlayıcıya ve tersi yönde sadakatle taşımak.
Neler Bozuldu
Vakanın detayları oldukça basit ve onları endişe verici kılan da tam olarak bu. Yolcu gizli bir ücretle tartışmaya girmemiş veya bir politika açığı için mücadele etmemişti. Standart bir işlem gerçekleştirmişti —bir uçuşu iptal etmek— ve var olmaması gereken bir hatayla karşılaştı. IndiGo iptali kabul etti. AirAsia MOVE etmedi. Sonuç, klasik bir kaybet-kaybet durumu oldu. Gezgin zamanını ve huzurunu kaybetti. Platform ise güvenilirliğini kaybetti.
Bu tür hatalar genellikle gezginlerin asla görmediği, sistemin derinliklerindeki "tesisat" kısmında meydana gelir. Çevrimiçi seyahat acenteleri ve süper uygulamalar (superapps), havayolu envanterini kendi sunucularında tutmazlar. Verileri karşılıklı olarak ileten uygulama programlama arayüzleri (API'ler) aracılığıyla havayollarına bağlanırlar. "İptal et" düğmesine bastığınızda, talebiniz telefonunuzdan toplayıcının arka ucuna (backend), oradan da havayolunun rezervasyon sistemine iletilir. Havayolu rezervasyon durumunu günceller ve bir onay gönderir. Toplayıcının bu değişikliği anında yansıtması ve para iadenizi veya seyahat kredilerinizi işlemesi gerekir.
Bu zincirin bir noktasında AirAsia MOVE kilitlendi. Belki de API, IndiGo'nun sisteminden güncellenmiş durumu sorgulamayı (poll) başaramadı. Belki de uygulamanın dahili mantığı, havayolunun yanıtını geçersiz kılan sabit kodlanmış (hardcoded) bir kural içeriyordu. Belki de müşteri hizmetleri temsilcileri ekrandaki uyumsuzluğu görebiliyor ancak iptali zorlamak için gerekli yetkilere sahip değildi. Tam olarak hangi hatanın (bug) buna sebep olduğunu bilmiyoruz ancak sonucu biliyoruz: Bir insan, her tarafın iptal edilmesi konusunda hemfikir olduğu bir işlemi geri alamayarak bir yazılım döngüsünün içine hapsoldu.
Güven Neden Kod Düzeltmelerinden Daha Hızlı Aşınıyor
Gezginler hantal arayüzlere katlanırlar. Yavaş yükleme sürelerine katlanırlar. Ancak söz konusu para ve planlar olduğunda çaresizliğe katlanmazlar. İptal işlemi önemsiz bir talep değildir. Genellikle bir krizin —tıbbi bir sorun, ailevi bir acil durum, ani bir iş çatışması— ardından gelir. Kullanıcı zaten stres altındadır. Uygulamanın rolü, arka uç karmaşıklığını yöneterek bu stresi azaltmaktır. Bunun yerine yeni bir engel çıkardığında, duygusal maliyet çok büyük olur.
Yolcunun bu kamuoyuna açık tepkisinin önemli olmasının nedeni budur. Eksik bir sadakat puanı veya gecikmiş bir bildirim hakkında şikayette bulunmadı. Platformu işe yaramaz olarak tanımladı çünkü en çok ihtiyaç duyduğu anda, meşru bir talebi aktif olarak engelledi. Dijital hizmetlere olan güven, koşullar değişse bile sistemin niyetinizi yerine getireceği inancı üzerine kuruludur. Bu vaadin tek bir kez bozulması, on tane sorunsuz rezervasyonun onarabileceğinden daha fazla zarar verir.
Bu sorun aynı zamanda birçok seyahat platformunun nasıl inşa edildiğine dair stratejik bir kör noktayı da ortaya koyuyor. Mühendislik ekipleri genellikle kaynaklarını ön yüze (front end) aktarırlar: hızlı arama, şık takvimler, tek dokunuşla ödeme, kişiselleştirilmiş fırsatlar. İndirmeleri teşvik eden özellikler bunlardır. Rezervasyon sonrası işlemler —değişiklikler, iptaller, iadeler— ise sonradan düşünülmüş detaylar gibi görülür. Bunlar daha eski API'lere, daha az izlemeye ve daha az yedekleme seçeneğine sahiptir. Ancak bir uygulamanın gerçek bir araç mı yoksa sadece parlak bir broşür mü olduğunu kullanıcılar tam da bu noktada keşfeder.
Seyahat Platformlarının Doğru Yapması Gerekenler
Müşteriler ile havayolları arasında yer alan her şirket için burada açık dersler var.
İptalleri rezervasyonlar kadar basit hale getirin. Eğer bir kullanıcı üç dokunuşla koltuk ayırtabiliyorsa, chatbot labirentleri, gizli menüler ve desteklenmeyen formlar arasında kaybolmadan bu işlemi geri alabilmelidir. İptal süreci görünür olmalı, ücretler konusunda dürüst davranmalı ve gezginleri kullanamayacakları bir rezervasyonu tutmaya zorlayan veya kafalarını karıştıran karanlık desenlerden (dark patterns) arındırılmış olmalıdır.
Gerçekten işe yarayan manuel müdahale imkanları oluşturun. Otomasyon, hata verene kadar harikadır. Bir API dönüş çelişkisi veya senkronizasyon hatası oluştuğunda, müşteri hizmetleri temsilcileri müdahale edebilecek yetkiye ve arayüze sahip olmalıdır. Çok fazla platform, insan müdahalesi için hiçbir kapısı olmayan, tamamen otomatik kaleler tasarlıyor. Temsilciler sonunda sadece senaryolardan okuyor, durmadan özür diliyor ve talepleri birer kara deliğe gönderiyor. Faydalı bir manuel müdahale imkanı, bir temsilcinin havayolunun onayını görebilmesi, bunu takılı kalan rezervasyonla eşleştirebilmesi ve iptali gerçek zamanlı olarak gerçekleştirebilmesi anlamına gelir.
Yazılımı havayolu gerçekliğiyle senkronize tutun. Seyahat platformlarının toplu güncellemelerden ve yavaş sorgulama (polling) döngülerinden uzaklaşması gerekiyor. Eğer bir havayolu bir bileti iptal edilebilir, iade edilebilir veya yeniden planlanmış olarak işaretlerse, aracı kurum bunu saatler içinde değil, dakikalar içinde öğrenmelidir. Bu; sağlam bir webhook mimarisi, başarısız el sıkışmalar (handshakes) için yeniden deneme mantığı ve kullanıcı fark etmeden uyumsuzlukları işaretleyen mutabakat (reconciliation) işleri gerektirir. Platform, kendi ürününün durumunu en son öğrenen taraf olmamalıdır.
Gezginlerin Şu An Yapabilecekleri
Sektör bu boşlukları giderene kadar yolcular kendilerini korumalıdır. AirAsia MOVE gibi büyük uygulamalar da dahil olmak üzere herhangi bir üçüncü taraf uygulama üzerinden rezervasyon yapıyorsanız, bir kayıt izi bırakın. Onay numaralarınızın, iptal politikalarınızın ve havayolundan gelen tüm iletişimlerin ekran görüntüsünü alın. Satın almadan önce havayolunun kendi politikasını öğrenin; bazı taşıyıcılar, ortaklar tarafından satılan biletler için bile doğrudan kendi web siteleri üzerinden değişiklik yapılmasına izin verir. Uygulama hata verirse, doğrudan havayoluyla iletişime geçin. Kamuoyuna açık paylaşımlar ilgi gördüğünde, şirketler özel destek kanallarına kıyasla daha hızlı hareket etme eğilimindedir. Ve eğer önemli bir tutar takılı kaldıysa, tüketici koruma forumları veya ters ibraz (chargeback) mekanizmaları aracılığıyla süreci üst mercilere taşımaktan çekinmeyin.
Asıl Çıkarılması Gereken Ders
Müşteri deneyimi, kod yazıldıktan sonra uygulanan bir parlatma katmanı değildir. Hayat karıştığında kodun doğru şekilde çalışmasıdır. Bir uçuşu iptal edemeyen bir rezervasyon platformu, geri vitesi olmayan bir arabaya benzer. İleriye doğru harika gidebilir ama er ya da geç bir yerden geri çıkmanız gerekecektir.
Gezginler sihir beklemiyor. Sadece kendilerini manipüle etmeden (gaslighting yapmadan) temel komutları yerine getiren araçlar istiyorlar. AirAsia MOVE'un, IndiGo'nun halihazırda kabul ettiği bir iptali yerine getirememesi, kolaylığın ancak tüm süreç (pipeline) düzgün çalıştığında gerçek olduğu konusunda bir hatırlatmadır. Seyahat platformları, satın alma sonrası güvenilirliğe, müşteri kazanımı hunileri (acquisition funnels) kadar büyük yatırımlar yapana kadar, kullanıcılar temkinli olmaya devam edecektir. Ve öyle de yapmalılar.