UCaaS Uygulaması: Adımlar, Zaman Çizelgesi ve Yaygın Tuzaklar

giriiş

Çoğu UCaaS projesi, platformun yanlış seçim olması nedeniyle başarısız olmaz. Bunlar da aynı bir avuç önlenebilir hata nedeniyle başarısız oluyor: kayan bir taşıma tarihi, yeni sistemle eşleşmeyen bir acil durum adresi kaydı veya eski telefon sistemi kapatıldıktan iki gün sonra bir özelliğin eksik olduğunu keşfeden önemli bir çalışan. UCaaS uygulaması, bir işletmenin mevcut telefon ve işbirliği araçlarını değiştirmek veya tamamlamak için Hizmet olarak Birleşik İletişim platformunu planlama, yapılandırma, test etme ve kullanıma sunma sürecidir ve iyi yapıldığında, tek bir geçiş hafta sonu yerine tanımlanmış bir aşamalar dizisini takip eder. Bu kılavuz, uygulamanın gerçekte neleri içerdiğini, çoğu geçişin takip ettiği altı aşamayı, şirket büyüklüğüne göre gerçekçi zaman çizelgelerini, erken sorunları önleyen teknik kontrolleri, normalde iyi planlanmış projeleri raydan çıkaran tuzakları ve çalışanların yeni sistemi hayata geçirdikten sonra gerçekten kullanmalarının nasıl sağlanacağını kapsar.

"UCaaS Uygulaması" Aslında Neleri İçerir?

UCaaS uygulaması, bir sözleşmenin imzalanması ile işletmenin yeni platformda tamamen faaliyet göstermesi arasındaki her şeyi kapsar: mevcut telefon ve ağ altyapısını değerlendirmek, yeni sistemi işletmenin gerçekte nasıl çalıştığına uyacak şekilde yapılandırmak, mevcut telefon numaralarını taşımak, kurulumu kimse ona güvenmeden önce test etmek, çalışanları eğitmek ve eski sistemden vazgeçmek.

Bu, tek bir kurulum değil, başlangıç ​​ve bitiş tarihi olan bir projedir. Bunu bir düğmeyi çeviriyormuş gibi ele alan işletmeler, daha derinlerde gizlenen tuzaklarla karşı karşıya kalanlar olma eğilimindedir.

UCaaS Uygulamasının 6 Aşaması Nelerdir?

İyi yürütülen UCaaS geçişlerinin çoğu, satıcıdan bağımsız olarak aynı altı aşamalı yapıyı takip eder:

1. 1Keşif ve değerlendirme — mevcut telefon sistemlerini, ağ kapasitesini, çağrı hacimlerini ve farklı ekiplerin gerçekte güvendiği özellikleri denetlemek
2. 2Tasarım ve konfigürasyon — İşletmenin bugünkü işleyişine uygun çağrı yönlendirme, dahili hatlar, sesli posta ve entegrasyonların ayarlanması
3. 3Pilot dağıtım — yeni sistemi tüm şirkete aynı anda sunmak yerine, önce küçük bir kullanıcı grubuna yaymak
4. 4Paralel test — yeni sistemi eski sistemin yanında kısa bir süre çalıştırmak, böylece eski sistem hizmet dışı bırakılmadan önce sorunlar ortaya çıkar
5. 5Üretim kesintisi — genellikle hafta sonu gibi daha düşük hacimli bir dönem için zamanlanmış şekilde tüm organizasyonun değiştirilmesi
6. 6Taşıma sonrası optimizasyon — yapılandırmaları ayarlamak, gerektiğinde yeniden eğitim vermek ve yalnızca gerçek günlük kullanımda ortaya çıkan sorunları düzeltmek

Zamandan tasarruf etmek için pilot veya paralel test aşamalarını atlamak, normalde iyi planlanmış bir projenin daha sonra sorunla karşılaşmasının en yaygın yollarından biridir.

UCaaS Uygulaması Ne Kadar Sürer?

Zaman çizelgeleri, şirket büyüklüğüne ve mevcut kurulumun karmaşıklığına göre birkaç haftadan birkaç aya kadar önemli ölçüde değişiklik gösterir. Referans noktası olarak, yaklaşık 50 kişilik bir işletme için iyi yürütülen bir uygulama, sözleşmenin imzalanmasından temiz bir geçişe kadar genellikle altı ila on hafta sürer. Daha büyük kuruluşlar, birden fazla konuma sahip işletmeler veya CRM'lere veya diğer iş sistemlerine yoğun entegrasyon gereksinimleri olan işletmeler daha uzun bir pist beklemelidir.

Rastgele bir canlı yayın tarihine ulaşmak için bu zaman çizelgesini aceleye getirmek, özellikle atlanan testler ve yetersiz eğitimli personel olmak üzere, aşağıda ele alınan tuzakların yaygın bir kaynağıdır.

Geçişten Önce Hangi Teknik Gereksinimlerin Kontrol Edilmesi Gerekir?

Ağ hazırlığı isteğe bağlı değildir ve aceleye getirilmiş bir uygulamada en sık atlanan adımlardan biridir. Geçiş yapmadan önce bir işletmenin şunları onaylaması gerekir:

• Bant genişliği diğer ağ trafiğiyle rekabet etmeden beklenen çağrı ve video hacmini karşılamaya yeterlidir
• Hizmet Kalitesi (QoS) Zamana daha az duyarlı trafikte ses ve video paketlerine öncelik verecek yapılandırma mevcuttur
• Gecikme Canlı bir aramada küçük gecikmeler bile fark edilebildiğinden, gerçek zamanlı arama için kabul edilebilir aralıklarda kalır
• Fiziksel donanımhala kullanıldığı yerlerde, yalnızca prize takılıp çalıştığı varsayılmak yerine, aslında gerçek ağ koşulları altında test edilmiştir

Bu kontrollerin atlanması, platformun kendisi tam olarak tasarlandığı gibi çalışıyor olsa bile, bazı UCaaS sunumlarının, canlıya geçişten hemen sonra çağrı kalitesi şikayetleriyle karşılaşmasının nedenidir.

En Yaygın UCaaS Uygulama Tuzakları Nelerdir?

Aynı bir avuç hata, ciddi sorunlarla karşılaşan UCaaS uygulamalarının çoğunun nedenidir:

• Taşıma tarihleri ​​fişi, bir işletmeyi geçici olarak ana telefon numarası olmadan bırakmak veya iki sistemi planlanandan daha uzun süre çalıştırmak
• E911 adres kayıtları eşleşmiyor Yeni sistem, birisinin yeni bir dahili numaradan acil yardım istemesi durumunda bir güvenlik açığı yaratıyor
• Önemli kullanıcılar eksik özellikleri keşfeder ancak eski sistem zaten kapatıldıktan sonra hızlı bir şekilde geri dönüş mümkün olmaz
• Ahizeler ve yazılım telefonları test edilmedi geçiş öncesinde gerçek ağ koşulları altında, çağrı kalitesi sorunlarının ilk gün ortaya çıkması
• Eğitim bir kez olur, canlı kullanıma geçmeden hemen önce, sistem günlük kullanıma girdikten sonra devam etmek yerine

Bunların çoğu, yukarıda ele alınan aşamalı yaklaşım ve teknik kontrollerle önlenebilir; platformun kendisindeki bir yetenek boşluğundan ziyade, bir proje son teslim tarihine yetişmek için aceleye getirildiğinde meydana gelme eğilimindedirler.

Çalışanlarınızın Yeni Bir UCaaS Platformunu Gerçekten Benimsemesini Nasıl Sağlarsınız?

Tangoe tarafından hazırlanan bir rapor, BT karar vericilerinin yalnızca %39'unun, UCaaS yatırımlarının, bekledikleri maliyet tasarrufları ve yönetim kolaylığı faydalarını tam olarak karşıladığını hissettiğini ve zayıf benimsemenin bunun yaygın bir nedeni olduğunu ortaya çıkardı.

Çalışanların yeni bir iletişim platformuna karşı direnci, özellikle eski araçlarla rahat çalışan ekipler arasında en büyük benimseme engellerinden biridir. Bunun üstesinden gelmek tek bir eğitim oturumundan daha fazlasını gerektirir: Liderliğin yeni platformu gözle görülür bir şekilde kullanması ve desteklemesi gerekir ve BT ekipleri, eğitimi hayata geçirmeden önce tek seferlik bir etkinlik olarak ele almak yerine sürekli, role özgü destek sağlamalıdır. Değişimi sadece yeni sistemin teknik olarak nasıl çalıştığı değil, her çalışanın günlük işi için neyin daha kolay olduğu etrafında çerçevelemek, benimsemeyi eğitimin uzunluğundan daha ileriye taşıma eğilimindedir. Tam kullanıma sunmadan önce küçük bir grupla pilot uygulama yapmak aynı zamanda bir işletmeye kafa karıştırıcı iş akışlarını herkese ulaşmadan düzeltme şansı verir.

Ringflow'un Katılımı Aynı Süreci mi İzliyor?

Ringflow bir UCaaS platformu olmasa da temeldeki disiplin devam ediyor. Kurulum Çağrı Yönlendirme ve mevcut sistemlerin bağlanması hâlâ aşamalı bir dağıtımdan, tam dağıtımdan önce bir pilot gruptan ve herhangi bir bulut iletişim platformu için önemli olan aynı tür ağ hazırlığı kontrollerinden yararlanır. Farklılaştığı nokta kapsamdır: Ringflow uygulamaları müşteriye yönelik çağrı akışlarına, kampanya yönlendirmesine ve CRM Entegrasyonları Dahili bir PBX'i değiştirmek veya çalışan dahili numaralarını taşımak yerine keşif aşaması, acil durum adres kayıtları veya masa telefonu envanterlerinden çok, bir satış veya destek ekibinin bugün çağrıları gerçekte nasıl ele aldığına odaklanır.

Bunun gibi daha geniş benimseme zorlukları şu belgede belgelenmiştir: Meridyen BTYukarıda özetlenen aynı öncelikli pilot, sürekli eğitim yaklaşımını yansıtan, ortak UCaaS kullanıma sunma engelleri üzerine araştırması.

Çözüm

Bir UCaaS uygulaması, teknolojiden çok disipline dayalı olarak başarılı olur veya mücadele eder: projenin geçiş öncesinde pilot testlerden ve paralel operasyondan geçip geçmediği, ağın hazır olup olmadığı varsayılmak yerine kontrol edilip edilmediği ve eğitimin durmak yerine ilk haftadan sonra da devam edip etmediği. Platformların kendisi bu noktada yeterince olgunlaşmış durumda; endişelenmeye değer arızalar neredeyse her zaman ürün arızaları değil, süreç arızalarıdır.

Sıkça Sorulan Sorular