Paket servis, oturmalı yemekten farklı bir iştir. Müşteriler oturmaz. Onları park edecek masa yoktur. Yalnızca iki şey bilmek isterler: yemek ne zaman hazır olacak ve nasıl ödeme yapacaklar. Bu iki sorunun önüne geçen her şey sürtüşmedir; sürtüşme ise siparişleri daha akıcı süreci olan rakibe kaptırır.
Son birkaç yılda paket servis için geçerli oyun planı, telefon görüşmeleri ve geliş sayaçlarından ölçeklenen bir QR-ve-sıra iş akışına doğru kaymıştır. Müşteriler bir sıra numarası alır, telefonlarında siparişlerini oluşturur, banka transferi dekontu yükleyerek öder ve numaraları çağrıldığında teslim alır. Her şey tarayıcıda çalışır; uygulama yok, karşılama noktası yok, kulaklık yok.
Bu makale, bu iş akışını gerçek bir restoranda işler kılan pratik kararları ele almaktadır.
Ayrı Paket Servis Fiyatlandırması
İlk karar, paket servis fiyatlarının oturmalı yemekle aynı olup olmayacağıdır. Pek çok ülkede yanıt hayırdır. Oturmalı yemek; tabakları, bardakları, masa hizmetini ve bir deneyimi kapsar. Paket servis ise ambalajı ve müşterinin başka bir yerde yiyeceği varsayımını kapsar. Maliyet yapıları farklıdır ve ödeme isteği de farklıdır.
Yaygın bir model, ambalaj ve paketleme emeğini karşılamak için paket serviste küçük bir artış, belki yüzde on ile on beş, uygulamaktır. Bazı restoranlar bunu tersine çevirir ve bulaşık ile masa devri tasarruf ettiği için küçük bir paket servis indirimi sunar. Her iki durumda da menü sistemi, ürün başına oturmalı yemek fiyatından ayrı, yalnızca müşteri teslim için sipariş verdiğinde görünen bir fiyat alanını desteklemelidir.
Ürünlerin ayrıca paket servis için ayrı bir uygunluk işaretçisine ihtiyacı vardır. Bazı yemekler taşınmaya uygun değildir. Sufle, narin bir karpatsyo, çok bileşenli bir tatlı tabağı, bunların hiçbiri paket servis menüsüne ait değildir. İki paralel menüyü bakımlı tutmak yerine tek bir geçiş düğmesiyle oturmalı yemek menüsünde bırakılıp paket listesinden gizlenmelidir.
İki Aşamalı Sipariş Onayı
Klasik hata, bir paket siparişini müşterinin her şeyi sonunda tamamladığı bir web sitesi ödeme süreci gibi ele almaktır. Pratikte bu başarısız olur çünkü ödeme adımı en yavaş ve en fazla hataya açık kısımdır. Banka transferleri zaman alır. Müşteri tutarı yanlış girebilir. Dekont okunaksız olabilir. Ödeme onaylanmadan sipariş kilitlenirse, mutfak restoranın hiç para almayabileceği yemekler pişirmeye başlar.
Daha iyi bir iş akışı iki aşamalı teslimdir. Birinci aşama: müşteri siparişi verir. Sistem ürünleri kaydeder, toplamı hesaplar ve müşteriye ödeme yapacağı para biriminde net bir toplam gösterir. İkinci aşama: müşteri bir ödeme dekontu yükler. Restoran dekontu manuel olarak onaylayana kadar sipariş "onay bekleniyor" durumunda kalır. Mutfak başlamaz. Müşterinin durum rozeti "Ödemenizi restoran onaylıyor" der; böylece topun kendi taraflarında değil, sizin tarafınızda olduğunu bilirler.
Bu yavaş görünür. Pratikte personel onayı on saniye alır: paneli açın, dekont görüntüsüne bakın, butona dokunun. Mutfak siparişi ödeme onaylandığı anda görür, öncesinde değil; bu tam olarak doğru andır.
Bozulmayan Ödeme Dekontu Yüklemeleri
Dekont yüklemelerinde en yaygın arıza nedeni izinlerdir. Müşteri telefonları rastgele IP adresleri kullanır. Görüntü boyutları 200 KB'dan 10 MB'a kadar değişir. Bazı müşteriler banka uygulamasının ekran görüntüsünü alır, diğerleri kağıt makbuzu kamerayla fotoğraflar, diğerleri bir sohbetten iletilen görüntüyü yapıştırır. Yükleme sistemi tüm bunları hata vermeden karşılayabilmek zorundadır.
Birkaç pratik kural. İlk olarak, birden fazla görüntü formatı kabul edin: JPEG, PNG ve WebP pratik olarak her telefon kamerasını ve ekran görüntüsü aracını kapsar. İkinci olarak, yüklemenin müşterinin telefonundan doğrudan depolama alanınıza gerçekleşmesi için birkaç dakika içinde sona eren ön imzalı yükleme URL'leri kullanın; sunucunuz araya girmez. Üçüncü olarak, URL'yi vermeden önce dosya türünü sunucu tarafında doğrulayın. Dördüncü olarak, dekontları ilerleyen bir ödeme anlaşmazlığında denetleyebilmek için net biçimde adlandırılmış bir yol altında saklayın.
Müşteri tarafındaki arayüz, çok adımlı bir form değil, "Ödeme dekontu yükle" etiketli büyük bir buton olmalıdır. Yüklemeden sonra, müşteriye yanlış ekran görüntüsü yükledileri durumunda "Değiştir" seçeneğiyle birlikte dekontu küçük resim olarak gösterin. Durum rozetleri yüklemenin çalıştığını anlamaları için hemen "Restoran onayı bekleniyor" olarak değişmelidir.
Teslim İçin Referans Kodları
Müşteri teslim almaya geldiğinde, telefonunu ekranınızdaki siparişle eşleştirmenin hızlı bir yoluna ihtiyaç duyarsınız. Sıra numarası bağırmak sakin bir restoranda işe yarar; ancak beş tane 12 numaranın sırada beklediği gürültülü bir boba çay dükkanında başarısız olur.
Karıştırılabilir karakter kümesinden altı karakterden oluşan kısa bir referans kodu bunu çözer. Sipariş verildiğinde sunucu tarafında oluşturun. Müşterinin telefonunda sıra numarasının yanında gösterin. Aynı kodu personel panelinde gösterin. Müşteri geldiğinde, telefonunu gösterir, kodları karşılaştırırsınız ve çantayı teslim edersiniz. Tüm işlem üç saniye sürer ve hiçbir zaman bağırılan isimlere dayanmaz.
Referans kodu aynı zamanda sahtekârlığa karşı işlev görür. Bir müşteri "42 numarayım" iddiasını, 42 numarayla eşleşen kodu göstermeden kanıtlayamaz. İki rastgele kişi makul hiçbir senaryoda aynı gün aynı kodla çakışamaz.
Günlük Kapanış Mutabakatı
Paket servis gelirinin banka transferleriyle her gün mutabakat yapılması gerekir. Bunu yapmanın en basit yolu, sıra panosundaki bir Geçmiş görünümüdür; belirli bir günde Teslim Edildi olarak işaretlenen her siparişi sıra numarası, referans kodu, saat, toplam ve dekont görüntüsüne bağlantıyla listeler. Bir tarih seçin, listeyi görün, günlük toplamı görün, banka hesap özeti ile çapraz kontrol edin. Günde beş dakika, ideal olarak kapanış rutininin bir parçası olarak.
Geçmişin saat dilimini doğru işlemesi gerekir. Gece yarısı yerel saatle kapanan Bangkok'taki bir restoran, o takvim günü için tüm siparişleri bir arada, UTC gece yarısında akşam yemeği servisinin ortasında bölünmemiş biçimde görmelidir. Sistem, restoranın ülkesini bilmeli ve gruplandırma için yerel saat dilimini kullanmalıdır.
Bir Şeyler Ters Gittiğinde Ne Yapmalı
Gerçek herhangi bir iş akışında, uç durumlar yaşanır. Müşteri yanlış tutarı öder. Dekont okunaksızdır. Müşteri teslim almak için gelmez. Mutfak, sipariş ile onay arasında bir üründe stok tükenmesi yaşar.
Bunların her biri için net bir yol tasarlayın. Yanlış tutar: personel siparişi açar, sorunu görür ve ya notla kısmi ödemeyi kabul eder ya da müşteriden yeniden ödeme yapmasını ister. Okunaksız dekont: personel müşteriye mesaj atar (telefon numarası varsa) ya da basitçe onaylamaz; müşteri durumunun takılı kaldığını fark edip yeniden yükler. Gelmeme: sıra kaydı, manuel olarak Teslim Edildi ya da İptal Edildi işaretlenene kadar, aktif listeden ayrıldığı noktaya kadar "hazırlanıyor" durumunda kalır.
Sipariş ile onay arasında stok tükenmesi en sancılı durumdur. En temiz yanıt, müşterinin aynı banka hesabına özür ve notla birlikte hızlı bir iadeyi kapsamaktadır. Sistemler bunu kolaylaştırmalıdır: dekontu gördükten sonra kullanabileceğiniz, müşterinin telefonunun iptali anında yansıtan bir İptal butonu.
Olumlu Senaryoyu Aşırı Optimize Etmeyin
Paket servis akışı tasarlarken her siparişin mükemmel gittiğini varsayma ve kullanıcı arayüzünü buna göre tasarlama cazibesine kapılmak kolaydır. Bu bir tuzaktır. Siparişlerin büyük çoğunluğu mükemmel gider; ancak kötü gidenler orantısız zaman tüketir ve en fazla müşteri hizmeti işi yaratır. İş akışını önce kötü durumlar etrafında oluşturun; iyi durumlar kendi kendine hallolur.
Müşterinin üç saniyede okuyabileceği net bir durum rozeti. Personelin tek bakışta ihtiyacı olan her şeyi görebildiği bir pano. Hızlı teslimat için referans kodları. Günlük kapanış mutabakatı için bir geçmiş görünümü. Artı bazı siparişlerin manuel müdahale gerektireceğine dair varsayılan bir beklenti ve sistemin o müdahaleyi imkânsız değil kolay kıldığı bilinciyle. Bunları doğru yapın; ölçeklenen bir paket servis operasyonuna sahip olursunuz.
