1. Neden satış sonrası destek iç iletişim köprüsüdür?
Satış sonrası destek, misafirle konuşan “ön hat” olduğu için tüm taleplerin ortak kesişim noktasıdır. Resepsiyon sahayı görür, housekeeping odaları yönetir, teknik servis arızayı çözer; fakat misafir iletişimi, takip ve kapanış disiplini çoğu zaman satış sonrası ekibe yaslanır. Köprü rolünün anlamı şudur: Talep doğru departmana gider, çözüm süreci görünür olur ve misafir “boşluk” yaşamaz.
Key Statistics / Data Point (rakam vermeden)
İyi kurgulanmış iç iletişim sistemlerinde çözümsüz kalan talep sayısının ve tekrar arama oranının azalabildiği; ekip içi sürtünmenin düştüğü ifade edilebilir.
Mini Check
- • Tüm talepler tek bir ticket/case sistemine giriyor.
- • Sahipsiz talep yok; owner zorunlu.
- • Kapanış, misafir teyidiyle yapılıyor.
Ne yapmalıyım?
- • “Tek kayıt sistemi” kuralını yazılı hale getir.
- • Owner ve SLA’yı ticket’ta zorunlu alan yap.
- • Kapanışta misafir teyidini standartlaştır.
- • Performansı ortak raporda izle.
2. Resepsiyon, housekeeping, teknik servis ve diğer departmanlarla akış
Departmanlar arası akışta en büyük hata, “mesajı WhatsApp grubuna atıp çıkmak”tır. WhatsApp grupları hızlıdır ama kayıt ve kapanış disiplini zayıftır. En iyi pratik: WhatsApp/e-posta “iletişim” için kalabilir, fakat kayıt ve takip ticket üzerinden yürür. Böylece her departman “ne yapacağını” ve “ne zaman biteceğini” bilir.
Talep türü → departman eşleştirme (örnek)
- •Oda hazırlık/temizlik → Housekeeping
- •Klima/elektrik/tesis arızası → Technical Service
- •Oda değişimi/kompanzasyon/upgrade → Front Desk + Supervisor
- •Transfer/konum → Concierge/Guest Relations (Varsayım: rol var)
Mini Check
- • Talep türleri departmanlara önceden map edildi.
- • Her map’in bir owner rolü var.
- • WhatsApp sadece “hızlı haberleşme”; kayıt ticket’ta.
Ne yapmalıyım?
- • Talep türleri sözlüğü çıkar (10–20 başlık).
- • Her başlığa departman + yedek owner ata.
- • Çok kritik talepler için escalation yolunu yaz.
- • Günlük kısa koordinasyonla tıkanıklıkları çöz.
3. Ticket/case yapısı nasıl kurulur?
Ticket sistemi, “kayıt defteri” değil, karar ve takip aracıdır. İyi ticket şu üç soruya cevap verir:
- Ne oldu? (durum)
- Kime gidecek? (owner)
- Ne zaman kapanacak? (SLA)
Örnek ticket alanları (minimum set)
- •Misafir / rezervasyon referansı (minimum gerekli)
- •Talep türü (kategori)
- •Kanal (telefon/WhatsApp/resepsiyon/OTA)
- •Öncelik (P1/P2/P3)
- •Owner (departman + kişi)
- •SLA (ilk yanıt / çözüm)
- •Durum (Açık / Beklemede / Çözüldü / Kapandı)
- •Notlar + ek (foto, ekran görüntüsü) (Varsayım: sistem destekliyor)
Mini Check
- • Ticket alanları standart ve zorunlu.
- • Öncelik ve SLA var.
- • Kapanış teyidi alanı mevcut.
Ne yapmalıyım?
- • Ticket alanlarını standardize et (minimum set).
- • Özel isteklerde PMS notu ile ticket’ı ilişkilendir (Varsayım).
- • “Durum” akışını netleştir (açık→çözüldü→kapandı).
- • Eğitimde 5 örnek ticket yazdır (role-play).
4. SLA ve geri bildirim döngüsü: hız + kalite dengesi
SLA sadece hız değildir; belirsizliği azaltır. Misafir için en büyük problem, “ne zaman çözülecek?” sorusunun cevapsız kalmasıdır. Bu yüzden iki SLA düşünün: ilk yanıt ve çözüm. Ayrıca çözülen talep kapanmadan önce “misafir teyidi” alın; aksi halde tekrar açılma oranı yükselir.
SLA ve sahiplik (owner) tablosu (örnek)
| Öncelik | Örnek talep | İlk yanıt SLA | Çözüm SLA | Owner | Eskalasyon |
|---|---|---|---|---|---|
| P1 | Klima/elektrik/tesis arızası, misafir konforunu anlık etkileyen kritik durum | 15 dk | 60 dk | Technical Service + Supervisor | Supervisor/amir → operasyon müdürü |
| P2 | Oda hazırlık/temizlik gecikmesi, oda değişimi, kompanzasyon ihtiyacı | 30 dk | 120 dk | Housekeeping / Front Desk | Bölüm amiri → operasyon müdürü |
| P3 | Bilgi talebi, transfer/konum yönlendirmesi, düşük kritik istekler | 60 dk | Aynı vardiya içinde | İlgili departman + atanmış kişi | Supervisor değerlendirmesi |
Mini Check
- • İlk yanıt ve çözüm SLA ayrı.
- • Owner ve escalation net.
- • Kapanış misafir teyidiyle.
Ne yapmalıyım?
- • P1/P2/P3 öncelik tanımla ve örneklerle öğret.
- • SLA’yı “gerçekçi” kur (ekibi yakma).
- • Eskalasyon kriterleri belirle (P1 gecikme, tekrar açılma).
- • SLA trendini aylık raporla.
5. İç iletişim hataları ve çözümleri: talep kayboluyor, sahip yok, kapanış yok
İç iletişimde tekrar eden hatalar genelde aynıdır:
- •Talep WhatsApp’ta kalır, ticket açılmaz.
- •Owner belirsizdir (“herkes” = kimse).
- •“Çözüldü” denir ama misafir teyidi yoktur.
- •Eskalasyon gecikir, tekrar arama artar.
Hızlı çözüm reçetesi (mini örnek)
- •“WhatsApp mesajı geldi” → ticket aç + linki ekle
- •“Sahip kim?” → owner zorunlu alan
- •“Kapandı mı?” → kapanış teyidi + not
Mini Check
- • WhatsApp’tan ticket’a dönüşüm var.
- • Sahiplik zorunlu.
- • Çözüldü ≠ Kapandı kuralı uygulanıyor.
Ne yapmalıyım?
- • “Ticket açmadan işlem yok” kuralı koy.
- • Owner atamayı otomatikleştir veya SOP’a bağla.
- • Kapanış teyidini metrik yap (takip edilir).
- • Günlük koordinasyonla tıkanıkları temizle.
6. Günlük kısa koordinasyon toplantıları: 10 dakikalık ritim
Büyük resort yapılarda (Antalya/Belek/Side) departman sayısı arttıkça talep kaybı riski büyür. Günlük 10 dakikalık “operasyon–satış sonrası” stand-up, en kritik açık talepleri görünür kılar. Ama toplantı, ticket sisteminin yerine geçmez; ticket’ı besler.
Stand-up gündemi (örnek)
- •Dün açık kalan P1’ler
- •Bugün riskli talepler (check-in yoğunluğu)
- •Tekrar açılan talepler (kök neden)
- •Owner değişiklikleri / kapasite
Mini Check
- • Stand-up kısa ve metrik odaklı.
- • Çıktı: ticket güncellemesi ve owner netliği.
- • Tekrar açılanlar kök neden listesine gidiyor.
Ne yapmalıyım?
- • 10 dk sınırı koy.
- • Sadece P1/P2 konuş (P3 raporda).
- • Toplantı sonunda 3 karar yaz (owner + tarih).
- • Haftalık trend raporuyla birleştir.
7. Operasyon ve çağrı merkezi performansının birlikte raporlanması
İç iletişim akışı doğru kurulunca raporlama iki tarafta da görünür olur: satış sonrası ekip “kaç talep geldi”yi, operasyon “kaçını çözdü”yü görür. Birlikte raporlamak, “suç” değil, iyileştirme üretir.
İç linkler (kullanım)
- •https://dgtlface.com/tr/cagri-merkezi/performans-analizi
- •https://dgtlface.com/tr/raporlama/satis-donusum
Mini Check
- • Ortak KPI paneli var.
- • SLA trendi ve tekrar açılma izleniyor.
- • İyileştirme aksiyonları owner’lı.
Ne yapmalıyım?
- • Ortak dashboard oluştur (Varsayım: BI/Looker).
- • Haftalık trend + aylık kök neden raporu çıkar.
- • Eğitim ihtiyaçlarını rapordan çıkar (role-play).
- • “Başarı hikâyeleri”ni ekip içi paylaş (motivasyon).
8. Departmanlararası Akış & Ticket Şablonunu İndir — Çağrı Merkezi / Satış Sonrası Destek
Departmanlararası Akış & Ticket Şablonunu İndir — Çağrı Merkezi / Satış Sonrası Destek (v1.0)
Bu şablon, satış sonrası destek ekibi ile resepsiyon/housekeeping/teknik servis arasındaki iç iletişimi “tek ticket + tek owner + SLA” modeliyle standardize etmek için hazırlandı. Talebin kaybolmasını önler, önceliklendirme ve eskalasyonu görünür kılar. Günlük 10 dakikalık koordinasyon ritmi ve ortak KPI paneli ile süreç iyileştirmeyi hızlandırır.
Kim Kullanır?
Operasyon müdürü, ön büro amiri, çağrı merkezi süpervizörü, housekeeping/teknik servis amirleri.
Nasıl Kullanılır?
- Her talep için ticket aç ve minimum alanları doldur (kategori, öncelik, owner, SLA).
- Akış diyagramına göre doğru departmana yönlendir ve “çözüldü/kapatıldı” ayrımını uygula.
- Günlük stand-up ve haftalık raporla tıkanıkları temizle, SLA trendini izle.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Ticket Alanları (minimum zorunlu)
- ▢ ✅ Owner & Eskalasyon Kuralı
- ▢ ✅ SLA Tablosu (kopyala–uygula)
- ▢ ✅ Akış Diyagramı (metin akışı)
- ▢ ✅ Günlük 10 dk Stand-up Gündemi
- ▢ ✅ Deliverables
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
9. Competitor gap’i kapatma: satış sonrası ekibi operasyonun merkezi köprüsü yapmak
Rakip içerikler şikâyeti tek departman üzerinden anlatır; oysa otelde gerçek çözüm, departmanlar arası koordinasyondur. Bu rehber, After-Sales Support’u merkezi köprü olarak konumlandırır; ticketing, SLA, owner atama, kapanış teyidi, günlük koordinasyon ve ortak raporlamayı tek modele bağlar. Böyle bir sistemin, sahipsiz talepleri ve tekrar aramayı azaltabileceği yönünde pratik bir çerçeve sunar (kesin rakam iddiası olmadan).
Bir Sonraki Adım
Departmanlar arası akışı ölçer, ticket alanları + SLA/owner modeli ve koordinasyon ritmini çıkarır; operasyon ve çağrı merkezi için.
Sık Sorulan Sorular
Satış sonrası destek ekibi resepsiyon ve operasyonla nasıl çalışmalı?▾
Ticket/case yapısı nasıl kurulur?▾
Misafir talebinin hangi departmana gideceğine kim karar verir?▾
Çözülmeyen talepler nasıl takip edilir?▾
Talep kayboluyor, nasıl engellerim?▾
İç iletişimde en sık hata nedir?▾
İlgili İçerikler