티켓 분류 내부 도구: 하루 만에 모델과 워크플로우 계획

실제로 티켓 분류 도구가 해결하는 문제

이메일, 채팅, 웹 폼, 내부 메신저의 빠른 메시지로 티켓이 들어오면 동일한 요청이 두 번 나타나거나, 심지어 전혀 보이지 않을 수 있습니다. 사람들은 스크린샷을 전달하고, 스프레드시트에 메모를 복사하고, 누가 무엇을 맡았는지 기억에 의존합니다. 긴급 항목은 묻히고, 가장 크게 우는 메시지가 승리합니다.

수동 분류는 인수인계에서도 깨집니다. 채팅 스레드에서 요청이 "할당됨"으로 표시되면 담당자가 오프라인일 때 다음 단계를 아는 사람이 없습니다. 상태가 사람마다 다르게 해석되면 관리자는 대시보드를 신뢰할 수 없고 요청자는 불필요하게 더 오래 기다립니다.

응답 지연은 보통 악의 때문이 아닙니다. 구조가 없을 때 발생합니다: 분명한 소유권, 명확한 기한, 에스컬레이션 경로가 없을 때입니다.

티켓 분류 내부 도구는 이 난잡한 입력을 단순하고 가시적인 흐름으로 바꿉니다. 하루짜리 빌드의 목표는 모든 기능을 갖춘 헬프데스크가 아니라 확장 가능한 신뢰할 수 있는 골격입니다.

하루가 끝날 때까지 다음 네 가지를 목표로 하세요:

• 티켓, 요청자, 에이전트, 활동을 위한 기본 데이터 모델
• 명확한 전환과 소유 규칙을 가진 소수의 상태 집합
• 설명하기 쉬운 SLA 타이밍과 에스컬레이션 트리거
• 일상 업무에 쓰이는 내부 대시보드와 티켓 상세 화면

AppMaster 같은 시각적 플랫폼에서 이걸 만들면 코드를 쓰는 대신 비즈니스 프로세스 로직으로 워크플로를 매핑하고, 팀의 실제 습관이 드러남에 따라 쉽게 조정할 수 있습니다.

하루 계획 범위: 최소한으로 유용한 분류 시스템

분류 도구는 첫날에 세 가지를 안정적으로 처리할 때만 유용합니다: 티켓을 한 곳으로 모으기, 소유자 지정하기, 연체된 작업을 눈에 띄게 만들기. 나머지는 기다릴 수 있습니다.

한두 개의 티켓 소스를 선택하세요. 초기 버전에는 이메일과 간단한 웹 폼이면 충분한 경우가 많습니다. 채팅은 소음(짧은 메시지, 누락된 세부사항)을 더하고 요청 그룹화 및 라벨링 규칙이 필요하므로 나중에 추가하세요.

누가 티켓을 다루고 각 그룹에서 "완료"가 무엇인지 결정하세요. 팀 구성은 작고 명확하게 유지하세요. 예: Support는 접수와 기본 해결, Ops는 접근 및 계정 작업, Engineering은 버그와 코드 변경을 담당합니다. 어떤 팀이 특정 티켓 유형에 조치할 수 없다면 그 팀에 할당 가능하지 않아야 합니다.

현실적인 하루 범위를 위해 다음 결과를 약속하세요: 티켓 생성 및 조회(제목, 요청자, 긴급도, 카테고리), 분류 및 할당(소유자 및 팀, 그리고 명확한 "unassigned" 상태), SLA 시계 추적(첫 응답 기한 및 해결 기한), 기한 초과 시 에스컬레이션(적절한 채널 또는 사람에게 알림), 짧은 결과 노트와 함께 종료.

이것은 AppMaster에서 잘 맞습니다: 간단한 데이터 모델, 기본 내부 대시보드, 그리고 할당 및 에스컬레이션 알림을 위한 시각적 비즈니스 프로세스 로직.

지금은 지표는 건너뛰세요. 원시 데이터(타임스탬프, 상태 변경, 담당자 이력)를 캡처하되 리포트를 즉시 만들 필요는 없습니다. 나중에 응답까지 걸린 시간이나 상위 카테고리 같은 추세 대시보드를 추가하되, 분석이 오늘 사람들이 필요로 하는 도구를 지연시키지 않게 하세요.

간단한 체크: 새 요청이 9:00에 도착하고 아무도 11:00까지 보지 않았다면 첫 버전은 그 실패를 가시화하고 무시하기 어렵게 만들어야 합니다.

역할, 접근 권한, 책임

분류 도구는 아무도 명확히 책임을 지지 않을 때 실패합니다. 실제로 필요한 몇 가지 역할의 이름을 정하고, 권한을 지원 작업 방식에 맞추세요.

대부분 팀은 네 가지 역할로 거의 모든 상황을 커버할 수 있습니다:

• Requester: 티켓 생성, 댓글 추가, 자신의 티켓만 보기 가능.
• Agent: 자신에게 할당된 티켓 작업 및 상태, 우선순위, 노트 업데이트 가능.
• Team lead: 팀 내 작업 재할당, 에스컬레이션 승인, 우선순위 재지정 가능.
• Admin: 팀, 카테고리, SLA 규칙 같은 글로벌 설정 관리.

가시성도 결정해야 합니다. 하나의 모델을 정하고 고수하세요, 그렇지 않으면 사람들이 도구를 신뢰하지 않습니다.

실용적인 접근법: 요청자는 자신의 티켓만 보고, 에이전트는 팀 큐의 티켓을 보고, 팀 리드는 부서의 모든 티켓을 보고, 어드민은 모든 것을 봅니다. 프라이버시가 필요하면 리드와 어드민만 열람할 수 있는 "restricted" 플래그를 추가하세요.

책임은 복잡한 권한 매트릭스가 아니라 몇 가지 엄격한 규칙에서 나옵니다. 예: 팀 간 소유권 변경은 리드와 어드민만 가능하게 하고, 상태를 Resolved로 옮길 수 있는 것은 담당자(또는 리드)만 가능하게 하며, 종료는 해결 노트와 카테고리 필수로 하세요. 재오픈은 이유가 있어야 합니다.

마지막으로 감사 기록을 요구하세요. 서비스에 영향을 주는 모든 변경은 기록되어야 합니다: 상태, 담당자, 우선순위, SLA 티어, 에스컬레이션 등. 누가, 언제, 이전 값과 새 값을 저장하세요.

AppMaster에서는 내장 인증과 비즈니스 프로세스를 사용해 핵심 필드가 바뀔 때마다 AuditEvent 레코드를 쓰도록 강제할 수 있습니다.

빠른 테스트: 리드가 "왜 이 티켓이 오후 6:12에 해결로 표시되었나?"라고 물으면, 시스템은 추측 없이 한 화면에서 답할 수 있어야 합니다.

데이터 모델 청사진: 필요한 테이블과 필드

티켓 분류 도구는 데이터 모델에 의해 성공과 실패가 갈립니다. 테이블이 깔끔하면 워크플로와 대시보드도 단순하게 만들 수 있고(나중에 변경하기도 쉬움) 유지보수도 수월합니다.

데이터베이스에서 다섯 가지 빌딩 블록으로 시작하세요(예: AppMaster의 Data Designer와 PostgreSQL 사용):

• Tickets: 제목, 설명, 채널(이메일, 웹, 전화), 우선순위, 현재 상태, 요청자 정보, created_at 및 updated_at.
• People structure: 사용자(에이전트 및 어드민)와 팀(지원, 결제, 운영). 팀 멤버십, 역할, on_call 플래그 추가로 워크플로가 빠르게 올바른 사람을 찾게 함.
• Assignment history: 빠른 필터링을 위한 current_assignee_id는 티켓에 두되, 모든 재할당은 assigned_by, assigned_to, reason, assigned_at으로 저장.
• Conversation: 공개/고객용 vs 내부용 가시성 플래그가 있는 댓글 또는 메시지. 첨부파일은 메시지나 감사 항목에서 재사용할 수 있게 별도 테이블로 둠.
• Audit log: 상태 변경, SLA 타이머 시작/중지, 에스컬레이션 이벤트를 기록하는 한곳.

몇 가지 필드는 미래의 고통을 막습니다. first_response_due_at과 resolve_due_at을 추가하세요(계산하더라도 저장). last_customer_message_at와 last_agent_message_at을 저장하면 복잡한 쿼리 없이 침묵을 감지할 수 있습니다.

상태 및 우선순위는 enum(또는 참조 테이블)으로 만드세요. 이렇게 하면 보고가 일관되고 "High", "HIGH", "Urgent!!!" 같은 혼란을 피할 수 있습니다.

이해하기 쉬운 상태와 전환

사람들이 상태의 의미를 모르면 분류 도구는 무너집니다. 상태 집합은 작고 명확하게 유지하세요. 기본은: New, Triaged, In Progress, Waiting, Resolved, Closed.

각 상태는 하나의 질문에 답해야 합니다:

• New: 누가 이걸 봤나?
• Triaged: 누가 담당인지, 얼마나 긴급한지 아는가?
• In Progress: 누군가 적극적으로 작업 중인가?
• Waiting: 요청자, 벤더, 다른 팀 때문에 대기 중인가?
• Resolved: 해결이나 답변이 제공되었는가?
• Closed: 후속 조치와 리포팅까지 끝났는가?

전환 규칙을 문서화하고 누가 어디로 이동시킬 수 있는지 정하세요. AppMaster에서는 이 규칙을 시각적 비즈니스 로직으로 강제해 UI가 유효한 다음 동작만 보여줄 수 있습니다.

혼란을 막는 실용 규칙:

• Triaged로의 이동과 우선순위 및 담당자 설정은 분류 역할만 가능.
• Triaged에서 In Progress로의 이동은 담당자만 가능.
• 모든 에이전트는 Waiting으로 설정할 수 있지만, 대기 사유(고객 응답 대기, 벤더, 내부 의존 등)를 선택해야 함.
• Resolved는 해결 노트가 필요하고, Closed는 종료 사유(중복, 수정 불가, 확인됨) 필요.
• 재오픈은 Resolved 또는 Closed에서만 허용되며 항상 재오픈 사유 필요.

타임스탬프가 무엇을 생성하는지 결정하세요. 이는 리포트와 SLA의 근거가 됩니다. 첫 응답 시간은 사람이 처음으로 공개 답글을 올릴 때 고정하고, Resolved는 상태가 Resolved가 될 때 고정하세요. 재오픈이 일어나면 원래 타임스탬프는 유지하고 reopened_at을 추가해 반복 이슈를 기록하세요.

SLA를 복잡하게 만들지 않고 모델링하는 방법

SLA는 타이머가 있는 약속입니다. 대부분 팀이 실제로 쓰는 타이머에 집중하세요: 첫 응답(누군가 인지함), 다음 응답(대화가 이어짐), 해결(문제가 해결됨).

규칙을 고르는 간단한 방법은 우선순위별로 정하는 것입니다. 고객 등급을 지원한다면 고객 유형별로 한 번 더 분기하세요. 이렇게 하면 예외의 미로 없이 예측 가능한 SLA 규칙을 얻을 수 있습니다.

SLA 기한은 기간뿐 아니라 타임스탬프로 저장하세요. 두 가지를 모두 원하면 저장해도 좋지만, 기한 타임스탬프가 보고와 에스컬레이션을 신뢰 가능하게 만듭니다. 예: P1 티켓이 10:00에 생성되면 FirstResponseDueAt = 10:30, NextResponseDueAt = 12:00, ResolutionDueAt = 18:00처럼 계산해 저장하세요.

타이머를 일시정지하는 조건을 명확히 하세요. 대부분의 팀은 Waiting on customer 상태에서 next response와 resolution 타이머를 일시정지하지만 first response는 일시정지하지 않습니다.

• 첫 응답 타이머는 티켓 생성 시 시작
• 다음 응답 타이머는 마지막 에이전트 답글 이후 시작
• 타이머는 특정 상태에서만 일시정지(예: Waiting on customer)
• 티켓이 활성 상태로 돌아오면 타이머 재개
• 현재 시간이 저장된 기한 타임스탬프를 지나면 위반 발생

SLA 충족으로 무엇을 셀지 하나의 이벤트로 고정하세요: 에이전트 코멘트, In Progress로의 상태 변경, 혹은 발신 메시지 등 하나를 정하고 고수하세요.

AppMaster에서는 티켓 생성, 댓글 추가, 상태 변경을 트리거로 하여 기한 타임스탬프를 재계산해 티켓에 다시 쓰는 비즈니스 프로세스를 모델링할 수 있습니다.

단계별 워크플로: 새 티켓에서 종료까지

경로가 예측 가능할 때 분류 도구는 가장 잘 작동합니다. 대부분의 티켓을 커버하는 하나의 "해피 패스"를 목표로 하고 예외는 숨기지 말고 가시화하세요.

1) 티켓 생성(기본값 설정)

폼, 이메일 가져오기, 내부 요청에서 티켓이 생성되면 몇 가지 필드를 자동으로 설정해 빈 상태로 시작하지 않도록 하세요. 초기 상태(보통 New), 기본 우선순위(예: Normal), 요청자, created_at과 last_activity_at 같은 타임스탬프를 저장합니다.

분류에 필요한 최소 항목: 짧은 제목, 설명, 카테고리 또는 서비스 영역. 누락이 있으면 티켓을 Incomplete로 표시해 실수로 할당되는 것을 방지하세요.

2) 분류(작업 준비)

분류는 빠른 품질 검사입니다. 필수 필드를 확인하고 카테고리를 설정하며 간단한 규칙(예: 우선순위 + 고객 유형 = 첫 응답 기한)으로 SLA 기한을 계산하세요. AppMaster를 사용한다면 이것을 시각적 비즈니스 프로세스로 만들어 due_at 필드를 쓰고 triage_event 항목을 기록할 수 있습니다.

진행 전에 "이게 우리 책임인가?"를 빠르게 확인하세요. 아니라면 올바른 큐로 라우팅하고 짧은 메모를 남겨 반송되지 않게 하세요.

3) 할당(소유자 선택 및 알림)

초기에는 수동 할당 또는 규칙 기반(카테고리 -> 팀, 그다음 열린 건수가 가장 적은 사람) 할당 중 선택할 수 있습니다. 담당자가 설정되면 상태를 Triaged로 유지하고 소유권이 보이도록 명확한 알림을 보내세요.

4) 작업(시간과 커뮤니케이션 투명성 유지)

작업 중에는 In Progress나 Waiting on Customer 같은 상태 변경을 허용하세요. 공개 답글마다 next_response_due 시간을 업데이트하고 각 코멘트는 last_activity_at을 갱신하게 하여 SLA 추적과 에스컬레이션이 신뢰성 있게 작동하게 합니다.

5) 해결 및 종료(결과 캡처)

해결에는 짧은 요약, 해결 코드(고침, 수정 불가, 중복) 및 resolved_at이 필요합니다. 닫기는 일정 기간 무응답이면 자동으로 하거나 확인 후 수동으로 할 수 있지만 항상 closed_at을 저장해 보고가 일관되게 유지되게 하세요.

사람들이 무시하지 않는 에스컬레이션 알림

에스컬레이션이 실패하는 이유는 두 가지입니다: 너무 자주 발생하거나 수신자에게 다음 행동을 알려주지 않습니다. 목표는 더 많은 알림이 아니라 적절한 시점에 한 번의 명확한 재촉입니다.

몇 가지 트리거만 선택하세요

설명하고 테스트하기 쉬운 트리거로 시작하세요. 대부분 팀은 다음 소수의 트리거면 충분합니다: SLA 위험(예: 창의 75% 소진), SLA 위반, 짧은 유예 기간 후 미할당(예: 10–15분), Waiting에 오래 묶여 있음.

각 트리거를 문제를 해결할 수 있는 가장 작은 사람 집합으로 라우팅하세요. 먼저 담당자에게 알리고, 담당자가 없으면 팀 리드나 온콜 로테이션에게 알립니다. 요청자에게는 입력이 필요할 때나 약속된 해결 시간이 변경될 때만 알리세요.

알림은 실행 가능하고 무시하기 어렵게 만드세요

좋은 에스컬레이션 메시지에는 티켓 제목, 우선순위, 현재 상태, 남은 시간(또는 초과된 시간), 그리고 다음 행동 하나가 포함되어야 합니다. 예: "티켓 #1842가 위반 30분 전입니다. 상태: In Progress. 담당자: unassigned. 다음: 담당자 지정 또는 우선순위 하향과 메모."

의도가 있는 채널을 사용하세요. 이메일은 "위험" 수준에 적당하고, SMS나 Telegram은 "위반" 또는 "중요 미할당"에 더 적합합니다. 대시보드 내부의 인앱 알림은 조용한 재촉에 유용합니다.

스팸을 막으려면 간단한 쓰로틀 규칙을 추가하세요: 단계당 한번의 알림, 반복은 예: 60분 쿨다운. 티켓 상태나 담당자가 바뀌면 에스컬레이션 타이머를 리셋하세요.

모든 알림을 기록해 신뢰 문제를 디버그할 수 있어야 합니다. 최소한 언제 보냈고 어떤 트리거로, 어떤 채널과 수신자에게, 전송 결과(전송, 실패, 반송)를 저장하세요. 가능하면 수신 확인(클릭, 응답, 확인 표시)도 캡처하세요.

AppMaster에서는 Notification 테이블과 비즈니스 프로세스를 사용해 타이머를 확인하고 수신자(담당자, 리드, 온콜)를 선택해 이메일, SMS, Telegram 모듈로 전송하고 인앱 기록을 남기는 매핑이 깔끔하게 됩니다.

설계 테스트용 현실적 예시

스크린을 만들기 전에 한 가지 어려운 시나리오로 실행해 보세요. 상태, 기한, 알림이 현실에서 통하는지 빠르게 드러납니다.

12:10 PM입니다. 핵심 고객으로부터 제목에 urgent가 있는 "Payment failed" 티켓이 도착했지만 할당은 안 되어 있습니다. 점심 시간에도 아무도 대시보드를 보지 않는다고 해도, 분류 시스템은 이를 시간 민감적으로 처리해야 합니다.

먼저 분류가 Category = Billing, Priority = Urgent로 설정됩니다. 이 필드가 설정되는 순간 시스템은 첫 응답 기한(예: 15분)을 계산해 티켓에 저장합니다. 그 기한은 목록 보기에서 눈에 띄어야 하고 숨겨져 있어서는 안 됩니다.

다음으로 자동 할당이 작동합니다. Billing의 온콜 에이전트를 선택하고 짧은 알림을 보냅니다: "긴급 결제 티켓이 할당되었습니다. 첫 응답 기한: 12:25." AppMaster로 만든다면 이 흐름은 티켓 생성(또는 우선순위 변경)을 트리거로 몇 개의 결정 블록을 쓰면 자연스럽게 구성됩니다.

12:25까지 공개 답글이 없으면 에스컬레이션합니다. 일관성 있고 단순하게: 팀 리드에게 알리고, 첫 응답 SLA 미준수에 대한 내부 코멘트를 추가하고 escalation_level 필드를 설정합니다(사람들이 오용할 상태를 새로 만들지 마세요).

12:40에 에이전트가 답글을 올리고 상태를 Waiting on Customer로 표시하면 SLA는 일시정지되어야 합니다. 고객이 2:05 PM에 답하면 SLA는 멈춘 지점에서 재개되어야 하고, 처음부터 다시 시작해서는 안 됩니다. 이 한 가지 테스트로 대부분의 워크플로 실수를 잡을 수 있습니다.

먼저 만들어야 할 화면

하루 안에 만들 수 있는 화면은 교류를 줄입니다: 큐를 보는 곳, 결정하는 곳, 작업하는 곳.

1) 티켓 목록(분류 큐)

여기가 홈 화면입니다. 10초 안에 지금 무엇이 주목받아야 하는지 답할 수 있어야 합니다.

상태, 우선순위, SLA 상태(정상, 위험, 위반), 미할당, 카테고리 같은 필터를 포함하세요.

각 행은 간결하게: 제목, 요청자, 우선순위, 현재 담당자, SLA 카운트다운, 마지막 업데이트 시간.

2) 티켓 상세(작업이 이루어지는 곳)

상세 페이지는 하나의 타임라인처럼 느껴져야 합니다. 주요 행동을 상단에 놓으세요: 할당, 상태 변경, 코멘트 추가, 우선순위 설정. 그다음에 전체 이력(상태 변경, 할당, 코멘트)을 순서대로 보여줍니다.

SLA는 시끄럽지 않게 가시화하세요. 간단한 카운트다운 라벨과 색상으로 충분합니다. 엣지 케이스를 위한 명확한 Escalate 버튼을 추가하세요.

3) 분류 폼(빠른 접수)

누군가 티켓을 생성할 때는 최소 필수 항목: 카테고리, 짧은 요약, 영향도를 요구하세요. "나에게 할당"이나 "중복 표시" 같은 빠른 액션을 추가하세요. 가능하면 카테고리나 워크로드 기반으로 추천 담당자를 보여주세요.

4) 에이전트 뷰 vs 리드 뷰

에이전트는 My tickets, Due soon, 원클릭 상태 업데이트가 필요합니다. 리드는 Unassigned, At risk, Breached와 빠르게 할당을 재조정할 수 있는 기능이 필요합니다.

5) 작은 관리자 화면

관리자는 카테고리와 SLA 규칙(카테고리 및 우선순위별), 온콜 로테이션 관리 정도만 있으면 됩니다. AppMaster에서는 UI 빌더로 이 화면들을 빠르게 조립하고 규칙은 시각적 비즈니스 프로세스에 둬서 앱을 다시 작성하지 않고도 변경할 수 있습니다.

분류 시스템을 망치는 흔한 함정

대부분 분류 도구는 규칙이 모호하고 UI가 우회 방법을 장려할 때 실패합니다.

첫 번째 함정은 상태 확장입니다. 팀은 모든 예외에 대해 새로운 상태를 추가하고(예: "Waiting for Vendor", "Waiting for Finance", "Blocked by Product"), 곧 아무도 각 상태의 의미에 동의하지 않게 됩니다. 상태는 적게 유지하고 진행 조건(예: In Progress는 담당자가 설정되어 있고 다음 행동이 명확함)을 정의하세요.

SLA 타이밍이 두 번째 함정입니다. 절대 멈추지 않는 시계는 에이전트가 고객 응답을 기다릴 때 벌을 줍니다. 항상 멈추는 시계는 SLA를 무의미하게 만듭니다. 한 문장으로 설명할 수 있는 명확한 일시정지 규칙을 고르고 특정 상태 집합(예: 고객 응답 대기일 때만 일시정지)에 묶으세요.

알림은 소유자가 없으면 실패합니다. 모든 사람에게 알림이 가면 배경 소음이 됩니다. 에스컬레이션은 온콜 리드나 팀 인박스 같은 특정 사람 또는 역할로 보내고, 다음 행동을 명확히 하세요.

흔한 실패 패턴:

• 감정(예: "Stuck")을 설명하는 상태 이름 대신 조건(예: "Waiting on requester response")을 사용하지 않음.
• 판단을 필요로 하는 SLA 규칙(예: "공정해 보이면 일시정지") 사용.
• 에스컬레이션 알림을 광범위한 채널에 보내서 소음만 만듦.
• 변경 이력이 없음(누가 우선순위를 변경했는지, 재할당했는지, 재오픈했는지 등).
• 요청자 메시지와 내부 메모가 섞여 실수로 과도한 정보 공유.

간단한 테스트: 티켓이 에스컬레이션되어 요청자가 불만을 제기하면, 각 단계에서 누가 소유했는지, SLA가 언제 일시정지되었는지, 외부에 무엇이 전달되었는지를 1분 내에 답할 수 있나요? 아니라면 감사 기록을 추가하고 공개 답글과 내부 노트를 분리하세요. AppMaster에서는 별도 데이터 필드와 화면 노출 규칙으로 이를 강제할 수 있습니다.

빠른 체크리스트와 다음 단계

구축 전에 "내일 바로 운영할 수 있나?" 관점으로 한 번 점검하세요. 도구는 데이터, 규칙, 알림이 서로 맞아야 동작합니다.

확인할 항목:

• 데이터 모델: 티켓(제목, 설명, 우선순위, 상태, 요청자), 사용자, 팀, 댓글, 감사 로그(누가 무엇을 언제 변경했는지), SLA 기한(첫 응답 기한, 해결 기한, 일시정지 만료).
• 워크플로: 명확한 전환( New -> Triaged -> In Progress -> Waiting -> Resolved -> Closed ), 할당 규칙(수동 vs 자동), SLA 일시정지/재개 규칙(대기 상태에서만 일시정지, 활성 상태에서 재개).
• 알림: 트리거(위험 임박, 위반, 재할당, 에스컬레이션), 수신자(담당자, 팀 리드, 온콜), 쓰로틀(매분 푸시 금지), 로그 기록.
• UI: 큐용 리스트 뷰, 티켓 상세 페이지, 분류 화면(할당, 우선순위, 상태 설정), 팀/온콜/템플릿 관리를 위한 작은 관리자 영역. 역할 기반 접근을 명확히 하세요.
• 책임성: 각 티켓은 한 번에 한 명의 소유자, 하나의 다음 행동, 모두가 볼 수 있는 하나의 기한을 가짐.

먼저 테이블을 만들고 그다음 워크플로를 연결하세요. AppMaster에서는 Data Designer(PostgreSQL)에 데이터베이스를 모델링한 뒤 Business Process Editor에서 상태 전환, SLA 타이머, 에스컬레이션 규칙을 시각적으로 구현할 수 있습니다. 한 팀과 한 SLA 정책으로 시작해 일주일간 운영해보고 안정화되면 복잡도를 추가하세요(다중 큐, 영업시간, 맞춤 폼 등).

안정적으로 느껴지면 팀이 편한 환경에 배포하세요: AppMaster Cloud, AWS, Azure, Google Cloud 또는 소스 코드를 내보내 자가 호스팅할 수 있습니다. 큰 구축 없이 접근 방법을 시험해보고 싶다면 AppMaster at appmaster.io는 내부 도구용으로 설계되어 시각적 워크플로와 프로덕션 준비 앱 생성을 지원합니다.