헬프데스크 티켓 시스템 만드는 법: 티켓, 상태, 담당자 배정, 이메일

헬프데스크 티켓 시스템은 흩어진 요청(이메일, 메시지, 복도에서 던지는 「간단한 질문」)을 티켓으로 바꿉니다. 문제 하나당 기록 하나이며, 담당자, 상태, 우선순위, 전체 대화가 함께 있습니다. 만들려면 티켓을 만드는 방법, 필터가 있는 공유 대기열, 담당자 배정, 공개 답변과 내부 메모를 구분하는 스레드, 그리고 아무도 기다리게 두지 않는 알림이 필요합니다. AI 앱 빌더는 사내 IT, HR, 시설 창구의 탄탄한 첫 버전을 하루 오후 만에 만들 수 있습니다. 이메일 스레딩, 응답 목표, 보고서가 필요한 고객 대상 지원은 더 신중해야 하며, 검증된 헬프데스크 제품이 비용을 정당화하는 영역입니다.

시스템에 필요한 것

데이터

첫 응답과 해결 시각을 처음부터 저장하세요. 모든 보고서가 이것을 기반으로 하며, 나중에는 다시 만들 수 없습니다.

페이지

• 요청자: 카테고리와 첨부 파일이 있는 「요청 제출」 양식, 「내 요청」 목록, 각 티켓의 스레드.
• 상담원: 대기열(내 티켓, 미배정, 열린 전체), 필터와 검색, 답변, 메모, 상태, 우선순위, 담당자를 조절하는 티켓 화면.
• 관리자: 카테고리, 팀, 상담원, 저장된 답변, 간단한 보고서.

권한

요청자는 자신의 티켓과 공개 답변만 봅니다. 상담원은 자기 팀의 티켓과 내부 메모를 봅니다. 리더와 관리자는 모든 것을 보고 설정을 관리합니다. 내부 메모가 고객에게 새는 것은 전형적인 헬프데스크 사고이므로, 탭을 숨기는 것에 그치지 말고 서버에서 강제하세요. 역할 기반 접근 제어를 참고하세요.

결정과 트레이드오프

양식, 이메일, 또는 둘 다

웹 양식이 가장 간단하고 깔끔한 데이터를 줍니다. 카테고리, 우선순위, 필수 필드를 받을 수 있습니다. 이메일 접수는 사람들이 「support@」로 메일을 보내면 티켓이 생기는 방식으로, 고객이 기대하는 방식입니다. 하지만 메시지를 받아 앱으로 전달할 수 있는 이메일 제공업체와, 답장이 올바른 티켓에 붙도록 하는 스레딩(보통 제목의 티켓 번호나 고유한 회신 주소)이 필요합니다. 양식으로 시작하고, 흐름이 검증되면 이메일을 추가하세요. 나가는 메일은 앱에서 이메일 보내기에서 다룹니다.

배정

선택지는 상담원이 미배정 대기열에서 고르는 방식, 팀 안의 라운드 로빈, 또는 카테고리별 배정입니다. 소규모 팀에는 대기열에서 고르는 방식이 잘 맞습니다. 주인 없는 티켓이 쌓이기 시작하면 자동 배정이 도움이 됩니다.

우선순위와 응답 목표

첫 응답 목표가 있는 우선순위를 두세 개 정하세요(「긴급: 1시간, 보통: 영업일 1일」). 아무도 읽지 않는 월간 보고서보다 각 티켓에 남은 시간을 보여 주는 편이 훨씬 유용합니다. 영업시간이 있으면 계산이 어려워지므로, 밤과 주말도 목표 시간에 포함하는지 일찍 정하세요.

병합과 중복

같은 문제가 세 번 접수되는 일은 흔합니다. 「티켓 #에 병합」 기능은 상담원이 같은 답을 반복하지 않도록 해 주므로 일찍 만들 가치가 있습니다.

효과가 있었던 첫 프롬프트

직원 60명 규모 회사의 사내 IT 헬프데스크를 만들어 줘. 직원은 양식으로 요청을 제출한다. 제목, 카테고리(하드웨어, 소프트웨어, 접근 권한, 네트워크, 기타), 우선순위(낮음, 보통, 긴급), 설명, 첨부 파일. 각 티켓은 번호를 받고, 상태는 신규, 진행 중, 요청자 응답 대기, 해결됨, 종료 중 하나다. IT 상담원은 미배정, 내 티켓, 열린 전체 탭이 있는 대기열을 보고, 카테고리, 우선순위, 상태로 필터링하고 검색한다. 티켓 페이지는 공개 답변과 내부 메모를 뚜렷이 구분해 스레드로 보여 주며, 직원은 내부 메모를 절대 볼 수 없다. 상담원은 담당자, 상태, 우선순위를 바꾸고, 저장된 답변을 쓰고, 중복 티켓을 병합할 수 있다. 첫 응답과 해결 시간을 추적하고, 각 티켓에 마지막 업데이트 후 경과 시간을 보여 준다. 직원에게는 「내 요청」 페이지가 있다. 역할은 직원, 상담원, 관리자. 모든 것은 데이터베이스에 저장한다. 간결하고 촘촘하며 빠른 인터페이스로 만들어 줘. 장식보다 속도가 중요하다.

빌드 단계

1. 티켓 모델과 양식. 제출, 목록, 티켓 열기, 답장.
2. 대기열과 필터. 미배정, 내 티켓, 열린 전체. 필터와 검색, 우선순위와 경과 시간순 정렬.
3. 역할과 로그인. 요청자, 상담원, 관리자. 메모는 서버에서 요청자에게 숨깁니다.
4. 담당자, 상태, 우선순위 조절, 모든 변경을 기록하는 활동 기록과 함께.
5. 알림. 공개 답변에는 요청자에게, 새 배정에는 상담원에게 이메일을 보냅니다. 직접 연결한 이메일 제공업체를 통해서요.
6. 저장된 답변과 병합.
7. 응답 목표와 기본 보고서: 나이별 열린 티켓, 첫 응답 시간, 카테고리별 티켓 수.
8. 이메일 접수를 나머지가 작동한 뒤 추가하고, 스레딩을 철저히 테스트합니다.
9. 모두에게 적용하기 전에 한 팀으로 2주간 시범 운영.

자주 하는 실수

• 내부 메모가 요청자에게 보임. 인터페이스에서만 숨겼기 때문입니다.
• 상태와 카테고리가 너무 많음. 상담원은 비슷해 보이는 첫 번째 항목을 고릅니다. 각각 최대 다섯 개로 시작하세요.
• 첫 응답과 해결 시각을 저장하지 않음. 누군가 「우리가 점점 빨라지고 있나요?」라고 물을 날에 필요한 숫자입니다.
• 이메일 답장이 스레딩 대신 새 티켓을 만듦. 휴대폰 메일 앱에서 답장하는 것을 테스트하세요. 종종 제목을 바꿉니다.
• 모두가 배정되었지만 아무도 책임지지 않음. 티켓마다 담당자는 한 명이어야 하며, 나머지는 감시자로 두세요.
• 공개 URL이 있는 첨부 파일. 오류 메시지 스크린샷에는 종종 개인 정보가 들어 있습니다. 파일은 비공개로 두고 티켓을 볼 수 있는 사람에게만 제공하세요.

기성 제품이 더 나은 경우

이메일, 채팅, 소셜 채널을 아우르는 고객 대상 지원, 즉 응답 목표 추적, 만족도 조사, 매크로, 보고서, 연동이 필요하다면 전용 헬프데스크 제품이 거의 항상 더 나은 투자입니다. 이런 제품은 이메일 스레딩, 스팸, 라우팅, 보고서에 수년을 들였고, 이 부분은 여러분의 사업을 차별화하는 영역이 아닙니다. Zendesk 대안 가이드에서 선택지를 비교합니다.

직접 만드는 것은 사내 창구(IT, HR, 시설, 재무 요청), 티켓이 실은 특정 단계가 있는 작업인 틈새 워크플로, 요청을 이미 가진 다른 데이터와 연결하고 싶은 팀에 맞습니다. 많은 사람이 가끔씩 티켓을 처리할 때 상담원별 요금을 피할 수 있다는 장점도 있습니다. 더 넓은 범주는 내부 도구 가이드에서 다룹니다.

Mythex로 만들기

Mythex에서는 채팅으로 헬프데스크를 설명하고, 실시간 미리보기에서 검토한 뒤, 팀을 위해 게시할 수 있습니다. 데이터를 저장해야 할 때 에이전트가 추가하는 Postgres 데이터베이스에 티켓이 저장되며, 첨부 파일은 프로젝트의 파일 저장소에 들어갑니다. 요청자와 상담원의 로그인, 그리고 들어오고 나가는 모든 이메일은 직접 연결한 제공업체를 사용합니다. Mythex에는 최종 사용자 로그인이나 이메일 제품이 내장되어 있지 않기 때문입니다. 접근 방식은 이메일 보내기 레시피에 나와 있습니다. 팀원은 공유 워크스페이스를 통해 함께 만들 수 있으며, Mythex 자체에는 좌석당 요금이 없습니다.

시작 프롬프트가 필요하다면 내부 요청 대기열이나 버그 트래커 템플릿을 참고하고, 헬프데스크를 지식 베이스와 함께 두면 자주 묻는 질문을 스스로 해결할 수 있습니다.

자주 묻는 질문