Bir transfer talebinde asıl zor karar, hangi bilgiyi toplayacağınızdan çok, asistanın hangi işi üstleneceğidir. Yalnız özet mi hazırlanacak, yoksa operasyon sistemine bağlı bir süreç mi kurulacak? Bu yazı uygulama talimatı vermek yerine kapsamın nerede başlayıp nerede bittiğini ve alternatifleri nasıl değerlendireceğinizi tartışır.
Kapsam Sınırı Neyi Kapsar?
İlk karar, asistanın yalnızca bilgi toplayıp toplamayacağıdır. Bilgi toplama, yön, tarih, yerel saat, karşılama noktası ve kişi sayısı gibi alanları sırayla doldurmaktır. Operasyon sistemine bağlanmak ise müsaitlik sorgulamak, araç ayırmak ya da tutar üretmek anlamına gelir. Bu iki iş aynı kapsamda değildir ve aynı güvenle yürütülemez. Kapsamı yazılı tanımlamadan ekibe geçmek, müşteriye verilen yanıtın neye dayandığını sonradan açıklamayı zorlaştırır.
Bağlantı yoksa kapsamı dar tutmak en sağlıklı yoldur: talep özeti, eksik alanların listesi ve ekibe devir. Bağlantı olsa bile müsaitlik ve tutar ayrı doğrulama ister. Bu nedenle kapsam belgesinde her işin kimin tarafından, hangi kanıtla tamamlandığı açıkça yazılmalıdır. Aksi halde “talebiniz alındı” ifadesi, sanki transfer ayrılmış gibi okunabilir.
Üç Yaklaşımı Karşılaştırmak
Pratikte üç ana alternatif vardır: yalnız talep özeti, özet ile insan onayının birlikte kullanıldığı akış ve operasyon sistemine bağlı bir süreç. Her birinin hız, doğruluk ve bakım yükü farklıdır. Aşağıdaki tablo, seçimi yaparken bakılacak ölçütleri gösterir.
| Alternatif | Güçlü yanı | Zayıf yanı | Ne zaman seçilir |
|---|---|---|---|
| Yalnız talep özeti | Hızlı kurulur, risk düşüktür | Müşteri uzun süre bekler | Talep hacmi düşük, ekip sınırlı |
| Özet ve insan onayı | Yanlış karşılama riski azalır | Onay kuyruğu oluşur | Araç ve saat kararı ekipte kalmalı |
| Operasyon sistemine bağlı süreç | Müsaitlik ve kayıt izlenebilir | Entegrasyon ve bakım gerekir | Mevcut bir araç planı ve sistem varsa |
Tüm sütunları görmek için tabloyu yana kaydırın.
Seçim, günlük talep sayısı ve yanlış karşılamanın maliyeti ile yapılmalıdır. Hangi alternatif seçilirse seçilsin, asistan çıktısı “ön talep” olarak etiketlenmeli; kesin onay ayrı bir adım olarak görünmelidir.
Havalimanı Dışı Karşılama Ne Zaman Ayrı Ele Alınır?
Müşteri şehir merkezindeki bir otogarı, limanı ya da özel bir adresi belirtirse talebin türü değişir. Havalimanı terminali için yeterli olan bilgi, bu noktalarda yetersiz kalır. Kapı numarası yerine girişin, kaldırımın ya da bekleme noktasının tarif edilmesi gerekir. Bu tür talepler aynı akışa sokulursa, asistan eksik adresi tamamlanmış gibi işleyebilir.
Bu nedenle havalimanı dışı karşılamalar için ayrı bir kontrol listesi tanımlamak faydalıdır. Liste, adresin açık yazılıp yazılmadığını, buluşma yerinin müşteriyle teyit edilip edilmediğini ve bekleme süresi kuralının bilinip bilinmediğini sorar. Ekip bu listeyi onaylamadan asistanın adresi “tam” olarak işaretlemesi doğru değildir.
Zaman Dilimi Ve Gecikme Riskini Ölçmek
Saat farkı ve gece geçişi, yanlış tarih üretmenin en yaygın nedenlerindendir. Kalkış yerinin saati ile varış yerinin saati farklı olabilir ve gece yarısını geçen uçuşlarda tarih kayabilir. Riski ölçmek için talepte kaç saatlik tampon bırakıldığı, iniş saatinin yerel mi yoksa kalkış yerinin saatine göre mi yazıldığı sorulmalıdır.
Gecikme bilgisi yoksa gecikme riski “bilinmiyor” olarak yazılmalıdır. Tahmini bir süreyi kesin değer gibi girmek, karşılama planını yanıltır. Müşterinin verdiği bilgi ile ekibin doğruladığı bilgi aynı alanda tutulmamalı; ikisi ayrı etiketlerle görünmelidir.
Kaynak Olarak Müşteri Beyanı, Acente Kaydı Ve Canlı Veri
Bir talepte üç farklı kaynak bulunabilir: müşterinin beyanı, acentenin kendi kayıtları ve varsa canlı bir servisten gelen durum bilgisi. Her birinin güvenilirliği farklıdır ve tek bir alanda karıştırılmamalıdır. Üç kaynak çeliştiğinde, en yeni kaydı otomatik olarak esas almak doğru değildir; hangi kaynağın operasyonca belirlendiği önceden tanımlanmalıdır.
Müşteri uçuş saatinin değiştiğini söylerse bu bilgi bir not olarak alınır. Yeni saat ekip tarafından teyit edilmeden kesin sayılmaz. Canlı veri bağlantısı yoksa asistanın “uçak indi” ya da “gecikme yok” gibi bir ifade kullanması doğru olmaz; bu alan bilinmiyor olarak kalır.
Ekip Sorumluluğunu Dağıtmak
Talep özeti hazırlandıktan sonra işin kimde olduğu belirsiz kalırsa, en iyi özet bile sahipsiz kalır. Vardiya, sorumlu kişi ve kapanış kriteri baştan yazılmalıdır. Kapanış kriteri, yalnızca bildirimin görülmesi değil, araç ve saat onayının verilmesi olmalıdır.
Ayrıca aynı yolcunun farklı kanallardan gelen talepleri ekipte birleşmez. Mükerrer kayıtların ayıklanması da bu sorumluluğun parçasıdır. Konuşma bildirimlerinin hangi koşulla ulaştığını bilmeyen bir ekip, geç kalan talepleri fark etmeyebilir.
Temsili Konuşma: Gece Varışında Minibüs Sorusu
Aşağıdaki görüşme TEMSİLİDİR; gerçek bir müşteri kaydı değildir ve gerçek bir işlemi göstermez.
Müşteri: Gece yarısından sonra İzmir’e iniyoruz, 5 kişiyiz ve iki bisikletimiz var. Otogara kadar alınabilir miyiz?
Asistan: Anladım: gece geç saatte iniş, 5 yolcu ve 2 bisiklet. Önce iniş tarihini gün, ay ve yıl olarak, yerel saatini tek değer olarak yazar mısınız? Bisikletlerin boyutunu ve buluşmanın havalimanı çıkışında mı yoksa otogarda mı olacağını da belirtin. Bu bilgiler ekibin araç değerlendirmesi için gerekli; bu konuşma kesin bir araç ayırmaz.
Müşteri: 15 Haziran 2027, yerel saat 00.40. Buluşma havalimanı çıkışı olsun.
Asistan: Teşekkürler. Talebi özetliyorum: havalimanı çıkışı, 5 yolcu, 2 bisiklet, 15 Haziran 2027 saat 00.40 yerel. Otogara gidiş bölümü için adres ve bekleme noktasını da teyit etmek gerekir. Özet ekip değerlendirmesi için hazır; araç ve saat onayı operasyondan gelecektir.
Bu örnekte asıl dikkat edilmesi gereken, gece saatinin ve bisiklet notunun ayrı tutulmasıdır. Müşterinin ikinci bir adres vermesi, talebi yeni bir kapsama taşır ve bu da ayrı bir kontrol gerektirir.
Test Planı Ve Karar Listesi
Seçilen alternatifi canlıya almadan önce, gerçek talep türlerini kapsayan bir test seti hazırlamak gerekir. Test setinde yalnız kolay senaryolar değil, gece varışları, adres değişiklikleri ve çelişkili saat bilgileri de yer almalıdır. Her senaryo için beklenen çıktının “ön özet” mi, “eksik bilgi sorusu” mu, yoksa “ekibe devir” mi olacağı önceden yazılmalıdır.
- Her alternatif için kapsam belgesi yazılsın ve kesin onay yetkisi açıkça belirtilsin.
- Gece geçişli, saat dilimi farklı ve çoklu bagajlı en az beş senaryo test edilsin.
- Havalimanı dışı adres talepleri ayrı kontrol listesinden geçirilsin.
- Gecikme ve uçuş değişikliği alanları “bilinmiyor” durumunu doğru göstersin.
- Müşteri beyanı ile ekip kaydı çeliştiğinde hangi kaynağın esas alınacağı yazılsın.
- Her talep için sorumlu kişi ve kapanış kriteri tanımlansın.
- Test sonucunda yanlış kesinleştirme görülürse alternatif yeniden değerlendirilsin.
Sonuç olarak, transfer talebinde doğru alternatif, en çok özellik sunan değil, kapsamını açıkça sınırlayan ve sorumluluğu netleştiren alternatiftir. Talep özetinin nasıl kullanılacağı için CRM talep özeti yaklaşımına, fiyat ve kapasite gibi konular için ise canlı fiyat entegrasyonu kapsamına bakmak karar sürecini netleştirir.
