Catering & toplu yemek için CRM: etkinlik, menü ve tekrar eden kurumsal müşteri
Tarihe bağlı catering işinde teklif, menü ve kaporayı kaçırmadan yönetmenin ve tekrar eden kurumsal müşteriyi elde tutmanın pratik yolları.
Bir catering işinde en pahalı hata, kaybedilen bir teklif değildir; aynı cumartesiye iki düğün almaktır. Tarih dolduğunda geri dönüşü yoktur, telafisi de yoktur. İşte bu yüzden catering CRM fikri, sıradan bir satış yazılımından farklı düşünülmek zorunda: burada takvim, menü ve kişi sayısı en az fiyat kadar belirleyicidir.
Bu yazıda, etkinliğe ve tarihe bağlı çalışan bir catering ya da toplu yemek işletmesinin teklif, menü ve kurumsal müşteri ilişkisini tek yerden nasıl yöneteceğini konuşacağız; hangi noktada bir sisteme geçmenin işe yaradığını, hangi noktada gereksiz bir yük olduğunu da açıkça söyleyeceğiz.
Catering, sıradan bir satış hunisi değildir
Çoğu satış yazılımı şu varsayımla kurulur: elinizde bir ürün vardır, teorik olarak sınırsız satabilirsiniz, tek mesele daha çok "evet" toplamaktır. Catering'de bu mantık tersine döner. Bir günde kaç etkinliğe fiziksel olarak yetişebileceğiniz bellidir; mutfağın, servis ekibinin ve aracın bir kapasitesi vardır. Yani her "evet", bazen bir sonraki "evet"i imkânsız kılar.
Bunun pratik sonucu nettir: teklifleri yalnızca rakama göre değil, tarihe ve kapasiteye göre yönetmeniz gerekir. Diyelim 12 Eylül cumartesi için üç ayrı talep geldi; hangisini onaylayacağınıza fiyat kadar lojistik de karar verir. 400 kişilik bir düğünle 80 kişilik bir kurumsal yemeği aynı güne alamazsınız. Kapasiteyi zorlayan bir "evet" çoğu zaman sessiz bir "hayır"a dönüşür: kalite düşer, ekip yetişemez, bir sonraki müşteri hayal kırıklığıyla ayrılır. Bunu bir elektronik tabloda takip etmek, ay ortasında "acaba bu tarih boş muydu" diye telefon karıştırmak demektir.
Tarihe bağlı, çoğu zaman tek seferlik ve yüksek bütçeli işler söz konusu olduğunda catering'in mantığı etkinlik ve düğün organizasyonundaki iş akışına çok benzer: kaçırılan bir tarih, doğrudan kaçırılan bir cirodur ve o parayı bir daha o günden çıkaramazsınız.
Talepten kaporaya: akışı netleştirin
Bir catering talebi genellikle WhatsApp'tan düşer: "23 Kasım'da 150 kişilik bir açılış kokteyli düşünüyoruz, fiyat alabilir miyiz?" Bu mesajın nereye gittiği aslında her şeyi belirler. Kafanızda tutarsanız yoğun bir günde unutulur; kişisel telefonunuza gelirse ekibin geri kalanı hiç görmez. Kayıt altına alınmayan bir talep, çoğu zaman hiç gelmemiş sayılır.
En sağlıklısı, işi basit ve tekrarlanabilir aşamalara bölmektir. Böylece "hangi teklif nerede kaldı, kim ödemeyi bekliyor, bu hafta neyi teyit etmem lazım" sorularının cevabı tek bakışta görünür. Aşağıdaki akış neredeyse her catering işinde aynıdır.
- Talep: Tarih, tahmini kişi sayısı, etkinlik türü ve iletişim bilgisi ilk temasta toplanır; eksik bir bilgi varsa hemen sorulur, "sonra hallederiz" denmez.
- Menü ve teklif: Kişi başı fiyat, seçilen menü ve ekstra kalemler yazılı ve tek bir teklife dönüşür; sözlü rakam vermek en sık yapılan hatadır.
- Kapora: Tarihi kilitleyen şey söz değil, kapora ödemesidir; bu adım atlanırsa tarih hep "yumuşak" kalır ve son anda boşa düşebilir.
- Etkinlik: Kesin kişi sayısı, mutfak hazırlık listesi ve ekip görevlendirmesi bu aşamada kesinleşir.
- Sonraki iş: Etkinlikten sonra geri bildirim alınır ve bir sonraki tarih için kapı bilinçli olarak açık bırakılır.
Menü ve kişi sayısı: teklif tek seferde bitmez
Catering teklifi biraz matbaadaki baskı provasına benzer: neredeyse hiçbir zaman ilk hâliyle onaylanmaz. Müşteri birkaç gün içinde "150 kişiydi ama 180'e çıktık", "tatlı tabağını çıkaralım, yerine ara sıcak koyalım", "12 kişi vejetaryen, ayrı menü lazım" der. Her revizyon hem fiyatı hem mutfak planını değiştirir.
Bu yüzden teklifin sürümlerini izleyebilmek kritik. Hangi menü, kaç kişiyle, hangi tarih için konuşuldu? Müşteri üç gün sonra aradığında elinizde tek ve güncel bir kayıt olmalı, dört farklı WhatsApp mesajını yukarı kaydırmak zorunda kalmamalısınız. Revizyon ve onay döngüsünün nasıl kurulduğunu matbaa için CRM örneğinde ayrıntılı anlatmıştık; catering'de mantık birebir aynıdır, sadece "prova" yerine "menü" vardır.
Kişi başı fiyatın gizli tuzağı
Kişi başı fiyat müşteriye anlatması kolaydır ama asıl risk sabit maliyetlerde saklıdır. Servis ekibi, ulaşım, ekipman ve masa-sandalye kirası; etkinlik 50 kişilik de olsa 200 kişilik de olsa büyük ölçüde vardır. Bu kalemleri teklifte ayrı göstermek, küçük etkinliklerde farkında olmadan zarar etmeyi önler ve müşteriye de fiyatın neden o rakam olduğunu açıklar.
Kapora ve takvim: o tarihi kim kilitledi?
Catering'de en sinir bozucu durum, telefonla "ayırdım, merak etmeyin" denen ama kaporası hiç yatmamış tarihlerdir. Müşteri son hafta vazgeçer; siz o cumartesiye güvenip başka üç talebi geri çevirdiğiniz için iki kere kaybedersiniz. Kaporayı en baştan netleştirmek — diyelim toplam bedelin üçte biri — hem müşterinin ciddiyetini ölçer hem de nakit akışınızı rahatlatır. Diyelim 250 kişilik bir düğün menüsü konuştunuz; makul bir kapora alındığı anda o cumartesi gerçekten sizindir, müşteri de yatırdığı parayı kolayca riske atmaz.
Kaporayı ve takvimi ayrı düşünmek en büyük hatalardan biri. Bir tarih ancak ödeme geldiğinde "dolu" sayılmalı; o ana kadar "opsiyonlu" kalmalı ve ekipteki herkes bunu aynı ekranda görebilmeli. Depozitonun rezervasyon takvimiyle birlikte nasıl işlediğini oto kiralama için CRM yazısında da ele almıştık; oradaki "araç müsait mi" sorusu, burada "o gün mutfak ve ekip müsait mi" sorusuna karşılık gelir.
Otomatik hatırlatmalar bu noktada gerçekten para kazandırır: kapora için son ödeme tarihi, kalan bakiyenin tahsilatı, etkinlikten bir hafta önce kesin kişi sayısı teyidi, bir gün önce ekip ve teslimat saati. Bunların hiçbiri insan hafızasına bırakılacak şeyler değildir; biri unutulduğunda maliyeti doğrudan masaya yansır.
Bir cumartesiyi daha boşa harcamayın
Rocketly, catering taleplerini tarih, menü ve kaporayla birlikte tek ekranda toplar.
Rocketly'yi ücretsiz deneyinAsıl para, tekrar eden kurumsal müşteride
Tek seferlik düğünler kâğıt üzerinde büyük rakamlardır, ama bir catering işletmesini asıl ayakta tutan çoğu zaman kurumsal tekrar eden müşteridir: her ay toplantı ikramı isteyen bir reklam ajansı, üç ayda bir bayi buluşması düzenleyen bir dağıtım firması, yıl sonu yemeğini yıllardır aynı yere veren bir şirket. Bu ilişkiler öngörülebilir gelir demektir.
Sorun şu ki bu ilişkiler unutulmaya çok müsaittir. Geçen sene hangi firmaya glutensiz menü hazırladığınızı, kimin bütçe tavanının ne olduğunu, hangi yöneticinin sunum detaylarına takıldığını hatırlamanız gerekir. Müşteri kartında geçmiş etkinlikler, tercih edilen menüler ve küçük notlar duruyorsa, bir sonraki teklif on dakikada ve isabetle çıkar. Örneğin her yıl aynı firmanın 300 kişilik bayi toplantısını yapıyorsanız, geçen seneki menüyü, beğenilmeyen tek tabağı ve onaylanan bütçeyi hatırlamak bu yılki teklifi hem hızlı hem güvenli kılar.
- Yıldönümü hatırlatmaları: Bir firma için geçen yıl yaptığınız etkinliğin tarihinden birkaç hafta önce atılan proaktif bir mesaj, çoğu zaman sizi rakiplerinizin önüne geçirir.
- Tercih notları: "Sunum tabakları beyaz olsun", "kahve molası tam 15.30'da" gibi küçük ayrıntıları ikinci seferde hatırlamak, sizi kolay kolay değiştirilmeyen bir tedarikçi yapar.
- Kurumsal muhatabın değişmesi: Firmadaki iletişim kişisi işten ayrılsa bile ilişki firma adına kayıtlı kalır; yeni gelen kişiye geçmişi sıfırdan anlatmak zorunda kalmazsınız.
Toplu yemek: sözleşmeli ve periyodik taraf
Etkinlik catering'i tarih odaklıysa, toplu yemek — fabrika, okul, ofis öğle yemeği — tamamen periyot odaklıdır. Burada her iş günü belli sayıda tabak çıkar, günlük kişi sayısı dalgalanır, aylık faturalama ve sözleşme yenileme öne çıkar. Tek bir etkinliği değil, aylarca sürecek bir ilişkiyi yönetirsiniz. Bir okulda sınav haftası, bir fabrikada vardiya değişikliği ya da resmi tatil günlük tabak sayısını her hafta değiştirir; bu dalgalanmayı kayıt altında tutmak hem mutfağı hem faturayı doğru planlamanızı sağlar.
Bu tarafın ihtiyaçları, periyodik hizmet veren başka sektörlerinkine şaşırtıcı derecede benzer. Örneğin temizlik firmaları için CRM tarafındaki tekrar eden iş, ekip planlama ve sözleşme yenileme mantığı toplu yemekte de birebir geçerlidir; tek fark, sunulan hizmetin yemek olmasıdır.
Sözleşme bitiş tarihleri, aylık hakediş ve günlük tabak sayısı gibi veriler tek yerde durduğunda iki şey kazanırsınız: yenileme görüşmesine rakamlarla hazırlıklı girersiniz ve kârlılığı tahmine göre değil, sözleşme bazında görürsünüz. Zararına dönen bir sözleşmeyi ancak ölçebiliyorsanız düzeltebilirsiniz.
Sezon, yoğunluk ve ne zaman gereksiz olduğu
Catering mevsimseldir. Düğün sezonu, yıl sonu kurumsal yemekleri, mezuniyetler ve bahar açılışları belli aylarda üst üste yığılır. Bu yoğunluğu önceden görebilmek — önümüzdeki üç hafta içinde kaç etkinlik, hangi günler var — ekip ve tedarik planlamasını baştan doğru kurmanızı sağlar. Sezona bağlı talep dalgalanmasını yönetmek, peyzaj ve bahçe bakımı gibi mevsimsel işlerde de aynı disiplini gerektirir.
Dürüst olmak gerekirse, bir yazılım her işletme için şart değildir. Ayda iki etkinlik yapıyorsanız ve her müşterinizi ismen tanıyorsanız, paylaşımlı bir takvim ve düzenli tutulan bir teklif şablonu uzun süre yeterli olur. Bir sisteme geçmenin anlamı, talep sayısı hafızanızı ve elektronik tablonuzu aşmaya başladığında ortaya çıkar; ondan önce kurulan ağır bir sistem çoğu zaman kullanılmadan kalır.
Bir catering işini batıran şey genelde kötü yemek değildir; unutulan bir kapora, karışan bir menü ya da iki kere satılmış bir cumartesidir.
Sıkça sorulan sorular
Küçük bir catering işletmesi için CRM gerçekten gerekli mi?
Ayda birkaç etkinlik yapıyorsanız ve hepsini rahatça hatırlıyorsanız, iyi bir takvim ve tek bir teklif şablonu yeterli olabilir. Talepler farklı kanallardan gelmeye ve tarihler çakışmaya başladığında bir sisteme geçmek mantıklı olur.
Menü ve kişi sayısı sürekli değişiyor; bunu nasıl takip ederim?
Teklifi tek ve güncel bir kayıt olarak tutun, her revizyonu tarih ve kişi sayısıyla birlikte not edin. Böylece müşteri üç gün sonra aradığında hangi sürümü konuştuğunuzu bir bakışta görürsünüz.
Kapora oranı ne olmalı?
Sabit bir kural yok; birçok işletme toplam bedelin belli bir yüzdesini —örneğin üçte birini— peşin alır. Önemli olan, tarihi ancak kapora geldiğinde "dolu" saymak ve bunu takvime yansıtmaktır.
Toplu yemek ile etkinlik catering'i aynı sistemde yönetilebilir mi?
Evet, ama farklı mantıkla. Etkinlik tarafı tarih ve kapora odaklı, toplu yemek tarafı sözleşme ve periyot odaklıdır; ikisini de aynı müşteri kartı altında ayrı iş türleri olarak tutmak en temizidir.
Catering'de fark, yemeğin lezzetinden önce çoğu zaman görünmeyen tarafında ortaya çıkar: doğru hatırlanan bir tarih, zamanında istenen bir kapora, iki yıl sonra bile hatırlanan bir menü tercihi. Bunları tek bir yerde toplamak, Rocketly gibi bir araçla teklif, takvim ve kurumsal ilişkiyi aynı ekrana getirmek, aslında mutfağın dışındaki mutfağı düzene sokmaktır. Yemeği siz yaparsınız; sistem yalnızca hiçbir cumartesinin boşa gitmemesini sağlar.