Problem

Küçük bir tur acentesinin işi tanıtımla bitmiyor. Tur ilanını yayınlamak sadece başlangıç; arkasında rezervasyon talebi, yolcu bilgileri, pasaport ve vize takibi, parça parça gelen ödemeler, kafile listeleri ve otel oda dağılımı var. Bu işlerin çoğu WhatsApp mesajları ve Excel dosyaları arasında yürüyor — ve aynı yolcunun bilgisi dört ayrı yerde tutuluyor.

Ayrıca acentenin kendisi de sabit değildi: iş umre turlarıyla başlamıştı, sonra genel tur satışına açıldı. Bu, sitenin ilk kurulduğu haliyle kalamayacağı anlamına geliyordu.

Çözüm

Vitrin ve arka ofisi tek bir Laravel uygulamasında birleştirdim. Ziyaretçi tarafında kategorili tur vitrini var: şehir, tarih, süre, bütçe ve vize dahil mi filtreleriyle daraltılıyor, tur detayında gün gün program, oteller, fiyata dahil olanlar ve galeri duruyor. Rezervasyon talebi aynı sayfadan, yolcu adlarıyla birlikte bırakılıyor; ziyaretçi sonrasında rezervasyon numarasıyla durumunu sorgulayabiliyor. Blog, sık sorulan sorular, referanslar ve iletişim formu da aynı panelden yönetiliyor.

Asıl kazanç yönetim tarafında: acente rezervasyonu onayladığı anda, talepteki yolcu bilgilerinden yolcu kayıtları otomatik açılıyor. Yani veri bir kez giriliyor, sonra pasaport bilgisi, vize durumu, ödeme geçmişi ve oda ataması hep aynı kaydın üzerinde büyüyor. Ödeme almak, rezervasyonu onaylamak/iptal etmek gibi işlemler tek tek ekranlar değil, rezervasyon kaydının üzerindeki adımlar.

Acentenin umreden genel tura açılması, veri modelinde de karşılık buldu: otel şehri sabit bir listeden serbest alana çevrildi, turlara kategori, para birimi ve varış noktası eklendi. Eski /paketler adresleri ise silinmedi — kalıcı yönlendirmeyle yeni /turlar adreslerine taşındı, böylece arama motorlarında birikmiş adresler kırılmadı.

Teknoloji

Laravel 13Filament 4PHP 8.3 LivewireMySQL Tailwind CSS 4Alpine.jsVite

Öne Çıkan Detay

Panelin en ilginç ekranı oda planlama. Onaylanmış rezervasyonlardaki yolcuları otel odalarına dağıtmak, göründüğünden zor bir problem: odalar iki, üç ve dört kişilik; gruplar bölünmemeli; boş yatak sayısı en aza inmeli. Bunu "önce en kalabalık grubu yerleştir, açık bir odaya sığdırmayı dene, sığmazsa yeni oda aç" mantığıyla otomatikleştirdim — klasik bir yerleştirme algoritması, ama asıl değeri kod tarafında değil.

Asıl değer, algoritmaya konulan alan kuralında: aynı rezervasyondan gelen kişiler aynı odayı paylaşabilir (aile sayılırlar), farklı rezervasyonlardan gelenler ise ancak cinsiyetleri uyuyorsa aynı odaya konur. Bu kuralı hiçbir genel amaçlı yerleştirme kütüphanesi bilemez; acenteyle konuşmadan da yazılamaz. Otomatik dağıtımdan sonra acente yolcuları elle de taşıyabiliyor — sistem kararı veriyor, son sözü insan söylüyor.

Aynı "gerçek işi tanı" yaklaşımı ufak yerlerde de var: yönetim panelindeki dışa aktarma, Türkçe Excel'in beklediği biçimde üretiliyor — çünkü çıktının açılmaması, çıktının olmamasıyla aynı şey. Kontrol paneli de acentenin gerçekten baktığı şeyi gösteriyor: bekleyen rezervasyonlar, tahsil edilmemiş tutar ve altı ay içinde süresi dolacak pasaportlar.

Görünürlük Tarafı

Bir acente sitesi için bulunabilirlik, özellik listesinden daha kritik. Site haritası ve robots dosyası veritabanından dinamik üretiliyor; her tur ve blog yazısı yayımlandığı anda listeye giriyor. Tur sayfaları arama motorlarına yapılandırılmış veri olarak da sunuluyor ve kontenjan dolduğunda bunu ilan ediyor. Başlık, açıklama, sosyal medya görseli ve analitik kodu gibi alanlar koda gömülü değil; acentenin kendi paneldeki ayarlar ekranından değiştirebildiği alanlar.

Benzer bir problemi konuşalım

Kapsamı belirsiz bir ürün fikri ya da dijitalleşmesi gereken bir süreç varsa, bir e-posta yeterli.