Keşke düşeceğin yeri bilsen, sadece saman değil, bir de halı sererdin. Ancak hayat ve pratiğin getirdiği sürprizler, hatta deneyimli uzmanların bile zaman zaman hatalar yapmasına neden olur. Bu, yeni bir yazılım ve donanım kompleksi veya çağrı merkezinin lansmanının başarısız olmasına yol açabilir. İşte gerçek olaylara dayanan bir hikaye. Şans eseri iyi sonuçlandı. Yürütme başarılı oldu, ancak her şey kötü bitebilirdi. Biz yapmadık, ama başkalarının hatalarını tekrarlamayın.
Çağrı merkezi yöneticisi için araç ile ilgili bir makaledir.
Giriş
“Romashka” şirketinde 200 kişilik kendi çağrı merkezi vardı, bu iki bölümden oluşuyordu. Bunları koşullu olarak satış departmanı ve servis bölümü olarak adlandıralım. Satış departmanı yeni müşterileri çekmek, gelen çağrılara ve chat üzerinden taleplere CRM-sistem kullanarak cevap veriyordu.Servis bölümü, Asterisk kullanarak mevcut müşterilere destek sağlıyordu ve kendi geliştirdikleri CRM’de (bu arada, sıkıcı olmaması için tam bir set olarak MS SQL Server, Oracle, PostgreSQL ve MySQL olmak üzere tam dört RDBMS kullanıyordu) işlemlerini yönetiyordu.Ve BT departmanı ayrı bir organizasyon birimi olarak kendi CRM’ini geliştirmedi ve desteklemedi, servis teknisyenleri zaman zaman kendileri bunu dönem dönem yeniliyorlardı – bu tarihsel olarak böyle gelişti. Şirket ekipman üretimi ve tedarikiyle ilgileniyordu.
Yönetim, yöneticilerin farklı bilgi sistemlerinin “hayvanat bahçesi” ile başa çıkmasına yardımcı olmak için bir ÇM (bulut çağrı merkezi lansmanı) platformu yürütmek konusunda karar aldı. Burada, verilerin doğal olarak senkronize edildiği, ancak “bir şekilde takılmadan” farklı bilgi sistemleri arasında karmaşıklıklar mevcuttu. ÇM’nin tek bir çağrı yönetimi üzerinden sorumlu olması ve CRM sistemlerinin de müşteri yönetimini üstlenmesi öngörülüyordu. Dolayısıyla, ÇM, işleme için bir müşteri bilgisini alacak ve sonra onu “doğru” CRM sistemine geri gönderecek, yani senkronizasyon mekanizması çağrı merkezinin “iç yapısında” gerçekleştirilecekti. Esasen, belirli koşullar altında, bu tür bir düzenleme mümkündü, çünkü satış departmanına doğrudan API aracılığıyla erişilebilirdi.
Çağrı merkezinin başlatılmasında karşılaşılan zorluklar ve çözümleri
Çağrı merkezinin başlatılmasında hemen zorluklar ortaya çıktı. İdeolojik nedenlerle bir platform seçildikten sonra, entegratör konusu açılır. Teknik şartları yazdık, deneyimleri yaklaşık olarak aynı olan dört şirketten teklif talep ettik, fiyatları üç kat farklı olan dört teklif aldık. Kime işi vermeniz gerektiğini nasıl anlarsınız? En ucuz SIP sağlayıcısını seçtik ve garip bir şekilde, sadece en az yüzsüz olanlar olmadıkları için, aynı zamanda yeterli niteliklere de sahip olduklarını keşfettik.
Ancak bu, şans eseriydi, entegratörlerin potansiyelinin değerlendirilmesi yapılmadı. Ve iş dünyasında en kötü şey, şansa güvenmektir.Sözleşme imzalandı, işe koyulduk. Ve işte, müşteri tarafından atanan sorumlu servis BT oldu (kendi içinde kaynayan ve kendi CRM’i hakkında hiçbir şey bilmeyen, çünkü doğada dokümantasyon yoktu). Servis bölümüne gittik, müdür entegrasyonla ilgilenmek için yeterli programcı saatine sahip olmadıklarını açıkladı. Sadece yok. Ancak genel olarak “acil-önemli” kategorisinden işler için onaylanmış bir plan var.
Satış departmanının müdürüne gittik. O, iki eliyle “destek veriyorum” dedi, ama yönetimi üstlenemez, çünkü o bir teknik uzman değil, bir satışçı ve onun…kendi planı var. Zor bela, işin sahibiyle iletişime geçerek, entegratör temsilcileri, BT ve servis bölümünden programcı saatleri ayırttı. Projeye müşteri tarafından atanmış yönetici olarak…doğru…baş satış görevlisi oldu!Teknik görevi yazıp onaylamak için oturduk. Bu sırada birileri, işletme istasyonları ÇM platformu ile işletim sistemleri gereksinimleri nedeniyle uyumsuz olabileceğini fark etti.
Ancak sorun yaşanmadı…ama yaşanabilirdi. Bu, ana sözleşme imzalanmadan önce, ön tasarım görüşmelerinde kontrol edilmesi gereken bir şeydi. Hata, entegratör tarafındaki yöneticiden kaynaklandı, kendi sözlerine göre, gözleriyle gördüğü çalışma istasyonlarında istenen işletim sistemi vardı. Ama göremediği istasyonların olabileceğini gözden kaçırdı.İlk iş olarak, ÇM’i bulut CRM ile birleştirmeye çalıştılar. Biraz zorlukla API üzerinden bağlandılar ve kombinasyon oldukça iyi çalıştı…gerçek yük altında test edene kadar. Ve orada – belirli bir zaman diliminde, buluta yapılan sorgu sayısı sınırlıymış meğerse, bu hakkında hiçbir yerde hiçbir şekilde söz edilmemiş, sadece bir gerçekmiş. Genelde, sorun, belirli bir bulutun belirli bir ÇM’i destekleyemediği gerçeğine indirgendi. Kutulu çözüm için bütçeyi hesapladılar – gözyaşlarına boğuldular ve neredeyse satın aldılar. Neredeyse – çünkü bu sefer entegratör, buluttan kutuya veri göçü hakkında doğru soruyu sordu. Çıkış olarak, kaynaklar kesinlikle göç etmeyecek. Bazı manevralarla buluta olan sorgu sayısını azaltmayı başardılar. Kutuyu satın almadılar.
Servis departmanı ile ÇM’i bağlama saati geldi. Tabii ki, oradan yardımcı olabilecek tek programcı, işe başlamadan üç gün önce izne ayrıldı. Proje iki hafta durdu (anahtar uzmanların tatil programlarını kesinlikle kontrol edin). Ancak kişi döndüğünde, iş tamamlandı.Her iki bulutta da zaten mevcut olan verilerle ne yapılacağı sorunu ortaya çıktı, bunları birbiriyle uyumlu hale getirmek gerekiyordu. Bu arada, hangi CRM’de hangi durumda olursa olsun bir temasa bağlı olarak iletişim yönlendirme şeması oldukça karmaşıktı, bu yüzden veri çelişkileri müşteriler için IVR’de ebedi döngüler gibi şaşırtıcı bir deneyim yarattı. Müşteriler “Romashka”ya iyi para ödüyor ve memnun değillerdi çünkü ekipmanla ilgili sorunlar olduğunda iş sürekliliği bozuluyordu. Mevcut verileri “olduğu gibi bırak ve sonra temizle”, yeni müşterilerin verilerini ise normal şekilde tut kararına vardılar. Bu işe yaradı, ama sorunu, elbette, çözmedi.Neredeyse zamanında ve (zorlukla) teknik şartlara uygun olarak, ancak teknik görevi tam olarak karşılayamayarak, entegratör işi teslim etmeye gitti. Ve işte burada, %100 TZ’ye uygun ÇM raporlarının…güzel olmadığı…hoşlanılmadığı ortaya çıktı. Neden güzel olmadığı ve nasıl düzeltileceği konusunda kimse açıklayamadı, yeniden düzenleme için basitçe para kalmamış olabilir. Genel olarak, müşteri birkaç hafta daha entegratörle raporların estetik cazibesi konusunda mücadele etti.Daha birçok sorun vardı, örneğin, müşterinin departman yöneticileri arasında iç çatışmalar ortaya çıktı. Ama – başardılar. Ve bu, bugüne kadar çalışıyor.
Sonuç
Bu masalın morali çok basit: Şeylerin birbirleriyle uyumsuz olabileceğini varsayın. İster işletim sistemleri ve ÇM yazılımı gibi kendi özellikleriyle (ister yük altında ve yük altında olmadan bazı koşullarda), ister insan faktörüyle olsun. Ve kağıt üzerinde her şey genellikle iyidir, ama … It’s always easier said than done.
