1. OTA entegrasyon projesini nasıl yönetirim?
“OTA entegrasyon projesini nasıl yönetirim?” sorusunun cevabı basit: kapsamı yazın, bir proje sahibi atayın, rolleri dağıtın, test senaryolarını planlayın ve go-live gününü vardiya gibi yönetin.
2. OTA entegrasyon projesinin aşamaları (uçtan uca çerçeve)
Projeyi “aşama”lara bölmek, ekiplerin aynı dili konuşmasını sağlar. En pratik ayrım:
- Kapsam & hedef (Kickoff): hangi OTA’lar, hangi oda tipleri, hangi rate plan’lar, hangi başarı KPI’ları
- Hazırlık (Setup): PMS/CM/OTA hesapları, yetkiler, mapping listeleri, politika/ödeme çerçevesi
- Konfigürasyon (Build): room/rate mapping, kısıtlar, stop-sell, ödeme/virtual card akışı
- Test (UAT): test rezervasyon, iptal/no-show, stop-sell, fiyat güncelleme, rapor doğrulama
- Go-live: planlı yayın, vardiya, “geri dönüş” (rollback) planı, izleme
- Stabilizasyon (İlk 30 gün): hata log’u, düzeltme sprint’i, KPI izleme ve süreç iyileştirme
☑ Mini Check : Proje aşamaları yazılı mı?
- •Kapsam ve başarı KPI’ları net
- •Test senaryoları ve kabul kriterleri yazılı
- •Go-live ve rollback planı var
Ne yapmalıyım?
- • Her aşama için “çıktı listesi” oluşturun (deliverables).
- • Aşamaları tarihe bağlayın (Gantt).
- • Stabilizasyonu proje kapsamına dahil edin (go-live ile bitmez).
3. Proje ekibi ve departman bazlı sorumluluklar (rol matrisi)
Proje başarısı, “kim onaylar?” sorusunun netliğine bağlıdır. Aşağıdaki roller, otellerde en sık ihtiyaç duyulan minimum seti oluşturur:
- •Project Owner (Proje Sahibi): kapsam, öncelik, karar ve tedarikçi koordinasyonu
- •Sales Manager / RM: fiyat, kampanya, rate plan, parity ve kanal stratejisi
- •Reservation Supervisor: mapping doğrulama, test rezervasyon senaryoları, kanal akışı
- •IT Lead: yetki/token, entegrasyon sağlığı, log analizi, senkron KPI
- •Finance Lead (Muhasebe/Finans): komisyon, virtual card/POS, posting, iade/no-show gelir kaydı
- •Front Office / Operations: check-in/out akışı, overbooking SOP, misafir iletişim standardı
- •Vendor Leads: PMSVendor, ChannelManagerVendor, OTAVendor (destek, konfigürasyon, SLA)
| Departman/Rol | Sorumluluk | Onay/Kabul |
|---|---|---|
| Project Owner | kapsam, takvim, risk, vendor koordinasyonu | kapsam ve go-live onayı |
| Sales/RM | rate plan, parity, kampanya, kanal rolü | fiyat/kampanya kabulü |
| Rezervasyon | mapping kontrolü, test rezervasyon, iptal senaryosu | UAT kabulü |
| IT | auth, log, senkron/latency, monitoring | teknik sağlık kabulü |
| Finans | virtual card/POS, posting, komisyon raporu | finansal akış kabulü |
| Operasyon/FO | go-live vardiya, misafir SOP, overbooking akışı | operasyon kabulü |
| Tedarikçiler | konfigürasyon, hata çözümü, SLA | teslim/çözüm taahhüdü |
☑ Mini Check : Rol çatışması var mı?
- •Tek bir Project Owner var
- •Fiyat/komisyon/ödeme kararında finans masada
- •Go-live günü FO/operasyon rolü net
Ne yapmalıyım?
- • Rol matrisi tablosunu kickoff’ta imzalatın (mail/meeting notes).
- • “Kabul kriterleri”ni yazın: test geçmeden go-live yok.
- • İç link referansları: /pms-ota/pms-kurulum ve /pms-ota/kanal-yonetimi
4. PMS–Channel–OTA tedarikçileri ile çalışma (SLA ve toplantı disiplini)
Tedarikçiyle çalışırken en büyük kayıp, “konuşuyoruz ama ilerlemiyoruz” durumudur. Bunu önlemek için:
5 pratik tedarikçi kuralı
- •Tek iletişim hattı: her tedarikçiyle tek sorumlu kişi (ProjectOwner veya IT)
- •Haftalık ritim: sabit status toplantısı + aksiyon listesi
- •SLA netliği: kritik hatada kim, ne sürede yanıt verir?
- •Log & kanıt standardı: destek kaydına eklenecek bilgiler şablonlu olsun
- •Değişiklik yönetimi: mapping değiştiyse “audit” şart
Mini örnek
Antalya’da sezona yetişmek için go-live tarihi yaklaştığında, tedarikçi toplantıları “günlük kısa stand-up”a döner. Burada en kritik şey, “bugün hangi 3 engeli kaldırıyoruz?” disiplinidir.
☑ Mini Check : Vendor yönetimi
- •Haftalık status + aksiyon listesi var
- •SLA ve escalation net
- •Değişiklikler için mapping audit prosedürü var
Ne yapmalıyım?
- • Aksiyon listesini her toplantıdan sonra maille sabitleyin.
- • Kritik hatalarda evidence pack ile gidin (log, requestId, ekran).
- • Bakım/destek perspektifi için: /yazilim/bakim-ve-destek
5. Test, Go-Live ve sonrası (disiplinli lansman)
Go-live başarısı, test disiplininin doğrudan sonucudur. “Bir şeyler çalışıyor gibi” yeterli değildir; kritik senaryoların uçtan uca geçmesi gerekir.
Test planı: minimum senaryo seti
- •Room mapping doğrulama (oda × rate plan)
- •Fiyat güncelleme testi (latency ölçümü)
- •Stok/stop-sell testi (overbooking risk kontrolü)
- •İptal/no-show testi (policy + posting + rapor)
- •Virtual card/POS ödeme testi (finans kabulü)
- •Rapor doğrulama (PMS vs OTA sayıları)
Go-live günü vardiya planı (otel gerçekliği)
- •FO/rezervasyon/IT/finans “hazır” olmalı
- •Bir “war room” iletişim kanalı (Teams/WhatsApp/Slack)
- •Rollback planı: kritik hata olursa neyi kapatıyoruz?
Veri noktası (yumuşatılmış, sheet ile uyumlu): İyi yönetilen projelerde go-live sonrası ilk ay destek taleplerinin ve hata oranının daha düşük seyrettiği; plansız kurulumlarda “ilk hafta kaosu” yaşandığı pratikte sık görülür. Bu farkı yaratan şey çoğu zaman test ve rol netliğidir.
☑ Mini Check : Go-live readiness
- •Test senaryoları “passed” ve kayıtlı
- •Go-live günü sorumlular ve iletişim hattı belli
- •Rollback planı yazılı
Ne yapmalıyım?
- • Go-live’ı “vardiya” gibi planlayın; kim neredeyse orada olsun.
- • Finansal akış testini (virtual card/posting) go-live’dan önce bitirin.
- • İlk 30 gün için hata log’u ve sprint planı kurun .
6. Sık yapılan proje hataları (en çok kaybettiren 7 hata)
- Kapsamın belirsiz olması (oda/rate/politika net değil)
- Tek proje sahibi olmaması (karar gecikir)
- Finansın projeye geç dahil olması (virtual card/posting krizi)
- Testin “gösterim” olması (senaryo kayıt yok)
- Go-live günü plansızlık (kimin ne yapacağı belli değil)
- Mapping değişikliklerinin audit edilmemesi (tekrar eden hatalar)
- Stabilizasyonun proje dışı görülmesi (go-live sonrası kontrolsüzlük)
☑ Mini Check : Hangi hata riski var?
- •Finans süreçleri netleşmedi
- •Test senaryoları yazılı değil
- •Go-live vardiya planı yok
Ne yapmalıyım?
- • Kapsamı 1 sayfada yazın, onaylatın.
- • Testi “senaryo + kanıt + kabul” formatına çevirin.
- • Stabilizasyonu proje planına dahil edin.
7. OTA entegrasyon projesi için 30 günlük aksiyon planı
Gün 1–5 (Kickoff & Kapsam)
- •kapsam + hedef KPI + oda/rate listesi
- •rol matrisi onayı
- •vendor iletişim/SLA netliği
Gün 6–15 (Build & Mapping)
- •room/rate mapping + kısıtlar
- •ödeme/virtual card akışı taslağı
- •ilk test günlüğü (latency ölçümü)
Gün 16–25 (UAT Test)
- •test rezervasyon, iptal/no-show, stop-sell
- •rapor doğrulama (PMS vs OTA)
- •go-live checklist ve rollback planı
Gün 26–30 (Go-live & Stabilizasyon)
- •go-live vardiya + war room
- •ilk hafta günlük kontrol (fiyat/stok/iptal)
- •hata log’u + 14 günlük düzeltme sprint backlog’u
İç link önerileri (otorite güçlendirme)
- • /pms-ota/pms-kurulum
- • /pms-ota/ota-entegrasyonu
- • /pms-ota/kanal-yonetimi
- • /pms-ota-yonetimi
8. OTA Entegrasyon Proje Checklist’i — PMS & OTA Yönetimi (v1.0)
OTA Entegrasyon Proje Checklist’i — PMS & OTA Yönetimi (v1.0)
Bu checklist, OTA entegrasyonunu “teknik kurulum” değil, otel içinde departmanlar arası yürüyen bir proje olarak yönetmenizi sağlar. Kapsam, rol matrisi, test senaryoları, go-live vardiya planı ve ilk 30 gün stabilizasyon döngüsünü tek standartta toplar. Sonuç: go-live sonrası hata oranı ve destek talepleri düşer; ekipler aynı hedefte hizalanır.
Kim Kullanır?
Project Owner, rezervasyon lideri, IT lead, finans lead ve FO/operasyon yöneticisi.
Nasıl Kullanılır?
- Kickoff’ta kapsam ve rol matrisi onayını al.
- Test senaryolarını yaz, kanıtla ve kabul kriteriyle go-live’a gir.
- İlk 30 gün hata log’u + sprint planıyla stabilizasyonu yönet.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Kapsam dokümanı (OTA’lar, oda tipleri, rate plan’lar) hazır
- ▢ ✅ Başarı KPI’ları tanımlı (hata oranı, latency, overbooking)
- ▢ ✅ Rol matrisi imzalı (PO/Sales/Rez/IT/Fin/FO)
- ▢ ✅ Vendor SLA + escalation net
- ▢ ✅ Mapping matrisi dokümante (oda × rate × kanal)
- ▢ ✅ Test senaryoları yazılı (rezervasyon/iptal/no-show/stop-sell/ödeme)
- ▢ ✅ Go-live vardiya + war room planı hazır
- ▢ ✅ Rollback planı yazılı
- ▢ ✅ İlk 30 gün izleme ritmi planlandı
- ▢ ✅ Hata log’u + düzeltme backlog’u oluşturuldu
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
9. Sonuç: OTA entegrasyonunda başarı teknik kurulumdan önce proje disiplinidir
OTA entegrasyonu teknik olduğu kadar bir proje yönetimi konusudur. Başarılı kurulum için kapsamın net tanımlanması, satış–rezervasyon–IT–muhasebe–operasyon ekipleri arasında rol paylaşımı yapılması, PMS–channel–OTA tedarikçileriyle ortak takvim oluşturulması ve go-live öncesi testlerin disiplinli yürütülmesi gerekir.
İyi yönetilen projelerde ilk ay hata oranı ve destek talepleri daha düşük seyreder; plansız kurulumlarda ise “ilk hafta kaosu” yaşanır.
Bir Sonraki Adım
Sezona yetişecek şekilde kapsam, rol ve test disiplinini kurmak isteyen oteller için.
Sık Sorulan Sorular
OTA entegrasyon projesi nasıl yönetilir?▾
OTA entegrasyonunda otel içindeki ekiplerin rolü nedir?▾
PMS–channel–OTA tedarikçileriyle proje süreci nasıl ilerler?▾
Go-live öncesi hangi adımlar mutlaka planlanmalı?▾
En sık proje hatası nedir?▾
İlk 30 günde ne izlenmeli?▾
İlgili İçerikler