고객사별 Slack 채널이 20개일 때는 그냥 스크롤하면서도 버텨진다. 그런데 50개를 넘기면 누가 답했는지, 어떤 질문이 아직 열려 있는지 이모지로 표시하기 시작하고, 100개 근처에서는 아침마다 30분씩 채널을 훑는 게 업무가 된다. 오늘 본 CS 팀 사례도 딱 그 얘기였다. 30~300개 고객 채널을 다루는 팀들이 거의 같은 순서로 무너진다고 했다. 흥미로운 건 다들 처음부터 거창한 툴을 찾지 않는다는 점이다. 처음엔 triage 채널 하나 만들고, “needs attention / resolved” 같은 이모지 규칙을 붙이고, 조용한 고객은 담당자가 기억해주길 바란다. 하지만 질문이 주 단위로 새고, 응답 지연 불만이 나오고, 큰 고객보다 큰소리 나는 고객이 먼저 처리되면 그때부터 비용이 보인다. 사람을 더 뽑아도 결국 또 스크롤러가 늘어나는 구조다. 작게 만들 수 있는 제품은 꽤 선명하다. 고객 Slack 전체를 읽어서 열린 요청만 모으고, SLA 위험도를 붙이고, 담당자·상태·마지막 응답 시간을 한 화면에 보여주는 얇은 관제판. AI 답변보다 먼저 필요한 건 “지금 무엇이 방치되고 있는지”를 놓치지 않는 레이더 같다.