Kapasitesinin Sınırlarına Dayanan Bir Otel
Bir kıyı şehrinde 180 odalı bağımsız bir otel hayal edin; yalın bir şekilde çalışan türden bir mülk: vardiya başına dört kişilik bir ön büro ekibi, bir operasyon müdürü ve yoğun sezonda zayıf bir temizlik personeli. Bu gerçek bir istemci değil, ancak aşağıdaki model orta büyüklükteki mülklerde yaygın olan durumlardan alınmıştır. Buna Özellik A adını verin.
A İşletmesi, manuel koordinasyonla çalışan bir otelin olağan semptomlarına sahipti: WhatsApp, e-posta ve ön büro telefonuna dağılmış misafir mesajları; bazen mühendisliğe hiç ulaşmayan, kağıt biletlere kaydedilen bakım talepleri; ve çoğu GM'nin yaptığı gibi, konuk çıkış yaptıktan sonra kötü bir değerlendirmeden haberdar olan bir genel müdür.
Hafta Sonu Mesajlar Birikti
Çatlakları ortaya çıkaran senaryo, hafta sonu tatilinin tamamen dolu olması ve ön bürodaki personel açığının bir araya gelmesiydi. Konuk mesajları, mevcut iki temsilcinin okuyabildiğinden daha hızlı ulaştı: geç çıkış talepleri, park etmeyle ilgili sorular, 412 numaralı odada sızdıran bir musluk, ekstra yastık isteyen bir misafir ve daha fazla ayrıntıya yer vermeden sadece "bu kabul edilemez" yazan bir mesaj.
Eski iş akışında bunların tümü aynı görsel ağırlığa sahip aynı gelen kutusunda yer alıyordu. Ön büro personeli içgüdüsü ve yeniliğiyle tetikteydi, bu da sızdıran musluk ve öfkeli misafirin genellikle yastık talebinin arkasında beklemesi anlamına geliyordu, çünkü yastık istekleri hızlı yanıtlanıyor ve hızlı yanıtlar üretken hissettiriyor.
Mülk A yakın zamanda, GadgetMall'ın Hermes'in Oracle OPERA Cloud ve OHIP'teki mülkler için yaptığına benzer şekilde, yapay zeka destekli bir operasyon katmanını PMS'sine bağlamıştı. Sistem, gelen mesajları varış zamanı yerine amaç ve aciliyete göre sınıflandırıyordu. Belirsiz şikayet, yüksek öncelikli olarak işaretlendi ve dakikalar içinde bir görev yöneticisine yönlendirildi; bunun nedeni, bir anahtar kelimenin eşleşmesi değil, dil yapısının daha önce artan şikayetlere benzemesiydi. Musluk sorunu bir bakım bildirimi olarak etiketlendi ve ön büro tamamen atlanarak doğrudan mühendisliğin görev kuyruğuna aktarıldı. Yastık ve park etme soruları, onaylanmış rezervasyon ayrıntıları kullanılarak otomatik olarak yanıtlandı ve böylece iki temsilcinin, gerçekten üzgün olan konuğa odaklanabilmesi sağlandı.
Şikayeti Tasarrufa Dönüştürmek
"Bu kabul edilemez" mesajını gönderen konuğun, rezervasyon yaptıkları odanın iki kat altındaki bir oda tahsisinden rahatsız olduğu ortaya çıktı; bu tutarsızlık, son dakika blok tahliyesinden kaynaklanıyordu. Manuel iş akışında, bu tür belirsiz şikayetler, bir insanın ne olduğunu anlayacak kadar dikkatli bir şekilde okuması için genellikle 20 ila 40 dakika bekletilir.
Bu kez görev yöneticisi uyarıya bağlam eklemişti: misafirin sadakat seviyesi, önceki iki konaklaması, daha yüksek katlara yönelik tercih hakkında önceki bir ziyaretten alınan bir not ve oda tipi değişikliğini gösteren tam rezervasyon geçmişi. Yönetici, genel bir özür yerine, orijinal mesajdan sekiz dakika sonra özel bir düzeltme, okyanusa bakan bir odaya sahip daha yüksek bir kata yükseltme teklifinde bulundu.
Fark özür değildi. Cevap zaten elimizdeydi.
Bu durumdaki bir mülk, şikayetten çözüme kadar geçen sürenin 30 ila 45 dakika aralığından 10 dakikanın altına düştüğünü görebilir, bunun nedeni personelin bağlam toplamak için pencereyi harcamayı bırakıp buna göre hareket etmeye başlamasıdır. Bu boşluk genellikle bir değerlendirmede hıçkırıklardan olumlu şekilde bahseden bir konuk ile bunu yapmayan bir konuk arasındaki farktır.
Kişiselleştirme Ertesi Sabah Nasıl Görünüyordu?
İyileşmeyi destekleyen aynı konuk zekası, aynı zamanda daha küçük, daha sessiz anları da şekillendirdi. Spa bakımları için rezervasyon yaptırdığı bilinen geri dönen bir misafir, genel bir karşılama şablonu yerine geçmiş tercihlerine atıfta bulunan bir varış öncesi mesaj aldı. Daha önce beşik talebinde bulunan bir aile, iki kere sormaya gerek kalmadan beşik bekletiyordu. Bunların hiçbiri büyük bir kişiselleştirme motoru gerektirmiyordu; sadece otele daha önce söylenenleri hatırlayan ve bir sonraki ihtiyacı olan kişinin kullanımına sunan bir sistemdi.
Bir Sonraki Dalgalanmayı Tepki Vermek Yerine Tahmin Etmek
A Mülkündeki uzun vadeli değişim günden güne daha az görünür hale geldi ancak çeyrek boyunca daha değerli oldu. Operasyon ekibi, PMS entegrasyonundan geçmiş doluluk durumunu, mesaj hacmini ve hizmet bileti kalıplarını çıkararak, mesaj hacminin, fırtına sırasında iptal politikaları ve park yeri müsaitliği hakkında soru soran misafirler nedeniyle, büyük hava olaylarından yaklaşık 36 saat önce artma eğiliminde olduğunu görebiliyordu.
Ekip, bunu her seferinde zor yoldan keşfetmek yerine, ön bürodaki personeli önceden hazırlamaya ve tahmin edilen hava koşullarındaki aksamalar öncesinde yanıtların ön taslağını hazırlamaya başladı. Bu modele sahip bir özellik, mesajlar gelmeye başladıktan sonra karıştırmak yerine, 12 saatlik bir pencere boyunca ek bir temsilci vardiyası planlayarak, hava durumuyla ilgili yanıt gecikmelerini azaltabilir.
- Misafir mesajlaşması: ilk giren ilk çıkar gelen kutuları yerine amaca dayalı yönlendirme
- Görev önceliklendirmesi: otomatik sınıflandırma, acil şikayetleri rutin taleplerden ayırır
- Hizmet kurtarma: Bağlam açısından zengin uyarılar şikayet ile çözüm arasındaki boşluğu kısaltır
- Kişiselleştirme: Konuk geçmişi, onu kaydeden departmanı değil, konuğu takip eder
- Tahmin: Geçmiş modeller personel alımını artış sırasında değil, artış öncesinde bilgilendirir
Genelleyen Ders
Bu değişikliklerin hiçbiri personel kararının değiştirilmesini gerektirmedi. Personele doğru bilgiyi doğru zamanda vermeyi ve sinyali bulmak için gürültüyü ayrıştırma zahmetli çalışmasını ortadan kaldırmayı gerektiriyorlardı. Operasyonlarda yapay zekayı değerlendiren oteller için asıl soru teknolojinin etkileyici olup olmadığı değil. Konuğun isteği ile bu isteği yerine getirebilecek insan arasındaki mesafeyi kısaltıp kısaltmadığıdır.