Otelde Misafir Şikâyeti Nasıl Yönetilir? Complaint Handling ve Service Recovery Rehberi

Misafir resepsiyona gelir:

“Odamdaki klima dün gece doğru düzgün çalışmadı.”

Resepsiyon görevlisi:

“Teknik servise haber vereyim.”

der.

Teknik ekip gider.

Klimayı düzeltir.

Problem çözülmüş müdür?

Teknik olarak belki.

Ama misafir açısından henüz bilmiyoruz.

Çünkü otelde şikâyet yönetiminin amacı yalnızca:

problemi ortadan kaldırmak

değildir.

Aynı zamanda:

• misafirin dinlendiğini hissetmesini,
• problemin sahiplenilmesini,
• doğru hızda çözülmesini,
• çözümün doğrulanmasını,
• gerekiyorsa Service Recovery uygulanmasını,
• misafire geri dönüş yapılmasını,
• problemin tekrar etmemesi için nedeninin analiz edilmesini

sağlamaktır.

Bu nedenle profesyonel Complaint Handling sistemi:

Complaint → Listen → Acknowledge → Record → Own → Prioritize → Resolve → Service Recovery → Follow-Up → Close → Analyze → Prevent Recurrence

şeklinde çalışmalıdır.

Çünkü iyi yönetilen otelde şikâyet:

yalnızca çözülmesi gereken bir problem değil, operasyon sisteminin nerede kırıldığını gösteren veridir.

1. Misafir Şikâyeti Nedir?

Misafir şikâyeti;

misafirin otelin:

• ürünü,
• hizmeti,
• personeli,
• fiziksel koşulları,
• iletişimi,
• fiyat/değer ilişkisi,
• rezervasyon süreci,
• ödeme süreci

hakkında beklentisinin karşılanmadığını ifade etmesidir.

Şikâyet her zaman:

“Şikâyet etmek istiyorum.”

cümlesiyle gelmez.

Misafir:

“Oda biraz sıcak.”

diyebilir.

“Kahvaltıda ekmek kalmamıştı.”

diyebilir.

“Dün iki kez havlu istemek zorunda kaldım.”

diyebilir.

Bunların hepsi:

operasyonel sinyaldir.

2. Şikâyet ile Misafir Talebi Aynı Şey Değildir

Misafir:

“Bir tane daha yastık alabilir miyim?”

diyorsa:

bu bir:

Guest Request

olabilir.

Ama:

“Üçüncü kez yastık istiyorum, hâlâ gelmedi.”

diyorsa:

artık konu yalnızca talep değildir.

Bir:

Complaint

oluşmuştur.

Dolayısıyla sistem:

Request → Delay / Failure → Complaint

dönüşümünü görebilmelidir.

3. Şikâyetin Gerçek Maliyeti Nedir?

Bir misafir şikâyetinin maliyeti yalnızca:

• ikram,
• indirim,
• upgrade,
• refund

değildir.

Asıl maliyet:

• düşük Review Score,
• olumsuz OTA yorumu,
• tekrar gelmeyen misafir,
• kötü ağızdan ağıza iletişim,
• personel zamanı,
• oda değişikliği,
• operasyonel tekrar iş,
• marka algısı kaybı

olabilir.

Bu nedenle:

şikâyet maliyeti ile Service Recovery maliyeti aynı şey değildir.

Bazen küçük bir Recovery Cost:

çok daha büyük bir Reputation Cost'u önleyebilir.

4. En Tehlikeli Misafir Her Zaman Şikâyet Eden Misafir Değildir

Şikâyet eden misafir:

en azından işletmeye:

problemi düzeltme fırsatı verir.

Daha tehlikeli senaryo:

misafirin hiçbir şey söylememesidir.

Misafir:

otelden çıkar.

Sonra:

• düşük puan verir,
• kötü yorum yazar,
• bir daha gelmez.

Otel ise:

problemi hiç öğrenmez.

Bu nedenle çalışanlar:

şikâyeti savunulması gereken bir saldırı olarak değil;

operasyonel geri bildirim

olarak görmelidir.

5. Şikâyet Yönetiminde İlk Kural: Dinleyin

Misafir konuşurken ilk refleks:

“Ama…”

olmamalıdır.

Örneğin misafir:

“Odam çok gürültülüydü.”

dediğinde:

“Ama diğer misafirlerden hiç şikâyet gelmedi.”

cevabı problemi çözmez.

Aksine misafire:

“Senin yaşadığın deneyim geçerli değil.”

mesajı verebilir.

İlk adım:

Listen.

Misafirin ne yaşadığını anlamaktır.

6. Misafirin Yaşadığı Deneyim ile Teknik Gerçek Farklı Olabilir

Örneğin misafir:

“Klima hiç çalışmadı.”

diyor.

Teknik kayıt:

klimanın çalıştığını gösteriyor olabilir.

Burada amaç:

misafirle teknik tartışmaya girmek değildir.

Daha doğru yaklaşım:

misafirin yaşadığı deneyimi anlamak ve problemi doğrulamaktır.

Çünkü otelcilikte:

teknik olarak çalışan bir ürün, misafir açısından işlevini yerine getirmemiş olabilir.

7. İkinci Adım: Acknowledge

Acknowledge:

misafirin yaşadığı problemin:

anlaşıldığını göstermektir.

Örneğin:

“Bunun özellikle gece saatinde rahatsız edici olduğunu anlıyorum.”

Bu:

her durumda otelin hukuki veya finansal sorumluluğunu kabul etmek anlamına gelmez.

Ama misafire:

“Seni dinledim ve problemi anladım.”

mesajı verir.

8. Empati ile Suç Kabulü Aynı Şey Değildir

Çalışanlar bazen:

“Özür dilersem otelin hatasını kabul etmiş olurum.”

diye düşünebilir.

Bu nedenle mekanik ve savunmacı cevap verirler.

Oysa:

“Böyle bir deneyim yaşamanıza üzüldüm.”

demek ile:

“Otel tamamen hatalı ve tüm zararınızdan sorumludur.”

demek aynı şey değildir.

İyi şikâyet yönetimi:

insani iletişim ile operasyonel kontrolü

birlikte yürütür.

9. Üçüncü Adım: Record

Şikâyet kayıt altına alınmalıdır.

Çünkü kayıt yoksa:

otel yalnızca:

hatırladığı problemleri yönetir.

Complaint Log'da örneğin:

• tarih,
• saat,
• misafir,
• oda,
• şikâyet kategorisi,
• açıklama,
• severity,
• ilgili departman,
• sorumlu,
• alınan aksiyon,
• Service Recovery,
• çözüm zamanı,
• Follow-Up,
• kapanış,
• Root Cause

bulunabilir.

10. WhatsApp Şikâyet Kayıt Sistemi Değildir

Resepsiyon:

“205 klima şikâyeti var.”

diye mesaj atabilir.

Bu hızlı iletişim için yararlıdır.

Ama şikâyetin kendisi:

yalnızca mesajlaşma grubunda kalmamalıdır.

Çünkü sonra:

• çözüldü mü?
• ne kadar sürdü?
• misafire geri dönüldü mü?
• compensation verildi mi?
• aynı oda tekrar şikâyet aldı mı?

bilinmeyebilir.

Bu nedenle:

Mesajlaşma = iletişim

Complaint Log / PMS / Task System = kayıt

olmalıdır.

11. Dördüncü Adım: Ownership

Şikâyet yönetimindeki en büyük problemlerden biri:

misafirin departmanlar arasında dolaştırılmasıdır.

Misafir:

resepsiyona söyler.

Resepsiyon:

“Housekeeping'e söyleyin.”

der.

Housekeeping:

“Teknik ilgileniyor.”

der.

Teknik:

“Resepsiyona bildirdik.”

der.

Misafir açısından:

kimse problemi sahiplenmemektedir.

12. Complaint Owner Olmalıdır

Her şikâyetin:

bir sahibi

olmalıdır.

Owner:

problemi bizzat çözen kişi olmak zorunda değildir.

Ama şunlardan sorumludur:

• doğru departmana iletmek,
• süreci takip etmek,
• gecikmeyi görmek,
• gerektiğinde Escalation yapmak,
• misafire geri dönmek,
• kapanışı doğrulamak.

Temel prensip:

Şikâyet departmana değil, bir Owner'a atanmalıdır.

13. “Benim Departmanım Değil” Yaklaşımı Olmamalıdır

Misafir:

housekeeping çalışanına:

“Odamdaki televizyon çalışmıyor.”

dediğinde:

cevap:

“Ben teknik departman değilim.”

olmamalıdır.

Çalışan:

problemi teknik olarak çözmek zorunda değildir.

Ama:

doğru sisteme sokmakla sorumlu olabilir.

Misafir açısından:

otel tek organizasyondur.

14. Misafir Deneyimi Departmanlara Bölünemez

Otel organizasyon şemasında:

• Front Office,
• Housekeeping,
• Technical,
• F&B,
• Guest Relations

ayrı olabilir.

Ama misafir:

departman satın almaz.

Bir:

otel deneyimi

satın alır.

Bu nedenle temel prensip:

Operasyonel sorumluluk departmanlara bölünebilir; fakat misafir deneyimi bölünemez.

15. Şikâyetleri Kategorilere Ayırın

Örneğin:

Room

• temizlik,
• konfor,
• gürültü,
• ekipman.

Technical

• klima,
• sıcak su,
• elektrik,
• TV,
• Wi-Fi.

Housekeeping

• temizlik,
• linen,
• amenities,
• eksik malzeme.

F&B

• kahvaltı,
• kalite,
• servis,
• hijyen.

Front Office

• check-in,
• check-out,
• ödeme,
• bilgi.

Reservation

• fiyat,
• oda tipi,
• rezervasyon hatası.

Service

• davranış,
• gecikme,
• iletişim.

Bu sınıflandırma:

şikâyetleri operasyonel veriye dönüştürür.

16. Severity Seviyesi Belirleyin

Bütün şikâyetler aynı önemde değildir.

Basit sistem:

L1 — Minor

Küçük hizmet problemi.

L2 — Moderate

Misafir deneyimini belirgin etkileyen problem.

L3 — Serious

Önemli operasyonel veya finansal etki.

L4 — Critical

Güvenlik, sağlık, ciddi hukuki veya itibar riski.

Seviye yükseldikçe:

yetki ve Escalation seviyesi de yükselmelidir.

17. Complaint Priority Nasıl Belirlenir?

Şunlara bakılabilir:

• güvenlik riski,
• misafire etkisi,
• problemin devam edip etmediği,
• çözüm süresi,
• finansal etki,
• başka misafirleri etkileyip etkilemediği,
• sosyal medya / reputation riski.

Örneğin:

bir havlunun geç gelmesi

ile:

odada ciddi su kaçağı

aynı seviyede yönetilmemelidir.

18. Şikâyet Yönetiminde Hız Neden Önemlidir?

Bir problem:

ilk 10 dakikada küçük olabilir.

İki saat sonra:

büyük şikâyete dönüşebilir.

Örneğin:

misafir:

“Ekstra havlu istiyorum.”

dedi.

10 dakika:

normal Request.

45 dakika:

gecikmiş Request.

90 dakika:

Complaint.

2 saat:

Service Failure

haline gelebilir.

Dolayısıyla:

problemin büyüklüğünü yalnızca problem değil, çözüm süresi de belirler.

19. Response Time ve Resolution Time

İki farklı KPI vardır.

Response Time

Şikâyetin alınması ile ilk aksiyon arasındaki süre.

Resolution Time

Şikâyetin alınması ile gerçek çözüm arasındaki süre.

Örneğin:

Complaint:

14:00

Response:

14:05

Resolution:

14:45

Response Time:

5 dakika

Resolution Time:

45 dakika

İkisi ayrı ölçülmelidir.

20. Misafire Gerçekçi Süre Verin

En kötü uygulamalardan biri:

“5 dakikaya hallederiz.”

deyip:

30 dakika sonra hâlâ çözmemektir.

Bu durumda misafir:

ilk problemden çok:

verilen sözün tutulmamasına

sinirlenebilir.

Daha doğru yaklaşım:

gerçekçi ETA vermektir.

Örneğin:

“Teknik arkadaşımız yaklaşık 15 dakika içinde odanıza ulaşacak.”

Eğer gecikme olacaksa:

misafir:

sormadan önce

bilgilendirilmelidir.

21. Service Recovery Nedir?

Service Recovery:

hizmet hatası sonrasında misafir deneyimini yeniden kabul edilebilir seviyeye getirmek için yapılan müdahalelerin bütünüdür.

Bu yalnızca:

para vermek

değildir.

Service Recovery:

• özür,
• hızlı çözüm,
• oda değişikliği,
• upgrade,
• ikram,
• özel hizmet,
• indirim,
• refund,
• kişisel takip

gibi farklı araçlardan oluşabilir.

22. Her Şikâyete İndirim Yapılmalı mı?

Hayır.

Şikâyet yönetiminin amacı:

misafire para dağıtmak

değildir.

Örneğin küçük bir sorun:

hızlı şekilde çözüldü.

Misafir memnun.

Bu durumda finansal compensation gerekmeyebilir.

Başka bir durumda:

misafir ciddi şekilde etkilenmiştir.

O zaman Recovery gerekir.

Doğru soru:

“Ne kadar indirim verelim?”

değil;

“Bu misafirin yaşadığı hizmet kaybını adil ve markaya uygun şekilde nasıl telafi ederiz?”

olmalıdır.

23. Service Recovery Ladder Oluşturun

Otel kendi Recovery seviyelerini tanımlayabilir.

Örneğin:

Level 1

• özür,
• hızlı çözüm,
• Follow-Up.

Level 2

• küçük ikram,
• amenity,
• F&B gesture.

Level 3

• upgrade,
• daha anlamlı ikram,
• belirli ücretin kaldırılması.

Level 4

• indirim,
• kısmi refund,
• yönetici müdahalesi.

Level 5

• ciddi finansal çözüm,
• GM kararı,
• kriz / hukuki süreç.

Ama:

Recovery seviyesi şikâyetin gerçek etkisine göre belirlenmelidir.

24. Yetki Matrisi Olmadan Service Recovery Yavaşlar

Her küçük karar için:

GM aranıyorsa:

şikâyet yönetimi yavaşlar.

Örneğin resepsiyon görevlisinin:

hiçbir Recovery yetkisi yoksa:

misafir bekler.

Supervisor:

küçük ikram yetkisine sahip olabilir.

Front Office Manager:

belirli seviyeye kadar indirim verebilir.

GM:

yüksek finansal kararları verebilir.

Bu yapı:

Authority Matrix

ile tanımlanmalıdır.

25. Empowerment Nedir?

Empowerment:

çalışana:

tanımlı sınırlar içinde karar verme yetkisi vermektir.

Ama Empowerment:

“Ne uygun görüyorsan yap.”

değildir.

Doğru sistem:

Yetki + Limit + Kayıt + Kontrol

şeklinde olmalıdır.

Böylece:

misafir hızlı çözüm alırken

otel de finansal kontrolü kaybetmez.

26. Service Recovery Misafire Özel Olmalıdır

Aynı çözüm:

her misafir için aynı değeri yaratmayabilir.

Örneğin:

bir misafire:

ücretsiz kahvaltı

teklif ediyorsunuz.

Ama rezervasyonu zaten:

Breakfast Included.

Bu Recovery değildir.

Başka misafir:

ertesi sabah erken uçuşa gidecek.

Late Check-Out teklif etmek anlamsız olabilir.

Dolayısıyla:

Recovery, misafirin gerçek ihtiyacına dokunmalıdır.

27. Oda Değişikliği Ne Zaman Kullanılmalı?

Oda değişikliği:

özellikle problem:

• hızlı çözülemiyorsa,
• misafir konforunu ciddi etkiliyorsa,
• tekrar etme riski varsa

güçlü bir Recovery olabilir.

Ama Room Move:

kendi içinde operasyon yaratır:

• yeni oda,
• bagaj,
• Housekeeping,
• PMS,
• key,
• room status,
• misafir bilgilendirme.

Dolayısıyla:

Room Move da standart bir workflow olmalıdır.

28. Upgrade Her Zaman En İyi Çözüm Değildir

Misafir:

gürültü şikâyeti yapıyor.

Daha büyük ama yine gürültülü bir odaya Upgrade etmek:

problemi çözmez.

Bu nedenle:

Recovery'nin değeri fiyatından değil, problemi çözme kapasitesinden gelir.

29. Özür Nasıl Olmalı?

Kötü özür:

“Yaşanan aksaklıktan dolayı üzgünüz.”

Her durumda aynı.

Mekanik.

Daha iyi yaklaşım:

yaşanan probleme referans veren:

kısa,

samimi,

savunmasız

bir iletişimdir.

Örneğin:

“Gece klima nedeniyle rahat edememenizden dolayı üzgünüm. Teknik ekibimiz problemi çözüyor; ben de süreci takip edeceğim.”

Burada üç şey vardır:

Empathy + Action + Ownership

30. Savunmacı Dil Kullanmayın

Şu cümleler tehlikelidir:

“Normalde böyle olmaz.”

“İlk kez siz söylüyorsunuz.”

“Diğer misafirler şikâyet etmedi.”

“Bizim sistemde sorun görünmüyor.”

“Housekeeping unutmuş.”

“Teknik ekibin hatası.”

Bunlar:

misafirin problemini çözmez.

Ayrıca:

otelin kendi departmanlarını misafirin önünde suçlamasına

neden olur.

31. Departmanı Değil Oteli Temsil Edin

Misafire:

“Housekeeping yapmamış.”

demek yerine:

“Bunu hemen düzeltiyoruz.”

demek daha doğrudur.

Misafir:

organizasyon içindeki suçluyu bulmak istemez.

Çoğu zaman istediği:

problemin çözülmesidir.

32. Çözüm Sonrası Follow-Up Şarttır

Problem çözüldü.

İş bitti mi?

Hayır.

Misafire:

“Klimanız şu anda düzgün çalışıyor mu?”

diye sorulmalıdır.

Çünkü teknik ekip:

“Tamam.”

demiş olabilir.

Ama misafir:

hâlâ memnun olmayabilir.

Bu nedenle:

Resolve ≠ Close

Doğru akış:

Resolve → Verify → Guest Follow-Up → Close

olmalıdır.

33. Follow-Up Ne Zaman Yapılmalı?

Probleme göre:

• hemen,
• 15–30 dakika sonra,
• birkaç saat sonra,
• ertesi sabah

yapılabilir.

Örneğin:

klima tamir edildi.

15 dakika sonra:

odanın gerçekten soğuyup soğumadığı kontrol edilebilir.

Gece gürültü şikâyeti yaşandıysa:

ertesi sabah:

misafirin geceyi nasıl geçirdiği sorulabilir.

34. Complaint Closed Ne Demektir?

Şikâyetin kapanması:

personelin aksiyon alması

değildir.

Kapanış için:

• problem çözüldü,
• misafir bilgilendirildi,
• gerekiyorsa Recovery yapıldı,
• Follow-Up tamamlandı,
• kayıt güncellendi

olmalıdır.

Kritik prensip:

Action Completed ≠ Complaint Closed

35. Şikâyet Kapanış Kodları Kullanılabilir

Örneğin:

Resolved

Problem tamamen çözüldü.

Resolved with Recovery

Problem çözüldü ve Recovery uygulandı.

Partially Resolved

Kısmi çözüm.

Pending

Aksiyon devam ediyor.

Escalated

Üst yönetime çıktı.

Unresolved

Çözüm sağlanamadı.

Bu sınıflandırma:

yönetimin gerçek performansı görmesini sağlar.

36. Complaint Log Örneği

Bu kayıt:

bir ay sonra:

hangi problemlerin tekrarlandığını

gösterebilir.

37. Complaint Log Neden Altın Değerindedir?

Çünkü şikâyetler:

operasyonun ücretsiz denetimidir.

Örneğin bir ayda:

• 12 klima şikâyeti,
• 9 sıcak su şikâyeti,
• 7 oda temizliği şikâyeti,
• 6 kahvaltı replenishment şikâyeti

geldiyse:

bunlar tek tek olay değildir.

Sistemsel sinyal olabilir.

38. Şikâyetleri Tek Tek Değil Trend Olarak Okuyun

Bir klima şikâyeti:

arıza olabilir.

Aynı ay:

15 klima şikâyeti

varsa:

artık soru:

“Bu klimayı kim tamir edecek?”

değildir.

Doğru soru:

“HVAC sistemimizde hangi sistemsel problem var?”

olmalıdır.

39. Pareto Analizi Kullanın

Örneğin:

100 şikâyet var.

Bunların:

65'i

yalnızca dört konudan geliyor:

• klima,
• gürültü,
• kahvaltı,
• housekeeping.

Bu durumda:

önce bu dört problem üzerinde çalışmak

toplam şikâyeti ciddi biçimde azaltabilir.

40. Root Cause Analysis Yapın

Şikâyet:

“Oda zamanında hazır değildi.”

Çözüm:

misafire içecek ikram edildi.

Güzel.

Ama neden oda hazır değildi?

Housekeeping geç bitirdi.

Neden?

Check-Out odaları aynı saate yığıldı.

Neden?

Staffing planı doluluğa göre yapılmadı.

Neden?

Forecast housekeeping planına aktarılmadı.

Kök neden:

iş gücü planlaması

olabilir.

Service Recovery misafiri kurtarır.

Root Cause Analysis:

gelecekteki misafiri kurtarır.

41. 5 Why Complaint Management'ta Kullanılabilir

Örneğin:

Misafir neden şikâyet etti?

Havlu gelmedi.

Neden?

Request tamamlanmadı.

Neden?

Housekeeping mesajı görmedi.

Neden?

Talep WhatsApp grubunda kaldı.

Neden?

Task Management sistemi kullanılmıyor.

Gerçek problem:

havlu değil, süreç tasarımıdır.

42. Corrective Action ile Preventive Action Ayrımı

Corrective Action

Mevcut problemi düzeltir.

Örneğin:

havluyu misafire götürmek.

Preventive Action

Problemin tekrarını azaltır.

Örneğin:

Guest Request sistemine:

• Owner,
• SLA,
• Escalation,
• Close

eklemek.

Profesyonel otel:

ikisini de yapar.

43. Şikâyet Yönetimi SOP'si Nasıl Olmalı?

Örneğin:

MG-001 — Guest Complaint Handling

başlıkları:

Amaç

Şikâyetleri hızlı, tutarlı ve misafir odaklı çözmek.

Kapsam

Tüm misafir şikâyetleri.

Sorumlu

Şikâyeti alan çalışan + Complaint Owner.

Adımlar

Listen → Acknowledge → Record → Prioritize → Assign Owner → Resolve → Recovery → Follow-Up → Close → Analyze

Escalation

Severity seviyesine göre.

KPI

Response Time, Resolution Time, Repeat Complaint, Recovery Cost vb.

44. Service Recovery SOP Ayrı Olabilir

Örneğin:

MG-002 — Service Recovery

şunları tanımlayabilir:

• Recovery seviyeleri,
• yetki limitleri,
• hangi durumlarda kullanılacağı,
• finansal kayıt,
• PMS notu,
• management approval,
• Follow-Up.

Böylece Recovery:

kişisel pazarlık olmaktan çıkar, kontrollü yönetim aracına dönüşür.

45. Complaint Escalation Matrix

Örneğin:

L1

Frontline Employee

L2

Supervisor

L3

Department Manager / Duty Manager

L4

General Manager

L5

Crisis / Emergency Management

Böylece çalışan:

hangi problemi hangi seviyeye taşıyacağını bilir.

46. Her Şikâyeti GM Çözmemelidir

GM:

her küçük şikâyete müdahale ediyorsa:

ilk bakışta misafir odaklı görünebilir.

Ama operasyon açısından:

yetki sistemi çalışmıyor olabilir.

Doğru sistemde:

frontline küçük problemleri,

supervisor orta problemleri,

manager ciddi problemleri

çözebilir.

GM:

kritik olaylara girer.

Bu:

ölçeklenebilir operasyon

yaratır.

47. Frontline Employee Ne Kadar Yetkili Olmalı?

Bu otelin konseptine göre değişir.

Ama çalışan en azından:

• dinleyebilmeli,
• kayıt açabilmeli,
• doğru Owner'a yönlendirebilmeli,
• küçük çözümleri uygulayabilmeli,
• ETA verebilmeli,
• Follow-Up başlatabilmelidir.

Çalışanın tek yetkisi:

“Müdürüme sorayım.”

ise:

Service Recovery yavaşlar.

48. Complaint Handling Eğitimi Nasıl Yapılmalı?

Sadece SOP okutmak yeterli değildir.

Role Play yapılmalıdır.

Örneğin senaryolar:

Senaryo 1

Oda hazır değil.

Senaryo 2

Klima çalışmıyor.

Senaryo 3

Kahvaltı ürünü bitmiş.

Senaryo 4

Misafir fiyat farkına itiraz ediyor.

Senaryo 5

Gece gürültü şikâyeti.

Senaryo 6

Misafir çok öfkeli.

Çalışan:

gerçekmiş gibi çözmelidir.

49. Öfkeli Misafirle Nasıl İletişim Kurulur?

Amaç:

misafiri tartışmada yenmek değildir.

İlk olarak:

• sakin kalın,
• sözünü kesmeyin,
• problemi netleştirin,
• kişisel algılamayın,
• savunmaya geçmeyin,
• çözüm seçenekleri sunun.

Ama:

tehdit,

hakaret,

şiddet

gibi durumlarda çalışan güvenliği ve otel politikası devreye girmelidir.

Misafir memnuniyeti, çalışan güvenliğinin üzerinde değildir.

50. “Misafir Her Zaman Haklıdır” Doğru mu?

Bu ifade operasyon için yeterli değildir.

Daha doğru yaklaşım:

Misafirin yaşadığı deneyim her zaman ciddiye alınmalıdır.

Ama misafir:

• yanlış bilgiye sahip olabilir,
• politikaya aykırı talepte bulunabilir,
• haksız finansal talep yapabilir,
• çalışanlara kötü davranabilir.

Profesyonel otel:

hem misafiri dinler

hem:

politikasını ve çalışanını korur.

51. Haksız Compensation Talebi Nasıl Yönetilir?

Misafir:

küçük bir problem nedeniyle:

“Tüm konaklamam ücretsiz olsun.”

diyebilir.

Çalışan:

hemen kabul etmek zorunda değildir.

Recovery:

proportionate

yani yaşanan hizmet kaybıyla orantılı olmalıdır.

Bu nedenle:

Severity + Impact + Duration + Recovery

birlikte değerlendirilmelidir.

52. Service Recovery Cost Takip Edilmeli mi?

Evet.

Örneğin aylık:

• complimentary F&B,
• upgrades,
• discounts,
• refunds,
• amenities

toplanabilir.

Ama amaç:

“Personel çok ikram yapıyor.”

demek değildir.

Asıl soru:

“Bu Recovery Cost neden oluşuyor?”

olmalıdır.

53. Recovery Cost'un Kök Nedenini Bulun

Örneğin aylık:

40.000 TL

Service Recovery Cost oluşmuş.

Bunun:

25.000 TL'si

oda hazır olmaması nedeniyle.

Bu durumda problem:

Recovery Policy değildir.

Muhtemelen:

Housekeeping / Front Office oda hazırlık sistemi

problemidir.

Dolayısıyla finansal veri:

operasyonel probleme götürür.

54. Complaint Rate Nasıl Hesaplanabilir?

Örneğin:

Complaint Rate = Complaint Count / Occupied Rooms × 100

veya:

Complaint Count / Guest Stays

kullanılabilir.

Önemli olan:

aynı tanımın sürekli kullanılmasıdır.

Böylece dönemler karşılaştırılabilir.

55. Complaint Rate Tek Başına Yeterli Değildir

Düşük Complaint Rate:

her zaman iyi değildir.

Çünkü:

şikâyetler kaydedilmiyor olabilir.

Çalışanlar:

“Çözdük, yazmaya gerek yok.”

diyebilir.

Bu durumda dashboard:

mükemmel görünür.

Ama gerçek operasyon:

problemli olabilir.

Bu nedenle:

şikâyet kayıt kültürü cezalandırılmamalıdır.

56. Şikâyet Kaydını Cezalandırırsanız Veri Kaybolur

Yönetim:

“Neden bu kadar çok şikâyet var?”

diyerek personeli suçlarsa:

personel bir sonraki ay:

daha az kayıt açabilir.

Şikâyet gerçekten azalmaz.

Yalnızca:

görünmez hale gelir.

Doğru yönetim sorusu:

“Bu veriden ne öğrenebiliriz?”

olmalıdır.

57. Complaint Resolution Rate

Formül:

Resolution Rate = Resolved Complaints / Total Complaints × 100

Örneğin:

100 Complaint.

96 Resolved.

Resolution Rate = %96

Ama bu KPI da tek başına yeterli değildir.

Çünkü:

“Resolved”

tanımı standart olmalıdır.

58. First Contact Resolution

Bazı şikâyetler:

ilk temas noktasında çözülebilir.

Bu:

First Contact Resolution

olarak takip edilebilir.

Örneğin:

misafir ekstra havlu gecikmesinden şikâyet etti.

Resepsiyon:

hemen Housekeeping'i yönlendirdi,

havlu geldi,

Follow-Up yapıldı.

Problem başka yöneticiye taşınmadan çözüldü.

Yüksek First Contact Resolution:

doğru Empowerment'ın göstergelerinden biri olabilir.

59. Repeat Complaint Rate

Aynı misafirin:

aynı problem için tekrar şikâyet etmesi

özellikle önemlidir.

Örneğin:

misafir:

“Klima çalışmıyor.”

dedi.

Tamir edildi.

İki saat sonra:

aynı şikâyet tekrar geldi.

Bu:

ilk çözümün başarısız olduğunu gösterir.

Repeat Complaint:

Service Recovery açısından çok daha ciddi ele alınmalıdır.

60. Reopened Complaint

Kapanmış şikâyet tekrar açılıyorsa:

Reopened Complaint

olarak takip edilebilir.

Bu KPI:

sahte kapanışları

ortaya çıkarabilir.

Çünkü bazı ekipler:

işi hızla “Closed” yapar.

Ama problem:

gerçekte çözülmemiştir.

61. Complaint Response Dashboard

Örneğin:

Burada yönetici:

Response Time'ın iyi,

ama Resolution ve Follow-Up'ın zayıf

olduğunu görebilir.

62. Review Score ile Complaint Data Birlikte Okunmalıdır

Örneğin:

Complaint Log:

“Gürültü” şikâyetlerinde artış gösteriyor.

Online Reviews:

aynı dönemde:

“Rooms are noisy.”

yorumlarını artırıyor.

Bu durumda:

iki veri birbirini doğrular.

İç operasyon verisi ile:

dış misafir algısı

birleştirilmelidir.

63. Online Review da Complaint Data'dır

Misafir otelde söylememiş olabilir.

Ama:

Booking,

Google,

Tripadvisor

gibi platformlarda yazmış olabilir.

Bu yorum:

Complaint Database'e:

Post-Stay Feedback

olarak dahil edilebilir.

Böylece:

otelde söylenen ve otelden sonra yazılan problemler aynı sistemde analiz edilir.

64. Online Şikâyete Nasıl Cevap Verilmeli?

İyi cevap:

• kısa,
• kişiselleştirilmiş,
• savunmasız,
• profesyonel,
• çözüm odaklı

olmalıdır.

Kötü cevap:

“Misafir gerçeği yansıtmamaktadır.”

gibi tartışmaya dönüşebilir.

Online cevap yalnızca yorumu yazan misafire değil:

gelecekte rezervasyon yapacak yüzlerce kişiye

yazılır.

65. Her Olumsuz Yoruma Aynı Cevabı Vermeyin

“Değerli yorumunuz için teşekkür ederiz. Sizleri tekrar ağırlamak isteriz.”

şeklindeki kopyala-yapıştır cevaplar:

marka değerini düşürebilir.

Yorum:

temizlik hakkındaysa:

temizlik konusuna,

gürültü hakkındaysa:

gürültüye,

kahvaltı hakkındaysa:

kahvaltıya

referans verilmelidir.

Ama:

misafirin kişisel veya hassas bilgileri kamuya açık cevapta paylaşılmamalıdır.

66. Şikâyet Yönetimi ile Guest Profile Arasındaki İlişki

Operasyonel olarak anlamlı bilgiler:

Guest Profile'a kaydedilebilir.

Örneğin:

“Sessiz oda tercih ediyor.”

gelecek konaklama için yararlı olabilir.

Ama:

gereksiz,

aşağılayıcı,

kişisel yorumlar

kaydedilmemelidir.

Örneğin:

“Zor misafir.”

profesyonel bir veri değildir.

Daha doğru:

“Noise sensitivity noted; quiet room requested.”

gibi operasyonel bilgi olabilir.

67. Repeat Guest İçin Service Recovery'nin Değeri

Misafir geçmişte problem yaşamış ama:

iyi Recovery nedeniyle tekrar gelmiş olabilir.

Yeni rezervasyonda:

ekip bunu biliyorsa:

daha dikkatli hazırlık yapabilir.

Örneğin:

önceki konaklamada gürültü sorunu yaşayan misafir:

sessiz oda ile karşılanabilir.

Bu:

şikâyetin sadakat verisine dönüşmesidir.

68. Pre-Arrival Recovery

Bazı durumlarda Service Recovery:

misafir otele gelmeden başlayabilir.

Örneğin:

önceki konaklamada problem yaşandı.

Repeat Guest tekrar rezervasyon yaptı.

Pre-Arrival Briefing:

“Bu misafir önceki konaklamada klima problemi yaşamıştı. Oda teknik kontrolü özellikle yapılsın.”

şeklinde olabilir.

Bu:

geçmiş hatadan gelecekteki deneyimi iyileştirmek

demektir.

69. Complaint Management Günlük Briefing'de Nasıl Kullanılır?

Sabah toplantısında:

bütün Complaint Log okunmamalıdır.

Özet:

Yesterday

Dün hangi ciddi şikâyetler oldu?

Open

Hangileri hâlâ açık?

Repeat

Tekrar eden problem var mı?

Today

Bugünkü misafirleri etkileyebilecek risk var mı?

Action

Kim ne yapacak?

Bu format:

şikâyeti toplantı konusu değil, aksiyon konusu

yapar.

70. Haftalık Complaint Review

Haftalık olarak:

1. Complaint Count
2. Complaint Rate
3. Top Categories
4. Severity
5. Response Time
6. Resolution Time
7. Repeat Complaint
8. Service Recovery Cost
9. Online Review Issues
10. Root Cause
11. Corrective Actions
12. Open Actions

incelenebilir.

Ama toplantının sonunda mutlaka:

Owner + Deadline

olmalıdır.

71. Aylık Complaint Pareto

Örneğin:

İlk dört kategori:

toplam şikâyetlerin:

%73'ünü

oluşturuyor.

Yönetimin önceliği:

bu dört kaynağı sistematik olarak azaltmak

olmalıdır.

72. Complaint Heat Map Oluşturulabilir

Şikâyetler:

• oda,
• kat,
• gün,
• saat,
• departman,
• kategori

bazında analiz edilebilir.

Örneğin:

gürültü şikâyetlerinin:

%70'i

belirli üç odadan geliyorsa:

problem:

genel misafir hassasiyeti değil,

fiziksel bina problemi

olabilir.

Bu durumda çözüm:

Service Recovery değil;

CAPEX

olabilir.

73. Şikâyet Verisi CAPEX Kararına Dönüşebilir

Örneğin:

aynı odalarda sürekli:

• gürültü,
• klima,
• duş,
• izolasyon

şikâyeti geliyor.

Yönetim her seferinde:

ikram yapıyor.

Bu sürdürülebilir değildir.

Belki:

• ses izolasyonu,
• HVAC değişimi,
• banyo yenilemesi

gereklidir.

Dolayısıyla Complaint Data:

yatırım kararına veri sağlar.

74. Service Recovery ile CAPEX Arasındaki Denge

Örneğin yılda:

200.000 TL

gürültü kaynaklı Recovery Cost oluşuyor.

Kalıcı izolasyon yatırımı:

600.000 TL.

Sadece Recovery Cost açısından:

yaklaşık üç yıllık bir karşılaştırma oluşabilir.

Üstelik yatırım:

• Review Score,
• Guest Satisfaction,
• Repeat Guest,
• ADR

üzerinde de değer yaratabilir.

Bu nedenle:

şikâyet yönetimi yalnızca operasyon değil, yatırım yönetimidir.

75. Şikâyetleri Personel Performansına Nasıl Bağlamalıyız?

Dikkatli olunmalıdır.

Örneğin resepsiyon görevlisi:

20 Complaint kaydetti.

Başka çalışan:

5 Complaint kaydetti.

Bu:

ikinci çalışanın daha iyi olduğu anlamına gelmez.

Belki ilk çalışan:

şikâyetleri daha doğru kayıt altına alıyordur.

Personeli:

Complaint Count

ile cezalandırmak yerine:

• doğru kayıt,
• Response,
• Ownership,
• Follow-Up,
• Resolution Quality

üzerinden değerlendirmek daha anlamlıdır.

76. Complaint Handling KPI Seti

Güçlü bir set:

Volume

• Complaint Count
• Complaint Rate

Speed

• Response Time
• Resolution Time

Quality

• Resolution Rate
• First Contact Resolution
• Repeat Complaint
• Reopened Complaint

Follow-Up

• Follow-Up Completion Rate

Financial

• Service Recovery Cost

Root Cause

• Recurring Complaint Rate

Guest

• Review Score
• Guest Satisfaction
• NPS varsa NPS

şeklinde kurulabilir.

77. Guest Satisfaction ile Complaint Rate Birlikte Okunmalı

Örneğin:

Complaint Rate yükseldi.

Ama Guest Satisfaction da yükseldi.

Bu mümkün mü?

Evet.

Belki otel:

şikâyetleri daha iyi kaydetmeye başlamıştır.

Tersi:

Complaint Rate düştü.

Ama Review Score da düştü.

Belki misafirler:

şikâyet etmiyor;

doğrudan online yorum yazıyordur.

Bu nedenle:

tek KPI ile karar verilmemelidir.

78. Service Recovery Başarısı Nasıl Ölçülür?

Sadece:

“İndirim verdik.”

değil.

Bakılması gereken:

• problem çözüldü mü?
• misafir Recovery'yi kabul etti mi?
• Follow-Up olumlu mu?
• Complaint tekrarlandı mı?
• Review etkisi ne oldu?
• misafir tekrar geldi mi?

Asıl başarı:

harcanan Recovery Cost değil, geri kazanılan misafir deneyimidir.

79. Misafir Şikâyetinde 15 Büyük Hata

1. Misafirin sözünü kesmek

2. Savunmaya geçmek

3. Başka departmanı suçlamak

4. Şikâyeti kayıt altına almamak

5. Owner atamamak

6. Gerçekçi olmayan süre vermek

7. Misafirin tekrar aramasını beklemek

8. Her probleme indirim vermek

9. Hiçbir çalışana Recovery yetkisi vermemek

10. Follow-Up yapmamak

11. Aksiyon tamamlanınca Complaint'i otomatik kapatmak

12. Repeat Complaint'i ayrı izlememek

13. Root Cause araştırmamak

14. Online Review'ları operasyon verisine dahil etmemek

15. Complaint Data'yı cezalandırma aracı olarak kullanmak

Bu hataların ortak sonucu:

şikâyetin çözülmesi ama sistemin öğrenmemesidir.

80. Complaint Handling İçin 12 Karar Kapısı

Karar Kapısı 1

Şikâyet kayıt altına alındı mı?

Karar Kapısı 2

Severity belirlendi mi?

Karar Kapısı 3

Complaint Owner belli mi?

Karar Kapısı 4

Response başladı mı?

Karar Kapısı 5

Misafire gerçekçi ETA verildi mi?

Karar Kapısı 6

Problem gerçekten çözüldü mü?

Karar Kapısı 7

Service Recovery gerekli mi?

Karar Kapısı 8

Recovery yetki sınırları içinde mi?

Karar Kapısı 9

Misafire Follow-Up yapıldı mı?

Karar Kapısı 10

Complaint doğru şekilde kapatıldı mı?

Karar Kapısı 11

Repeat Complaint / Root Cause var mı?

Karar Kapısı 12

Sistemsel aksiyon gerekli mi?

Bu soruların tamamı:

şikâyeti olaydan yönetim sürecine dönüştürür.

81. Butik Otel İçin Minimum Complaint Management Dosyası

Küçük otelde karmaşık CRM şart değildir.

Başlangıçta:

1. Complaint Handling SOP
2. Complaint Log
3. Complaint Category List
4. Severity Matrix
5. Escalation Matrix
6. Service Recovery Policy
7. Authority Matrix
8. Recovery Cost Log
9. Follow-Up Checklist
10. Online Review Log
11. Root Cause Analysis Form
12. Corrective Action Log
13. Monthly Complaint Dashboard

yeterli olabilir.

Önemli olan:

dokümanın varlığı değil, günlük kullanım disiplinidir.

82. Şikâyet Yönetiminin Tam Döngüsü

Profesyonel sistem:

Guest Experience → Service Failure → Complaint → Listen → Acknowledge → Record → Categorize → Severity → Owner → Response → Resolve → Service Recovery → Follow-Up → Guest Verification → Close → Complaint Database → Trend Analysis → Pareto → Root Cause → Corrective Action → Preventive Action → SOP / Training / Process / CAPEX Change → Improved Guest Experience

Bu döngü kapanıyorsa:

otel yalnızca şikâyet çözmüyor; şikâyetlerden öğreniyor demektir.

83. Otel Yatırımcısı İçin 30 Saniyelik Complaint Dashboard

Yatırımcının bütün şikâyet kayıtlarını okumasına gerek yoktur.

Aylık olarak şu sekiz göstergeyi görmek güçlü bir başlangıçtır:

1. Complaint Rate

Ne kadar problem misafire ulaşıyor?

2. Top 5 Complaint Categories

En büyük problemlerimiz neler?

3. Average Response Time

Ne kadar hızlı harekete geçiyoruz?

4. Average Resolution Time

Problemi ne kadar hızlı çözüyoruz?

5. Repeat Complaint Rate

Gerçekten çözüyor muyuz?

6. Follow-Up Completion

Misafire geri dönüyor muyuz?

7. Service Recovery Cost

Hatalarımız bize ne kadara mal oluyor?

8. Review Score / Guest Satisfaction

Misafir sonuçta ne düşünüyor?

Bu göstergeler birlikte:

şikâyetin operasyonel, finansal ve itibari etkisini

göstermeye başlar.

Sonuç: Şikâyeti Çözmek Yetmez, Şikâyetten Öğrenmek Gerekir

Misafir:

“Klimam çalışmıyor.”

dedi.

Teknik ekip geldi.

Klimayı tamir etti.

Bu:

Repair

işidir.

Resepsiyon misafire geri döndü.

Konforunu kontrol etti.

Gerekli Recovery'yi yaptı.

Bu:

Service Recovery

işidir.

Yönetim ay sonunda aynı klima probleminin:

12 farklı odada tekrarlandığını gördü.

Root Cause Analysis yaptı.

Preventive Maintenance planını değiştirdi.

Bu ise:

operasyon yönetimidir.

Aradaki fark büyüktür.

Zayıf sistem:

şikâyeti kapatır.

Güçlü sistem:

şikâyetin nedenini ortadan kaldırmaya çalışır.

Çünkü otelcilikte en pahalı şikâyet:

misafire verilen ücretsiz kahve değildir.

En pahalı şikâyet:

aynı problemin yüzlerce misafire tekrar tekrar yaşatılmasıdır.

Bu nedenle iyi Complaint Handling sistemi:

dinler,

kaydeder,

sahiplenir,

çözer,

telafi eder,

geri döner,

ölçer,

analiz eder

ve:

öğrenir.

Sonuçta hedef:

sıfır şikâyet kaydı

değildir.

Çünkü sıfır kayıt:

sıfır problem anlamına gelmeyebilir.

Gerçek hedef:

problemleri mümkün olduğunca misafire ulaşmadan önlemek; ulaştığında hızlı ve adil şekilde çözmek; aynı problemin tekrarını sistematik olarak azaltmaktır.

İyi otel:

şikâyeti çözer.

İyi yönetilen otel ise:

şikâyeti daha iyi bir operasyon sistemine dönüştürür.

Otel Yatırım Rehberi — Cilt V

Bu makale, Otel Yatırım Rehberi — Cilt V: Operasyon kapsamında ele aldığım Misafir İlişkileri, Complaint Handling ve Service Recovery yaklaşımından hazırlanmıştır.

Cilt V'te misafir şikâyetleri;

• Guest Journey,
• Complaint Handling,
• Complaint Ownership,
• Severity,
• Escalation,
• Service Recovery,
• Authority Matrix,
• Follow-Up,
• Complaint Log,
• Root Cause Analysis,
• Corrective / Preventive Action,
• Review Management,
• Guest Satisfaction,
• Repeat Guest,
• operasyonel öğrenme

ile birlikte bütünsel bir misafir deneyimi yönetim sistemi içinde ele alınmaktadır.