Danışmanlık Proje Örnekleri
Müşterilerimizin ne söylediğini zaten yayınlıyoruz. Bu sayfa farklı bir soruyu yanıtlıyor: o projelerde tam olarak ne yaptık, işin zor tarafı neresiydi?
Sayfada Ne Var?
Farklı sektörlerden ayrıntılı proje anlatımları
Her Vakada Ne Yazıyor?
Başlangıç durumu, kapsam, karşılaşılan zorluk, süre ve sonuç
Neden İsim Yok?
Vakalar firmaların iç işleyişini anlatıyor, bu yüzden isimsiz yayımlanıyor
Kimden Hizmet Alıyorsunuz?
Zoho üzerine bir danışmandan değil, Türkiye'de Zoho üzerine en tecrübeli olan uzman bir ekipten hizmet alıyorsunuz.
Ekibimiz Hakkında
Cloudyflex bünyesinde Zoho üzerine 10 yıl üzerinde uzmanlığa sahip bir proje ekibimiz bulunmaktadır.
CRM Tecrübemiz
Ekibimizin CRM tecrübesi tek bir sektörden gelmiyor. Üretimden sağlığa, lojistikten yazılıma kadar birbirine benzemeyen satış süreçleri kurduk
Proje Ekip Liderleri
Haluk Çavuşoğlu - CEO
Zoho Deneyimi : 10+ Yıl
Proje Deneyimi : 25+ Yıl
Cenk Arslan - Kıdemli Danışman
Zoho Deneyimi : 10+ Yıl
Proje Deneyimi : 25+ Yıl
Murat Olgun - Kıdemli Danışman
Zoho Deneyimi : 10+ Yıl
Proje Deneyimi : 25+ Yıl
Proje Ekibimiz
Ekibimiz proje yöneticisi, çözüm danışmanı ve geliştiricilerden oluşuyor. Böylece bir CRM projesinin planlaması, kurgusu ve teknik tarafı aynı çatı altında yürüyor.
Sayfayı okumaya vaktiniz yoksa: hızlı özet
Altı soru, altı cevap.
Müşteri yorumu ile proje örneği arasındaki fark
Sitemizde iki ayrı içerik ailesi var ve karıştırılmaları kolay. Aradaki fark, kimin konuştuğudur.
Firma yetkilisi adıyla, soyadıyla ve firma adıyla konuşuyor
Projeyi yürüten ekip işin içinden anlatıyor, firma adı geçmiyor
Aşağıdaki sekiz vaka bu biçimde yazıldı: altı başlık, hep aynı sıra, isim yok.
İsim meselesini biraz açalım, çünkü sorulması olağan. Bir firmanın kendi ağzıyla “memnunuz” demesi ile bizim o firmanın satış sürecinin neresinin tıkalı olduğunu anlatmamız aynı şey değil. Birincisi firmanın kendi beyanıdır ve isimle yayımlanır. İkincisi firmanın iç işleyişidir ve isimsiz anlatılır. Bu yüzden aynı proje iki sayfada iki farklı biçimde karşınıza çıkabilir. İsimli anlatım arıyorsanız müşteri yorumları sayfamızda firmalar kendi ağzıyla konuşuyor.
Vakaları nasıl okumalı
Her vaka aynı sırayla altı başlıktan oluşuyor. Sıra bilinçli: önce firmanın nerede durduğu, sonra ne yaptığımız, en sonda ne değiştiği.
Künye
Sektör, iş modeli, kullanılan ürünler ve çalışma modeli. Vakanın size uyup uymadığını buradan anlarsınız.
Firma neye benziyordu
Proje başlamadan önceki durum. Hangi araçlar kullanılıyordu, veri neredeydi, ne çalışmıyordu.
Bizi neden aradılar
Tetikleyici ihtiyaç. Firmalar sistemi “iyi olur” diye değiştirmez; büyüme bir yerde mevcut yapıyı aştığında değiştirir. O eşiği yazıyoruz.
Ne yaptık
Vakanın en uzun bölümü. Kapsam, sırasıyla ve somut olarak.
İşin zor tarafı neydi
Her projede bir tane asıl zorluk olur, gerisi ayrıntıdır. Bu bölümde o zorluğu ve nasıl çözdüğümüzü yazıyoruz. Kolay geçmiş gibi anlatmıyoruz, çünkü kolay geçmiyor.
Sonuç ve bu vakadan çıkan not
Sistemin bugünkü hâli ve okuyucuya dönük bir cümle.
Bu sayfada hiçbir vakanın süresini yazmıyoruz. Bunun sebebi bilgiyi saklamak değil, paylaşılan bir sürenin okuyan firma tarafından taahhüt gibi okunması. Her projenin süresi kapsama, veri hacmine, karar hızına ve ekip müsaitliğine göre değişir ve bu kalemlerin bir kısmı bizim tarafımızda değildir. Süreyi neyin belirlediğini nasıl çalışıyoruz ve nasıl fiyatlıyoruz sayfasında anlatıyoruz.
Vakalar
Çok lokasyonlu otomotiv servis zinciri
Firma neye benziyordu
Firma daha önce hiç CRM kullanmamıştı. Müşteri bilgisi servis tarafındaki iş emirlerinde tutuluyor, satış tarafı ise kişisel dosyalarda yürüyordu. Dijital reklama düzenli bütçe ayrılıyordu ancak gelen talebin hangi kampanyadan geldiği, aranıp aranmadığı ve sonuçlanıp sonuçlanmadığı hiçbir yerde birleşmiyordu. Aynı müşteriyle kurulan temasların tamamını görebilmek için en az iki kişiye sormak gerekiyordu.
Bizi neden aradılar
Firmanın ihtiyacı tek bir modülün kurulması değildi. Dijital pazarlama süreçleriyle bütünleşik çalışacak güçlü bir CRM altyapısına ve bu altyapının üzerinde duracak net bir akışa ihtiyaç vardı. Bunun yanında satış sonrası servis tarafının da aynı yapıyla senkron çalışması gerekiyordu; çünkü bu sektörde müşteriyi elde tutan şey ilk satış değil, sonrasında yaşadığı deneyim. Yani ortada bir yazılım ihtiyacından çok bir müşteri deneyimi yapılanması ihtiyacı vardı. Bu amaçla bize geldiler.
Ne yaptık
Önce satış ve servis akışını uçtan uca çıkardık. Ardından CRM’deki modülleri bu akışa, yani şube ve operasyon işleyişine göre düzenledik. Kurgu firmanın çalışma biçimine uyduruldu, firma hazır bir kalıba sokulmadı.
Dijital pazarlama tarafını sisteme bağladık. Reklamlardan ve web formlarından gelen talepler kaynak ve kampanya bilgisiyle birlikte CRM’e düşüyor. Web sitesindeki canlı sohbetten çıkan talep de kaybolmadan kayda dönüşüyor. E-posta pazarlaması CRM’deki segmentler üzerinden çalışacak şekilde kurgulandı, böylece kampanya listesi elle hazırlanmıyor ve gönderim sonucu müşteri kaydında görünüyor. Sosyal medya tarafı da aynı yapıya bağlandı; şubelerin ayrı ayrı yürüttüğü paylaşım ve mesaj trafiği tek yerden yönetilir hâle geldi.
Satış sonrası servis tarafını CRM ile bütünleşik bir yardım masası yapısına aldık. Servis talebi müşteri kaydına bağlı bir talep olarak açılıyor; müşterinin satış geçmişi ile servis geçmişi aynı kayıt üzerinden görülüyor.
Sanal çağrı merkezi entegrasyonunu kurduk. Firma çağrı merkezini ilk kez CRM içinden kullanacaktı, bu yüzden temsilcinin çağrı sırasında gördüğü ekranı ve çağrı sonrası akışı ayrı bir başlık olarak tasarladık. Gelen çağrıda müşteri kaydı otomatik açılıyor, görüşme kayıt altına alınıyor ve çağrı bir sonuca bağlanmadan kapanmıyor.
Deneyim döngüsünü kapattık. Servis tamamlandıktan sonra müşteriye memnuniyet anketi gidiyor ve sonucu müşteri kaydına işleniyor. Böylece şube performansı yalnızca iş hacmiyle değil, müşterinin ne söylediğiyle birlikte izlenebiliyor.
İşin zor tarafı neydi
Yıllardır biriken verinin yeni sisteme nasıl aktarılacağıydı. Firma ilk kez CRM kullanacaktı ve elindeki veri farklı yerlerde, farklı biçimlerde ve farklı kalitede duruyordu. Bu veriyi olduğu gibi taşımak, ilk günden itibaren güvenilmeyen bir sistem üretirdi. Verinin nasıl temizleneceği konusunda danışmanlık verdik; hangi kaydın taşınacağı, hangisinin arşivde kalacağı ve hangi alanın hangi bilgiyi taşıyacağı firmayla birlikte karara bağlandı. Temizliğin kendisi firmanın sorumluluğundaydı, biz bu kararın gerektirdiği kuralları ve kontrol listelerini sağladık.
Çağrı merkezi tarafıydı. Temsilciler çağrıyı ilk kez CRM ekranı üzerinden karşılayacaktı ve bu ekran çağrı sırasında bakılacak tek yer olmak zorundaydı. Fazla bilgi koymak temsilciyi yavaşlatıyor, eksik bilgi koymak başka ekrana geçmesine sebep oluyordu. Ekranı ve çağrı sonrası akışı gerçek çağrılarla test ederek sadeleştirdik.
Reklam bütçesinin hangi kanaldan ne getirdiği görünüyor, gelen talep sahipsiz kalmıyor, satış, çağrı merkezi ve servis aynı müşteri kaydı üzerinden konuşuyor.
Bu vakadan çıkan not: ilk kez CRM kuran bir firmada projenin kaderini belirleyen şey modül seçimi değil, sisteme hangi verinin girdiğidir. Kirli veriyle açılan bir sistem, ekibin güvenini ilk haftada kaybeder.
Yurt dışından hasta kabul eden sağlık kuruluşu
Firma neye benziyordu
Kurumun halihazırda kullandığı bir CRM sistemi vardı ve hasta adayları orada tutuluyordu. Sorun sistemin varlığında değil, sistemin kurumun gerçek işleyişini taşımamasındaydı. Bu iş modelinde bir hasta adayı reklamdan gelir, konuşulur, teklif verilir, tedaviye dönüşür ve tedavi bittikten sonra takibi devam eder. Eski yapıda bu zincirin yalnızca ilk halkası vardı; teklif, operasyon ve sonrası sistemin dışında, tablolarda ve mesajlaşmalarda yürüyordu. Reklam yatırımı yüksekti ancak gelen adayın hangi kampanyadan geldiği çoğu kayıtta yazılı değildi, gelen adayın kime atanacağı da kişiye bağlı ilerliyordu.
Bizi neden aradılar
Kurum büyüyordu ve büyüme mevcut yapıyı taşımıyordu. Danışman sayısı artıyor, reklam bütçesi büyüyordu. Tetikleyici şu oldu: gelen adayların bir bölümünün hiç dönülmeden kaldığı ve bunun ancak aday tekrar yazdığında fark edildiği görüldü. İhtiyaç yeni bir CRM almak değil, aday girişinden tedavi sonrası takibe kadar tüm zinciri tek sistemde yürütmekti. Zoho One bu yüzden tercih edildi.
Ne yaptık
Önce hedef yapıyı kurduk, taşımaya sonra başladık. Kurumun süreci uçtan uca çıkarıldı ve CRM bu sürece göre kurgulandı: müşteri adayı, kişiler ve firmalar, satış fırsatı, teklif, operasyon ve satış sonrası takip. Her modülde kullanılmayan alanlar çıkarıldı, kuruma özgü alanlar eklendi. Sonradan ayrıca bir tedavi modülü kuruldu ve fiyat listeleri tanımlandı.
Kritik üç noktada aşama bazlı süreç yönetimi kurduk. Aday kalifikasyonu, satış fırsatı ve operasyon artık serbest ilerlemiyor; bir kayıt bir sonraki aşamaya, o aşamanın gerektirdiği bilgi girilmeden geçemiyor.
Aday girişini otomatikleştirdik. Web sitesindeki form, reklam platformundan gelen aday formları ve sosyal medya tarafı CRM’e bağlandı. Gelen aday kaynak bilgisiyle birlikte düşüyor ve otomatik atama kuralıyla sıradaki danışmana veriliyor. Sahipsiz kalan aday sorunu buradan çözüldü.
Eski CRM’deki veriyi taşıdık. Önce alan haritası çıkarıldı: kaynak sistemdeki her alanın yeni yapıda nereye karşılık geldiği, karşılığı olmayanların ne yapılacağı ve serbest metin içinde duran bilgilerin hangi alana taşınacağı yazılı olarak kararlaştırıldı. Hangi kaydın taşınacağına ve hangisinin dışarıda kalacağına kurum karar verdi; verinin temizliği kurumun kendi sorumluluğundadır, biz bu kararı verebilmesi için gereken listeleri ve kontrolleri sağladık. Aktarım kontrollü şekilde yapıldı ve sonuç kurumla birlikte gözden geçirildi.
Canlıya geçiş sonrası verinin yeniden bozulmaması için kontrol mekanizmaları kurduk. Mükerrer kayıt yakalama kuralları tanımlandı; aynı hasta adayı ikinci kez temas ettiğinde sistem bunu yeni bir kayıt olarak açmadan önce uyarıyor. Alan bazlı doğrulama kuralları eklendi, böylece eksik veya biçimsiz veri girişi kaynağında engelleniyor. Teklif tarafı sisteme alındı, teklif şablonu ve onay yapısı kuruldu, yönetim için panolar hazırlandı ve ekip rol bazlı eğitimlerle yeni yapıya geçirildi.
İşin zor tarafı neydi
Taşıma ile yeniden kurgunun aynı anda yürümesiydi. Kurum eski sistemden çıkıyordu, ancak yeni sistem eskisinin kopyası değildi; operasyon ve satış sonrası gibi eskiden hiç olmayan aşamalar ekleniyordu. Hedef yapı değişmeye devam ederken veri taşınamaz, çünkü her değişiklikte eşleştirme bozulur. Bu yüzden sırayı tersine çevirdik: önce hedef yapıyı kurup dondurduk, taşımayı ondan sonra yaptık. Bu karar projenin ilk döneminde kurumun beklediğinden daha az görünür ilerleme anlamına geldi ve bunu baştan konuştuk.
Eski sistemdeki kaynak bilgisiydi. Adayın hangi kampanyadan, hangi platformdan ya da doğrudan temasla geldiği kayıtların bir kısmında hiç yoktu, bir kısmında da danışmanın kendi yazım alışkanlığıyla notta duruyordu. Geçmiş veriyi geriye dönük tamamlamak mümkün değildi. Bunu kabul ettik ve enerjiyi ileriye harcadık: yeni yapıda kaynak bilgisi elle yazılan bir alan olmaktan çıkarıldı, adayın geldiği kanal tarafından otomatik olarak yazılıyor.
Aday girişinden tedavi sonrası takibe kadar zincirin tamamı tek sistemde yürüyor, gelen aday otomatik olarak bir danışmana atanıyor ve reklam yatırımının karşılığı kaynak kırılımında görülebiliyor.
Bu vakadan çıkan not: taşımanın zor kısmı veriyi taşımak değil, verinin yeni yapıda ne anlama geleceğine karar vermektir. Hedef yapı netleşmeden başlayan taşıma iki kez yapılır.
ERP kullanan üretim firması, CRM ve ERP entegrasyonu
Firma neye benziyordu
Firmanın oturmuş bir ERP kullanımı vardı; stok, cari ve sipariş orada yönetiliyordu. CRM tarafında ise satış fırsatları takip ediliyordu. İki sistem birbirinden habersizdi. Satış temsilcisi teklif hazırlarken stok ve fiyat bilgisi için ERP’ye giriyor, bilgiyi kopyalıyor, teklifi CRM’de hazırlıyordu. Kazanılan fırsat ise elle siparişe çevriliyordu. Aynı ürünün iki sistemde iki farklı kodu, zaman zaman da iki farklı fiyatı bulunuyordu.
Bizi neden aradılar
İki olay üst üste geldi. Önce stokta bulunmayan bir ürün için teklif verildi ve taahhüt edilen teslim tarihi tutmadı. Ardından ödeme geçmişi sorunlu bir cariye satış yapıldı, çünkü risk bilgisi teklif aşamasında satışçının önünde değildi. İkisinin de ortak sebebi aynıydı: karar anında gerekli bilgi başka bir sistemdeydi. Firma bir entegrasyon istemekten çok, satışçının ekran değiştirmeden karar verebilmesini istiyordu.
Ne yaptık
Entegrasyona başlamadan önce ürün kartı ve fiyat listesini tek referansa bağladık. Bu teknik bir iş değil bir veri yönetişimi kararıydı, ancak bu karar verilmeden kurulacak her entegrasyon iki sistemi birbirine yanlış bağlardı.
ERP’den CRM’e akan veriyi tanımladık. Ürün, fiyat, stok durumu ve cari risk bilgisi CRM’e aktarılır hâle geldi. Bu bilgiler CRM’de değiştirilemiyor, yalnızca görünüyor; böylece iki sistemde iki farklı doğru oluşmuyor.
CRM’den ERP’ye akan veriyi tanımladık. Kazanılan fırsat ERP tarafında sipariş olarak açılıyor, elle giriş ortadan kalktı.
Hata yönetimi kurduk. Aktarımda bir sorun olursa kayıt kaybolmuyor; kuyrukta bekliyor, sorumluya bildiriliyor ve düzeltildikten sonra tekrar deneniyor. Entegrasyonun sessizce kopma ihtimali kapatıldı.
İzleme ekranı hazırlandı. Son çalışma zamanı, bekleyen kayıt sayısı ve hata veren kayıtlar tek yerden görülüyor. Bir aksaklık müşteri şikâyetiyle değil, bu ekranla fark ediliyor.
İşin zor tarafı neydi
Hangi sistemin hangi verinin sahibi olduğuna karar vermekti. Ürün ve fiyatın sahibi ERP, müşteri adayının sahibi CRM, cari kaydın sahibi yine ERP olmalıydı. Bu karar verilmeden çift yönlü bir akış kurulursa iki sistem birbirinin verisini ezer ve hangi bilginin doğru olduğu tartışma konusu hâline gelir. Sahiplik tablosunu yazılı olarak çıkardık ve entegrasyonu bu tabloya göre kurduk. Bu tablo üzerinde anlaşmak, entegrasyonun kendisini kurmaktan uzun sürdü.
ERP tarafındaki alan yapısının değişebilir olmasıydı. Bir güncelleme sırasında alan adı değişti ve aktarım durdu. Bunun üzerine alan eşleştirmesini koda gömülü olmaktan çıkarıp ayrı bir tabloya taşıdık; benzer bir değişiklikte artık tablo güncelleniyor, geliştirme yapılmıyor.
Teklif, stok ve fiyat bilgisi görünürken hazırlanıyor. Kazanılan fırsat elle siparişe çevrilmiyor. Cari risk teklif aşamasında fark ediliyor.
Bu vakadan çıkan not: entegrasyonun teknik kısmı genellikle en kolay kısmıdır. Projeyi uzatan şey, hangi verinin kime ait olduğu sorusunun daha önce hiç cevaplanmamış olmasıdır.
Uluslararası eğitim ve değişim programları yürüten kuruluş
Firma neye benziyordu
Kurum, kendi geliştirdiği basit bir aday takip yazılımı kullanıyordu ve artık onunla devam etmek istemiyordu. Süreç tek bir satış hattı değildi: bir başvuru alınıyor, aday değerlendiriliyor, yerleştirme yapılıyor, resmi belge süreci yürütülüyor ve katılımcı program boyunca takip ediliyordu. Bu zincirin içinde kurumun kendi ekibi kadar okullar, acenteler ve katılımcıların kendisi de vardı. Başvuru formları, aday takibi, iş akışı ve raporlama farklı yerlerde duruyordu.
Bizi neden aradılar
Kurum yeni bir program açıyordu ve mevcut yazılım bunu taşımıyordu. İhtiyaç listesi baştan belliydi: web ile bütünleşik başvuru formları, katılımcı takibi, aday seçme ve yerleştirme, iş akışı yönetimi ve raporlama. Aranan şey hazır bir CRM değildi, çünkü bu süreç hazır bir CRM’in kapsamına girmiyordu. Kurumun kararı da buna göreydi: önce bir programı doğru kurmak, sonra aynı yapıyı diğer programlara yaymak.
Ne yaptık
Süreci sistemden bağımsız olarak çıkardık ve standart yapının nereye kadar yettiğini belirledik. İlişki yönetimi, kurumsal temaslar ve satış tarafı Zoho CRM üzerinde kaldı. Gereksiz geliştirme yapmamanın tek yolu bu ayrımı baştan netleştirmekti.
Programın kendisi için kuruma özel bir yapı geliştirdik. Başvurunun alınmasından katılımcının program boyunca takibine, okul ve acente ilişkisinden belge süreçlerine kadar akışın tamamı Zoho’nun uygulama geliştirme tarafında kurgulandı ve CRM ile bağlandı.
Dış paydaşlar için ayrı portal yapıları kurduk. Okul, acente ve katılımcı kendi ekranından giriyor ve yalnızca kendisini ilgilendiren veriyi görüyor. Bu yapı, kurumun iç kullanıcılarından ayrı bir yetki ve erişim katmanı olarak tasarlandı.
Resmi başvuru sürecinin yürüdüğü dış sistemle entegrasyon kurduk. Daha önce elle yürüyen dosya alışverişi bu entegrasyonla sistemin içine alındı.
İlk program canlıya alındıktan sonra aynı yapı diğer programlara genişletildi. Kurum her yeni programda sıfırdan yazılım yaptırmadı, mevcut yapının üzerine ekledi.
İşin zor tarafı neydi
İlk tasarımın tek program üzerine kurulmuş olmasıydı. Sistem kurulduğunda ortada bir program vardı; kısa süre sonra kurum aynı yapı üzerinden birden fazla programı yürütmek istedi. Bu, görünürde küçük bir istekti ama tasarımın temeline dokunuyordu: aynı okul iki farklı programda iki ayrı kullanıcı ve iki ayrı şifreyle giriyordu, çünkü yapı bir okulun birden fazla programda bulunabileceği varsayımıyla kurulmamıştı. Tasarımı çok programlı olacak şekilde yeniden ele aldık. Bunu mevcut yapının içinde yapamadık, çünkü ilk program yıllara yayılan ve kesintisiz veri üreten bir programdı; yeni yapıyı dışarıda kurup sonra içeri taşımak zorunda kaldık. Yani aynı işi iki kez yaptık. Bunu burada yazıyoruz, çünkü bu maliyetin sebebi tek bir sorunun ilk gün sorulmamış olmasıydı.
Resmi sistemle entegrasyondu. Karşı taraf güncel bir arayüz sunmuyordu; toplu dosya alışverişine dayanan, sabah gönderilen dosyanın saatler sonra cevaplandığı eski bir yapı kullanıyordu ve eski bir güvenlik sertifikası tipi bekliyordu. Zoho tarafı güncel güvenlik standartlarını kullandığı için doğrudan bağlantı kurulamadı. Uzun süre denedikten sonra doğrudan bağlantı fikrinden vazgeçtik ve akışı kurumun kendi sunucuları üzerinden geçen bir köprüyle kurduk. Harcanan sürenin bir kısmı sonuç vermedi ve bunu kabul ettik.
Program operasyonunun tamamı tek yapı üzerinde yürüyor, okul, acente ve katılımcı kendi ekranından sisteme giriyor, resmi belge süreci elle yürütülmüyor. Kurum yeni bir program açtığında sıfırdan yazılım yaptırmıyor.
Bu vakadan çıkan not: özel geliştirmede asıl risk istenen şeyin yapılamaması değil, ilk tasarımın ileride gelecek ikinci ve üçüncü kullanımı taşımamasıdır. Projenin ilk gününde “bu yapı kaç farklı durumu taşıyacak” sorusunu sormak, sonradan yapılacak işin yarısını ortadan kaldırır.
Uzun satış döngüsü olan bilişim firması, yeniden yapılandırma
Firma neye benziyordu
CRM yıllardır kullanılıyordu. Zaman içinde her yeni ihtiyaçta yeni bir alan, yeni bir rapor ve yeni bir otomasyon eklenmişti. Kimse eskilerini kaldırmamıştı. Satış ekibi alanların çoğunu boş geçiyor, yönetim hangi raporun güncel olduğunu bilmiyordu. Bunların hepsinden önemlisi, satışlar müşteri adayı kayıtları üzerinden yürütülüyordu; satış fırsatları modülü açıktı ama kullanılmıyordu.
Bizi neden aradılar
Tetikleyici yıl sonu tahminiydi. Yönetim yılın kalanında kaç işin kapanacağını ve bunun tutarını sordu. Sistem bu soruya cevap veremedi, çünkü aşama, kapanış tarihi ve tutar bilgisini taşıyacak yapı kullanılmıyordu. Ekip kendi kişisel tahminini söyledi ve yönetim bu tahminle karar vermek zorunda kaldı.
Ne yaptık
Denetimle başladık. Hangi alanın gerçekten doldurulduğunu, hangi raporun son dönemde açıldığını ve hangi otomasyonun hâlâ çalıştığını ölçtük. Tahmin yürütmedik, kullanım verisine baktık.
Asıl bulguyu ortaya koyduk. Satış fırsatları modülünün kullanılmaması bir alışkanlık meselesi değil, mimari bir hataydı. Müşteri adayı kaydı bir satışın aşamalarını taşımak için tasarlanmamıştır; dolayısıyla tahmin, kapanış tarihi ve huni hiçbir zaman güvenilir olamazdı. Bu tek hata hem CRM tarafındaki hem operasyondaki verimi düşürüyordu.
Süreci doğru modüller üzerine yeniden kurduk. Müşteri adayı, fırsat ve teklif ayrımı netleştirildi. Aşamalar bu sektördeki uzun ve çok temaslı satış döngüsüne göre tanımlandı.
Mevcut veriyi yeni yapıya taşıdık. Açık işler fırsat kaydına dönüştürüldü, hangi kaydın hangi aşamada açılacağına firmayla birlikte karar verildi.
Sadeleştirme ve eğitim. Kullanılmayan alanlar kaldırıldı, çakışan otomasyonlar tekleştirildi, raporlar kullanan role göre yeniden kuruldu.
İşin zor tarafı neydi
Yanlış kullanımın yıllardır sürüyor olmasıydı. Ekip mevcut düzeni biliyordu ve her değişikliği kendisine yüklenen ek iş olarak görüyordu. Yeni yapının kendi işini nasıl kolaylaştırdığını göstermeden geçiş yapmanın mümkün olmadığı ortaya çıktı. Bu yüzden önce satış ekibinin en çok şikâyet ettiği iki işi yeni yapıda çözdük, geçişi ondan sonra başlattık.
Geçmiş veriydi. Müşteri adayı kaydında biriken bilginin bir bölümü fırsat kaydına birebir karşılık gelmiyordu. Otomatik dönüştürme yerine, açık işleri firmayla birlikte tek tek gözden geçirip aşamalarına yerleştirdik.
Satış hunisi gerçek durumu gösteriyor, yönetim tahminini sistemden alıyor, satış ekibi sistemi süreci ilerlettiği yer olarak kullanıyor.
Bu vakadan çıkan not: istenen rapor alınamıyorsa sorun genellikle raporda değil, verinin nereye girildiğindedir. Rapor sorununu raporla çözmeye çalışmak zaman kaybıdır.
Kaynak açığını kaynak kiralamayla kapatan sağlık turizmi firması
Firma neye benziyordu
Firmanın kurulu ve işleyen bir Zoho yapısı vardı. Sistem günlük operasyonu taşıyordu ve iş bu yapı üzerinden yürüyordu. Zoho tarafını firma içinde kıdemli bir çalışan yönetiyordu; talepleri topluyor, düzenlemeleri yapıyor ve sistemin gündelik sahipliğini üstleniyordu.
Bizi neden aradılar
Bu kişi işten ayrıldı ve firmanın Zoho tarafında bir kaynak açığı oluştu. Aynı profilde bir çalışanı işe almak zaman alan bir süreçti, oysa sezon açıktı ve sistem üzerinde yapılması gereken işler birikmeye başlamıştı. Firma iki seçenek arasındaydı: acele bir işe alım yapmak ya da bu açığı dışarıdan bir kaynakla kapatmak. Bize bu ikinci seçeneği konuşmak için geldiler.
Ne yaptık
Sistemi devraldık. Hangi otomasyonun neyi tetiklediğini, hangi entegrasyonun nereye bağlı olduğunu ve hangi alanın hangi raporu beslediğini çıkardık. Bu çalışma, sonraki her değişikliğin yan etki üretmeden yapılabilmesi için gerekliydi.
Bekleyen işleri bir ister listesine aldık ve firmayla birlikte önceliklendirdik. Hangi işin kimde olduğu ve hangi sırayla ilerlediği açık tutuldu.
Uzmanımız firmanın kendi çalışma düzeninin içinde, belirlenen günlerde çalıştı. Talepler doğrudan ekipten geldi, arada bir iletişim katmanı oluşmadı.
Yapılan her iş kayıt altına alındı ve firmanın kendi ekibine anlatıldı. Böylece sistemin sahipliği hizmet süresince de firmada kaldı.
Rutin işler firma içinde yapılabilir hâle getirildi. Uzmanımızın zamanı, ancak dışarıdan uzmanlık gerektiren işlere ayrıldı.
İşin zor tarafı neydi
Devralma ile üretimin aynı anda yürümek zorunda olmasıydı. Sezon açıktı, bekleyen işler vardı ve bunların tamamının sistem tam olarak öğrenilene kadar beklemesi mümkün değildi. Bu yüzden iki hattı paralel yürüttük: bir yandan bekleyen ve düşük riskli işler hızla çıkarıldı, diğer yandan sistemin bütünü çıkarıldı. Yan etki riski taşıyan işler ikinci hat tamamlanana kadar bilinçli olarak sıraya alındı ve bu sıralama firmayla birlikte belirlendi.
Beklentinin doğru tanımlanmasıydı. Başlangıçta bu hizmet “ayrılan kişinin yerine geçmek” olarak konuşuluyordu. Bunun bir kaynak kiralama hizmeti olduğunu, kapsamın ister listesiyle yürüdüğünü ve önceliklendirme yetkisinin firmada kaldığını baştan netleştirdik. Bu konuşmayı erken yapmak, sonradan çıkacak kapsam tartışmalarını önledi.
Kaynak açığı işe alım beklenmeden kapandı, bekleyen işler ilerledi ve sistem sezon boyunca durmadı. Firma bu dönemde kadro genişletmek zorunda kalmadı.
Bu vakadan çıkan not: bir pozisyon boşaldığında tek seçenek hemen yerine birini almak değildir. Kaynak kiralama, ihtiyacın büyüklüğü netleşene kadar işi yürütmenin verimli bir yoludur. İhtiyaç zamanla büyür ve kalıcı bir kadro gerektirirse, firma o kararı kendi zamanlamasıyla verir; bu model onun önünü kapatmaz, tam tersine karar için zaman kazandırır.
Hızlı büyüyen gayrimenkul firması, ekip eğitimi
Firma neye benziyordu
Firmanın CRM yapısı düzgün kurulmuştu ve olması gerektiği gibi çalışıyordu. Mevcut ekip sistemi kullanıyor, portföy ve müşteri takibi sistem üzerinden yürüyordu. Ortada bir kurgu sorunu yoktu.
Bizi neden aradılar
Firma kısa sürede çok sayıda yeni satış danışmanı işe aldı. Yeni gelenler kurulu yapıyı anlamadı ve alışkın oldukları yönteme, yani kendi telefon defterlerine döndü. Bu bilgiyi içeride aktaracak bir kaynak yoktu; sistemi en iyi bilen kişiler kendi satışlarını yürütmekle meşguldü ve aktarım kişiden kişiye, eksik şekilde yapılıyordu. Tetikleyici, aynı müşterinin iki ayrı danışman tarafından aranmasıydı.
Ne yaptık
Eğitime başlamadan önce bir tespit yaptık. Sorun bilgi eksikliği miydi yoksa sistemin kendisi mi? Kurgu sağlamdı, eksik olan yalnızca aktarımdı. Bunu söylemek, gereksiz bir yeniden yapılandırma projesini baştan eledi.
Eğitimi firmanın kendi sistemi ve kendi portföy verisi üzerinden kurguladık. Genel ürün anlatımı yapılmadı; katılımcılar kendi gerçek kayıtlarıyla çalıştı.
Danışman oturumunda günlük iş çalışıldı. Müşteri adayı girişi, portföy eşleştirme, görüşme kaydı ve takip.
Yönetici oturumu ayrı yapıldı. Ekip takibi, danışman bazlı görünürlük ve raporlar.
Eğitim sonrasında sistemde tutulmayan işlerin hangileri olduğu tespit edildi. Bu işler ayrıca ele alındı.
İşin zor tarafı neydi
Yeni danışmanların bir bölümünün daha önce başka bir CRM kullanmış olmasıydı. Bu kişiler sistemi bilmiyor değildi, başka bir sistemi biliyordu ve alışkanlığını taşıyordu. Onlara sistemi anlatmak işe yaramadı; aynı işin bu sistemde nasıl yapıldığını göstermek işe yaradı. Eğitim içeriğini bu ayrıma göre ikiye böldük.
Eğitimin kalıcılığıydı. İşe alım devam ettiği için tek seferlik bir eğitimin etkisi birkaç ay içinde eriyordu. Kurum içinden bu eğitimi tekrarlayabilecek bir kişi belirlendi ve o kişiyle ayrıca çalışıldı.
Yeni danışmanlar sistemi kurgulandığı şekilde kullanıyor, aynı müşterinin iki danışman tarafından aranması sorunu ortadan kalktı.
Bu vakadan çıkan not: hızlı büyüyen ekiplerde eğitim bir defa yapılıp bitirilen bir iş değildir. Kurum içinde aktarabilecek birini yetiştirmek, eğitimin kendisinden daha kalıcı bir sonuç üretir.
Çok bölümlü hastane, bakım ve destek
Firma neye benziyordu
Hastanenin Zoho yapısı büyüktü ve birbirinden farklı işleyişe sahip birden fazla birim tarafından kullanılıyordu. Hasta talepleri, yönlendirmeler ve müşteri deneyimi bölümleri arası aktarımlar bu sistem üzerinden ilerliyordu. Zoho burada yardımcı bir araç değil, kurumun müşteri deneyimi yapısının kendisiydi.
Bizi neden aradılar
Bu ölçekte bir yapıda mesele sistemin çalışıp çalışmadığı değil, bir şey aksadığında ne kadar sürede toparlandığıdır. Hasta talebinin aktığı bir akış duraksadığında etkisi doğrudan hastaya ve sahadaki personele yansır; bu yüzden müdahale süresi burada teknik bir konu değil, müşteri deneyimi konusudur. Hastanenin ihtiyacı, sistemi tanıyan bir ekibin sürekli erişilebilir olması ve her talep için baştan bir teklif süreci işletilmemesiydi. Bakım ve destek anlaşması bu ihtiyaç için yapıldı.
Ne yaptık
Mevcut yapıyı devraldık ve haritaladık. Hangi birimin neyi kullandığını, hangi akışın neyi tetiklediğini ve hangi entegrasyonun nereye bağlı olduğunu çıkardık. Hızlı müdahalenin ön şartı, müdahale anında sistemi öğrenmek zorunda kalmamaktır.
Talepler için tek kanal kurduk. Tüm birimlerin talebi aynı yerden geliyor, aciliyetine göre sıraya giriyor ve yapıyı zaten tanıyan bir ekip tarafından ele alınıyor. Her talep için ayrı bir ticari süreç işletilmiyor.
Aciliyet tanımı yapıldı. Hastayı veya sahadaki personeli doğrudan etkileyen akış arızaları ile iyileştirme talepleri ayrıldı. Öncelik bu ayrıma göre veriliyor.
Değişiklik yönetimi tanımlandı. Bir birim için yapılacak değişikliğin başka bir birimi etkileyip etkilemediği, değişiklik uygulanmadan önce değerlendiriliyor.
Dönemsel değerlendirme yapılıyor. Dönem içinde ne yapıldığı ve sistemin genel durumu yazılı olarak paylaşılıyor.
İşin zor tarafı neydi
Birimlerin birbirinden bağımsız talep vermesiydi. Aynı akışı kullanan iki farklı birim, kendi işleyişine göre birbirine ters yönde değişiklik isteyebiliyordu. Talepler tek kanala alındığında bu çakışma, değişiklik uygulanmadan önce görünür hâle geldi ve karar, akışı kullanan birimlerle birlikte veriliyor.
Aciliyet sıralamasının kabul görmesiydi. Her birim için kendi talebi acildir ve bu bakış açısı yanlış da değildir. Sıralamanın işlemesi, kimin talebinin daha değerli olduğu tartışmasından çıkarılmasına bağlıydı. Ölçüt hastaya ve personele etki olarak tanımlandığında sıralama kişisel olmaktan çıktı ve birimler tarafından kabul edildi.
Kritik akışlarda müdahale, sistemi baştan öğrenmesi gereken birinin devreye girmesini beklemiyor. Küçük işler ticari süreç beklemiyor, aciliyet sıralaması tartışma üretmiyor.
Bu vakadan çıkan not: Zoho bir kurumun müşteri deneyiminin taşıyıcısı hâline geldiğinde bakım, sistemi ayakta tutan bir kalem olmaktan çıkıp deneyimin kendisini koruyan bir kalem hâline gelir. Bu ölçekte geçen her saat doğrudan hastaya ve personele yansır.
Sekiz vakanın ortak noktası
Sekiz proje sekiz ayrı ihtiyaçtan doğdu ve birbirine benzemiyor. Yine de tekrar eden dört şey var. Bunları baştan bilmek, projeyi hem kısaltır hem ucuzlatır.
İhtiyaç büyümeyle ortaya çıkıyor
Sekiz vakanın hiçbirinde başlangıç noktası “yeni bir sistem alalım” olmadı. Reklam yatırımının karşılığını görmek, aday zincirini tek yerde yürütmek, karar anında doğru bilgiyi ekranda görmek, yeni bir program açmak, yıl sonu tahminini sistemden alabilmek, oluşan kaynak açığını kapatmak, büyüyen ekibe aktarım yapmak, müdahale hızını garanti altına almak. Hepsi işin büyümesiyle ortaya çıkmış somut bir ihtiyaç. Kendi ihtiyacınızı bu netlikte yazabiliyorsanız kapsamı da hızlı çıkarırsınız.
Zorluk teknikte değil tanımda
Sekiz vakanın hiçbirinde zorluk “bu ekran nasıl yapılır” sorusunda çıkmadı. Hangi sistemin hangi verinin sahibi olduğunda, serbest metinde duran bilginin hangi alana karşılık geldiğinde, bir yapının kaç farklı durumu taşıyacağında ve hangi talebin acil sayılacağında çıktı. Bunlar kurulum işi değil karar işidir ve bu kararı tek başımıza veremeyiz; her birinde kararın bir tarafı firmadır.
İlk tasarım sonraki kullanımı da kapsamalı
Tek programa, tek şubeye ya da tek birime göre kurulan bir yapı, ikinci kullanım geldiğinde temelinden ele alınmak zorunda kalıyor. Bu, sonradan yapılan işin en büyük kalemi. Ortadan kaldıran şey teknik bir önlem değil, projenin ilk gününde sorulan bir soru: bu yapı kaç farklı durumu taşıyacak. Cevabı bilinmiyorsa bile sorulmuş olması tasarımı değiştirir.
Canlıya geçiş bir bitiş değil
Sistem devreye alındıktan sonra ihtiyaç bitmiyor: yeni düzenlemeler geliyor, ekip değişiyor, müdahale hızı önem kazanıyor. Bu, her firmanın Zoho için içeride kadro kurması gerektiği anlamına gelmiyor. Vakaların ikisinde bu ihtiyaç bakım ve destek anlaşması ve kaynak kiralama ile karşılandı; firma ihtiyacın büyüklüğü netleşene kadar kadro genişletmek zorunda kalmadı. Kalıcı bir kadro gerektiğinde de kararı kendi zamanlamasıyla verdi.
Veri neredeyse hiçbir zaman tek dosyada durmuyor; mükerrer kayıt ve eksik alan ilk haftaları belirliyor, ayrıntısı CRM taşıma ve migrasyon sayfasında. Ve kapsam projenin ortasında büyüyor; bu olağandır, sorun konuşulmadan büyümesidir, o yüzden kapsam değişikliğini yazılı olarak ele alıyoruz.
Sizin projeniz hangisine benziyor
Yukarıdaki vakalardan birine yakın durduğunuzu düşünüyorsanız, ilgili hizmet sayfası işin nasıl yürüdüğünü ayrıntısıyla anlatıyor.
Sıkça Sorulan Sorular
Önce ihtiyacınızı konuşalım
İlk görüşme bir teklif sunumu değil, ihtiyacınızı anlama görüşmesidir. Durumunuzu dinliyor, hangi işin gerektiğini ve gerekmediğini söylüyoruz.
ZOHO ÜZERİNE UZMAN EKİBİMİZ
Haluk ÇavuşoğluKURUCU VE CEOCloudyflex’i kurdu ve Zoho ile iş ortaklığını kendi girişimiyle başlattı. Öncesinde Koç, Siemens ve Yıldız Holding bünyesinde yöneticilik yaptı. Kurumsal tarafta CRM projelerinin içinden geliyor.
Cenk ArslanKIDEMLİ DANIŞMANOn yılı aşkın süredir Zoho projeleri yürütüyor. Lojistik sektöründeki operasyon geçmişinin ardından bulut tarafına geçti, süreçleri sahadan bilerek tasarlıyor.
Murat OlgunKIDEMLİ DANIŞMANZoho projelerinde on yılı aşkın deneyimi var. Boğaziçi Üniversitesi Bilgisayar Mühendisliği mezunu, Koç bünyesinde çalıştıktan sonra kendi şirketini kurdu. Yazılım ve iş tarafını birlikte görüyor.
+
Arkalarında yalnızca Zoho üzerine çalışan bir ekip var. Uzun yıllardır bu ekosistemin içindeyiz ve başka bir yazılım markası satmıyoruz.
Durumunuzu anlatın
Formu doldurduğunuzda ekibimiz sizinle iletişime geçer. İlk olarak telefonda ihtiyaçlarınızı dinleriz ve bölgenizdeki uygun yöneticimiz tarafınıza atanır ve detaylı bir toplantı için sizle iletişime geçer.
