"senaryo" etiketli yazılar:

26 Eylül 2026 Cumartesi

Bankada MOST® – 2

Alelade süreç tasarımı ile dijitalleştiğini sanan banka

Dün TEB şubesinde işlem yapmaya çalıştım.

Özeti şöyle:

  • Dijital işlem yapmam gereken kabinde 15+ dakika geçirdim işlem yapamadım.
  • 4-5 dakika yeniden şube içine dönüp sıra bekledim.
  • Şube elemanıyla 3 dakikada işlemi tamamladık.

Dikkatinizi çekeyim. Şube iş yükünü (ve eleman sayısını) azaltmak için şubeye koydukları dijital işlem yapılan hücrede 15 dakika geçirdim ve sonuç SIFIR. Şubede çalışanla 3 dakikada bitti.

Dijital Bankacılık Sınavı

Bankadaki döviz hesabıma para yatırmam gerekiyordu. Kuyrukmatik beni turbo diye adlandırdıkları dijital makinenin bulunduğu (yukarı resimdeki) hücreye yönlendirdi. Hücreye girdim. Zaten kuyrukmatik üzerinden geldiğim için adım soyadım ekranda belirdi. Kredi kartımı koyup şifresini girdim. Büyük ekranda ne yapacağımı sordu. Para yatırma için tuşladım. Kendi hesabım olduğunu tuşladım. Önüme gelen listede para yatıracağım hesap yoktu. Sadece TL hesaplar vardı. Başka hesap tuşlayınca, mobil uygulamadaki EFT/FAST ekranına benzer bir görüntü geldi.

  • TEB’deki bir hesabıma para yatıracağımı tuşlamama rağmen neden o bankadaki diğer hesaplarımın değil de başka bankaya işlem yapar gibi bir ekran geldiğini birkaç saniye sorguladım. Listede ilgili hesabı göremeyince “müşteri temsilcisi ile görüşmek” istediğimi tuşladım.

Karşıma çıkan hanımefendiye “neden insan ile görüşmek zorunda kaldığımı” da anlattım. Sonrası tam bir eziyetler zinciri oldu.

Hanımefendi, ilk önce “kimlik veya ehliyet” istedi. Ehliyetimi okuttum. Ama “zaten kredi kartını ve şifreyi girdiğimi” hatırlattım.

Sonra kimlik istedi. “Ehliyetimi okuttunuz, neden kimlik soruyorsunuz” dedim. Prosedür gereği imiş. “Şubede de kimlik istiyorlarmış”. Öyleyse neden az önce ehliyet sordu. “Banka kendi veri setini mükemmelleştiriyor” diye düşündüm. İşimi hızlıca bitirmek istediğim için tartışma açmadım.

Dijital hücrede kimlik kartımı 2 kere önlü arkalı okuttular. “Neden 2 kere” diye sorduğumda “İki nüsha” yanıtını aldım.

  • Şaka değil. Dijital işlem yapıyor ve 2 nüsha için ikişer kere önlü arkalı okutuyor. İki günden beri bunu kime anlattıysam ya inanmadı ya da kahkahayla güldü.

Daha birkaç ay önce, başka bir işlemi yaparken yine kimlik kartımı önlü arkalı okutmuşlardı. Onu hatırlattım. Yanıt olarak “Kimlik kartınız GEÇERLİ statüsünde” dedi. “İyi ya. GEÇERLİ ise işlemi tamamlayın” Meğerse GEÇERLİ statüsü değil, ONAYLI statüsü olması gerekiyormuş. Kimlik kartımın iki kere önlü arkalı okutulması da bu nedenle yapılmış.

Defalarca, “Önce benim para yatırma işlemlerimi bitirin, sonra kimlik kartı statüsüyle ilgilenin. Beni geciktiriyorsunuz” dediysem de işe yaramadı. İnatla, benim için hiç katma değeri olmayan prosedüre devam etti.

  • Muhtemelen müşteri dijital hücrede otururken karşı taraftaki görevli arkadaşın performans hedeflerinde işi erken ve düzgün bitirme yok ama veri toplama var. (Şu yazıyı mutlaka okuyunuz.)

Nihayet para yatırma işlemine geçebildik. Elimde kupürleri farklı banknotlar vardı. “Para yatırma haznesini açıyorum” dedi hanımefendi. Banknotları koydum. İşlem tamamlanmadı. Hatırladığım kadarıyla 5 kere denedik. Sonuç SIFIR.

En sonunda “Şubeye mesaj gönderdim. İşlemi onlar yapacaklar” dedi. Hücreden çıktım. O sırada bankolarda 2 kişi vardı. O müşterilerden birinin gitmesi 4-5 dakika aldı. O ana kadar şubeye gireli 20 dakika olmuştu ve ben de patlamaya hazır bomba gibi olmuştum.

Yine de şubede sıram gelince kendime hâkim oldum. Bankodaki arkadaşın hiç suçu yoktu. Kimlik kartımı verdim. Parayı yatırdım. Mobil uygulamada, hesaba geçtiğini gördüm. Şubeden çıktım. İşlem sadece 3 dakika sürdü.

  • Şubede 23 dakika geçirmiştim ve işlem sadece 3 dakika sürmüştü.

Bugün sabah şubeden aradılar. Kredi kartımı turbo 🙂 cihazında unutmuşum. Hemen gidip aldım. Kendime “iki gündür sabah yürüyüşleri yaptığımı” söyleyerek teselli aradım.

🙁

Müşteri Odaklı Süreç Tasarımı – MOST®

Birkaç ay önce, bankada MOST® konusuna değinmiştim. Bu yazı, aynı çerçevede ikinci yazı olacak.

Şubedeki iş yükünü ve eleman sayısını azaltmak için turbo adını verdiğiniz cihazlara yüzbinlerde dolar yatırıyorsunuz. Sonra o cihazların iş akışlarını yazarken müşteri deneyimini tümden göz ardı ediyorsunuz. Sonuçta, turboya ve sizin dijital bankacılığınıza lanet okuyan, şubede çalışanları kutsayan müşteri yaratıyorsunuz.

Bakın:

  • Neden bankadaki “para yatırılabilir” hesaplarımın tamamı listelenmiyor? Neden müşteri temsilcisiyle görüşmek zorunda bırakılıyorum?
  • ATM’den para yatırırken veya para çekerken kredi kartı veya banka kartı + şifre yeterli mi? EVET ise, neden turbo hücresinde yeterli değil?
  • Turbo hücresinde (varsayalım ki) ikinci bir kimlik doğrulaması için ehliyet okuttuktan sonra neden kimlik kartı da isteniyor?
  • Kimlik kartı neden iki kez arkalı önlü okutuluyor? Bu işlemin yanlış olduğu neden ilgili elemana UYARI olarak gitmiyor?
  • Zaten GEÇERLİ kart olduğu belliyken, neden işlem yapılmıyor?
  • Döviz hesabına küçük bir miktar para yatırılacakken neden süre 15 (hatta 23) dakikaya uzuyor?
  • Süre uzadığında neden ilgili elemana “kimlik doğrulamayı bırak, müşterinin işini yap” uyarı mesajı gitmiyor?
  • Farklı kupürdeki banknotları kabul etmiyorsa, neden UYARI mesajı verilmiyor?
  • Neden “işlem yapılamadı” olduğunda (veya hücrede yapılacak iş kalmadığında) “kredi kartınızı geri alın” mesajı verilmiyor?

Bu soruların yanıtları çok zor değil. Aslında, bu soruların hiç sorulmamasını sağlamak gerekiyordu. Öncesinde müşteri deneyimine uygunluğu senaryolarla denenmiş, işlemler ve akışlar test edilmiş ve gözden geçirilerek hayata alınmış olsaydı, bu kadar memnuniyetsizlik yaratılmazdı.

İyi de… Doğrusu Nasıl?

Evrim Ersoy, Marketing Türkiye’deki  röportajını sanki, TEB ile yaşadığım olay için yazmış. Bazı cümleleri cımbızlıyorum:

  • Sadakati yaratan vay be anları değil, düşük çabadır.
  • Görünmez deneyim, kullanıcının zihnindeki “nasıl yapacağım?” sorusunun ve bilişsel yükün tamamen ortadan kaldırılmasıdır, markanın müşteri ihtiyacını, müşteri talep etmeden önce sezip proaktif olarak karşılamasıdır.
  • Sürtünmesiz olmayı insansız olmakla karıştırmamak gerekli.

Nalan Yenigün Eren‘in Marketing Türkiye’deki röportajından cımbızladığım cümleler ise şöyle:

  • Teknoloji, yapay zekâ, otomasyon ve kişiselleştirme… Hepsi ancak gerçek bir ihtiyaca dokunduğunda ve deneyimin doğal bir parçası olduğunda anlam kazanıyor.
  • Herkese ya da belirli segmentlere aynı sabit yolculukları tasarlamak artık geride kalıyor. Bugün geleneksel demografik verilerden çok, müşterinin o anda nerede olduğu, nasıl hissettiği ve ne yapmaya çalıştığı önem kazanıyor.
  • Başarılı bir görünmez deneyim, müşterinin hayatını kolaylaştırırken aynı zamanda kontrolün hâlâ onda olduğu hissini vermeli.

Üzerine söylenecek söz yok. Deneyim tasarımı ilkeleri yeterince anlatılmış. “Teori ile uygulama arasındaki fark, insanın becerisi ve aklıyla ters orantılıdır” derdi bir hocamız.

Devamı Var

Yazı çok uzadı. Daha söylenecek çok şey var ama bir yerde kesmek gerekiyor.

TEB’deki deneyim tasarımcıları başta olmak üzere, bütün bankalardaki tasarımcılar için bu yazının devamını yazacağım. O daha eğlenceli olacak.

😛

Eş zamanlı olarak Linkedin’de yayınlandı.

21 Şubat 2026 Cumartesi

Müzakere Kavramını Anlamak – 1

Pazarlamanın çeşitli konularında eğitmen olarak uzun yıllar geçirdim. Eskiden kalma yöneticilik deneyimim de var. Geçmişte eğitimlerime katılanlarla ve eski ekip arkadaşlarımın bir kısmıyla dostluğumuz sürüyor. Bunlardan biri yakın geçmişte, uluslararası bir şirketin Türkiye ofisini kurdu. Kendisi de sermaye yatırdı, böylece üst düzey beyaz yakalı olmayı terk edip girişimci oldu.

Ana şirketle bir sorun yaşadığında beni aradı. Konuyu nasıl ele almak gerektiği ve müzakere üzerine uzunca sohbet ettik. Bu yazı, o sohbette anlattıklarımdan oluşuyor.

Bu yazıyı “Müzakerenin Temel İlkeleri” diye adlandırıp, 6-8 tane ilkeyi alt alta sıralayabilirdim. En başta birkaç ilkeyi vurguladım ama, aşağıdaki şekilde anlattığımda, daha fazla akılda kaldığını gördüm. Bu nedenle, müzakere eğitimlerinden aklımda kalanları ve iş hayatımda kullandığımda başarı getirenleri destekleyen anılarla yazmayı tercih ettim.

Özellikle belirtmek isterim ki, müzakere teknikleri konusunda eğitim verecek düzeyde olmadığımı biliyorum. Bu nedenle yazıyı, bir pazarlama aracı değil bir öğretiler tortusu olarak okumanızı isterim.

Temel İlkeler

İlk müzakere eğitimini 1980’de ODTÜ’de, efsane hocamız Muhan Soysal’dan aldım. Muhan hocamız, her sene ABD’nin önde gelen okullarında okutulan dersleri inceler ve önemli gördüklerini bize aktarmak için çalışırdı. Derslerde okutulan kitapları da getirtirdi. (40 sene önce öğrendiğini sürekli anlatan hocalardan değildi.) Sanırım globalleşmenin etkisiyle şirket evlilikleri (M&A) yoğunlaşmıştı ve ABD’nin zirve okullarında müzakere psikolojisi dersi veriliyordu.

Muhan Hocamızın tüm yaz boyunca çalışıp, ders döneminde bize aktardığı Müzakere Psikolojisi dersinden aklımda kalanlar:

.. A – Müzakere ve pazarlık, aslında birçok konuda benzer ama müzakere uzun vadeli ilişkiler için geçerlidir. Bir seferlik fiyat veya miktar pazarlığı müzakere değildir.

“Müzakere = öldüresiye pazarlık” değildir.  İlgili taraflar için kazanç – kazanç yaratan çözümleri bulmak, dolayısıyla yeniden masaya oturmayı gerektiren anlaşmazlık ve yeniden sürekli müzakere ortamı oluşturmamak gerekir. Taraflardan biri işi gurur meselesine çevirirse, müzakere değil pazarlık yapıyor demektir. Unutmayalım, bir atasözü der ki “İki testiyi birbirine çarparsan, biri kırılırsa, diğeri de çatlar”.

.. B – Tarafların beklentileri karşılaştırıldığında, ancak bir müzakere tabanı varsa karşılıklı etkileşim olabilir. Şöyle örnekleyebiliriz:

    • Satıcı 100 TL’ye satmak istiyor. Daha yukarısını, kendisi bile hayal etmiyor. En az 60 TL’ye de razı. Daha azına kesinlikle satmayacak.

    • Alıcı ise 50 TL ödemeyi umuyor. Daha azı olsa çok iyi olur ama, kimsenin daha ucuza vereceğini düşünmüyor. Zorlanırsa, cebinden 80 TL’ye kadar çıkabilir. Daha üstünü ödemeye hiç niyeti yok.

.

Bu örnekte müzakere tabanı 60-80 TL arasında oluşmuştur. Bir şekle dönüştürürsek:

Yukarıdaki örnekte, satıcı “81 TL’den azına asla satmam” veya alıcı “59 TL’den bir kuruş fazla ödemem” deseydi, müzakere tabanı oluşmayacaktı.

Önemli not: Müzakere tabanı kavramının kolay anlaşılması için sadece fiyat örneği verdim. Bir müzakerede iş birliği koşulları, sermayenin ve kârın veya riskin paylaşılması, teslimat ve nakliyat koşulları gibi çok sayıda başlık söz konusu olabilir.

.. C – Müzakerelerde çoğunlukla en az iki pazarlık söz konusudur:

    1. Diğer taraf ile pazarlık;
    2. Kendisiyle pazarlık.

Müzakerenin her aşamasında “acaba kabul etsem mi” diye düşünmeyi, kendisiyle pazarlık etmek diye tanımlıyorlar. Aslında en yıpratıcı olan da bu “kendisiyle pazarlık” etmesidir.

Satıcı “Acaba Alıcı X TL’den çok verebilir mi? Yoksa çok ucuza mı gidiyor? Biraz daha direnseydim daha yukarıya satabilir miyim?” diye düşünürken alıcı da kendisiyle aynı savaşı vermektedir. “Kendime koyduğum sınırlar çok mu düşük? Ben yanlış mı değerlendiriyorum? Geri satmak için değil de yaşamak için alıyorum. Satıcının daha önce yaptığı yatırım işime yarar mı?”

Müzakerelerde, yukarıda örnekteki gibi tek boyut fiyat olmadığı için, kendimizle pazarlığımız da karmaşıklaşır. “Sermaye konusunda verdiğimiz tavizi, kâr paylaşımı konusunda geri alabilir miyiz?” veya “Eleman tahsis etmeye evet dedik ama bütçeyi artırabilir miyiz?” gibi, müzakerede masadaki başlıkların sayısı arttıkça iç pazarlığımız çoğalır. Bazen yönetemeyeceğimiz düzeye gelir.

Müzakerelerde çoğunlukla de en kârlı çıkan taraf, kendisiyle pazarlık etmeyendir. İnsanın kendisiyle pazarlık ettiğini düşündüğümde Nazım Hikmet’in şu dizelerini anımsarım:

Tavşan,
korktuğu için kaçmaz,
kaçtığı için korkar.

Dolayısıyla, ayrıntılı bir ön hazırlık yaparak, konular arasındaki etkileşimi ve kendi sınırlarını doğru belirlemek çok önemlidir.

😉

Bu eğitimi aldığımız sırada üniversitede öğrenciydim. Ön hazırlığın iyi yapılması, diğer tarafın azami ve asgari beklentilerinin belirlenmesi, kendi tarafımın sınırlarının saptanması gibi bazı ilkeler aklımda kaldı ama en önemli konuyu atladığımı iş hayatının ileri yıllarında anladım. “Nedir o konu?” derseniz… yazı dizisinin  son bölümlerinde değindim.

Bu yazı BrandMap’in Kasım-Aralık 2025 sayısında yayınlanmıştır.

09 Ocak 2025 Perşembe

CRM’de Senaryo Geliştirme

Bir şirkette Sosyal CRM workshop’ı yapıyorduk. Eğer yeterli zamanım varsa, önce kısaca CRM’i anlatıp, veriye dayalı düşünme konusundan bahseder sonra Sosyal CRM’e geçiş yaparım. Burada da CRM’den giriş yaptık.

Veriye Dayalı Düşünme

Sosyal CRM eğitimlerine, önce veriye dayalı düşünme ile başlarım. Bunu da açıkça söylemem. Burada da, veri kısmını anlatırken tahtaya


yazdım.

Sonra “Hedef kitlenizdekilerin hangi bilgilerini öğrenmek istersiniz?” diye sordum. Sektörden bağımsız olarak, perakende kurumlarda hemen her zaman aynı yanıtlar gelir. Onlar da aşağıdaki listeyi tekrarladılar.

  • Adı – Soyadı
  • Doğum tarihi (veya Yaşı)
  • Cinsiyeti
  • Medeni Durumu
  • Eğitimi (aslında Bitirdiği Okul olması gerekir)
  • Mesleği
  • Adresi

Söylenenleri tahtada Veri’nin altına gelen bölüme yazdım.

Sonra CRM projesinin amaçlarını sordum.

  • Hangi ürün grupları kime daha iyi satar?
  • En sık gelen müşterilerim kimler ve ne alıyorlar?
  • Sunulan teklife cevap verme ihtimali yüksek olan müşteriler kimlerdir?
  • Hangi müşterilerimi kaybetme ihtimalim var?
  • Hangi müşterilerime hangi sıklıkta ve nasıl yaklaşmalıyım?

gibi cümleler söylendi. Bu sefer söylenilenleri İhtiyaç’ın altına yazdım.

Tahtada şöyle bir görüntü oldu.

Kendilerinin söyledikleri ihtiyaçları karşılamak için hangi verilerin gerekli olduğunu sorgulayınca… kırmızıyla yazılı olanların pek azına dokunduğunu gördüler. Kısa sürede bambaşka noktalara geldik. Amacım veriye dayalı düşünmeyi anlatmaktı. Veriden değil ihtiyaçlardan yola çıkılması gerektiğini böylece anlatabildim. (Daha ayrıntılı isterseniz şurada)

Daha sonra “Hiç bu gözle bakmamıştık. Devasa sosyal veri dağında ne yapacağımızı düşünüp duruyorduk. Şimdi hedefimizi daha kolay saptayabiliriz” dediler.

Veri var ama…

Bunu blog yazısı olarak yayınladığımda, sayın Ibrahim Gokcen yorum yazmış ve senaryo ile başlamak gerektiğini söylemişti. İhtiyaçlar, senaryolardan sonra ortaya çıkıyor. İbrahim bey yüzde yüz haklıydı ama bir workshop’ta bunu anlatmakta zorlandığım için oraya hiç gir(e)memiştim. Nasıl oldu da yeniden gündeme geldi, anlatayım.

Segmentasyon’un dönüşümünü tartıştığım blog yazısına yorum yazan sevgili Burcu Tüzün Altınkeser yazıda konaklama sektörü üzerinden örnek verdiğim için, aynı sektördeki sorunların küçük bir kısmını dile getirmiş. (“… bir kısmını…” diye yazdım. Konaklama sektörü, hak ettiği veri yönetiminin çok gerisinde çalışıyor.)

Biz CRM’in ana öğesi segmentasyonu ne kadar derinleştirirsek derinleştirelim, veri taşıma sorunu çözülmeden ilerleyemiyoruz. Yani sert yastık isteyen müşteri, bir iş adamı da olabiliyor, boyun fıtığından mustarip bir yazılımcı da, geçmişindeki bir kazada boyun omur hasarı almış bir ev hanımı da olabiliyor.

Bu kadar ayrıntılı datayı ilk alan ise aslında müşteri ile ilk temasta olan resepsiyon, oda servisi, kat görevlisi vs. Yani asıl sorunu verinin taşınmasında yaşıyoruz. Çünkü o veri sisteme kadar iletilmiyor, havada kalıyor. Bu nedenle İngiliz sigorta şirketlerine ödeme iadesi yapan çok otel var.

Odaya tamir amaçlı teknik ekip gidip gitmediği bilgisi sisteme iletilmediğinden, otel kendisini savunamıyor ve para iadesine kadar gidiyor iş. Pek çok yabancı turist bunu bilip, buna göre tatilini yapıyor ve dönünce şirketinden parasını iade istiyor.

Bu veriyi taşımayı başaran da, bireye ait bir hizmet sunmak istemiyor.

Burcu’nun yorumunu yanıtlarken, bu blog yazısını oluşturmak aklıma geldi.

İhtiyaç’tan önce Senaryo

2022 senesinde, 6-7 tesisi olan bir tatil köyü zincirinin CRM projesinde danışmanlık yaptım.

Orada veri ve süreç ihtiyaçlarını bulmanın en iyi yolunun senaryolar üretmek olduğunu anlatma fırsatım oldu.
Yukarıdaki örneği senaryolaştırırsak:

  • Müşteri bir önceki gelişinde sert yastık istediğini söylemiştir. Bu talep oda hizmetlerine iletilirken müşteri bilgi dosyasına (MBD) da girilir. → Demek ki

1 – Müşterinin sert yastık talebini yapabileceği noktalardaki ekranlarda, benzer müşteri taleplerinin sisteme girileceği bir saha oluşturulacak;

2 – MBD’de yastık tercihi sahası olacak

  • Müşterinin bir sonraki rezervasyonunda sistem otomatik olarak “yine sert yastık” talep edilip edilmediğini sorar. → Demek ki

a – Müşteri tekilleştirmesi yapılmış olacak. Daha önce konaklamış müşteriyi tanıyacak.

a1 – Bazı konaklama yazılımlarında yapay zeka kullanılarak “yüzde # olasılıkla şu müşteri” diye eşleştirme yapılıyormuş.

b – MBD’ler rezervasyon sistemine bağlı bir şekilde çalışacak. Daha önce konaklamış bir müşterinin farklı bilgileri rezervasyon noktası (muhtemelen çağrı merkezi) ekranına gelecek

c – Rezervasyon kaydını alan kişi, “bir rezervasyon daha yaptım” ile yetinmeyecek. Sistemde “eski müşteri benzerliği” söz konusu ise, bir-iki soru ile daha önce gelen (mevcut) müşteri olup olmadığını öğrenecek ve sisteme ona göre girecek.

b1 – Müşteri temas noktalarında çalışanlara eğitim verilmesi gerekir

b2 – Müşteri temas noktalarında çalışanların performans kriterlerine (KPI) bilgi doğruluğu oranı eklenir.

  • Müşteri tesise geldiğinde, talepleri ve (varsa özel durumu) doğrulanacak. → Demek ki

d – Ön-büro ve misafir ilişkileri ekranlarında farklı talepler (sadece yastık değil, alerji, dini gereklerle odada istenmeyenler, vb. bilgileri) tekrar yer alacak,

e – Bu müşterinin ekranı açıldığında, “şu bilgileri doğrula” diye uyarı ekrana gelecek,

f – Rezervasyon sonrasında müşterinin odası önceden belirlenmemiş ve gerekli düzenleme yapılmamışsa, oda hizmetlerine “ACİL – sert yastık” bildirimi gidecek

…

  • Varsayalım ki müşterinin talebini tatmin olacağı şekilde karşılayamadınız ve şikayet geldi. Sonrasında ne yapacaksınız (2014 senesi, CRM dersi final sorularından biri bu konudaydı. Çözümleri oradan okuyabilirsiniz.)

Daha senaryoya yeni başladık… Böylece gidiyor.

😉

Sevgili Burcu, teknik servis konusunda da bir örnek vermiş. Müşterinin klima arızası şikayetiyle kimse ilgilenmediğinde ne olduğunu (yatağını otelin lokantasına taşıyıp “Burası serin. Burada uyunur” dediğini ve eşinin videoya aldığını) tüm Türkiye öğrenmişti. (Videoyu seyretmek için resme tıklayın)

Burada sadece iş akışı hatası değil, iletişim noksanlığı da var. Bu da senaryo geliştirirken dikkate almamız gereken unsurlardan biri olarak düşünülmeli.

Teknik servis için de senaryo geliştireceksek, müşterinin şikayetiyle (sıfır noktası) başlayan ve olası (istisnai durumlar dışındaki) sonuçları dikkate alan tasarımı yaparız.

😉

Bizzat yaşadığım ve konaklama sektörü için senaryolaştırdığım bir vakayı da şuradan okuyabilirsiniz.

Makul İdeal

Senaryo oluştururken, “tüm alt-yapıyı şimdi kursak ve ideal durumu hedeflesek neler yapardık” diye düşünmek gerekir. Makul ideal denilmesinin nedeni, ışınlama gibi uçuk idealler değil, piyasada olanlar arasından, makul bütçe ile satın alınabilecek veya hayata geçirilebilecek hedeflerin seçilmesidir. Elbette rakipler ve dünyadaki en iyi uygulamalar araştırılarak yapılır.

Ben ısrarla, “İdeal durumu hedefleyin ve oraya doğrudan ulaşmaya çalışın” diyorum. (Gerekçeleri yukarıdaki referans yazılarda)

Biliyorum hiç kolay değil.

Bunları yaparak makul ideal’i tasarlayabilirsiniz.

Ez Cümle…

Tüm çalışanların bilgileri kolayca aktarabileceği iş akış tasarımlarını yapmak ve hayata geçirmek aslında çok maliyetli değil. Müşteri odaklı süreçler, hem maliyetleri azaltır hem de müşteri memnuniyetini artırır. Muhtemelen, konaklama tesislerinin bir çoğunun İngiliz turistlere ödedikleri tazminatlar ile kısa sürede yatırımı geri ödeyecektir.

🙂