Bayi ve acente kimlik ekranı (yetki, kapsam, şirket ayarı)
Panelin ilk ekranı, bayi ve acente kullanıcılarını doğru yetkilendirmelidir. “Şirket profili” ekranında; şirket adı, muhasebe notu, çalışma saatleri (varsa), iptal/refund kuralları için referans kodları ve servis alanı (bölge/rota) tutulmalıdır. “Yetki matrisi” ekranında kullanıcıya rol atanır: yalnızca fiyat görme, rezervasyon oluşturma, rezervasyon onaylama, özel fiyat verme, iptal talebi oluşturma gibi izinler net olmalıdır. Bu ekran aynı zamanda “bağlı bayiler” listesini de içermeli; bir acente tek panelden birden fazla bayi adına işlem yapıyorsa her bayi için ayrı fiyat/rezervasyon limitleri tanımlanmalıdır. Karar ölçütü: Aynı oturumdan birden fazla bayinin fiyat veya rezervasyonuna erişim engellenmeli; yetki ihlali kolayca tespit edilebilir olmalıdır.
Bayi rezervasyon takvimi ve hızlı oluşturma
Rezervasyon ekranı iki ana parçada çalışmalıdır: takvim görünümü ve hızlı oluşturma formu. Takvim ekranında rota, tarih, saat aralığı ve araç/tip gibi filtreler olmalı; gün içinde yoğunluk durumları görsel etiketle gösterilebilir. Hızlı oluşturma formunda zorunlu alanlar: kalkış/biniş noktası, varış noktası, tarih-saat, yolcu sayısı, çocuk/ek bagaj opsiyonları, müşteri adı/iletişim ve ödeme tipi. “Kaydet” sonrası mutlaka bir doğrulama özet kartı gelmelidir: fiyat kaynağı (standart mı özel mi), opsiyonlar ve toplam tutar. Operasyon adımı: acente önce müsaitlik kontrolünü görür, sonra rezervasyonu oluşturur ve sonrasında ilgili durum adımına geçer. Sık hata: saat dilimi ve tarih formatı karıştığında “yanlış gün rezervasyonu” oluşur; bunu engellemek için UI’da saat alanı yerel saat olarak sabitlenmeli ve tarih önizlemesi net verilmelidir.
Fiyat ekranı: standart fiyatlar, özel fiyat ve indirim mantığı
Fiyat görme ekranı “rota + tarih + opsiyon” kombinasyonuna göre çalışmalıdır. Standart fiyat tablosu; transfer tipi, yolcu sayısı, ek bagaj/çocuk gibi kalemlere göre parçalara ayrılmış olmalıdır. Özel fiyat için ayrıca bir ekran önerilir: “Özel Fiyat Tanımları”. Burada bayi, rota, geçerlilik tarih aralığı ve uygulanacak fiyat/indirim yüzdesi tanımlanır. Önemli nokta: özel fiyat önceliği kuralı ekranın içinde açıklanmalı. Aynı anda birden fazla kural varsa hangisi geçerli olur? UI, seçimden önce “uygulanan kural” etiketini göstermeli. Neptün Transfer tarafında bu mantık; rezervasyon ekranıyla birebir aynı fiyat hesap sonucunu üretmelidir. Sık hata: özel fiyatın yalnızca teklif ekranında görünmesi ama rezervasyon onayı sırasında farklı hesaplanmasıdır; tek bir fiyat servisinden sonuç üretip aynı değeri hem teklif hem rezervasyonda göstermek gerekir.
Fiyat teklifi (quote) ekranı ve onay süreci
Bayi bazen anında rezervasyon istemeyebilir; bu durumda “Fiyat Teklifi” ekranı kritik olur. Teklif oluşturma akışında kullanıcı rota ve tarih seçer, sistem standart/özel fiyatı hesaplar, teklif numarası üretir. Teklifte geçerlilik süresi, iptal şartı notu ve ödeme planı (varsa) bulunmalıdır. “Teklifi gönder” adımı, panel içi durum etiketleriyle takip edilebilmelidir: Taslak, Gönderildi, Onaylandı, Süresi doldu. Onaylanan tekliften rezervasyona geçiş için “Rezervasyon oluştur” butonu olmalı; bu işlem teklif kalemlerini kopyalamalıdır. Karar ölçütü: Teklif onayından sonra fiyat değişirse bayi bilgilendirilmeli; bunun için rezervasyonla birlikte teklif snapshot’ı saklanmalıdır. Sık hata: teklif kalemleri güncellenip rezervasyon fiyatı geriye dönük değiştiğinde itiraz doğar; snapshot kayıt zorunlu olmalıdır.
Rezervasyon durumu yönetimi (pipeline) ve durum detay kartı
Durum ekranı, “liste + detay” yapısında olmalıdır. Liste görünümü; rezervasyon numarası, rota, tarih-saat, bayi, toplam tutar ve durum etiketi sunar. Durumlar örnek olarak: Oluşturuldu, Fiyat Bekleniyor, Onay Bekleniyor, Onaylandı, Şoför/operasyon planlandı, Tamamlandı, İptal edildi, Değişiklik talebi var. Detay kartında: yolcu/opsiyonlar, fiyat kırılımı, referans notları, ilgili dokümanlar (varsa), değişiklik geçmişi ve zaman damgaları gösterilir. “Durum aksiyonu” alanı; rol bazlı butonlarla kurgulanır: bayi yalnızca onay talep edebilir, acente onaylayabilir, belirli kullanıcılar iptal talebi girebilir. Sık hata: durum geçişlerinin serbest bırakılması; örneğin “Tamamlandı”dan sonra “Onaylandı”ya dönme gibi hatalar oluşur. Bu yüzden geçiş matrisi UI’da ve servis tarafında kontrol edilmelidir.
Müsaitlik ve kapasite ekranı (rota bazlı doğrulama)
Müsaitlik ekranı, rezervasyon hatalarını erken kesmek için gereklidir. Burada “rota + tarih + saat aralığı” seçildiğinde kapasite durumu gösterilir: müsait, sınırlı, dolu. Ayr��ca tercih edilen transfer tipi (araç sınıfı) için seçenekler listelenmelidir. Sınırlı durumda sistem; alternatif saat önerisi veya opsiyon kısıtlarını not etmelidir. Operasyon adımı: acente önce müsaitlik görür, sonra rezervasyon oluşturur; rezervasyon oluşturulurken tekrar doğrulama yapılarak “yarış durumu” (double booking) engellenir. Sık hata: müsaitlik sonucu ile rezervasyon işlemi aynı anda güncellenmezse iki kullanıcı aynı kapasiteyi görüp oluşturabilir. Çözüm: rezervasyon sırasında atomik kontrol ve kilitleme mantığı uygulanmalıdır.
Geçmiş işler ekranı: arama, iade/iptal ve rapor görünümü
Geçmiş işler ekranı; tarih aralığı, bayi, rota, rezervasyon numarası ve durum filtreleriyle arama sağlamalıdır. Sonuçlarda temel bilgiler: oluşturulma tarihi, tamamlanma/iptal tarihi, toplam tutar ve bakiye/ödeme durumu (varsa). İptal veya iade süreci varsa “Talep geçmişi” sekmesi bulunmalı; her talepte gerekçe, işlem adımı ve dokümanlar izlenebilmelidir. İki rapor türü önerilir: “Rezervasyon kırılımı” (gün/rota/transfer tipi) ve “Özel fiyat kullanım oranı” (hangi rotalarda özel fiyat devreye girdi). Sık hata: geçmişteki fiyatın artık değişen fiyat tablosuna göre yeniden hesaplanması; geçmiş işlerde fiyat snapshot saklanmalı ve raporlar o snapshot’ı kullanmalıdır. Neptün Medya için bu ekranlar, bayi tarafında itirazı azaltan en net kanıttır.
Bildirimler, değişiklik günlüğü ve dokümanlar (iletişim paneli)
Panelde bildirimler, kullanıcıların aksiyon almasını sağlar. “Bildirimler” ekranı; yeni rezervasyon onayı, fiyat değişikliği uyarısı, iptal talebi yanıtı ve durum güncellemesi gibi olayları göstermelidir. Her bildirimde işlem linki olmalı; tıklanınca ilgili rezervasyon detay kartına gidilmelidir. “Değişiklik günlüğü” sekmesi özellikle önemlidir: rezervasyon kalemleri, yolcu sayısı, opsiyonlar, fiyat kırılımı ve durum geçişleri zaman damgasıyla kaydedilmeli. Dokümanlar gerekiyorsa; teklif, onay mesajı, operasyon notu gibi kalemler klasörlenebilir. Sık hata: kullanıcıların e-posta beklemesi; panel içinde takip edilebilirlik zayıflarsa operasyon gecikir. Bu nedenle bildirimler hem panelde listelenmeli hem de okunma durumu tutulmalıdır.
Uygulama sonrası kontrol listesi
- Mobil görünüm, form ve WhatsApp yönlendirmeleri test edilir.
- Title, description, canonical ve sitemap kayıtları kontrol edilir.
- Kırık link, hatalı görsel ve boş CTA alanı bırakılmaz.
- İçerikler gerçek hizmet kapsamıyla uyumlu kalır.