tool

주문 데이터 기반으로 티켓 관리 시스템 만들어보기

고객을 응대할때 같은 질문을 반복하게 됩니다. 이 고객이 무엇을 샀는지, 지금 주문 상태는 어떤지, 이전에도 같은 이슈가 있었는지. 문의를 처리하는 기존 방법들부터, 주문 데이터를 기준으로 티켓을 정리하면 무엇이 달라지는지를 다룹니다. 복잡한 자동화가 아니라, 검색과 처리에 집중한 최소한의 시작 방법을 정리했습니다.

Hakbeom Kim

22 1월 2026 — 13 min read

Photo by Claudio Schwarz / Unsplash

— 문의를 단순히 기록하는 걸 넘어서 더 잘 활용하는 방법

고객 문의를 처리하는 팀은 결국 같은 질문으로 돌아옵니다.
“이 고객이 뭘 샀지?”
“지금 배송/서비스 상태는?”
“환불 규정상 이 케이스는 어디까지 가능하지?”

문의가 늘고 다양해지면서 이런 질문을 더 자주 하게 되고, 찾는 시간도 길어집니다. 팀을 힘들게 하는 건 주문/고객/이력 정보가 여기저기 흩어져 있다는 점입니다.

이런 문제를 해결하기 위해
“주문 데이터 기반으로 티켓 관리 시스템을 만들었을 때 장점”과
“어떻게 단순하게 시작할 수 있는지”를 정리해보았습니다.

1) 왜 기존 툴로는 계속 답답해질까

Zendesk, Freshdesk… 다 좋은데 ‘주문’이 밖에 있다

기존 티켓 시스템은 강력합니다. 상태, SLA, 자동화, 리포트까지 갖춰져 있죠.

그런데 고객지원(Customer Support, 이하 CS) 담당자가 실제로 많이 하는 일은
“티켓 상태 관리”보다 “주문 맥락 찾기”입니다.

CS가 당장 보고 싶은 건 보통 이런 정보입니다.

이 고객의 최근 주문 몇 건
현재 주문의 결제/배송 상태
이 주문으로 이미 비슷한 이슈가 있었는지
VIP/반복 클레임 고객인지

문제는 이 정보가 티켓 툴 안에 자연스럽게 붙어있지 않다는 겁니다.
그래서 티켓은 티켓대로 보고, 주문은 주문대로 보고, 메모는 또 다른 곳에 남습니다.
연결은 사람 손으로 하고요.

“API로 붙이면 되지 않을까요?”
가능합니다. 다만 실무에서는 연동 한 번으로 끝나지 않습니다.
주문 조회 화면, 티켓 생성/변경, 권한, 로그, 예외처리, 유지보수까지 이어지면서
개발 부담이 커집니다.

Cafe24 같은 기본 관리자 기능… ‘우리 회사 방식’을 담기 어렵다

커머스 플랫폼 관리자 기능에도 메모/문의 기능이 있긴 합니다.
하지만 운영이 조금만 복잡해지면 한계가 빨리 옵니다.

환불 규정(기간/사유/위약금)이 케이스별로 다름
파손/오배송/부분반품처럼 분기가 늘어남
VIP/반복 클레임/특정 상품·파트너 예외 처리 필요
물류/CS/개발/파트너팀이 같은 케이스를 함께 처리해야 함

‘우리 회사의 실제 처리 규칙’을 담기에는 구조적으로 여지가 적은 경우가 많습니다.

결국 기본 관리자 기능은 조회 정도로만 쓰이고, 실제 업무는 엑셀·노션·슬랙으로 흩어집니다. 이렇게 데이터가 흩어지면 누락/중복/업무 공백이 생기기 쉽습니다.

2) 구글 시트/노션으로 시작해도 되는가?

— 가능하지만 “케이스, 사람이 늘어나는 순간” 아쉽다.

초기에 시트와 노션은 좋습니다. 빨리 시도할 수 있고 누구나 참여할 수 있습니다.

다만 주문량과 문의량, 팀 인원이 늘어나면, 업무 처리가 느려지거나 데이터가 쉽게 망가지기 시작합니다.

구분	구글 시트 / 노션	주문 데이터 기반 티켓 시스템
데이터 무결성	실수로 수정/삭제/덮어쓰기 쉬움	스키마로 안정적으로 관리, 변경 이력도 추적가능
보안/권한	링크 공유/복사로 유출 리스크	역할별 접근 제어, 마스킹 가능
자동화	수동 입력 중심, 상태 집계·현황 파악이 번거로움	상태/유형/기간별 지표 쿼리 기반 집계 가능
연결성	주문·고객·문의가 분리됨	주문 ID 하나로 이력 통합 가능
속도	케이스가 늘면 운영 속도가 느려짐	검색 → 처리까지 한 화면에서 끝낼 수 있음

시트/노션에서도 일부 권한 설정이나 변경 이력 관리는 가능합니다. 다만 데이터와 사람이 늘어날수록, 실수의 비용을 시스템이 아니라 사람이 떠안게 됩니다.

3) 주문 중심으로 티켓을 잡으면 무엇이 달라질까

티켓은 업무 단위이긴 하지만, 커머스/구독/거래 기반 비즈니스에서 업무의 기준점은 대체로 “주문(거래)”입니다.

계정/정책/사용법 문의도 존재하지만, 반복·지연·분쟁으로 이어지는 대부분의 CS 케이스는 주문과 연결됩니다.

주문을 중심으로 잡으면 티켓은 이런 형태로 정리됩니다.

특정 주문에서 발생한 이슈(파손, 환불, 오배송 등)
그 주문과 연결된 커뮤니케이션 기록(고객 메시지, 내부 메모)
해결되지 않은 상태(대기/진행/완료)

이렇게 정리하면 장점이 명확합니다.

같은 주문에서 재문의가 와도 히스토리가 한 줄로 연결됨
“어떤 주문/상품/배송에서 이슈가 많이 나는지”가 데이터로 보임
담당자/팀이 바뀌어도 케이스를 빠르게 따라갈 수 있음

4) 시작은 “검색이 되는 화면”부터

최소 주문 데이터 + 티켓 연결

여기서 자주 고민하게 되는 포인트가 하나 있습니다.

“전화가 오면 자동으로 조회되는 화면” 같은 기능을 상상하기 쉽지만, 현실적으로 모든 팀이 전화 시스템/CTI를 갖추고 있진 않습니다.

그래서 1차 목표는 단순하게 접근해볼 필요가 있습니다.

이름/전화번호/주문번호로 빠르게 검색할 수 있다
검색 결과에서 주문 상태와 기존 티켓 이력을 한 번에 볼 수 있다
필요하면 그 자리에서 티켓을 생성/상태 변경할 수 있다

이 정도만 되어도 CS 업무 체감이 크게 바뀝니다.

주문 데이터가 없는 경우(외부 플랫폼에만 있는 경우)

“우리는 내부 주문 DB가 없어요”는 흔한 상황입니다.

이 경우 처음부터 전체 주문을 복제할 필요는 없습니다. 실제로는 완전한 주문 데이터보다, 티켓을 연결할 기준점만 있어도 운영은 시작됩니다.

최소한 아래만 있어도 시작 가능합니다.

고유 주문 ID(내부에서 쓸 키) + 외부 주문번호
고객 식별자(전화번호/이메일/고객ID 중 하나)
주문 시점
상태(결제/배송/취소 정도)
금액(선택)

이렇게라도 내부에 쌓이면, 티켓을 주문 기준으로 연결할 수 있고, 반복되는 이슈 패턴도 나중에 데이터로 볼 수 있습니다.

실시간 주문 확인이 필요한 경우 플랫폼에서 제공하는 API를 통해 주문 정보를 가져와 디비에 쌓거나, 일일 주문 확인으로 충분한 경우 엑셀 다운로드 후 업로드 UI를 통해 디비에 주문 데이터를 쌓아볼 수 있습니다.

5) 기본 데이터 구조(최소 버전)와 연결 방식

스키마는 단순하게 시작해봅니다. “검색/조회/처리”에 필요한 최소 구조로 잡고, 나중에 확장해볼 수 있습니다.

Orders

order_id (PK)
channel_name
channel_order_code
customer_id 또는 phone/email
status (paid / shipped / delivered / canceled)
amount
created_at

Tickets

ticket_id (PK)
order_id (FK)
type (배송/환불/교환/파손/오배송/결제 등)
status (open / pending / in_progress / resolved)
priority
assignee
created_at

Ticket Events (History)

event_id
ticket_id
action (created / assigned / status_changed / commented)
actor
payload (메모/변경값)
timestamp

이 구조로 할 수 있는 질문이 바로 생깁니다.

“이 주문으로 티켓이 몇 번 열렸지?”
“파손 이슈는 어떤 배송사/상품에서 많이 나오지?”
“같은 고객이 이번 달에 반품 티켓을 몇 번 만들었지?”

자체 주문 시스템이 있는 경우엔 기존 Orders에 Tickets만 연결하면 되고, 외부 주문 솔루션을 쓰는 경우에도 최소 데이터만 가져와 내부 키로 연결하는 방식이 현실적입니다.

6) 실제 업무 흐름과 화면 구성

검색 → 처리 → 현황 파악이 한 흐름으로 이어집니다. 주문 중심으로 티켓을 잡으면, 업무 흐름은 자연스럽게 이렇게 정리됩니다.

검색 (lookup)

이름 / 전화번호 / 주문번호로 검색합니다. 검색 결과에서 아래 정보를 한 화면에서 확인합니다.

고객 기본 정보
최근 주문 목록과 현재 상태
해당 주문에 연결된 기존 티켓 이력

CTI처럼 자동 조회가 아니어도 괜찮습니다. “검색만 하면 맥락이 한 번에 보인다”는 것만으로 CS 업무 체감은 크게 달라집니다.

티켓 생성·처리 (workflow)

바로 해결되지 않는 건은 티켓으로 남기고 상태를 움직입니다.

예시) 배송 파손

type: 파손
status: pending (수거 필요)
assignee: 물류팀
이벤트: 사진 수령 / 수거 요청 / 재발송 여부 기록

예시) 단순 변심 반품

type: 반품
status: in_progress (회수 요청)
완료 시 resolved + 환불 완료일/금액 기록

중요한 건 모든 걸 자동화하는 게 아니라, 반복되는 케이스에서 실수와 누락을 줄이는 구조를 먼저 만드는 것입니다.

현황 파악 (status)

개별 티켓을 처리하다 보면, 자연스럽게 이런 질문이 나오기 시작합니다.

지금 어떤 유형의 이슈가 가장 많이 발생하고 있는지
특정 주문/상품/배송사에서 문제가 반복되는지
처리 지연이 자주 발생하는 구간은 어디인지

그래서 최소한 아래 정도의 지표는 함께 보이기 시작합니다.

상태별 티켓 분포 (open / pending / in_progress / resolved)
유형별 티켓 비중 (배송 / 환불 / 파손 / 오배송 등)
반복 발생한 주문·고객 티켓 횟수
평균 처리 소요 시간 (유형별 / 담당자별)

이 지표들은 “어디에서 구조적인 문제가 생기고 있는가”를 보는 데 쓰입니다.

필요한 최소 화면 구성

이 흐름을 적용하기 위해 필요한 화면은 아래와 같습니다.

티켓 리스트 + 상세 (좌우 분할)
- 연속 처리 시 페이지 이동 최소화
티켓 상세(처리 화면)
- 주문 핵심 정보, 고객 메시지, 내부 메모
- 상태 / 담당자 / 우선순위 변경
- 변경 이력
주문 + 티켓 타임라인
- 재문의 대응, 인수인계, 분쟁 대응에 유용

위 구성으로 CS·물류·운영팀이 같은 주문을 기준으로 같은 화면을 보며 업무를 진행할 수 있습니다.

7) 셀렉트 어드민으로 구성하면 이렇게 된다

셀렉트 어드민으로 위 구조를 구성하면, 결과적으로 이런 모습이 됩니다.

Orders / Tickets 테이블 또는 API를 그대로 연결
주문 검색 → 티켓 처리 → 이력 확인이 한 화면에서 이어짐
리스트 / 상세 / 모달 액션 중심의 화면 구성
운영 현황 지표를 필요한 것부터 화면에 바로 붙일 수 있음
옵션 추가시 역할별 접근 권한, 변경 이력, 로그가 남음

처음부터 완벽한 CS 시스템을 만드는 게 아니라, 지금 가장 많이 쓰이는 검색·처리 흐름을 먼저 화면으로 고정시키는 데 초점이 맞춰집니다.

정리

주문 데이터 기반 티켓은 문의를 주문 단위 업무로 바꿔줍니다.
시작은 고급 기능이 아니라 검색 → 처리 → 현황이 이어지는 흐름이면 충분합니다.
스키마와 화면은 최소로 시작하고, 반복 패턴이 보이면 확장하는 게 현실적입니다.
셀렉트 어드민은 이런 어드민 페이지를 작게 시작하고 안정적으로 확장하는데 초점이 맞춰진 도구입니다.