Otel satışında yapay zekâ: grup talepleri, teklifler ve takip e-postaları

Otel satışında yapay zekâ ile teklif hazırlama, bir dil modelinin grup ve etkinlik taleplerini okuması, gereksinimleri çıkarması, teklif metnini taslaklaması ve takip e-postalarını yazması demektir. Fiyat, oda bloğu, release tarihi veya attrition koşullarını model belirlemez; bunlar gelir kararından ve sözleşme şablonundan gelir ve göndermeden önce her sayıyı bir kişi kontrol eder.

Kurumsal bir müşteri üç günlük bir toplantı hakkında dört paragraflık bir e-posta gönderir; tarihler, oda sayısı, toplantı salonu düzeni ve bir bütçe ipucu bu e-postanın bir yerlerindedir. O e-postayı bir teklife dönüştürmek bir öğleden sonra alır; yanlış bir teklife dönüştürmek tek bir kontrol edilmemiş sayı alır. Bu yazı, bir dil modelinin grup satışında gerçekten nerede işe yaradığını, gereksinimlerin nasıl güvenli çıkarılacağını, kendi şablonunuz çevresinde nasıl taslak hazırlanacağını ve otelden çıkmadan önce neyin kontrol edileceğini gösteriyor.

Yapay zekâ otel satışında gerçekten nerede işe yarar?#

Üç yerde: talebi okumak, verilmiş bir kararın çevresindeki metni yazmak ve takibi yazmak. Para veya oda taahhüt eden her şey bir kişide kalır.

Okumak, en yüksek değerli ve en düşük riskli iştir. Grup talepleri uzun e-postalar, web formları ve ekler halinde gelir; gereksinimler paragraflara ve imza bloğuna dağılmış durumdadır. Bir model bunu saniyeler içinde yapılandırılmış bir listeye dönüştürebilir ve işin en yavaş yazı işini ortadan kaldırır.

Taslak hazırlamak, otelin kendi şablonundan yazılan eşlik metni, gün gün program ve dahil olan hizmetler listesi demektir; satış müdürü boş bir sayfadan başlamak yerine üzerinde düzeltme yapar. Takipler de asistana uyar, çünkü bağlamı elinde tutabilir: ne teklif edildi, ne zaman, müşteri ne sordu ve ne hâlâ açık.

İnsanda kalansa ticari çekirdek: fiyat, oda bloğu, release tarihi, attrition, depozito ve iptal koşulları, ayrıca grubu hiç alıp almama kararı. Çalışma kuralı basittir: asistan bir kararı yeniden ifade edebilir, asla veremez. Akıcı yazan bir model, kendinden emin bir biçimde yanlış rakamlar da yazar; bu yüzden taslaktaki her sayı, biri rezervasyon sistemiyle veya onaylı fiyat listesiyle karşılaştırana kadar doğrulanmamış sayılır.

Grup talebinden gereksinimler nasıl çıkarılır?#

Modele sabit bir alan listesi verin ve her değerin yanında kaynak cümle yer alacak biçimde tablo döndürmesini isteyin; böylece biri okumayı e-postayla karşılaştırabilir, özetin doğruluğuna güvenmek zorunda kalmaz.

Alan listesi varış ve ayrılış tarihlerini, gece sayısını, oda tipine göre odaları, misafir sayısını, tek ve çift kişilik dağılımı, toplantı salonunu ve düzenini, yeme içmeyi (kahvaltı, kahve molası, akşam yemekleri, beslenme ihtiyaçları), transferleri, ses görüntü ekipmanı ve tabela gibi yerinde ihtiyaçları, varsa bütçe göstergesini, karar tarihini ve karar vericiyi, ayrıca müşterinin oteli nasıl bulduğunu kapsamalıdır. Sabit liste önemlidir, çünkü modeli her seferinde aynı şeyleri aramaya zorlar; ne ön plandaysa onu özetlemeye bırakmaz.

Her çıkarılan değerin yanında, talepten alıntılanan tam cümleyi isteyin. Bu, bir özeti denetlenebilir bir okumaya dönüştürür ve kontrolü iki dakikalık bir iş yapar: her satırı uzun bir e-postanın hafızasıyla değil, alıntılanan cümleyle karşılaştırırsınız.

Modele, boşluğu doldurmak yerine "belirtilmemiş" yazmasını söyleyin. Boş bir alan müşteriye sorulacak bir soruya dönüşür; doldurulmuş bir tahmin teklifte bir hataya dönüşür. Belirsizliği açıkça işaretlemesini de isteyin, çünkü grup talepleri belirsizlik doludur. "Kırk kişi" kırk oda da olabilir kırk katılımcı da. "Üç gün" iki gece demek olabilir. Bir oda bloğu toplantı salonunu içerebilir de içermeyebilir de.

Özgün talebi fırsat kaydına ekli tutun. Çıkarma işlemi belgenin bir okumasıdır, belgenin yerine geçmez. Tekrarlayan kurumsal müşteriler için yeni talebi, son konaklamanın gerçekte tükettiğiyle karşılaştırın: bloktan kullanılan oda sayısı, servis edilen yemekler, kullanılan toplantı salonu. Blokların ve rooming listelerin nasıl çalıştığı hakkında daha fazlası için grup rezervasyonu nasıl yönetilir? Blok, rooming list ve ana folyo yazısına bakın.

Listenin yanında iki kural durur: her değer için kaynak cümleyi alıntılayın ve tahmin etmek yerine "belirtilmemiş" yazın.

Asistandan asla gelmemesi gereken nedir?#

Fiyatlar, oda blokları, release tarihleri, attrition koşulları, depozitolar ve iptal koşulları. Bunlar ticari taahhütlerdir ve gelir kararından ile onaylı sözleşme şablonundan gelir.

Bir grup fiyatı bir yer değiştirme sorusudur: aynı odalar aynı tarihlerde bireysel misafirlere satılsaydı ne kazandırırdı. Bu, kendi girdileri olan bir analizdir; bir modelin yazabileceği bir cümle değildir. Blok ve release süresi gerçek maliyeti olan sözleşme koşullarıdır. Çok kısa bir release süresi oteli satılmamış odalarla baş başa bırakır; çok uzun süresi müşteriye bağlanacak bir şey vermez.

Attrition ve ön ödeme maddeleri hukuki metindir. Asistan otelin onaylı maddesini kelimesi kelimesine alıntılayabilir, ama asla yeni bir madde yazamaz. Bir dil modelinin ayrıca envanterinizi gören bir tarafı yoktur. Odaların boş olup olmadığını bilemez; bu yüzden ürettiği her müsaitlik ifadesi, gerçek gibi görünen bir tahmindir.

İş akışının tamamındaki en tehlikeli çıktı, inandırıcı bir fiyattır, çünkü tam olarak bir insanın verdiği bir karar gibi görünür.

Fiyat kararının ardındaki analiz için grup talebini kabul etmeli misiniz? Displacement analiziyle karar yazısına bakın. Sözleşme mekaniği için allotment sözleşmesi: release süresi ve kontrol edilecek maddeler yazısına bakın.

Bir sınır daha: müşteri adlarını ve kişisel verileri, veri politikanız ve danışmanınız aksini söylemedikçe dış araçlara gönderilen komutlara koymayın. Grup talepleri adlar, iletişim bilgileri ve bazen fatura bilgisi taşır; kişisel veri kuralları uygulanır.

Otelin kendi teklif şablonu çevresinde taslak nasıl hazırlanır?#

Modele şablonun sabit bölümlerini verin ve yalnızca değişken kısımları doldurmasına izin verin; böylece teklif, genel bir satış mektubu gibi değil, otelinizin belgesi gibi görünür ve okunur.

Sabit kısımları değişken kısımlardan ayırın. Sabit olanlar: kapak, tesis tanıtımı, standart dahil olan hizmetler, şartlar ve koşullar, imza bloğu. Değişken olanlar: müşteri adı, tarihler, oda tipleri ve sayıları, toplantı salonu, yeme içme, fiyat tablosu, geçerlilik tarihi. Model yalnızca değişken kısımlar üzerinde çalışır.

Fiyat tablosunu, bir kişinin sistemden dolduracağı bir yer tutucu olarak tutun. Model sayının çevresindeki cümleyi yazar, asla sayının kendisini yazmaz. Tonu sıfatlarla değil örneklerle eşleştirin: "profesyonel bir ton" istemek yerine modele stil referansı olarak geçmişteki iki teklifi verin. Müşteri Almanca ya da Rusça yazdıysa o dilde taslak hazırlatın ve o dile hâkim bir çalışma arkadaşınıza kontrol ettirin. Akıcı bir taslak, kontrol edilmiş bir taslak demek değildir.

Grup teklifleri hızlı gözden geçirilir; bu yüzden en üste tek sayfalık bir özet isteyin: teklif, tarihler, blok ve geçerlilik tarihi. Taslakları müşteri adı ve tarihe göre adlandırın ve gerçekten gönderilen sürümü talep kaydının yanında tutun.

Bu tür komutların nasıl yapılandırılacağı için prompt nasıl yazılır? Otel işleri için örnekli bir yöntem yazısına bakın.

Baskı taktiği olmadan takip e-postaları nasıl yazılır?#

Bir takip e-postası hak ettiğini bir şey ekleyerek kazanır: açık bir soruya yanıt, tutulan bir tarih, daha küçük bir sonraki adım. Yalnızca "haber var mı" diye soran bir hatırlatma, müşteriyi sizi yok saymaya alıştırır.

Dahili olarak bir ritim üzerinde anlaşın, örneğin tekliften sonra 3. gün, 10. gün ve 21. gün; takvimi asistan tutsun. Her seferinde gönderip göndermemeye bir kişi karar verir. Her takip bağlam taşır: ne teklif edildi, ne zaman, ne hâlâ açık ve sırada ne var; örneğin seçeneğin süresi doluyor ya da fiyat belirtilen bir tarihe kadar tutuluyor.

Model, kısa bir iç notu ("müşteri park sorununu sordu, onayladık, depozito bekleniyor") kibar iki paragraflık bir e-postaya çevirmekte iyidir. Aciliyet uydurmasına asla izin vermeyin. Takipteki her son tarih, sözleşmeden veya fiyat geçerliliğinden gelen gerçek bir son tarih olmalıdır; yanıt almak için kurulmuş bir düzenek değil.

İmzalamaktan daha küçük bir sonraki adım önerin: bir telefon görüşmesi, bir tesis ziyareti, daha az odalı revize bir blok. Ve takibi, taleple aynı kayda işleyin ki sıradaki alan kişi tam geçmişi e-posta kutusunda aramak yerine kayıtta bulsun.

Bir teklif gönderilmeden önce ne kontrol edilir?#

Dört sayı ve bir ad: fiyat, oda çarpı gece, release tarihi, geçerlilik tarihi ve müşterinin kendi yazdığı biçimiyle adı ve adresi.

Fiyatı sistemle veya onaylı fiyat listesiyle karşılaştırın ve para biriminin belgede yazılı olduğunu doğrulayın. Oda sayısının gecelerle çarpımının belirtilen toplamla eşleştiğini, tek ve çift kişilik dağılımın taleple eşleştiğini kontrol edin. Release tarihi ve geçerlilik tarihinin ikisinin de bulunduğunu, ikisinin de gelecekte olduğunu ve hem birbiriyle hem sözleşme şablonuyla tutarlı olduğunu kontrol edin.

Toplamı elle ya da bir elektronik tabloda yeniden hesaplayın. Dil modelleri, çevresindeki metin doğru olsa bile aritmetikte güvenilmezdir. Attrition, depozito ve iptal maddelerinin onaylı hâleri olduğunu, hiçbir cümle eklenmeden veya çıkarılmadan değiştirilmediğini kontrol edin. Alıcıyı da kontrol edin: doğru şirkette doğru kişi, selamlamada ya da metinde önceki bir tekliften kalma bir ad olmadan.

Bu hafta nereden başlamalı#

Bu hafta gereksinim çıkarma alan listesini yazın ve önümüzdeki üç talepte kullanın; her değerin yanında kaynak cümle alıntılansın. Sonra yazının bütününe dayanak olan çizgiyi çizin: asistan okur, taslak hazırlar ve hatırlatır; fiyat, blok, release tarihi ve koşullar ise displacement analizinden, sözleşme şablonundan ve onay veren bir kişiden gelir. İki yarıyı ayrı tutarsanız kazandığınız hız gerçektir; karıştırırsanız ilk yanlış fiyat, kazandığınız saatlerden daha pahalıya mal olur.