Bir restoranın kendi sipariş altyapısını kurmak

Başlangıç noktası

Restoranların online sipariş tarafındaki en büyük sorunu genelde teknik değil, ekonomik: pazaryeri platformları sipariş başına komisyon alıyor ve müşteri verisi restoranın elinde kalmıyor. Her Mutfak bu döngüden çıkmak, siparişi kendi alan adı üzerinden almak istedi.

Karar, sıfırdan bir sipariş yazılımı yazmak yerine WooCommerce'i çekirdek olarak kullanmak oldu. Sepet, stok, sipariş durumu, vergi ve iade gibi konular WooCommerce'te zaten olgun. Yazılması gereken şey, bu çekirdeğin bilmediği restoran işiydi: yemek kartları, mutfak ekranı, kurye ve vardiya personeli.

Site ikiye ayrıldı. Tanıtım ve menü tarafı olan hermutfak.com statik HTML olarak, sipariş tarafı olan siparis.hermutfak.com ise WordPress üzerinde tutuldu. Böylece pazarlama sayfaları WordPress'in yükünü taşımıyor, sipariş sistemi de tanıtım sayfası her değiştiğinde risk almıyor.

Yemek kartı ödemesi

Türkiye'de kurumsal çalışanların büyük bölümü öğle yemeğini Multinet, Sodexo, Setcard gibi yemek kartlarıyla ödüyor. Bu kartları kabul etmeyen bir restoran sipariş sitesi, hedef kitlesinin önemli bir kısmını daha ilk adımda kaybediyor. WooCommerce'in hazır ödeme geçitleri arasında bu kartlar yok.

Bu yüzden Multinet için özel bir WooCommerce ödeme geçidi (payment gateway) eklentisi yazıldı. Eklenti WC_Payment_Gateway sınıfını genişletiyor ve şu akışı yönetiyor:

• Ödeme adımında yemek kartı seçeneğinin ayrı bir yöntem olarak görünmesi
• Multinet tarafına işlem başlatma isteğinin gönderilmesi ve kullanıcının doğrulama ekranına yönlendirilmesi
• Dönüş adımında işlemin gerçekten onaylandığının sağlayıcı tarafından teyit edilmesi — kullanıcının tarayıcısından gelen bilgiye güvenilmez, işlem durumu sunucu tarafında sorgulanır
• Onay gelirse WooCommerce siparişinin ödendi olarak işaretlenmesi ve mutfağa düşmesi
• Hata veya iptal durumunda siparişin ödenmemiş kalması ve müşteriye anlaşılır bir mesaj gösterilmesi

Kritik nokta son iki madde. Ödeme entegrasyonlarında en sık yapılan hata, sağlayıcının kullanıcıyı geri yönlendirdiği adresteki parametrelere bakıp siparişi ödendi saymak. Bu adres kullanıcının tarayıcısından geçtiği için üzerinde oynanabilir. Doğru davranış, dönüş adımında sağlayıcıya ayrı bir sunucu-sunucu sorgusu atıp işlemin durumunu oradan öğrenmek. Bu vakada akış bu şekilde kuruldu.

Mutfak paneli

Sipariş alındıktan sonraki gerçek problem mutfakta başlıyor. WooCommerce'in yönetici sipariş listesi bir e-ticaret deposu için tasarlanmış; ekranın başında duran ve elleri dolu olan bir mutfak personeli için değil.

Bu yüzden ayrı bir mutfak paneli geliştirildi. Panelin tasarım kararları doğrudan mutfakta gözlemlenen ihtiyaçlardan çıktı:

• Sadece bugün. Panel varsayılan olarak yalnızca günün siparişlerini gösteriyor. Dünün siparişleri ekranı kirletmiyor.
• Bekleme süresi ve renk kodu. Her siparişin üzerinde ne kadar süredir beklediği yazıyor ve süre uzadıkça kart rengi değişiyor. Personel listeyi okumadan, ekrana bakar bakmaz geciken siparişi görüyor.
• YENİ rozeti. Yeni düşen sipariş belirgin biçimde işaretleniyor, böylece yoğun saatte gözden kaçmıyor.
• Titremeyen yenileme. Panel kendini düzenli olarak tazeliyor; ancak ilk sürümde her tazelemede tüm liste yeniden çizildiği için ekran titriyordu. Yenileme, listeyi baştan çizmek yerine yalnızca değişen kartları güncelleyecek şekilde düzeltildi.

Bu tür bir panelde asıl mühendislik işi veri tarafında değil; ekranın yoğun bir serviste okunabilir kalmasında.

Kurye ve teslimat

Sipariş hazır olduğunda dağıtım tarafına geçmesi gerekiyor. Bunun için kurye/dağıtım sistemine sipariş aktaran bir webhook entegrasyonu yazıldı. WooCommerce sipariş durumu ilgili aşamaya geldiğinde, sipariş bilgisi dağıtım tarafına aktarılıyor ve teslimat süreci restoran panelinden ayrı bir sisteme devrediliyor.

Entegrasyonun ayrı bir eklenti olarak yazılmasının nedeni sürdürülebilirlik: dağıtım tarafı değiştiğinde ya da sözleşme sona erdiğinde, tek bir eklenti devre dışı bırakılıyor. Sipariş sisteminin geri kalanına dokunulmuyor.

Personel yetkileri

Restoranda paneli açan herkesin aynı şeyi görmesi doğru değil. Vardiyadaki bir personelin siparişleri yönetmesi gerekiyor; günlük ciroyu, toplam satış raporlarını veya müşteri veri tabanının tamamını görmesi gerekmiyor.

Bunun için rol bazlı sınırlı personel erişimi kuruldu. Hazır tanımlı yetki setleri (preset) üzerinden çalışan bir yapı; personel rolüne atanan kişi sipariş akışını yönetebiliyor, ancak ciro ve rapor ekranları bu roller için gizleniyor. WordPress'in kendi yetenek (capability) sistemi üzerine oturduğu için, yeni bir personel eklemek yalnızca rol atamaktan ibaret.

Hız ve mobil

Yemek siparişinin ezici çoğunluğu telefondan, çoğu zaman mobil veriyle veriliyor. Bu yüzden performans, bu projede kozmetik bir konu değil doğrudan sipariş kaybı meselesi.

Yapılan başlıca iyileştirmeler:

• Görsel formatı. Yükleme sırasında sunucu tarafında WebP üretimi devreye alındı. Yemek fotoğrafları bu sitenin en ağır varlığı; format değişimi tek başına ciddi bir kazanç sağlıyor.
• LCP ön yüklemesi. Sayfanın ilk görünen büyük görseli (Largest Contentful Paint öğesi) tarayıcıya preload ile bildirildi; tarayıcı bu görseli CSS'i çözmeyi beklemeden istemeye başlıyor.
• Logo kaynaklı düzen kayması. Başlıktaki logonun boyutu belirtilmediği için sayfa yüklenirken içerik zıplıyordu (Cumulative Layout Shift). Sabit ölçü verilerek düzeltildi.
• Canlı açık/kapalı rozeti. Restoranın o an sipariş alıp almadığını gösteren rozet, sayfa önbelleğe alınsa bile doğru değeri göstermek zorunda. Bu yüzden rozet, sayfanın geri kalanından bağımsız olarak canlı veri çeken ayrı bir bileşen hâline getirildi. Önbellekten gelen sayfada "açık" yazarken restoranın kapalı olması, bu tür sitelerde en sık görülen ve en çok şikâyet üreten hatalardan biri.

Sonuç

Her Mutfak bugün siparişlerini kendi alan adı üzerinden, kendi ödeme geçitleriyle ve kendi müşteri verisiyle alıyor. Sistem canlı ve aktif kullanımda.

Bu projenin devredilebilir dersi şu: bir restoran sipariş sistemi kurarken sıfırdan yazılım yazmak nadiren doğru karar. Doğru karar, olgun bir çekirdeği (WooCommerce) almak ve yalnızca o çekirdeğin bilmediği işi — yemek kartı, mutfak ekranı, kurye, vardiya personeli — özel olarak yazmak. Böylece bakım yükü küçük kalıyor ve sistem restoranla birlikte büyüyebiliyor.