Lucidchart, Lucid Software에 의해, 명확하게 아이디어, 정보 및 프로세스를 공유하는 데 도움이 되는 비주얼 생산성 플랫폼입니다. 강력한 헬프 센터, 온라인 커뮤니티 및 일대일 지원을 통해 Lucidchart의 지원 팀은 1500만 명 이상의 만족스러운 사용자에게 서비스를 제공하며, 팀 규모와 티켓 볼륨은 평형을 유지합니다. 우리는 Lucidchart의 고객 운영 수석 이사인 Keyvan Sadigh와 함께 앉아 그의 팀이 어떻게 지원 능력을 확장하고 팀을 확장하지 않고도 수익을 창출했는지 알아보았습니다.

우리와 함께해 주셔서 감사합니다, Keyvan! 귀하의 배경을 설명해 주시고 Lucidchart에서 고객 운영의 수석 이사가 된 배경에 대한 맥락을 제공해 주실 수 있나요?

물론! 나는 많은 twists and turns가 있는 긴 경력을 가지고 있습니다. 나는 생물학 학위로 Cornell에서 졸업했고 유전학 박사 과정을 하기를 원한다고 생각했습니다. 나는 보스턴의 생의학 연구소에서 2년 동안 유전학 연구를 하며 일했으며, 그 삶이 나에게 맞지 않는다는 것을 깨달았습니다. 무엇을 하고 싶은지 혼란스러웠습니다. 내 인생의 모든 시간을 과학을 공부했기 때문에 이제는 연구 경로를 원하지 않았습니다.

그래서 나는 필라델피아에서 Teach for America에 참여했고, 거기서 교육 먼저 친구들과 고등학교 수학을 2년 동안 가르쳤습니다. 그것이 내가 반성하고 내가 해왔던 모든 것에서 한 발 물러설 수 있는 좋은 기회를 제공할 것이라고 생각했습니다. 내가 거기서 시간을 마친 후 나는 일자리를 찾기 시작했고, 구글에서 일하고 있는 내 친구에게 연락하여 그곳의 역할에 지원하도록 격려했습니다. 나는 구글에서 그들의 헬프 센터를 강화하는 데 매우 집중하고 있던 시점에 합류했습니다. Gmail은 비교적 새로운 제품이었지만 사용자 기반은 매우 빠르게 성장하고 있었습니다. 구글은 사람들이 지원을 받을 수 있는 전화번호나 이메일이 없었기 때문에, 우리는 사용자들이 스스로 도와주고 서로 도울 수 있는 헬프 센터를 구축하기 위한 전략을 세웠습니다.

나는 다양한 역할로 약 4년 동안 그렇게 했고, 인력 관리에 도전하고 싶어져서 구글의 아일랜드 더블린 사무소로 전근하여 여러 유럽 시장에서 커뮤니티 전략을 출범하는 데 도움을 주었습니다. 다시 말해, 우리가 사용자들이 서로 도울 수 있는 플랫폼을 제공할 수 있다면, 그들은 자신이 가지고 있는 질문에 대한 높은 품질의 답을 더 빠르게 얻을 수 있다고 생각했습니다.

나는 더블린에서 1년 동안 있어야 했지만 거의 4년 동안 머물렀습니다. 정말 좋았고, 매우 좋은 시간이었다고 생각합니다. 나는 다양한 문화의 사람들을 관리할 수 있었고, 나에게는 정말 멋진 새로운 경험이었습니다. 내가 그곳에 머물던 마지막 쯤에, 나는 회사가 매우 잘 운영되는 엔진처럼 느껴졌고, 내가 그 안에서 작은 부분만 맡고 있는 것 같아 예전 구글의 고군분투 시절을 그리워하기 시작했습니다.

나는 더 작은 회사로 눈을 돌리기 시작했고, 구글과 비슷한 문화를 가진 무언가를 원했습니다. 그래서 구글 벤처스 웹사이트를 살펴보며 구글이 투자하고 있는 회사를 찾았고 Lucid를 발견했습니다. 우리의 CEO인 Karl Sun은 사실 구글의 전 직원이기도 하며, 그와의 대화에서 내가 마음에 두었던 것은 #1, 사람들이 할 수 있는 훌륭한 일을 할 수 있도록 해주는 문화를 정말로 만들겠다는 그의 강조; 그리고 #2, 사람들이 소프트웨어를 통해 시각적으로 의사소통할 수 있도록 하는 플랫폼인 Lucidchart를 만드는 것에 대한 것입니다.

그것은 나에게 새로운 개념이었습니다. 우리는 시각적으로 의사소통하는 것이 무슨 의미인지 알고 있지만, 전통적으로는 회의, 메모 또는 스프레드시트와 같은 것에 의존하여 서로 소통해왔습니다. Lucid는 사람들이 브라우저에서 할 수 있는 범위를 밀어붙이기 시작하였고, 우리가 더 협업적으로 시각적으로 생각할 수 있도록 목표를 세웠습니다. 그래서 나는 회사의 사명에 정말로 끌리게 되었습니다.

내가 합류했을 때, 지원팀은 겨우 4명이었고, 주로 이메일 지원에 집중하고 있었습니다. 내게 주어진 임무는, 우리의 사용자 기반이 극도로 빠르게 성장하고 있었기 때문입니다. - 그것은 4년 또는 5년 연속으로 매년 두 배가 되었습니다 - 그러나 우리는 사용자들이 스스로 돕는 것으로 가장 좋고 빠른 답을 받을 수 있게 하는 것이 올바른 전략이라고 확신했습니다. 그래서 그것이 내가 맡은 일이었습니다.

와우, 구글 크기의 지원팀에서 Lucidchart의 4인 팀으로 이직하면서 정말 고군분투한 것 같네요!

확실히 그렇습니다.

Lucidchart에서 규모를 확장한 후, 최근 몇 년 동안 지원 팀의 인원을 10명으로 유지하고 티켓 발행량을 일정하게 유지해왔다고 들었습니다. 작은 팀을 유지하는 것이 귀하의 지원 전략에서 어떤 역할을 합니까?

내 전략은 사용자가 찾고 있는 것을 스스로 도울 수 있도록 측정할 수 있는 풍부한 콘텐츠를 제공하는 데 초점을 맞추고 있습니다. ATM을 예로 들어 설명하겠습니다: 정상적인 근무시간에 은행에 가면 이 질문에 직면하게 됩니다: 은행에 들어가서 대기하며 질문하겠습니까? 아니면 ATM에서 스스로 도와줄까요? 대개는 ATM입니다. 그리고 그 비유를 기술 세계에 적용하면, Lucidchart에서 우리는 매우 잘 작성된 헬프 센터 기사가 사용자들이 하고자 하는 90%에 대해 충분할 뿐만 아니라 실제로 선호된다고 생각합니다.

게다가 헬프 센터는 다양한 것들에 대한 수요를 측정할 수 있는 훌륭한 방법입니다. 수천 명의 사람들이 특정 주제에 관한 기사에 방문하고 있다는 사실을 보여줄 수 있다면, 그 정보를 엔지니어링 팀에 전달하여 실제 고객 데이터를 기반으로 한 변경 사항을 요구할 수 있습니다. 반면 사용자가 우리 지원 팀에 이메일을 제출할 때는 볼륨이 훨씬 낮아져서 우리가 엔지니어링 팀에 이를 제시할 때 데이터가 응용하기가 더 어려워집니다. 15명의 사용자가 특정 기능을 요청하는 이메일을 보냈을 때에도, 수천 명의 사용자가 그 기능과 관련된 헬프 센터 기사를 방문함으로써 그 사실을 보여줄 수 있습니다.

두 번째로는, 우리의 헬프 센터 콘텐츠가 이제 여섯 가지 언어로 현지화되었기 때문에, 팀에서 고품질 콘텐츠를 작성하는 데 드는 비용이 있습니다. 그래서 긴 꼬리 콘텐츠를 위해 사용자들이 자신의 콘텐츠를 제출할 수 있는 커뮤니티를 제공하고, 다른 사용자들이 그것을 활용할 수 있게 하고 있습니다. 내가 이 개념에 대한 예를 들자면, Lucidchart의 안드로이드 앱이 있고 실제로 수천 개의 다른 안드로이드 전화가 있습니다. 만약 사용자가 자신의 특정 전화가 우리 소프트웨어와 상호 작용하는 문제로 어려움을 겪고 있다면, 그 특정 전화를 구할 수 있는 가능성은 매우 낮습니다. 하지만 우리의 1500만 사용자는 아마 그 전화를 가지고 있으며, 그와 동일한 문제를 경험했을지도 모릅니다. 때때로 우리의 역할은 사용자들이 서로 연결되어 서로 도와줄 수 있도록 하는 것입니다.

그것은 정말 멋진 것을 볼 수 있습니다. 헬프 센터와 커뮤니티의 트래픽을 살펴보면, 실제로 사용자 기반 성장률을 초과했습니다. 그리고 당신이 언급한 것처럼, 지난 3년간 제품 지원 티켓 볼륨을 살펴보면 본질적으로 평형을 유지했습니다. 내게는 이것이 사용자들이 실제로 이 자기 도움 모델을 즐기고 이끌고 있다는 것을 의미합니다.

당신의 온라인 커뮤니티에 대해, 지식을 기여하고 다른 사용자를 도와주는 사람들은 어떤 종류의 사람들인지 알고 있나요? 당신의 제품에 대해 잘 모르는 사람들을 도와주기 위해 자신의 개인 시간에 대화를 나누는 사람을 생각하는 것은 멋진 개념입니다.

우리의 커뮤니티는 여전히 진화 중입니다 - 대개 사용자가 질문을 하면 우리가 커뮤니티에서 응답하지만, 다른 사용자들은 여전히 그 답변으로부터 혜택을 볼 수 있습니다. 하지만 점점 더 많은 다른 사용자들이 들어와서 답변을 제공하는 것을 볼 수 있습니다. 이것이 우리에게는 최상의 시나리오입니다.

당신의 질문에 답하기 위해, 세상에 사용자가 매우 열정적인 제품은 몇 개 없지만, Lucidchart와 같은 작업을 하게 된 것은 정말 운이 좋았습니다. 우리 제품이 사용자 요구에 정확히 맞지 않더라도, 때때로 미친 우회 과정을 거쳐 사용해야 할 때 조차도, 그들은 이를 선택합니다.

이 열정의 한 예로, 어떤 사용자 는 실제로 Lucidchart의 iPhone 앱을 일일 일정으로 설정한 것입니다. 이 사용 사례는 우리 팀이 제품을 위해 절대 상상하지 못했던 것이지만, 이 사용자에게 이유가 무엇이든 간에 우리 솔루션이 Google 및 Apple의 캘린더보다 훨씬 낫다고 결정했습니다.

그런 사고방식을 생각하면, 사용자가 하는 많은 일은 우리 제품의 한계를 팽창시키는 것입니다. 다른 사람들을 돕고 그들의 사용 사례를 공유함으로써, 그들의 열정을 자극합니다. 그들은 이 제품을 사랑하고, 그 열정을 다른 사람들과 나누고 싶어합니다.

정말 놀랍습니다. 귀하의 팀은 이러한 사용자 아이디어와 제출물에 어떻게 대응하고 있습니까?

우리 커뮤니티 내에는 다이어그램 공유하기;사용자들이 우리 제품을 사용하여 얻은 새롭고 창의적인 방법에 대해 듣고 싶습니다. 이것이 우리가 이러한 사용 사례에 대해 듣는 한 가지 방법입니다. 더 일반적인 방법은 우리가 여전히 이메일에 응답하는 데 매우 관여하고 있다는 것입니다. 티켓 볼륨이 일정하게 유지되고 있음에도 불구하고, 우리는 여전히 매주 대략 600개의 제품 관련 지원 이메일을 받습니다. 그런데 사용자가 우리에게 연락하여 "내가 하고자 하는 것이 이런 건데, 이 장애물에 부딪혔습니다. 제 문서를 살펴보시고 이 문제를 도와주실 수 있으세요?"라고 말합니다. 그들이 도움을 요청하는 문서의 경우, 대개는 우리의 템플릿을 매우 직관적으로 사용하는 경우가 많지만, 때로는 제품의 매우 혁신적인 사용 사례를 관찰할 수 있습니다. 그런 경우에는 그들에게 커뮤니티에 올릴 수 있는지 문의하기도 합니다. 종종 그들이 도움을 원하고 있는 문서는 우리의 템플릿을 간단히 사용하는 것이지만, 다른 경우에는 우리가 제품의 매우 혁신적인 사용 사례를 보게 되며, 그런 경우에는 다른 사용자들도 도움이 될 수 있도록 그들이 커뮤니티에 게시하는 것을 괜찮은지 물어보곤 합니다.

이런 방식으로 들어오는 혁신적인 아이디어는 다시 우리 제품에 반영되나요? 그 작업을 내부적으로 어떻게 공유합니까?

우리는 고객 성공 및 솔루션 엔지니어링 팀과 협력하여 모든 고객으로부터 들어오는 기능 요청을 종합한 고객의 목소리 보고서를 작성합니다. 템플릿 요청 경우에는 새로운 아이디어와 사용자 생성 아이디어를 제출하는 제품 템플릿 팀이 있습니다. 그 팀은 제출된 자료에 대해 자체 연구를 수행하고 공식 템플릿을 제품에 추가할 가능성을 평가합니다. 우리는 헬프 센터 내에 템플릿 갤러리를 보유하고 있으며, 일부 사용자 제작 콘텐츠가 거기에 포함되고 그런 방식으로 발견될 수 있습니다.

우리의 장기 비전은 헬프 센터와 커뮤니티 결합이 사람들이 무엇인가 잘못되었을 때만 가는 곳이 아니라 영감과 적극적 도움의 장소가 되는 것입니다. 우리는 사람들이 여전히 산업 전반에 걸쳐 일반적인 기준을 형성하고 있는 그 인식을 뛰어넘기를 원합니다.

당신이 구상하고 있는 두 방향 통로는 귀사와 고객 간의 관계를 의미합니다.

확실히 그렇습니다.

그렇게 되면 Lucid의 핵심 가치가 떠오릅니다: 자아보다 팀워크; 모든 일에 혁신; 개인의 권한, 주도, 책임; 그리고 모든 영역에서 열정과 탁월함. 상호 방향의 통로를 만든다는 것은 이 모든 것에 대해 이야기하고 있습니다. CX 접근 방식에서 이러한 핵심 가치를 어떻게 실천하고 있습니까?

우리는 이러한 핵심 가치를 회사 차원에서 세우고 있으며, 특히 고객과의 접점에 있는 측면에서 더욱 진실하게 다가올 수 있습니다. 이러한 핵심 가치는 매년 회사 킥오프에서, 그리고 회사 업데이트 때마다 강조하는 내용입니다. 매년 일회성 전체 행사에서 우리는 3일을 쉬고 Zion National Park 또는 Bear Lake에 가서 팀 빌딩을 하고 오는 해의 전략에 대해 집중하고, 처음 참석하는 신입 직원들에게도 다시 우리의 핵심 가치를 강조합니다.

정말 듣기 좋습니다. 우리도 Guru에서 하는 모든 일에서 핵심 가치를 실천하려고 노력합니다.

그렇다면 귀하의 팀은 적극적인 고객 교육을 어떻게 접근하고 있습니까? CX 팀의 반응적 측면과 능동적 측면의 구분은 어떻게 됩니까?

반응적인 측면부터 시작하는 것이 좋겠다고 생각합니다. 사용자가 제품에서 무엇을 하고 싶은지 아는 경우 그들이 우리의 헬프 센터나 커뮤니티에 와서 그것을 알아내려고 할 경우, 우리는 그들에게 필요한 콘텐츠를 제공하며, 종종 비디오와 스크린샷을 추가하여 성공적인 설정을 도와줍니다.

우리가 움직이려는 모델은 사용자에게 무언가를 할 수 있는 방법을 알려주는 것이 아니라, 그 방법을 해야 하는 이유를 설명하는 것입니다. 사용자가 우리 헬프 센터를 방문하고 다른 수단과 신호를 통해 생물학 선생님임을 알게 되었다고 가정해 보십시오. 우리는 그 선생님에게 그들이 원하는 것을 하는 방법에 대한 단계별 지침을 보여줄 뿐만 아니라, 그렇게 하는 데 사용할 템플릿을 제시하고 싶습니다. 우리의 전문 팀, 이 예제에서는 교육 팀이, 더 나은 정보 제공을 위해 사용 사례를 제공하는 작업을 수행하고 있습니다.

따라서 고객이 특정 기능을 사용하는 방법을 읽고 있다면, 우리는 그 기능을 사용한 다른 사용자로부터 일부 제품 신호를 캡처하여 고객에게 해당 정보를 제공하고, 유사한 사용자가 작업한 다른 기능과도 연결하여 제공합니다. 그래서 우리는 그 개념을 헬프 센터로 가져가, "좋아요, 방금 프레젠테이션에 대한 기사를 읽었는데, 이제 레이어와 레이어를 보여주고 숨기는 방법에 대한 기사를 읽어야 합니다. 이 두 기능은 제품에서 함께 작동하기 때문입니다."라고 말합니다. 이제 여러분은 레이어와 다양한 레이어의 표시 및 숨기기에 대한 이 기사를 읽어야 합니다. 우리는 이 두 가지 기능이 제품에서 함께 간다는 것을 알고 있습니다. 이것이 우리가 추구하는 목표의 일부입니다.

그렇다면 이 전략을 목표로 어떻게 공식화합니까? 귀하의 목표는 티켓 볼륨을 일정하게 유지하고 첫 응답 시간을 줄이는 것만 넘어서고 있는 것 같습니다.

우리 지원 메트릭의 "홀리 그레일"은 사용자가 헬프 센터에서 하는 것과, 그 후 제품에서 하는 것을 연결하는 것입니다. 어떤 기사를 보든, 예를 들어 데이터 연결에 관한 기사가 있을 때, 우리는 다음과 같은 목표를 세우고 싶습니다: 그 기사를 읽은 1000명의 사용자 중 700명이 데이터 연결 기능을 사용하기 위해 제품으로 들어갑니다. 최근에는 헬프 센터의 사용량을 제품 사용량과 연결 짓는 데 성공했습니다. 그래서 우리는 거기서 추론할 수 있고, 헬프 센터와 제품 사용 사이의 상관관계를 파악할 수 있습니다.

그것이 우리가 달성하려는 목표의 핵심이라고 생각합니다: 우리의 제품 사용을 증가시키는 것입니다. 그리고 사용자 유지율에 가치를 부여할 수 있게 되는 것입니다. 그렇다면 우리는 헬프 센터를 방문한 1000명의 사용자와 방문하지 않은 사용자 1000명을 비교하여, 우리의 유지율이 이 비율만큼 올라갔다고 결론을 내릴 수 있습니다. 또한 유지율만 고려하지 않고 그들의 참여율이 이만큼 증가했는지도 확인할 수 있습니다.

정말 사랑합니다. 최근에 여러 CX 리더와 대화해 보았습니다 그리고 지원이 비용 센터보다는 수익 창출원이 된다는 주제가 계속해서 언급되고 있습니다. 여러분도 지원이 비용을 발생시키는 것보다는 수익을 창출할 수 있다는 모델에 동의하시나요?

물론입니다. 하지만 저희 팀은 그 이상으로 나아갑니다. 대부분의 경우, 사용자가 저희에게 연락을 하곤 합니다. 그들은 "안녕하세요, Lucidchart를 사용하는 것에 만족하지만, 문서 가져오기 문제를 겪고 있습니다."라고 말합니다. 저희가 가져온 문서들이 이상하게 보입니다. 이 문제를 해결할 수 있다면, 저희는 회사에서 Lucidchart의 사용을 확장할 수 있을 것입니다.” 그래서 저희는 지원 문제를 도와드리고, 이를 저희 영업팀에게 넘깁니다.

“작년에는 지원이 실제로 회사에서 세 번째로 큰 판매 리드의 출처였습니다. 이 지원 채널을 통해 들어오는 수익이 팀에 지급되는 급여를 훨씬 초과합니다. 그래서 저희는 전혀 비용 센터가 아닙니다.”

정말 놀라운 일입니다! 여러분의 팀이 추적하는 다른 지표는 무엇인가요? 여러분의 모델을 존경하는 다른 지원 리더에게 추천하고 싶은 지표는 어떤 것이 있나요?

저희가 자랑하는 것 중 하나는 헬프 센터와 커뮤니티 사이트가 얼마나 빠르게 성장하고 있는지입니다 – 저희가 스케일 지원이라고 부르는 것에 비해, 일대일 지원은 이메일, 전화 통화, 채팅 지원입니다.

일대일 지원의 성장을 측정하는 한 가지 방법은 사용자 기반당 이메일 수를 보는 것입니다. 그래서 저희는 사용자 기반이 얼마나 빠르게 성장하고 있는지 추적하고, 각 지원 플랫폼이 얼마나 빨리 성장하고 있는지를 추적하며, 그 후 하나를 다른 것과 정규화하여 10,000활성 사용자당 발송된 이메일 수를 파악합니다. 그리고 대조적으로, 저희가 제품의 10,000활성 사용자당 얼마나 많은 헬프 센터 페이지 조회수를 받고 있는지도 살펴봅니다.

저는 일대일 지원 측면을 살펴보면, 그건 더 전통적입니다: 저희는 첫 번째 응답 시간, 고객 만족도, 그리고 고객이 더 많은 정보를 제공할 때까지 기다리는 시간을 제외한 해결까지 걸리는 시간을 포함한 사용자 대기 시간을 살펴봅니다.

저희가 스케일 지원을 살펴보면, 일대일 지원과는 조금 다릅니다. 그래서 스케일 지원을 사용하는 사용자들 중 – 헬프 센터인지 아니면 커뮤니티인지 – 그들은 제품에서 무엇을 하고 있는지 살펴봅니다? 그들의 7일 유지율과 30일 유지율, 그리고 헬프 센터를 사용하지 않는 사람들의 유지율은 어떤가요? 그런 다음 저희는 이것을 수익에도 연결할 수 있습니다. 헬프 센터를 방문하는 사람들은 더 업그레이드 하는 경향이 있나요? 그들은 자신의 계정에서 사용자 수를 확장하는 경향이 있나요? 저는 그것들이 우리가 추적해온 주요 지표들이라고 말할 것입니다. 그러나 이는 여전히 진행 중인 작업입니다.

여러분은 이전에 헬프 센터의 특정 기사가 얼마나 자주 사용되는지 파고드는 것에 대해 언급하셨고, 그 데이터가 향후 제품 결정에 영향을 미칠 수 있습니다. 이것은 저희가 Guru에서 하는 일과 관련이 있습니다 지식에 관한 것이며, 당신은 헬프 센터를 통해 수집된 데이터와 지식이 여러분의 전략에 어떻게 적용된다고 생각하나요?

정말 좋은 질문입니다. 저희는 항상 일대일 지원이 저희의 스케일 지원에 정보를 제공한다고 말합니다. 저희가 커뮤니티에서 어떤 문제가 발생하고 있는지 보게 되면 사용자들이 어떤 것을 알고 싶어 하는지 포스팅을 하실 경우, 그게 많은 페이지 조회수를 얻고 있다면, 저희는 그것을 실제 헬프 센터 기사로 업그레이드하고 더 많은 트래픽을 유도하기 위해 로컬화할 것입니다. 그리고, 제가 티켓 볼륨을 살펴보면, 같은 주장을 할 수 있습니다. 저희가 제품에서 어떻게 하는지에 대해 많은 이메일이 오는 경우, 저희는 그 이메일들을 살펴보고, “좋아요, 이것이 커뮤니티 포스트로 더 합리적이거나 헬프 센터 기사로 더 의미가 있나요?” 라고 생각할 것입니다. 그래서 이 일종의 졸업 과정이 있습니다. 만약 저희가 어떤 문제에 관해 많은 이메일을 받는다면, 그것은 커뮤니티 포스트로 졸업하고, 그 후 그것이 많은 트래픽을 받으면 헬프 센터 기사로 졸업합니다. 그런 다음, 저희는 우리가 하고 있는 것의 성공을 측정할 수 있습니다.

그리고 나면, 우리가 하고 있는 것의 성공을 측정할 수 있습니다. 그래서 저희가 이 헬프 센터 기사를 생성한 후, 저희는 그런 유형의 티켓이 줄어들었는지 확인할 수 있습니다. 왜냐하면 이제 저희가 스케일 지원에 더 많은 트래픽을 유도하고 있기 때문입니다.

마지막으로 페이지 조회수에 관한 부분입니다. 저희에게는 페이지 조회수가 이메일 볼륨을 대신할 수 있습니다. 만약 저희가 기능 요청인 커뮤니티 포스트를 받으면, 저희는 그 커뮤니티 포스트의 참여 및 페이지 조회수를 보여줄 수 있고, 그 데이터를 엔지니어링 팀에 전달하여 "이것에 대한 수요가 있습니다."라고 말할 수 있습니다. “이것을 제품 로드맵에 추가합시다.”

여러분의 조직을 여러분처럼 확장하고자 하는 지원 리더들에게 마지막으로 조언할 것이 있나요?

저의 다른 조언은 최고의 인재를 채용하고 유지하는 방법에 관한 것입니다. 많은 지원 조직은 이직률이 꽤 낮다는 큰 문제를 겪고 있습니다. 저희가 성공할 수 있었던 한 가지 이유는 저희 팀의 유지율이 매우 높기 때문입니다. 지난 18개월 동안, 저의 팀에서 단 한 명의 구성원만이 떠났고, 이는 이 분야에서는 유례가 없는 일입니다. 그리고 지난 3년 반 동안 저의 팀을 떠난 individuals는 모두 Lucid 내에 남아 다른 부서로 이동하면서 그들이 습득한 사용자 통찰력을 회사 다른 부서로 가져갔습니다. 하지만 저는 지원팀의 사람들에게 최상급 전략에 대한 소유권을 가질 수 있도록 권한을 부여하는 것이 중요하다고 생각합니다. 단순히 이메일을 정리하거나 전화 통화를 처리하는 것이 아니라, 이것이 그들에게 힘을 주고 그들이 다른 역할로 이전할 수 있는 기술을 구축하는 데 도움이 됩니다.

그것이 제가 시간을 두고 다시 강조하고 싶은 부분입니다: 가능한 한 많은 전략에 팀을 포함시키십시오. 궁극적으로 그것이 그들을 흥미롭고 열정적인 상태로 유지하며 성장하게 할 것입니다.

정말 훌륭한 방식으로 마무리하겠습니다. 시간 내 주셔서 정말 감사합니다, Keyvan! 혹시 독자들이 여러분의 지원 철학이나 Lucidchart에 대해 질문할 게 있다면 어떻게 연락할 수 있을까요?

저와 LinkedIn에서 연결하실 수 있습니다.