Lucidchart, Lucid Software tarafından hazırlanan, insanların fikirlerini, bilgilerini ve süreçlerini net bir şekilde paylaşmalarına yardımcı olan görsel bir verimlilik platformudur. Güçlü bir yardım merkezi, çevrimiçi topluluk ve bire bir destek ile, Lucidchart’ın destek ekibi, ekip büyüklüğünü ve bilet hacmini sabit tutarken, 15 milyonun üzerinde mutlu kullanıcıya hizmet etmektedir. Lucidchart Müşteri Operasyonları Kıdemli Direktörü Keyvan Sadigh ile bir araya geldik ve ekibinin destek yeteneklerini nasıl büyüttüğünü ve takımını büyütmeden gelir elde ettiğini öğrenmeye çalıştık.

Katıldığın için teşekkürler, Keyvan! Arka planını anlatabilir misin ve Lucidchart’ta Müşteri Operasyonları Kıdemli Direktörü olana kadar nasıl geldiğine dair biraz bağlam verebilir misin?

Tabii ki! Uzun ve çok karmaşık bir kariyerim oldu. Biyoloji diplomasıyla Cornell’den mezun oldum ve genetikte doktora almak istediğimi düşündüm. Boston'da iki yıl boyunca biyomedikal laboratuvara genetik araştırması yaparak çalıştım, ardından bu yaşam tarzının bana uygun olmadığına karar verdim. Ne yapmak istediğim konusunda biraz kafam karışıktı, çünkü hayatım boyunca bilimi çalıştım ve şimdi araştırma yoluna gitmek istemiyordum.

Bunun yerine Philadelphia’da Teach for America’da görev yaptım ve burada iki yıl boyunca lisede matematik öğrettim. Bunun, yaşadığım her şeyden bir adım geri çekilip düşünmek için iyi bir fırsat sunabileceğini düşündüm. Oradaki zamanımın sonunda iş aramaya başladım ve Google'da çalışan bir arkadaşım ile iletişime geçtim; orada bir rol için başvurmamı teşvik etti. Google'a, yardım merkezlerini geliştirmeye odaklandıkları bir zamanda katıldım. Gmail, görece yeni bir ürün olsa da, kullanıcı tabanı çok hızlı bir şekilde büyüyordu. Google’ın bir destek için telefon numarası veya e-posta adresi yoktu, bu yüzden kullanıcıların kendilerine yardım edebileceği ve birbirlerine yardım edebileceği bir yardım merkezi oluşturmak için bir strateji geliştirdik.

Bunu farklı görevlerde yaklşık dört yıl yürüttüm, ardından insan yönetimini denemek istedim, bu yüzden Google’ın Dublin ofisine transfer oldum ve buradaki topluluk stratejisini birkaç Avrupa pazarında başlatmaya yardımcı oldum. Burada da, kullanıcıların birbirlerine yardım edebileceği bir platform sağlarsak, çok daha hızlı kaliteli bir cevap alabileceğini düşünüyorduk.

Dublin’de bir yıl kalmam gerekiyordu ama neredeyse dört yıl kaldım. Harikaydı, o zamanlar çok keyifliydi. Farklı kültürlerden insanları yönetme fırsatım oldu, bu benim için gerçekten harika bir deneyimdi. Oradaki zamanımın sonunda, şirketin çok iyi yönetilen bir motor gibi çalıştığını hissettim; ben de bunun sadece küçük bir parçasıydım ve Google’daki daha önceki günlerin karmaşasını özlemeye başladım, burada birçok farklı görevle karşılaşma fırsatım olurdu.

Daha küçük şirketlere bakmaya başladım ve Google’a benzer bir kültür arıyordum, bu yüzden Google Ventures web sitesine göz atarak Google’ın yatırım yaptığı şirketleri buldum ve Lucid bunlardan biriydi. CEO'muz Karl Sun da eski bir Google çalışanıdır ve ben onunla yaptığım konuşmada özellikle toplum yaratmaya ve insanlara büyük şeyler yapmaları için güç vermeye önem verdiğini sevdim; ve insanların yazılım yoluyla görsel olarak iletişim kurmalarına olanak tanıyan Lucidchart isimli bir platform oluşturma üzerine de.

Bu benim için yeni bir kavramdı. Görsel olarak iletişim kurmanın ne demek olduğunu hepimiz biliyoruz ama geleneksel olarak toplantılara, notlara ya da elektronik tablolara güveniyorduk. Lucid, insanların bir tarayıcıda yapabilecekleri sınırları zorlamaya başladı ve daha işbirlikçi bir biçimde görsel düşünmemizi sağlama amacını gütmeye başladı. Bu nedenle şirketin misyonuna gerçekten katıldım.

Katıldığımda, destek ekibi sadece dört kişiydi ve e-posta desteğine çok odaklanmıştı. Yapmam gereken görev, kullanıcı tabanımızın son derece hızlı bir şekilde büyümesiydi - dört ya da beş yıl boyunca her yıl iki katına çıktı - ama doğru stratejinin kullanıcılarımızın kendilerine en iyi ve en hızlı yanıtı alabilmesi için kendi kendilerine yardım etmelerini sağlamak olduğunu düşündük. Bu yüzden ben de buna katıldım.

Vay, Google boyutunda bir destek ekibinden, Lucidchart'taki dört kişilik bir ekibe geçince gerçekten istediğin o karmaşayı yakaladığını duyuyorum!

Kesinlikle.

Şimdi Lucidchart'ta büyüdüğüne göre, destek ekibini son birkaç yılda 10 kişi olarak sabit tutmaya ve bilet hacmini düz tutmaya devam ettiğini duydum. Küçük bir ekibin destek stratejinizdeki rolü nedir?

Stratejim, ekibimizin ölçebileceği zengin içerik sağlamaya odaklanıyor, böylece kullanıcılar aradıkları şeye kendileri ulaşabiliyor. Bir ATM örneği ile bunu açıklıyorum: Bir bankaya normal iş saatlerinde gittiğinizde, bu soruyla karşılaşırsınız: Bankaya girip, sırada bekleyip, sorumu soracak mıyım? Yoksa ATM'de kendime mi yardım edeyim? Genellikle ATM'yi tercih ediyorum. Ve bu benzerlikten yola çıkarak teknoloji dünyasına geçersek, Lucidchart'ta çok iyi bir şekilde yazılmış bir yardım merkezi makalesinin, kullanıcılarımızın yapmaya çalıştıkları şeylerin %90’ı için yalnızca yeterli değil, aslında tercih edilen bir seçenek olduğunu düşünüyoruz.

Bunun yanı sıra, yardım merkezi, birçok farklı şey için talebi ölçmek için harika bir yol. Eğer on binlerce insanın belirli bir konu ile ilgili bir makaleye geldiğini kanıtlayabilirseniz, bu bilgiyi mühendisliğe iletip, gerçek müşteri verileriyle desteklenen değişiklikler için baskı yapabilirsiniz. Oysa kullanıcılar destek ekibimize e-posta gönderdiğinde, hacim genellikle daha düşük oluyor ve dolayısıyla bu veriyi mühendislik ekiplerimize sunduğumuzda daha az uygulanabilir oluyor. Bizim için gerçekten harika oldu, çünkü yalnızca 15 kullanıcıya bir özellik için e-posta göndermiş olsalar bile, o özellikle ilgili yardım merkezi makalelerine binlerce kullanıcı ulaşmış oldu.

İkinci parça, yardım merkezi içeriğimizin altı farklı dile yerelleştirilmiş olmasıdır, bu yüzden ekibiniz tarafından yazılan yüksek kaliteli içerik oluşturmanın doğal bir maliyeti vardır. Uzun kuyruk içerik için, kullanıcıların kendi içeriklerini gönderebilecekleri ve diğer kullanıcıların bundan yararlanabileceği bir topluluk sağlıyoruz. Bu kavram için kullanmayı sevdiğim örnek, Lucidchart için bir Android uygulamamız olduğu ve gerçekten binlerce farklı Android telefon bulunduğudur; eğer bir kullanıcı belirli telefonuyla ilgili bir sorun yaşıyorsa, bu belirli telefona ulaşma şansımız oldukça düşük. Ama muhtemelen 15 milyon kullanıcımızdan biri o telefona sahip ve bu tam sorunu yaşamış olabilir. Bu nedenle bazen rolümüz, kullanıcılarımızı birbirleriyle bağlantı kurabilmeleri için bağlamaktı.

Ve bu, izlemek için gerçekten harika bir şeydi, çünkü yardım merkezimiz ve topluluğumuz için trafiği incelediğimizde, kullanıcı tabanı büyümesini gerçekten aşmış durumda. Ve senin noktan için, ürün destek bilet hacmini son üç yıl içinde incelediğimizde, esasen sabit kalmıştır. Bu benim için, kullanıcıların gerçekten bu kendi kendine yardım modelini sevdiklerini ve ona doğru yöneldiklerini ima ediyor.

Çevrimiçi topluluğunuz söz konusu olduğunda, bilgi sağlayan ve diğer kullanıcılara yardım eden kişilerin ne tür insanlar olduğunu biliyor musunuz? Başka biriyle ilgili ürününüz hakkında konuşurken kişisel zaman harcayan birini düşünmek hoş bir kavram.

Topluluğumuz hala gelişme aşamasında – birçok kez kullanıcılar sorular sorar ve biz de toplulukta onlara yanıt veren taraf oluruz, ama diğer kullanıcılar da bu yanıttan yararlanabiliyor. Ancak giderek daha fazla, diğer kullanıcıların girip yanıt sağladığını görüyoruz ki bu, bizim amacımız için en iyi senaryo.

Neden böyle olduğunu sormak gerekirse, dünyada kullanıcıların oldukça tutkulu olduğu çok az ürün var, ama ben bu kategoriye kesinlikle giren Lucidchart gibi bir ürün üzerinde çalıştığım için şanslıyım. Çünkü ürünümüz tam olarak bir kullanıcının ihtiyaçlarına uymadığında ve bazen onu kullanabilmek için çılgın çözümler deneyimlemek zorunda kaldıklarında, bunu seçiyorlar.

Bu tutkuyu örneklendirmek için, Lucidchart iPhone uygulamasını günlük takvimleri olarak ayarlayan bir kullanıcı var. Bu, ekibimizin ürüne yönelik hiç hayal etmediği bir kullanım durumu, ama nedense bu kullanıcı, çözümümüzün Google ve Apple’ın takvimlerinden daha iyi olduğunu düşündü ve bu kullanım durumuna hiç odaklanmamıza rağmen, bunu onlarla birlikte çalıştırmak için gerektiğinden fazla çaba harcamak için karar verdi.

Bu zihniyeti düşündüğümüzde, kullanıcıların yapmak istedikleri birçok şey, ürünümüzün başarma yeteneğini zorlamak. Diğerlerine yardımcı olmak ve kendi kullanım durumlarını paylaşmak, tutkularını besliyor. Bu ürünü seviyorlar ve bu tutkuyu başkalarıyla paylaşmak istiyorlar.

Harika. Ekibiniz, bu kullanıcı fikirleri ve gönderimlerini nasıl takip ediyor?

Topluluğumuzda şemalarınızı paylaşın; ürünümüzü kullanmanın yenilikçi yolları hakkında kullanıcılarımızdan duymak istiyoruz. Bu, bu kullanım durumlarından bazılarının nasıl duyulduğunun bir yoludur. Daha yaygın olan yöntem, ekibimizin hala e-postaları yanıtlamakta çok aktif olmasıdır. Bilet hacmi sabit kalsa da, yine de haftada yaklaşık 600 ürünle ilgili destek e-postası alıyoruz. Bir kullanıcı bize ulaşarak, "Bunu yapmaya çalışıyorum ama bu engelle karşılaştım." der. "Belgeime bir göz atıp bu konuyu çözmeme yardım eder misin?" diyebilir. Sıklıkla, yardım istedikleri belgeler, şablonlarımızın oldukça basit kullanımlarını içeriyor ama bazen gerçekten yenilikçi kullanım durumları görüyoruz ve bu durumlarda onlardan bu belgeleri topluluğa göndermelerini isteyerek diğer kullanıcıların da bundan yararlanmasını sağlıyoruz.

Bu şekilde gelen yenilikçi fikirler ürününüze geri dönebilir mi? O çalışmayı içerde nasıl paylaşırsınız?

Müşteri Başarıları ve Çözüm Mühendisliği ekiplerimizle işbirliği yaparak, tüm müşterilerimizden gelen özellik taleplerini derleyen bir Müşteri Görüşü raporu hazırlıyoruz. Şablon taleplerinde, yeni ve kullanıcı tarafından oluşturulan fikirlerimizi gönderdiğimiz bir ürün şablon ekibimiz var. Bu ekip, gönderimleri araştırıyor ve ardından bir resmi şablon eklemeyi değerlendiriyorlar. Yardım merkezimizde bir şablon galerimiz var ve bazı kullanıcılarımızın oluşturduğu içerikler orada yer alıyor ve bu şekilde keşfedilebiliyor.

Uzun vadeli vizyonumuz, yardım merkezi ve topluluğun birleşik halde ilham verici ve proaktif yardım sunabileceği bir yer olmasıdır; bunun yerine kullanıcıların yalnızca bir şey bozulduğunda geldikleri bir yer olmasını istemiyoruz. Kullanıcıların endüstrideki genel standart olan bu algının ötesine geçmelerini istiyoruz.

Size, şirketiniz ile müşterileriniz arasında daha ikili bir caddenin varlığını hayal ettiğinizi söylüyorsunuz gibi geliyor.

Kesinlikle.

Bu, Lucid’in temel değerlerini hatırlatıyor: Ego yerine takım çalışması; yaptığımız her şeyde yenilik; bireysel güçlenme, girişim ve sahiplenme; ve her alanda tutku ve mükemmeliyet. İkili bir cadde oluşturmak, bunların çoğuna işaret ediyor. CX yaklaşımınızda bu temel değerleri başka nasıl somutlaştırıyorsunuz?

Bu temel değerler, şirket genelinde belirlenmiş durumda ve bizim gibi müşteri ile yüz yüze olan sektörlerde daha da geçerlidir. Bunun ötesinde, bu temel değerleri her şirket başlangıcında ve her şirket güncellemesinde vurguluyoruz. Ve yılda bir kez üç gün boyunca şirket genelinde bir inzivaya çıkıyoruz; Zion Ulusal Parkı veya Bear Lake’e giderek takım oluşturuyor ve gelecek yıl için stratejimizi yoğunlaştırıyoruz ve ayrıca ilk inzivaya katılan yeni insanlara temel değerlerimizi yeniden hatırlatıyoruz.

Bunu duymak harika. Biz de her şeyde temel değerlerimizi benimsemeye çalışıyoruz .

Peki, ekibiniz proaktif müşteri eğitimine nasıl yaklaşır? Proaktif ve reaktif CX ekibi arasındaki ayrım nedir?

Reaktif tarafla başlayalım, bu konuda oldukça iyi olduğumuzu düşünüyorum. Eğer bir kullanıcı, üründe yapmak istediklerini biliyorsa ve yardım merkezimize veya topluluğumuza nasıl yapacağını öğrenmek için geldiyse, onlara ihtiyaç duydukları içeriği sağlamaya çalışıyor ve genellikle bunu videolar ve ekran görüntüleri ile destekliyoruz, böylece başarı için hazır hale gelmiş oluyorlar.

Geçiş yapmak istediğimiz model, proaktif model; sadece insanlara ne yapacaklarını söylemek değil, neden öyle yapmaları gerektiğini de anlatmaktır. Diyelim ki bir kullanıcı, yardım merkezimize geliyor ve diğer yollarla, biyoloji öğretmeni olduğunu biliyoruz. O öğretmeni, neyi nasıl yapacaklarını gösterirken, hangi şablonu kullanmalıdır diye özel içeriklere taşımalıyız. Uzman ekiplerimiz – burada eğitim ekibi örneğinde – daha iyi ve bilgilendirici kullanım durumları sağlamaya çalışıyorlar.

Eğer bir müşteri, belirli bir özelliği nasıl kullanacağı hakkında bir şeyler okuyorsa, o özelliği kullanmış diğer kullanıcılardan bazı ürün sinyalleri (verileri) yakalayıp, bu bilgiyi müşteriye sunarak benzer kullanımda diğer özelliklerle birlikte sunmaya çalışabiliriz. Sonra bu kavramı yardım merkezine taşıyıp, “Tamam, şimdi bir sunum hakkında bir makale okudun. Şimdi katmanlar ile neyin gösterilip gizleneceği hakkında okuyabilirsin; çünkü biliyoruz ki bu iki özellik, ürün kapsamı içinde birbiriyle el ele çalışıyor.” diyebiliriz. Artık katmanlar hakkında okuyup farklı katmanları gösterme ve gizleme üzerine bu makaleyi okumalısınız çünkü bu iki özelliğin üründe bir arada gittiğini biliyoruz. Bunlar, ulaşmaya çalıştığımız şeyin bir parçasıdır.

Bu stratejiyi hedeflere nasıl resmileştiriyorsunuz? Hedefleriniz yalnızca bilet hacmini düz tutmak ve ilk yanıt süresini azaltmakla kalmıyor gibi görünüyor.

Destek metriklerimiz için “Kutsal Kâse”, bir kullanıcının yardım merkezindeki eylemlerinin, ürün içindeki eylemleriyle bağlantılı olduğunu belirlemektir. Örneğin, belirli bir makaleye, diyelim ki veri bağlantısına, bakan her 1000 kullanıcının 700’ünün ürüne geçip veri bağlantı özelliğini kullanmasını sağlamak gibi bir hedefe ulaşmak istiyoruz. Ve son zamanlarda, yardım merkezinin kullanımını, ürün kullanımıyla bağlayabilmeyi başardık. Bunun üzerinden, yardım merkezi kullanımıyla ürün kullanımı arasında ilişki bulabiliyoruz.

Benim için bu, yapmak istediğimiz şeyin özüdür: ürünümüzün kullanımını artırmak. Ve ardından kullanıcıların tutulmasına bir değer ekleyebilmek. Bunu, yardım merkezini ziyaret eden 1000 kullanıcının tutma oranlarını, ziyaret etmeyen 1000 kullanıcıyla karşılaştırdığımızda şu yüzdeden daha fazla olduğunu söyleyerek gösterebiliriz, çünkü onlara değerli bir bilgi öğrettik. Ya da hatta tutmanın ötesine geçerek, katılım oranlarının da yükselip yükselmediğine bakmak.

Bunu çok seviyorum. Son zamanlarda birkaç CX lideriyle konuştum ve desteğin bir maliyet merkezi değil, gelir üretici olması teması sürekli gündeme geliyor. Bu modelin, desteklerin sadece maliyet yaratmak yerine gelir sağlaması gerektiğini abone olduğunuzu mu düşünüyorsunuz?

Kesinlikle, ama ekibimiz bunun ötesine geçiyor. Çoğu zaman, bir kullanıcı bize ulaşıyor ve şöyle diyor: "Merhaba, Lucidchart'ı kullanmaktan memnunuz, ancak bir belge içe aktarmada bir sorun yaşıyoruz. İçe aktardığımız belgeler çok garip görünüyor. Bu sorunu çözebilseydik, şirketimizdeki Lucidchart kullanımı artırabilecektik.” Yani destek sorununa yardımcı olacağız ve ardından bunu satış ekibimize ileteceğiz.

“Son bir yılda destek, aslında şirketin satış fırsatlarının üçüncü en büyük kaynağı oldu. Eğer destek kanalı üzerinden gelen gelir miktarına bakarsanız, ekiplerin maaşlarını çok aşmaktadır. Yani biz aslında hiç maliyet merkezi değiliz.”

Bu son derece etkileyici! Ekibinizin takip ettiği diğer metrikler nelerdir? İlkeleri takip etmenizi önerdiğiniz destek liderleri için hangi metrikleri tavsiye edersiniz?

Kendimize gurur duyduğumuz şeylerden biri, yardım merkezi ve topluluk sitelerinin ne kadar hızlı büyüdüğüdür – buna ölçeklendirilmiş destek diyoruz – bire bir destekle karşılaştırıldığında; bu da e-postalar, telefon görüşmeleri ve sohbet desteğidir.

Bire bir desteğin büyümesini ölçmenin bir yolu, kullanıcı tabanındaki e-posta sayısına bakmaktır. Bu nedenle, kullanıcı tabanımızın ne kadar hızlı büyüdüğünü takip ediyoruz ve destek platformlarımızın ne kadar hızlı büyüdüğünü takip ediyoruz, ardından birini diğerine normalize ederek 10.000 aktif kullanıcı başına gönderilen e-posta sayısını anlamaya çalışıyoruz. Ve buna karşı, ürünün her 10.000 aktif kullanıcısı için yardım merkezi sayfa görüntüleme sayısını alıyoruz.

Bire bir destek tarafını incelediğimde, daha geleneksel: ilk yanıt süresi, müşteri memnuniyeti ve kullanıcı bekleme süresi gibi şeylere bakıyoruz; bu, tickets submitted when a ticket is submitted to when it is resolved, subtracting any time that we are waiting for the customer to get back to us with more information.

Ölçeklendirilmiş desteğe baktığımızda, birine bire bir destekten biraz farklıdır. Öyleyse, ölçeklendirilmiş desteği kullanan o kullanıcılar – ister yardım merkezi ister topluluk olsun – ürün içerisinde ne yapıyorlar? Yedi günlük kalma oranları nedir, 30 günlük kalma oranları nedir, yardım merkezini kullanmayan kişilerin kalma oranları ile karşılaştırıldığında? Ve bunu aynı zamanda gelire de bağlayabiliriz. Yardım merkezini ziyaret eden kişiler, daha fazla yükseltme yapma eğilimindeler mi? Hesaplarındaki kullanıcı sayısını artırma eğilimindeler mi? Bunların, bu süreçte izlediğimiz ana metrikler olduğunu söyleyebilirim ancak bu işlem çok ilerleme kaydetmiş durumda.

Önceden, yardım merkezinizde belirli bir makalenin ne kadar sık kullanıldığına dair bilgi edinmeye yönelik bir şey söylediniz ve bu verinin gelecekteki ürün kararlarını bilgilendirmesi. Bu, bilgi açısından Guru'da gerçekleştirdiklerimize biraz atıfta bulunuyor, peki yardım merkeziniz aracılığıyla topladığınız veriyi ve bilgiyi stratejinizde nasıl değerlendiriyorsunuz?

Bu harika bir soru. Her zaman bire bir desteğimizin ölçeklendirilmiş desteğimizi bilgilendirdiğini söyleriz. Bu nedenle, toplulukta bir sorunun patladığını görecek olursak, bir kullanıcı toplulukta bir şey yapmayı öğrenmek istediğini paylaşıyor ve bunun çok fazla sayfa görüntülemesi alıyorsa, bunu gerçekten bir yardım merkezi makalesine yükselteceğiz ve daha fazla trafik çekmek için yerelleştireceğiz. Ve sonra, bilet hacimlerine baktığımda, aynı şey söylenebilir. Ürünle ilgili bir konuda birçok e-posta aldığımızda, o e-postalara bakıp "Tamam, bu bir topluluk gönderisi olarak mı yoksa bir yardım merkezi makalesi olarak mı daha mantıklı?" diye düşünüyoruz. Herhangi bir şeye çok fazla e-posta alırsak, bu bir topluluk gönderisine terfi ediyor. Eğer bu, çok fazla trafik alıyorsa, o zaman yardım merkezi makalesine terfi ediyor.

Ve şimdi yaptıklarımızın başarısını ölçebiliriz. Bu yardım merkezi makalesini oluşturduğumuzda, ardından o tür biletlerde bir azalma olup olmadığını görebiliriz çünkü şimdi ölçekli desteğe daha fazla trafik yönlendiriyoruz.

Son parça sayfa görüntülemeleri ile ilgilidir. Bizim için sayfa görüntülemeleri genellikle e-posta hacminin yerini alır. Eğer bir topluluk gönderisi bir özellik isteği olursa, o zaman bu topluluk gönderisindeki etkileşimi ve sayfa görüntüleme sayısını gösterip o veriyi mühendislik ekibine götürebiliriz ve "Hey, bunun için bir talep var. Bunu ürün yol haritasına alalım.”

İşlerinizi sizin gibi ölçeklendirmek isteyen destek liderleri için son bir ipucunuz var mı?

Diğer ipuçlarım, en iyi yetenekleri nasıl işe alacakları ve elde tutacakları etrafında yoğunlaşıyor. Çoğu destek organizasyonunun büyük zorlukları var, çünkü elde tutma oranları oldukça düşük olmaya meyilli. Başarılı olmamızı sağlayan şeylerden biri, ekipimizin elde tutma oranının son derece yüksek olmasıdır. Son 18 ayda, benim ekibimden sadece bir kişi başka bir yere geçiş yaptı, bu da bu alanda nadir görülen bir durumdur. Son üç buçuk yılda ekibimden ayrılan bireyler tümüyle Lucid içinde kalmış ve kullanıcı bilgilerini şirketin diğer bölümlerine taşımışlardır. Ama, destek organizasyonundaki insanları üst düzey stratejinin gerçek sahipleri olmaları için güçlendirirseniz, bu sadece e-postaları geçmek veya telefon görüşmelerini üstesinden gelmekle ilgilenmekten çok daha anlamlıdır; bu, onlara gerçekten güç katar ve sonra diğer alanlara geçebilecekleri beceriler geliştirir, ister şirketteki başka bir rolde ister ekip içinde olsun.

Bu benden sürekli tekrarlamayı sevdiğim bir şeydir: ekibi mümkün olduğunca stratejinin bir parçası olarak dahil etmek, çünkü bu nihayetinde onları heyecanlı, tutkulu ve gelişmeye devam ettirecek olan şeydir.

Ne harika bir bitiriş. Zaman ayırdığın için çok teşekkür ederim, Keyvan! Okuyucularımız sorularını sizin destek felsefeniz veya Lucidchart ile ilgili nasıl sizinle iletişime geçebilir?

Bana LinkedIn üzerinden ulaşabilirsiniz.