티켓 처리는 왜 늘 냄비처럼 끓어넘칠까

고객지원 티켓은 이상하다.

분명 아침에는 “오늘은 차분히 정리해보자”라고 시작한다. 그런데 오전이 조금 지나면 냄비 세 개가 동시에 끓는다.

하나는 고객이 “진행 상황이 어떻게 되나요?”라고 묻는 냄비다.
하나는 개발 티켓이 어디선가 막힌 냄비다.
하나는 담당자가 없는 채로 조용히 타고 있는 냄비다.

그리고 우리는 종종 이렇게 말한다.

일단 Jira 열어볼게요.

물론 Jira는 중요하다. 모든 티켓이 들어 있는 거대한 창고니까. 문제는 창고가 너무 넓다는 것이다. 창고 안에서 소화기를 찾다 보면, 어디서 연기가 나는지 먼저 잊어버릴 때가 있다.

그래서 CS Cockpit은 창고가 아니라 관제탑처럼 쓰는 게 좋다.

Jira가 “모든 박스가 있는 곳”이라면, CS Cockpit은 “오늘 먼저 출동할 곳을 알려주는 화면”이다.

티켓 목록이 아니라 오늘의 작전판

대부분의 대시보드는 숫자를 보여준다.

열린 티켓 몇 개.
완료된 티켓 몇 개.
담당자별 몇 개.
상태별 몇 개.

다 필요한 정보다. 하지만 아침 9시 30분에 CS 담당자가 진짜 알고 싶은 건 보통 이것이다.

그래서 오늘 뭐부터 봐야 하지?

CS Cockpit의 핵심은 이 질문에 답하는 것이다.

특히 Today Action Queue는 티켓을 단순히 나열하지 않는다. risk, SLA, QPD dependency, priority, stale, key customer, unassigned 같은 신호를 섞어서 “오늘 볼 이유”를 만든다.

여기서 중요한 차이가 있다.

High Risk는 위험 점수 중심이다.
Action Queue Urgency는 오늘 처리해야 할 이유 중심이다.

그래서 어떤 티켓은 고위험은 아니어도 오늘 봐야 한다. 담당자가 없거나, 오래 멈춰 있거나, 개발 의존 티켓이 막고 있을 수 있기 때문이다.

이건 마치 냄비 온도계와 주방 알람의 차이다. 온도만 높은 냄비도 위험하지만, 타이머가 울리고 있는데 아무도 안 보는 냄비도 위험하다.

아침 15분: 화재 지도부터 본다

추천하는 시작은 단순하다.

아침에 CS Cockpit을 열고 먼저 Sync Health Strip을 본다.

최신 동기화가 오늘 기준인지, snapshot이나 metric 날짜가 멈춰 있지 않은지 확인한다. 관제탑 레이더가 어제 화면이면 그 다음 판단이 다 흔들리기 때문이다.

그 다음 Today Action Queue를 본다.

Critical은 불난 냄비다. 바로 뚜껑을 열어야 한다.
High는 끓기 직전 냄비다. 오전 안에 불 조절을 해야 한다.
Medium은 타이머 맞춘 냄비다. 담당자와 체크 시간을 잡는다.
Low는 냉장고 정리다. 중요하지만 지금 불은 아니다.

이 비유가 조금 우스워 보여도 꽤 유용하다. 티켓 처리에서 가장 어려운 일은 “모두 중요해 보이는 것”을 분리하는 일이기 때문이다.

모든 티켓을 같은 힘으로 보면 결국 아무것도 먼저 보지 못한다.

다음 질문은 “누가 공을 잡고 있나?”다

티켓을 읽다 보면 자꾸 내용으로 빨려 들어간다.

로그가 어떻고, 고객 환경이 어떻고, 재현 조건이 어떻고, 마지막 댓글이 언제고.

물론 중요하다. 하지만 데일리 운영에서는 그 전에 더 중요한 질문이 있다.

다음 공은 누가 잡아야 하지?

CS Cockpit은 next action owner를 기준으로 티켓을 나눠 볼 수 있다.

다음 담당	오늘의 질문	좋은 첫 액션
CS	고객에게 지금 설명할 수 있는가	현재 확인 범위와 다음 업데이트 시점을 남긴다
Dev	연결 개발 티켓이 막고 있는가	QPD 상태, 담당자, 완료 예정일을 확인한다
Partner / Installation	설치나 파트너 일정이 병목인가	다음 일정이나 준비물을 확인한다
Unclear	소유자가 애매한가	CS / Dev / Partner 중 다음 액션 주체를 먼저 정한다

좋은 티켓 처리는 “분석을 많이 했다”가 아니라 “다음 액션 주체가 명확하다”에 가깝다.

공이 바닥에 떨어져 있으면 아무리 좋은 분석도 느려진다.

시나리오 1: Critical 티켓 세 개가 상단에 떴다

아침에 Action Queue를 열었는데 Critical 티켓이 세 개 보인다고 해보자.

하나는 위험 점수가 높다.
하나는 9일 동안 의미 있는 활동이 없다.
하나는 연결된 QPD가 두 개나 막고 있다.

예전 방식이면 회의에서 각 티켓을 열어보며 하나씩 설명했을 가능성이 크다.

CS Cockpit 방식은 조금 다르다.

먼저 Action Score가 가장 높은 티켓부터 상세를 연다. “왜 지금 봐야 하나?”를 읽고 급한 이유를 한 문장으로 만든다. 그리고 next step label을 본다.

예를 들어 이렇게 나뉜다.

• “위험 점수 70점 + 9일 미활동 + 주요 고객사”라면 고객 업데이트가 먼저다.
• “미완료 QPD 2건”이라면 고객에게 약속하기 전에 Dev 병목 확인이 먼저다.
• “담당자 없음”이라면 내용 분석보다 담당자 지정이 첫 액션이다.

여기서 재미있는 점은, 세 티켓 모두 “급함”으로 보이지만 실제 첫 행동은 다르다는 것이다.

하나는 고객에게 말해야 하고, 하나는 개발팀에 물어야 하고, 하나는 owner부터 붙여야 한다.

급한 티켓을 빠르게 처리한다는 건 빨리 클릭한다는 뜻이 아니다. 첫 번째 공을 올바른 사람에게 던진다는 뜻이다.

시나리오 2: 고객이 “진행 상황이 어떻게 되나요?”라고 물었다

이 질문은 단순해 보이지만 꽤 어렵다.

정답을 알고 있으면 쉽다. 문제는 정답이 아직 없을 때다.

나쁜 답변은 대개 너무 흐릿하다.

확인 중입니다.

틀린 말은 아니지만 고객 입장에서는 별로 도움이 되지 않는다. 무엇을 확인 중인지, 누가 보고 있는지, 언제 다시 알려줄지 모르기 때문이다.

CS Cockpit을 끼우면 답변 구조가 조금 선명해진다.

먼저 해당 티켓이 Action Queue에 있는지 본다. 다음 담당이 Dev라면 연결 QPD 상태와 담당자 유무를 먼저 확인한다. 다음 담당이 CS라면 현재 확인 중인 내용과 다음 업데이트 시점을 바로 고객에게 남길 수 있다. Partner / Installation이라면 설치 일정이나 준비물이 병목인지 본다.

좋은 고객 업데이트는 세 줄이면 충분하다.

현재 상태: 지금 어디에서 멈춰 있는지
다음 액션: 누가 무엇을 확인 중인지
다음 업데이트: 언제 다시 공유할지

예를 들면 이런 식이다.

현재 개발 티켓 진행 상태를 확인 중입니다. 담당자와 완료 예상 시점을 확인한 뒤 오늘 오후에 다시 업데이트드리겠습니다.

완벽한 해결책이 없어도 괜찮다. 고객은 종종 “답”만 기다리는 게 아니라 “내 일이 잊히지 않았다”는 신호도 기다린다.

다음 업데이트 시점은 작지만 강력한 약속이다.

시나리오 3: QPD가 주문서를 물고 있다

QCP는 고객이 보는 주문서다.
QPD는 주방 안쪽의 조리표다.

주문서만 보고 “곧 나옵니다”라고 말하면 위험하다. 주방에서 누가 요리 중인지, 재료가 있는지, 불은 켜졌는지 봐야 한다.

Action Queue에서 Dev 필터를 누르면 이런 티켓들이 보인다.

• QPD 담당자 지정 필요
• QPD 착수 여부 확인
• Dev 완료 예정일 확인

이 라벨들은 작지만 아주 유용하다.

Dev에게 “이 티켓 좀 봐주세요”라고 말하는 것보다, “이 QPD 담당자 지정이 필요합니다” 또는 “착수 여부와 예상 일정을 확인해주세요”라고 말하는 편이 훨씬 빠르다.

요청이 구체적이면 응답도 구체적이 된다.

그리고 고객 안내도 좋아진다. “개발팀에 확인 중입니다”에서 “담당자와 완료 예상 시점을 확인 중입니다”로 바뀌기 때문이다.

시나리오 4: 조용히 타는 미할당 티켓

미할당 티켓은 조용하다.

누구도 내 티켓이라고 생각하지 않기 때문에, 알람이 크게 울리지 않는다. 그런데 시간이 지나면 이 조용함이 가장 위험해진다.

CS Cockpit에서는 unassigned 신호가 Action Queue에 반영된다. 이때는 내용 분석보다 owner 지정이 먼저다.

CS 미할당이면 CS 담당자를 정한다.
Dev 미할당이면 연결 QPD 담당자 지정이 필요한지 본다.
그 다음에 고객 업데이트가 필요한지 다시 확인한다.

하루 시작 시 목표를 하나만 잡는다면 이것도 좋다.

High 이상 미할당 티켓 0개.

거창하지 않지만 효과가 크다. “누군가 하겠지”를 “누가 한다”로 바꾸는 순간, 티켓은 움직이기 시작한다.

하루 끝에는 숫자로 회고한다

하루 종일 티켓을 봤는데, 정말 나아졌는지 모를 때가 있다.

그럴 때는 QCP Flow & Backlog Trend를 본다.

Created가 Resolved보다 많으면 오늘 들어온 일이 더 많았다는 뜻이다. 내일 아침 Action Queue가 무거워질 수 있다.

Resolved가 Created보다 많으면 처리 속도가 유입보다 빨랐다는 뜻이다. 좋은 날이다.

Backlog는 그대로인데 high-risk가 줄었다면? 전체 수는 같아도 위험한 불은 껐다.

특정 고객사에 미완료 티켓이 몰린다면? 개별 티켓 대응이 아니라 고객 단위 정리가 필요할 수 있다.

이 숫자들은 사람을 혼내기 위한 숫자가 아니다. 길찾기용 지도다.

“왜 아직 이것밖에 못 했지?”가 아니라 “어디가 막혔지?”를 묻기 위한 도구다.

내가 좋아하는 운영 룰 다섯 개

첫째, Action Queue 상단 10개는 매일 본다.

모든 티켓을 다 보는 것보다 위험 신호가 겹친 상단 티켓을 놓치지 않는 것이 더 중요하다.

둘째, 티켓마다 다음 공을 하나만 정한다.

CS가 답할 차례인지, Dev가 QPD를 정리할 차례인지, Partner가 설치 일정을 확인할 차례인지 정한다.

셋째, 고객 업데이트는 완벽한 답보다 다음 약속이 중요하다.

해결이 아직 없어도 다음 업데이트 시점은 남길 수 있다.

넷째, High Risk와 Action Queue Urgency를 구분한다.

위험한 티켓과 오늘 봐야 하는 티켓은 겹치지만 완전히 같지는 않다.

다섯째, 숫자는 벌주기용이 아니라 길찾기용이다.

Backlog, Resolved, Stale은 팀을 평가하는 회초리가 아니라 병목을 찾는 지도다.

다음에 만들고 싶은 것들

이 흐름이 익숙해지면 CS Cockpit은 더 재미있어질 수 있다.

아침에는 데일리 브리핑 카드가 있으면 좋다.

오늘 Critical 2건, High 7건입니다.
Dev 확인이 필요한 티켓이 5건입니다.
미할당 High 이상 티켓이 1건입니다.
어제보다 stale 티켓이 3건 줄었습니다.

오후에는 고객 업데이트 후보만 따로 모아도 좋다. CS가 커뮤니케이션 시간을 잡기 쉬워진다.

Dev handoff pack도 유용할 것 같다. QPD 담당자 지정, 착수 여부, 완료 예정일 확인이 필요한 티켓을 자동으로 묶어주면 개발팀에 요청하기가 훨씬 쉬워진다.

그리고 하루 끝에는 작은 회고 뱃지가 있으면 재미있겠다.

• 오늘의 소방수: high-risk 4건 감소
• 오늘의 교통정리: 미할당 0건 달성
• 오늘의 병목 해소: QPD blocked 3건 owner 지정

숫자를 조금 덜 무섭게 만들면, 운영 회고도 조금 더 자주 하게 된다.

많이 보는 것에서 제때 움직이는 것으로

CS Cockpit의 가치는 티켓 목록을 예쁘게 보여주는 데 있지 않다.

아침에는 우선순위를 알려준다.
처리 중에는 다음 담당을 알려준다.
고객에게는 더 명확한 업데이트를 돕는다.
하루가 끝나면 운영 흐름이 좋아졌는지 보여준다.

결국 좋은 데일리 티켓 처리는 많이 보는 싸움이 아니다.

제때 보는 싸움이다.
제때 넘기는 싸움이다.
제때 알려주는 싸움이다.

냄비는 계속 끓는다. 중요한 건 냄비가 끓는다는 사실이 아니라, 어떤 냄비부터 불을 줄일지 아는 것이다.