Contents
♥️ CX팀과 개발팀, 함께 일하는 중입니다!✅ 오버커뮤니케이션 - 결국 우리는 같은 팀이에요.🔍 최대한 많은 단서를 제공해드리자!🧐 해결 여부뿐만 아니라, 원인과 영향 범위까지 알고 싶어요.📌 이슈 보드는 우리의 무기!✅ 배려 - 결국 우리는 같은 팀이에요.🕛 개발팀에겐 버그를 잡기 위한 시간이 필요해요.👀 CX매니저 앞에는 고객이 앉아 있어요.🎯 실제로 협업한 사례들을 소개드려요고객 통합 뷰 만들기 - 고객보다 한 발 먼저 고민하기유저 테스트 – 고객은 예상대로 움직이지 않아요세일즈 상담 – 개발팀이 설명해주면 CX팀은 더 똑똑해진다!고객 권리보호 – 리스크는 사전에 잡아야 해요.글을 마치며"35회"
오늘 하루 CX팀이 멘션된 횟수예요. 팀스파르타에서 CX팀은 다양한 이해 관계자와 소통하죠.
고객 분들과 소통할 뿐만 아니라, 신규 기능을 배포하려는 PM, 고객 반응이 궁금한 마케터, VOC(Voice of Customer)를 알고 싶은 디자이너까지 저희를 찾곤 합니다.
CX팀이 조직 내에서 점점 더 중요한 역할을 맡게 되면서, 우리는 다양한 이해 관계자들과 어떻게 소통하고 협업 하는지 기록하기 시작했어요.
팀스파르타에서 협업을 가장 원활하게 할 수 있는 방식을 찾아가는 과정에 함께해 보시죠! 🤗
♥️ CX팀과 개발팀, 함께 일하는 중입니다!
CX팀과 개발팀 모두 더 나은 고객 경험을 위해 일하지만, 일하는 방식은 완전 달라요.
CX팀은 고객과 직접 대화하면서 문제를 발견하고, 개발팀은 이를 해결하기 위한 기술적인 접근을 하는 것이죠.
보통 제품 개선 요청은 PM을 통해 티켓이 발행되기 때문에, CX팀이 직접 개발팀을 찾아갈 일은 많지 않아요. 하지만 긴급한 이슈가 터지면? 이야기가 달라지죠.
긴급한 이슈가 발생하여 CX매니저가 개발팀 쪽으로 다가가는 순간,
개발팀: "전가요?" (살짝 긴장)
CX팀: "아... 맞아요!" (미안하지만 급해요 😅)
어쩌겠어요. 우리는 각자의 역할에 충실할 뿐입니다.
우리는 문제를 찾고, 개발팀은 그 문제를 해결하고. 결국 더 좋은 제품을 만들기 위해 같은 목표를 향해 가고 있는거죠.
그렇다면 이제 문제는, 이 두 팀이 어떻게 하면 더 잘 협업할 수 있을까? 가 되어야겠죠.
밤낮 가리지 않고 고민한 끝에 우리 팀이 찾은 핵심 포인트는 두 가지였어요.
✅ 오버커뮤니케이션 - 서로의 관점을 맞추는 과정
✅ 배려 - 협업의 기본
아래에서 자세하게 소개 드려볼게요!
✅ 오버커뮤니케이션 - 결국 우리는 같은 팀이에요.
CX팀과 개발팀은 각자의 역할과 관점이 다르다고 할 수 있어요,
CX는 최전선에서 고객과 소통하고, 개발팀은 제품의 가장 뒷 단을 담당하는 역할을 맡죠.
따라서 원활한 협업을 위해서는 서로의 배경 지식을 공유하는 것이 필수적이에요.
그래서 저희는 오버커뮤니케이션을 하는 걸 원칙으로 삼고 있어요.
커뮤니케이션할 때 "이 정도면 됐겠지?"가 아니라,
"이것도 공유하면 도움이 되겠지!"라는 마인드로 접근하는 거죠.
이러한 오버커뮤니케이션을 실천하기 위해 우리 팀이 지키는 몇 가지 원칙이 있어요.
아래에서 함께 살펴볼까요?
🔍 최대한 많은 단서를 제공해드리자!
저희는 개발팀이 원활하게 디버깅할 수 있도록 최대한 많은 단서를 제공하고자 해요.
개발팀이 버그를 해결하려면 최대한 많은 정보가 필요하기 때문이죠.
저희는 특히,
1️⃣ 어떤 상황에서(조건)
2️⃣ 어떤 액션을 했을 때(트리거)
3️⃣ 어떤 문제가 발생하는지(결과)
를 명확하게 전달함으로써 빠르고 정확한 해결을 돕고자 노력합니다.
특히 버그가 의심되는 문의가 들어오면 아래 정보를 꼼꼼하게 수집해요.
• 기기 및 브라우저 정보 (아이폰인지 안드로이드인지, 크롬인지 사파리인지)
• 진입 경로 및 수행한 액션 (어떤 화면에서, 어떤 버튼을 눌렀는지)
• 에러 메시지 및 스크린샷 (영상이 있으면 제일 좋아요)
만약 동일한 이슈가 여러 고객에게 발생하는 경우도 있는데요, 이러한 경우에는 CX팀이 유저 정보를 정리해서 공통점이나 패턴을 분석한 후 개발팀에 공유드려요. 이런 과정을 거치면서 CX팀도 자연스럽게 프로덕트에 대한 이해도가 점점 깊어지는 것 같아요.
"어? 이거 저번에도 비슷한 거 있었는데?"
"이 경우라면 아마 저 설정이 문제일 수도?"
이제 CX팀도 문제를 보면 대충 감이 오기 시작하죠.
이런 게 바로 경험치가 쌓인다는 거 아닐까요? 😉
🧐 해결 여부뿐만 아니라, 원인과 영향 범위까지 알고 싶어요.
이슈가 생기면, 당연히 해결하는 게 1순위겠죠?
그런데 팀스파르타의 CX팀은 해결을 끝이라고 생각하지 않아요.
근본적인 원인을 찾아야 ‘진짜 해결’이 된 거죠.
이슈는 고객 경험을 해치는 요인이라고 생각해요.
재발 가능성을 최소화하려면 이슈의 근본적인 원인을 파악하고 확실하게 해결해야 합니다.
작은 이슈 같아 보여도 막상 파보면 예상 못 한 원인과 연결된 경우가 많기 때문이죠.
그래서 우리는 "이슈 발생 배경"을 질문하는 걸 원칙으로 삼았어요.
💡 왜 이런 문제가 발생했는지?
💡 앞으로 같은 문제가 또 생길 가능성이 있는지?
💡 이게 다른 기능에도 영향을 줄 수 있는지?
원인을 알게 되면 더 명확하게 이해하고, 근본적인 대응책을 제안할 수 있겠죠?
물론, 개발팀이 한창 해결하는 중일 때는 좋은 타이밍이 아니겠죠.
해결이 완료된 후, 적절한 순간을 기다렸다가 집요하게 질문합니다. 😉
📌 이슈 보드는 우리의 무기!
이슈를 해결하고 나면, 우리는 그냥 넘어가지 않아요. 이슈보드에 다음 내용을 꼼꼼하게 정리해둡니다.
• 이슈 현상 (뭐가 문제였는지?)
• 발생 원인 (왜 이런 일이 생겼는지?)
• 임시 대응 & 근본 대응 (지금 해결한 방법 & 앞으로 완전히 없앨 방법)
이렇게 정리해두면 비슷한 이슈가 다시 생겼을 때, 바로 히스토리를 소환해서 빠르게 해결할 수 있어요.
이렇게 이슈 제보를 하고 해결-정보를 공유 받는 협업 과정에서 제품에 대한 이해도가 많이 높아지기도 한답니다.
✅ 배려 - 결국 우리는 같은 팀이에요.
🕛 개발팀에겐 버그를 잡기 위한 시간이 필요해요.
버그를 수정하는 과정은 단순하지 않아요.
어디서 왜, 뭐 때문에 발생한 문제인지 파악하고 해결하는 데는 시간이 걸리죠, CX팀은 개발팀이 이슈를 해결할 때까지 시간을 벌어주어야 합니다.
고객에게 불편함에 대한 충분한 공감과 사과, 지금 어떤 상황인지, 그래서 어떻게 조치할 예정인지, 언제 쯤 해결을 예상하는지를 공유함으로써 고객과 진심으로 소통하고, 문제 해결을 위한 시간을 확보하는 것이죠.
👀 CX매니저 앞에는 고객이 앉아 있어요.
우리의 키보드 앞에는 실제 고객이 앉아있어요. 어떤 문제가 생겨서 답답한 마음으로 우리를 찾아온 고객이죠. 하지만 고객은 우리가 어떻게 문제를 해결하고 있는지, 언제 쯤 해결될지 알 수 없어요. 기다림이 길어지면 답답함은 커지고, 점점 불안해지죠.
그래서 CX매니저는 고객 경험을 해치지 않기 위해 충분한 맥락을 공유하는 것을 중요하게 생각해요. 현재 상황을 설명하고, 어떤 조치를 취하고 있는지, 언제 쯤 해결될지 안내하면 고객도 안심할 수 있거든요.
혹시 개발자 분들이 이 글을 보고 있다면, CX매니저가 "혹시 언제 쯤 해결될까요?" 라고 물을 때 그걸 단순한 재촉으로 받아들이지 않아주셨으면 해요. CX팀도 고객과 개발팀 사이에서 최대한 시간을 벌어드리기 위해, 해결 과정을 원활하게 만들기 위해 노력하는 중이거든요.
우리는 이렇게 시간을 벌어주고, 시간을 예측해주는 방식으로 서로를 배려하며 일하고 있습니다. ♥️
🎯 실제로 협업한 사례들을 소개드려요
지금까지 이슈를 해결하는 과정에서 CX팀과 개발팀이 어떻게 협업하는지, 그리고 CX팀이 중요하게 생각하는 원칙이 무엇인지에 대해 이야기해봤어요. 하지만! 우리가 함께하는 일이 이슈 해결만 있는 건 아니죠.
CX팀과 개발팀은 더 나은 고객 경험을 만들기 위해 다양한 프로젝트에서도 긴밀하게 협업하고 있어요.
아래에서 우리가 실제로 진행했던 몇 가지 프로젝트를 소개해드릴게요!
고객 통합 뷰 만들기 - 고객보다 한 발 먼저 고민하기
상담을 하러 온 고객에게, 그동안의 히스토리를 다 파악하고 있는 상담사가 맞이한다면 어떨까요? 🤔
여러 면에서 고객은 감동을 받을 수밖에 없어요. 소위 “개떡같이 말해도 찰떡같이 알아듣는다” 라는 환상적인 티키타카가 가능해지고, 고객이 어떤 불편을 겪었을지 바로 캐치해서 해결까지 걸리는 시간도 확 단축될 수 있어요. ☺️
이런 경험을 만들기 위해, 우리는 고객 통합 뷰를 구축했어요.
어드민에서 고객 정보, 결제 내역, 대고객 메시지(문자, 알림톡, 메일 등), 상담 내역, 케어 기록까지 한 번에 확인할 수 있도록 정리했죠.
개발팀이 CX팀이 더 빠르고 정확하게 고객을 파악할 수 있는 기반을 제공해준 덕분에,
CX매니저는 제품 이슈를 더 꼼꼼하게 제보하고, 리스크 검토도 훨씬 수월하게 할 수 있게 되었어요.
유저 테스트 – 고객은 예상대로 움직이지 않아요
복잡도가 높은 기능이나 서비스를 배포하기 전에, 개발팀에서 CX팀에 유저사이드 QA를 요청하는 경우가 종종 있어요.
이때 CX매니저는 우리가 잘 아는 고객들의 행동 패턴을 바탕으로 테스트를 진행하게 되죠. 왜냐하면, 사용자는 기획자나 개발자의 예상대로만 행동하지 않거든요.
오랫동안 고객과 대화해온 CX매니저, 그리고 버그 히스토리를 누구보다 강렬하게 기억하고 있는(!) CX매니저가 테스트를 하면, 생각지도 못한 엣지 케이스를 기가 막히게 찾아내는 경우가 많아요. 덕분에 배포 전에 미처 발견하지 못했던 문제들을 먼저 잡아낼 수 있고, 결과적으로 더 안정적인 서비스 제공이 가능해지는 거죠.
세일즈 상담 – 개발팀이 설명해주면 CX팀은 더 똑똑해진다!
우리는 IT 교육 서비스를 제공하다 보니, 판매하는 제품(교육 콘텐츠)에 대해 더 깊이 이해해야 할 때가 있어요. 보통은 콘텐츠 제작팀과 소통하지만, 가끔은 개발팀을 찾아가야 할 때도 있죠.
팀스파르타의 개발팀분들은 배경지식이 없는 동료들에게도 쉽게, 재미있게 설명하는 능력자들이에요. 비유를 기가 막히게 들어주셔서, 듣다 보면 "아~!" 하고 무릎을 탁 치게 되죠.
게다가 이미 CX팀과 여러 번 협업해 온 덕분에, 고객이 이해하기 쉬운 방식으로 풀어 설명해 주시기도 해요.
그럴 때 마다 CX매니저는 개발자 분들께 감사한 마음을 담아
주로 간식을 드리곤 합니다 🍪
고객 권리보호 – 리스크는 사전에 잡아야 해요.
예민한 시각과 촉을 가진 우리 CX 매니저들은 리스크에도 굉장히 민감합니다.
고객 권리와 연관된 리스크의 싹이라도 보이면 털이 쭈삣 서는 것을 느끼며 바로 예방 조치를 고민하게 되는데요, 이 부분은 자연스럽게 보안 면에서 개발팀에게도 도움을 주기도 합니다.
작은 문제 같아 보여도 깊이 파보면 더 큰 리스크로 이어질 수 있기 때문에, CX팀은 미리 감지하고 빠르게 대응하는 것을 가장 중요하다고 믿습니다.
글을 마치며
CX팀과 개발팀은 결국 같은 목표를 가지고 있어요.
더 좋은 제품을 만들고, 고객 경험을 향상시키는 것.
서로의 관점을 이해하고, 적극적으로 소통하고, 배려하며 협업하면 결과도 좋아지고, 일하는 과정도 훨씬 매끄러워져요. 앞으로도 CX팀과 개발팀은 더 나은 협업 방식을 찾아갈 예정이에요.
(그리고 간식은 계속 제공될 거예요. 🍪)
"우리, 앞으로도 잘 부탁해요!"
Share article
Subscribe to our newsletter
