월요일 오전 9시, CS팀 김주원 팀장의 하루는 이렇게 시작됩니다.
메신저 채널에는 어젯밤 고객이 남긴 “결제가 안 돼요” 문의가 세 건 쌓여 있습니다.
이메일함을 열어보니 같은 고객이 새벽에도 같은 내용을 보냈습니다.
하지만 채널이 다르다는 이유만으로 같은 고객인지 알 수 없었고, 신입 상담원은 이미 메신저로 답변을 보낸 상태입니다. 대표번호로 걸려온 전화는 옆자리 동료가 급하게 받아 메모지에 적어두고 퇴근했다고 하는데, 메모가 어디에 있는지 도저히 찾지 못하겠습니다.
오후에는 고객 문의 현황을 업데이트하려고 고객문의_전체관리_최종.xlsx를 열려는데 파일이 열리지 않습니다.
팀 공유 폴더에는 이름만 다른 엑셀 파일이 네개나 있고, 어느 파일이 최신인지 아무도 확신하지 못합니다. 파일을 하나하나 열어보고, 업데이트 이력을 비교하며 데이터를 확인합니다. 지난주 퇴사한 상담원이 관리하던 시트는 이미 함께 사라진 상태입니다. 일단 급한 불을 끄자는 마음으로 우선 개발팀에 묻습니다.
“결제 오류, 지난달에도 똑같은 문의 들어오지 않았어요?”
돌아오는 대답은 늘 같습니다.
“저희 쪽에는 그런 기록이 없는데요.”
같은 문제를 고객도 세 번째 설명하고, CS도 세 번째 설명하고, 개발팀도 세 번째 설명하는데 늘 새롭습니다.
이 이야기는 특정 회사만의 사례가 아닙니다. 채널은 계속 늘어나는데 기록은 흩어지고, 담당자는 바뀌는데 맥락은 이어지지 않습니다. 많은 CS 조직이 매주 월요일처럼 반복해서 겪는 현실입니다.
많은 조직은 고객 지원을 위해 메신저, 이메일, 전화, 엑셀 같은 여러 도구를 조합해 운영하곤 합니다. 조직이 작을 때는 크게 문제가 되지 않습니다. 하지만 고객이 늘고, 상담원이 늘고, 문의 채널이 늘어날수록 정보는 여러 곳으로 흩어지기 시작합니다.
고객은 같은 내용을 여러 번 설명해야 하고,
상담원은 이전 이력을 찾느라 시간을 쓰며,
개발팀은 같은 장애가 반복되는지 알지 못하고,
관리자는 고객 만족도나 반복 문의를 제대로 분석하기 어렵다.
결국 사람들의 업무 방식이 문제가 아니라, 고객 지원을 위한 시스템 자체가 없는 것이 근본 원인입니다.
여러분은 Atlassian을 생각하면 어떤 제품이 제일 먼저 떠오르시나요?
보통은 Jira와 Confluence, 그리고 Jira Service Management(JSM)를 떠올리실 겁니다.
그러면 자연스럽게 이런 질문이 생깁니다.
“JSM도 고객 포털을 제공하는데 왜 굳이 CSM(Customer Service Management)을 새로 만든 걸까?”
답은 간단합니다. JSM과 CSM은 처음부터 해결하려는 문제가 다르기 때문입니다. JSM은 조직 안에서 발생하는 서비스 요청을 관리하기 위해 만들어졌습니다.
예를 들어
- 노트북이 고장 났다.
- VPN 접속이 안 된다.
- 신규 계정을 만들어 달라.
- SAP 권한을 신청하고 싶다.
즉, 같은 IT 서비스 관리(ITSM)가 핵심입니다.
반면 CSM은 조직 밖의 고객 경험(Customer Experience)을 중심으로 설계되었습니다.
둘 다 SR(Service Request/Ticket)을 사용하지만, 중요하게 생각하는 것도 다릅니다.
| 구분 | JSM | CSM |
| 주요 대상 | 내부 직원, 비즈니스 팀 | 외부 고객 |
| 목적 | 안정적인 내부 서비스 제공 | 일관된 고객 지원 경험 |
| 대표 기능 | Incident, Problem, Change, Asset | 고객 프로필, 옴니채널 상담, AI Agent |
즉 Atlassian은 JSM을 대체하기 위해 CSM을 만든 것이 아닙니다.
ITSM만으로는 해결하기 어려운 외부 고객 지원이라는 영역을 위해 별도의 제품을 만든 것입니다.
사실 JSM만으로도 고객 지원은 가능합니다. 실제로 많은 기업이 외부 고객에게 JSM 포털을 개방해 문의를 받고 있습니다. 하지만 고객 지원 조직이 커질수록 필요한 것은 단순한 티켓 관리가 아닙니다. 고객은 이메일뿐 아니라 웹 지원 사이트, 인앱 채팅, 전화 등 다양한 채널을 이용합니다. 상담원은 고객이 지난달 어떤 문의를 했는지 알고 싶고, 관리자는 반복 문의와 고객 만족도를 분석하고 싶으며, 개발팀은 동일한 문제가 얼마나 반복되는지 확인하고 싶습니다. 즉 고객 지원에서는 티켓보다 고객이 중심이 됩니다. CSM은 이러한 고객 중심(Customer-centric) 지원 경험을 제공하기 위해 설계된 제품입니다.
고객은 자신이 편한 채널로 문의하기 마련입니다. 하지만 회사는 채널마다 서로 다른 문의처럼 관리합니다. 그 결과 고객은 같은 내용을 반복해서 설명하고, 상담원은 중복 대응을 하게 됩니다. CSM은 이메일, 웹 지원 사이트, 인앱 채팅, 전화 등 다양한 고객 접점을 하나의 고객 컨텍스트 안에서 관리할 수 있도록 설계되었습니다. AI Agent가 상담을 시작하더라도 필요하면 상담원에게 이전 대화와 함께 자연스럽게 이어질 수 있어 고객이 같은 설명을 반복해야 하는 상황을 줄여줍니다.
※ 메신저는 기본 제공 채널이 아니며, 필요한 경우 별도 연동을 통해 사용할 수 있습니다.
‘최종.xlsx’가 다섯 개 생기는 이유는 엑셀을 잘못 써서가 아닙니다. 고객 정보를 중앙에서 관리하는 시스템이 없기 때문입니다. CSM은 고객 프로필, 티켓, 상담 이력, 조직 정보 등을 하나의 플랫폼에서 관리합니다. 담당자가 변경되거나 퇴사해도 기록은 시스템에 남기 때문에 특정 개인에게 업무가 종속되지 않습니다.
CS팀은 반복되는 결제 오류를 체감하지만, 개발팀은 관련 이슈를 인지하지 못합니다. 각자 다른 시스템에서 일하고 있기 때문입니다. CSM은 Atlassian Platform 위에서 동작하며 Jira와 자연스럽게 연결됩니다. 고객 문의를 Jira 프로젝트와 연계하고, 진행 중인 버그나 기능 요청, 인시던트와 함께 맥락을 공유하면서 협업할 수 있습니다. 여기에 Atlassian의 Teamwork Graph가 더해진다면 어떨까요? Teamwork Graph는 Jira 이슈, Confluence 문서, 고객 프로필, 지식베이스, 인시던트, 기능 요청 등 플랫폼 전반의 관계를 연결해 AI와 상담원이 필요한 정보를 맥락(Context)과 함께 활용할 수 있도록 돕습니다. 결국 CS와 개발팀은 서로 다른 정보를 보는 것이 아니라 하나의 맥락을 공유하게 됩니다.
이런 반복적인 문의까지 상담원이 직접 처리하면 정작 복잡한 고객 문제를 해결할 시간이 부족해집니다. CSM은 AI Agent가 지식베이스와 고객 정보를 활용해 반복 문의를 먼저 응답하고, 해결하지 못한 경우에는 지금까지의 대화 내용을 그대로 상담원에게 전달할 수 있습니다.
덕분에 상담원은 같은 질문을 다시 하지 않아도 되고, 더 복잡한 문제 해결에 집중할 수 있습니다.
Zendesk, Intercom, Salesforce Service Cloud처럼 이미 훌륭한 고객 지원 솔루션은 많습니다.
Atlassian CSM의 차별점은 단순히 또 하나의 헬프 데스크를 만드는 것이 아닙니다. 이미 사용 중인 Atlassian 플랫폼과 자연스럽게 연결된다는 점입니다.
고객 문의는 Jira 프로젝트와 연결되고, 관련 문서는 Confluence에서 함께 참고하며,
AI는 Teamwork Graph를 기반으로 Jira 이슈, 고객 이력, 지식베이스, 인시던트 등 여러 제품에 흩어진 정보를 함께 활용합니다.
즉, 고객 지원이 개발과 운영, 문서화와 분리된 별도의 시스템이 아니라 하나의 협업 플랫폼 안에서 이어지는 것입니다. 이미 Jira와 Confluence를 사용하고 있는 조직이라면, 별도의 고객 지원 솔루션을 도입하기보다 기존 Atlassian 생태계를 확장하는 방식이라는 점이 가장 큰 장점입니다.
다음과 같은 조직이라면 CSM 도입을 검토해볼 만합니다.
반대로 고객 문의량이 많지 않고 이메일만으로도 충분한 조직이라면 JSM이나 기존 운영 방식만으로도 충분할 수 있습니다.
또한 CSM은 비교적 새로운 제품인 만큼 일부 기능은 아직 성숙해 가는 단계에 있습니다. 따라서 조직 전체를 한 번에 전환하기보다는 파일럿 프로젝트를 통해 적합성을 검증한 뒤 점진적으로 확대하는 접근이 현실적입니다.
만약 김주원 팀장에게 CSM이 있었다면 어땠을까요? 월요일의 풍경은 조금 달랐을 것입니다.
여러 채널에서 들어온 문의는 하나의 고객 맥락으로 연결되고, 퇴사한 상담원의 기록은 시스템에 그대로 남아 있으며, 반복되는 결제 오류는 개발팀과 같은 데이터를 기반으로 논의할 수 있었을 것입니다.
Atlassian이 CSM을 만든 이유도 여기에 있습니다.
JSM이 조직 내부의 안정적인 서비스 운영을 위한 제품이라면, CSM은 조직 밖의 고객에게 일관된 서비스 경험을 제공하기 위한 제품입니다.
두 제품은 경쟁 관계가 아니라 서로 다른 문제를 해결하는 상호보완적인 제품입니다.
이미 Atlassian 생태계를 사용하고 있는 조직이라면 CSM은 새로운 고객 지원 도구를 하나 더 추가하는 것이 아니라, 고객 경험을 기존 협업 플랫폼 안으로 자연스럽게 확장하는 방법이 될 수 있습니다.
