Ödeme adımı, güzel görünen sepetlerin sınandığı yerdir: vergiler, servis süreleri, ekstralar ve ödeme, para el değiştirmeden önce mutfağın gerçekten sunabileceğiyle örtüşmelidir. Restoran ödeme akışı genel bir mağaza entegrasyonu değildir. Menüyü, teslimatı ve ödemeyi tek bir sistemde tutan bir mimariye ihtiyaç vardır; böylece web sitesi mutfağın karşılayamayacağı hiçbir şeyi vaat etmez.
Misafirler dolu bir salonu, tereddüt eden bir ödeme adımından daha kolay affeder. "Neredeyse sipariş verdim" ile terk edilmiş bir sepet arasında yalnızca birkaç saniye vardır — bir de önemli bir soru: sipariş sisteminiz ödeme adımının sahibi mi, yoksa onu mobil dönüşümü zedeleyen gömülü bir üçüncü taraf forma mı devrediyor?
Ödeme mimarisi, doğrudan siparişin bel kemiğidir: sepet, gel-al ve teslimat, ekstralar ve seçenekler, vergiler, bahşişler, ödeme yöntemleri ve onay — hepsi kendi markanız altında, ödeme anında hiçbir pazar yeri uygulaması markası görünmeden.
Genel mağaza eklentileri restoranlarda neden başarısız olur
Restoran ödeme akışı sıradan bir online mağaza değildir. Bir kitap, müşterinin sepetinde beklerken tükenmez; bir yemek tükenebilir. Kitabın ekstrası, hazırlık süresi ya da çalışma saati yoktur. Genel mağaza sistemleri tam da bu restorana özgü detaylarda başarısız olur — mutfağın karşılayamayacağı siparişleri sessizce kabul eder:
Restoran ödeme akışının dört temel bileşeni
Güvenilir bir ödeme akışı dört sütuna dayanır. Biri eksikse, cuma akşamı bunu ortaya çıkarır:
Aşağıdaki bölümlerde her birini tek tek ele alıyoruz.
Ekranlardan daha önemlisi: durum yönetimi
Cilalı bir arayüz yeterli değildir. Önemli olan güvenilir sepet durumudur. Sipariş sürerken bir yemek tükendiğinde, misafir teslimat bölgesini değiştirdiğinde ya da gel-al ile teslimat arasında geçiş yaptığında ne olur? Sistem, canlı menüyü — stok durumu, süreler ve kapasite — sayfayı yeniden yüklemeden sepete bağlamalıdır.
Bunun çalışabilmesi için genel menü ve sepet aynı kaynaktan okunmalıdır. Aksi halde bir fiyat değişikliği ya da tükenen bir yemek ödeme adımıyla çelişir ve yanlış siparişler ekranda değil mutfakta fark edilir. Misafir geri döndüğünde kendini "unutan" bir sepet, kaybedilen gelirin en sessiz halidir.
Menü doğruluğu: yalnızca mutfağın karşılayabileceğini vaat edin
İkinci sütun en az görünen ama en çok sonuç doğuran sütundur. Sipariş sayfası menünün kendi güncelliğini yitirmiş kopyasını tutuyorsa, er ya da geç mutfağın karşılayamayacağı bir şeyi vaat eder: tükenen bir yemek, artık var olmayan bir seçenek ya da dolmuş bir zaman dilimi. Misafir bunu çok geç öğrenir ve ekip durumu servis sırasında düzeltmek zorunda kalır.
Bu yüzden ödeme adımı, bir şablonun içindeki ikinci bir varsayımlar bütünü değil, mutfakla aynı kuralları kullanmalıdır. Stok durumu, servis süreleri ve kapasite hepsi tek bir kaynaktan gelir. İşte bu, siparişi kabul eden bir sistemle yalnızca gerçekten karşılayabileceği siparişleri kabul eden bir sistem arasındaki farktır.
Markayı bozmadan ödeme
Sertifikasyon ve tokenizasyon uzman ödeme sağlayıcılarının işidir — ama adres ve deneyim yine de restoranınıza ait olmalıdır. Birinci taraf ödeme, misafirlerin "şu an hangi sitedeyim?" diye düşünmeden kartla, Apple Pay veya Google Pay ile ödeme yapabilmesi demektir. 3-D Secure gibi güvenlik kontrolleri gerektiğinde yine çalışır — bir pazar yeri uygulamasının değil, sizin markanız altında.
Bu hem bir güvenlik hem de bir dönüşüm meselesidir: öde butonundaki güven, tezgahtaki güven gibi hissettirmelidir. Sonrasında gelen şey — tekrar ziyaret — sizin kontrolünüzdeki bir uygulama, e-posta ya da sadakat programı gibi bir sebebe bağlıdır. Başkasının ödeme sayfasında ilişki işlemle birlikte biter; kendi sayfanızda ise tam da o noktada başlar.
Yoğunlukta da güvenilir
Cuma akşamı saat 19:00 gerçek yük testidir. İyi bir ödeme akışı, kararsız bir mobil bağlantıda bile yeniden denemeleri düzgün yönetir, net hata mesajları gösterir ve çift dokunuşun asla çift tahsilata dönüşmemesini sağlar. Ödemeden sonra bağlantı koparsa, ne hayalet bir sipariş oluşmalı ne de para iki kez çekilmelidir. Mimari işte burada, başarısız bir tatlı kadar görünür hale gelir — yalnızca çok daha maliyetli.
Mimarinin sahibi olun, geri dönüşü elinizde tutun
Şeffaf olmayan üçüncü taraf sistemler, başkasının kesintisi ve başkasının ücretleri demektir. Kendi sitenizdeki şeffaf bir ödeme akışı, doğrudan sipariş ekonomisini işletmenizle uyumlu tutar: ödeme markanızın ve sipariş yolculuğunuzun bir parçası kalırken, sertifikalı sağlayıcılar güvenli işlemi yürütür. Kimin sipariş verdiğini görebilir, marjın daha büyük kısmını elinizde tutabilir ve başkasının akışını kabul etmek yerine her adımı dönüşüm için iyileştirebilirsiniz.
En sık yapılan 7 ödeme hatası
- Genel bir mağaza eklentisi kullanmak, restorana özgü ihtiyaçları karşılayamaz.
- İki ayrı menü kaynağı tutmak; sipariş sayfası ve mutfak farklı bilgiler gösterir.
- Çok fazla zorunlu alan istemek ya da misafiri satın almadan önce hesap oluşturmaya zorlamak.
- Maliyetleri yalnızca sonda göstermek, ücretleri ve teslimat masraflarını baştan netleştirmek yerine.
- Ödemeyi başka bir siteye yönlendirmek, hem markayı hem güveni zedelemek.
- Çift dokunuşa karşı koruma olmaması, tek dokunuşun iki tahsilata dönüşmesine izin vermek.
- Misafir geri döndüğünde ya da ağ değiştirdiğinde sepeti kaybetmek.
Ödeme mimarisi kontrol listesi
Sıkça sorulan sorular
Hazır bir mağaza eklentisi restoran siparişleri için yeterli mi?+
En sık yapılan ödeme hatası nedir?+
Ödeme akışı kendi markamı taşırsa ödeme güvenliğinden ödün mü veririm?+
Tek bir menü kaynağı neden bu kadar önemli?+
Ödeme sırasında bağlantı koparsa ne olur?+
Ödeme, sahip olduğunuz en değerli alandır
Arayüz, misafirlerin ödeme adımını beğenip beğenmeyeceğine karar verir; mimari ise verilen sözlerin tutulup tutulmayacağına karar verir. Bir arada — tek kaynak, kendi siteniz üzerinden ödeme ve güvenli sipariş aktarımı — güzel görünen bir sipariş sayfasını, marjı ve misafir ilişkisini sizde tutan bir sisteme dönüştürür. Ödeme adımının sahibi olun, misafir ilişkisinin de sahibi olursunuz — uzun vadeli gelirin en güçlü kaldıracı.
