SLA 트래커: 기한, 일시 중지, 팀 보고서 만들기

고객 운영 팀이 SLA 기한을 놓치는 이유

고객 운영 팀이 SLA를 놓치는 이유는 누군가 날짜를 무시해서인 경우가 드뭅니다. 기한은 바뀌고, 티켓은 담당자 사이를 이동하며, 고객의 답변 때문에 업무가 며칠씩 멈출 수 있습니다. 변경될 때마다 누군가 업데이트하지 않으면 기한 열 하나만 있는 스프레드시트는 곧 한계에 부딪힙니다.

첫 번째 문제는 모든 SLA 목표를 하나의 기한으로 처리하는 것입니다. 최초 응답 목표는 에이전트가 새 요청을 얼마나 빨리 확인하는지를 측정합니다. 해결 목표는 팀이 문제를 해결하는 데 허용된 시간을 측정합니다. 티켓이 15분 안에 응답 목표를 충족해도 3일 뒤 해결 목표를 놓칠 수 있습니다. 기한 하나만으로는 어떤 약속을 지키지 못했는지 알 수 없습니다.

담당자도 또 다른 문제를 만듭니다. 에이전트가 답변하고, 전문가가 조사하고, 관리자가 수정 사항을 승인할 수 있습니다. 활성 SLA 타이머를 책임지는 사람이 없으면 모두가 다른 누군가가 지켜보고 있다고 생각할 수 있습니다. 티켓은 시간이 다 될 때까지 대기열에 남습니다.

오전 10시에 계정 액세스 문제가 접수되었다고 가정해 보겠습니다. 에이전트는 10시 12분에 답변해 30분 응답 목표를 충족한 뒤, 10시 20분에 스크린샷을 요청했습니다. 고객은 다음 날 오후에 답변했습니다. 트래커가 이 대기 시간을 해결 목표에 포함하면 지원 팀이 사용할 수 없었던 시간을 지원 팀의 책임으로 돌리게 됩니다. 반대로 타이머를 일시 중지하고 다시 시작하지 않으면 결과는 반대 방향으로 부정확해집니다.

트래커는 모든 티켓에 담당자, 팀, 우선순위, 응답 및 해결 기한, 타이머 상태, 일시 중지 사유, 변경 이력을 담은 하나의 공유 운영 기록을 제공해야 합니다. 그러면 에이전트는 위반이 임박한 업무에 집중할 수 있고, 관리자는 인력 배치, 인계 또는 고객 대기 시간으로 인한 지연을 파악할 수 있습니다.

작고 안정적인 대기열이라면 수동 시트도 사용할 수 있습니다. 하지만 기한이 우선순위, 영업시간, 재배정, 일시 중지에 따라 달라지기 시작하면 트래커에 일관된 규칙이 필요합니다.

각 SLA 기록에 필요한 항목 정하기

모든 티켓에는 누가 담당하는지, 어떤 약속이 적용되는지, 타이머를 실행해야 하는지를 설명할 수 있는 충분한 정보가 필요합니다. 먼저 고객 또는 계정, 우선순위, 배정 팀, 티켓 담당자, 현재 상태를 정하세요.

그다음 기한을 결정하는 필드를 추가합니다.

• SLA 정책, 예: «표준 지원» 또는 «우선 지원»
• 시작 시간
• 최초 응답 기한과 해결 기한
• 일시 중지 사유와 시작 시간
• 재개 시간 또는 전체 일시 중지 시간

최초 응답과 전체 해결을 분리하세요. 팀이 최초 답변은 영업일 기준 4시간 이내로 약속하면서 해결에는 영업일 2일을 허용할 수 있습니다. 기한 하나만 두면 빠른 확인 답변이 해결되지 않은 티켓을 가릴 수 있습니다.

에이전트에게 «위반»을 수동으로 선택하게 하지 마세요. 현재 시간, 기한, 티켓 상태, 유효한 일시 중지 정보를 바탕으로 계산하세요. 예를 들어 기한이 지났고 티켓이 열려 있으며 타이머가 활성 상태라면 해결 SLA를 위반한 것입니다.

AppMaster를 사용하면 이 로직을 한곳에서 관리할 수 있습니다. Data Designer에서 티켓 필드를 모델링하고, 시각적 Business Process에서 에이전트가 티켓을 만들거나 수정할 때마다 기한과 위반 상태를 계산할 수 있습니다.

트래커를 만들기 전에 SLA 규칙 정하기

명확한 규칙은 SLA 결과를 공정하게 만듭니다. 수식이나 보고서를 만들기 전에 각 티켓 유형의 목표를 정하세요. 그렇지 않으면 두 에이전트가 같은 요청을 다르게 처리하고 위반 건수의 의미가 약해집니다.

대부분의 팀은 우선순위, 고객 요금제, 요청 유형에 따라 목표를 다르게 설정합니다. 첫 버전은 작게 시작하세요. 예를 들어 긴급한 운영 장애는 1시간 이내 최초 응답, 유료 요금제의 액세스 문제는 영업시간 기준 4시간, 일반적인 질문은 영업일 기준 2일로 정할 수 있습니다.

각 규칙을 쉬운 문장으로 작성하세요. «프리미엄 고객의 높은 우선순위 결제 문제에는 영업시간 기준 2시간 이내에 최초 응답해야 한다»라고 쓰면 저장해야 할 데이터가 분명해집니다. 우선순위, 요금제, 요청 유형, 생성 시간, 최초 응답 시간이 필요합니다.

근무 일정 정하기

목표 시간이 24시간 내내 흐르는지, 지원 시간에만 흐르는지 결정하세요. 지원 시간이 월요일부터 금요일, 9시부터 17시까지라면 금요일 16시 30분에 접수된 2시간 목표 티켓의 기한은 금요일 저녁이 아니라 월요일 10시 30분입니다.

근무일, 지원 시간, 시간대, 공휴일, 별도의 24시간 장애 대응 일정을 문서화하세요. 가능하면 정책마다 이름이 지정된 캘린더 하나를 사용합니다. 여러 나라의 고객을 상대하는 팀에는 지역별 캘린더가 필요할 수 있지만, 고객마다 캘린더를 만들면 관리 부담이 커집니다.

시작 지점과 정책 담당 정하기

타이머가 정확히 언제 시작되는지 정하세요. 새 티켓은 보통 시스템이 받은 시점에 시작합니다. 다시 열린 티켓에는 별도의 규칙이 필요합니다. 남은 시간을 계속 사용할지, 기존 타이머를 다시 시작할지, 새로운 목표를 시작할지 정하고 일관되게 적용하세요.

정책 변경을 담당할 사람이나 소규모 그룹을 지정하세요. 에이전트는 티켓 데이터를 수정할 수 있지만 위반을 없애기 위해 목표 시간을 바꿔서는 안 됩니다. 각 기록에 정책 버전을 저장하고, 승인된 예외에는 사유와 날짜를 남기세요.

AppMaster 앱에서는 관리자 영역 하나에서 정책을 관리하고 티켓이 시스템에 들어올 때 맞는 규칙을 적용할 수 있습니다. 여러 스프레드시트 수식 대신 일관된 타이머 하나를 사용하게 됩니다.

트래커의 데이터 구조 설계하기

첫 버전은 운영 책임자가 티켓 하나를 보고 기한이 바뀐 이유를 이해할 수 있을 만큼 단순하게 만드세요.

먼저 ID, 제목, 고객, 우선순위, 상태, 생성 시간, 최초 응답 시간, 해결 시간, 기한, 배정 담당자, 책임 팀이 포함된 티켓 테이블을 만드세요. 여러 사람이 댓글을 달더라도 각 티켓에는 현재 담당자 한 명과 팀 하나를 지정해야 합니다.

팀과 SLA 정책은 별도 레코드로 관리하세요. 팀 레코드에는 이름과 영업시간 일정을 저장할 수 있습니다. 각 정책에는 적용 대상 티켓, 응답 및 해결 목표, 타이머 유형, 고객 대기 시간이 타이머를 멈추는지 여부를 적습니다.

날짜, 관련 팀 또는 지역, 짧은 라벨이 포함된 공휴일 레코드를 추가하세요. 모든 타임스탬프는 보통 UTC처럼 일관된 시간대로 저장한 뒤, 필요할 때 화면에서 현지 시간으로 표시합니다. 시간대가 섞이면 주말과 일광 절약 시간 변경 시 오류가 발생합니다.

과거 상태를 덮어쓰지 말고 상태 이력을 보관하세요. 각 항목에는 티켓 ID, 이전 상태와 새 상태, 이벤트 시간, 변경을 수행한 사람 또는 규칙을 기록합니다. «고객 대기», «고객 답변», «배정», «해결» 같은 이벤트도 남기세요.

이 이력은 기한이 바뀐 이유를 설명합니다. 기한이 화요일 오전에서 화요일 오후로 이동했다면 관리자는 고객을 기다리는 3시간 동안 팀이 SLA를 일시 중지했다는 사실을 확인할 수 있습니다. AppMaster의 시각적 Data Designer로 관련 레코드를 모델링하고 Business Process Editor에서 상태 변경 후 기한을 업데이트할 수 있습니다.

티켓 기한 계산하기

시스템이 지원 티켓을 받은 때처럼 명확한 이벤트에서 타이머를 시작하세요. 누군가 우연히 티켓을 확인한 시점에 시작하지 마세요. 시작 시간을 저장해야 이후 모든 계산이 같은 기준점을 사용합니다.

그다음 고객의 요금제, 티켓 유형, 우선순위 또는 지역에 맞는 SLA 정책을 선택합니다. 그리고 다음 순서로 기한을 계산하세요.

1. 티켓의 목표를 읽습니다. 예를 들어 응답 시간 4시간입니다.
2. 정책에서 허용한 근무 시간만 더합니다.
3. 정책에서 제외한 휴무 시간, 주말, 공휴일을 건너뜁니다.
4. 기한을 티켓에 저장합니다.
5. 우선순위, 요금제 또는 카테고리가 바뀌어 다른 정책이 선택되면 다시 계산합니다.

영업시간을 적용하면 생각보다 복잡해집니다. 4시간 SLA가 오후 4시에 시작되고 지원 시간이 9시부터 17시까지라면 그날 남은 시간은 1시간입니다. 기한은 오후 8시가 아니라 다음 영업일 정오입니다.

티켓의 우선순위가 바뀌면 기존 시작 시간은 유지하고 문서화한 에스컬레이션 규칙을 적용하세요. 일부 팀은 원래 시작 시점부터 긴급 목표를 적용하고, 다른 팀은 티켓이 에스컬레이션된 시점에 새 목표를 시작합니다. 모두가 같은 방식을 따른다면 어느 쪽도 사용할 수 있습니다.

정확한 기한과 남은 시간을 모두 표시하세요. «2시간 15분 남음», «1일 후 기한», «35분 초과» 같은 라벨은 타임스탬프보다 대기열을 빠르게 확인하는 데 도움이 됩니다. 정상 티켓에는 중립 상태를, 기한이 가까워지면 경고를, 기한이 지나면 명확한 위반 상태를 표시하세요.

고객 답변을 기다릴 때 타이머 일시 중지하기

고객 없이는 티켓을 진행할 수 없을 때만 타이머를 일시 중지하세요. 정보, 확인, 액세스 권한, 승인 또는 파일을 기다리는 경우가 일반적인 예입니다. 동료를 기다리는 것과 같은 내부 지연은 SLA를 일시 중지하면 안 됩니다.

상태는 짧고 명확하게 유지하세요.

• 고객 정보 대기
• 고객 승인 대기
• 고객 액세스 대기
• 고객 제공 파일 대기

에이전트가 이러한 상태 중 하나를 선택하면 정확한 일시 중지 시간과 사유를 저장하세요. 고객에게 답변을 요청한 메시지나 이벤트도 기록합니다. 그러면 관리자가 일시 중지가 타당했는지 확인할 수 있습니다.

고객이 답변하면 답변 시간에 타이머를 다시 시작하세요. 대기 시간을 total paused time에 더한 뒤 영업시간 규칙에 따라 남은 시간을 다시 계산합니다. 고객이 90분 동안 답변을 기다리게 했다면 휴무 시간을 고려해 기한을 90분 뒤로 이동합니다.

티켓 화면에 일시 중지 시간을 표시하세요. 에이전트는 티켓이 15분 기다렸는지 3일 기다렸는지 알아야 하고, 관리자는 대기 상태로 반복해서 돌아가는 티켓을 확인할 수 있어야 합니다.

일시 중지 사유는 SLA 정책에서 허용한 항목으로 제한하세요. 일시 중지를 승인하기 전에 고객 요청 이벤트가 있는지 확인하도록 하세요. AppMaster에서는 Business Process가 새 상태를 확인하고, 일시 중지 시작 시간을 저장하며, SLA 레코드를 업데이트하기 전에 잘못된 변경을 거부할 수 있습니다.

자동으로 발송되는 «메시지를 받았습니다» 이메일은 타이머를 다시 시작하면 안 됩니다. 고객의 수신 메시지 또는 에이전트가 확인한 답변을 사용하고 전체 일시 중지 이력을 티켓에 보관하세요.

고객 지원 사례로 확인하기

고객이 화요일 10시에 «청구서에 왜 두 건의 요금이 표시되나요?»라는 결제 질문을 보냈다고 가정해 보겠습니다. 트래커는 티켓 B-184를 만들고 Support에 배정한 뒤 결제 SLA를 적용합니다. 팀에는 유용한 최초 응답까지 영업시간 기준 4시간, 해결까지 영업시간 기준 8시간이 주어집니다.

Support의 운영 시간은 월요일부터 금요일, 9시부터 17시까지입니다. 10시 35분에 에이전트가 계정을 확인 중이라고 답합니다. 최초 응답 타이머는 35분에서 멈추고 3시간 25분이 남습니다. 티켓은 최초 응답 목표를 충족했습니다.

11시에 에이전트가 청구서 번호를 요청하고 티켓을 «고객 대기»로 표시합니다. 1시간 동안 실제 업무를 수행한 뒤 해결 타이머가 일시 중지됩니다. 트래커는 일시 중지 시작 시간과 사유를 저장합니다.

고객은 15시 30분에 답변합니다. 트래커는 일시 중지된 4시간 30분을 기한에 다시 반영합니다. 원래 해결 기한은 화요일 18시였으므로 남은 시간이 다음 영업일로 넘어가 조정된 기한은 수요일 14시 30분이 됩니다.

에이전트는 수요일 15시 10분에 문제를 해결합니다. 티켓은 40분 늦었습니다. Support의 해결 지연 1건으로 집계되지만 최초 응답은 제시간에 처리되었습니다.

위반 보고서는 이 결과를 분명히 보여줘야 합니다. Support는 결제 티켓 1건을 받았고 최초 응답 목표를 지켰지만, 해결 목표를 40분 넘겼으며 고객을 4시간 30분 기다렸습니다. 전체 티켓 경과 시간만 보면 잘못된 결론에 이르게 됩니다.

팀별 SLA 위반 보고하기

필요한 조치가 발생하기 전에 기한이 지나면 티켓은 SLA를 위반한 것입니다. 고객 대기 중 유효한 일시 중지를 반영해 조정된 기한을 사용하세요.

기한이 지난 미해결 티켓과 늦게 해결된 티켓을 분리하세요. 기한이 지난 미해결 티켓은 지금 처리해야 합니다. 늦게 해결된 티켓은 성과 보고에 포함합니다. 둘을 합치면 긴급한 업무가 가려지고 보고서를 사용하기 어려워집니다.

각 기간의 결과를 기한이 지났을 때 티켓을 담당하던 팀별로 그룹화하세요. 정책, 우선순위, 날짜 범위로 필터링합니다. 4시간 응답 정책을 사용하는 결제 팀을 영업일 기준 2일 해결 정책을 사용하는 기술 에스컬레이션 팀과 직접 비교해서는 안 됩니다.

건수와 비율을 함께 사용하세요.

• 활성 SLA가 있는 전체 티켓
• 목표 시간 내 해결된 티켓
• 기한이 지난 미해결 티켓
• 기한 후 해결된 티켓
• 위반율, SLA가 있는 티켓 중 위반 티켓의 비율

위반율 50%는 티켓 2건 중 1건이 늦은 경우와 100건 중 50건이 늦은 경우 의미가 다릅니다. 티켓 세부 정보와 함께 추이를 검토하세요. 높은 우선순위 위반이 자주 발생한다면 전체 업무량보다 에스컬레이션 규칙이나 인계 방식에 문제가 있을 수 있습니다.

유용한 보고서에서는 관리자가 늦은 티켓 목록을 열어 정책과 우선순위를 확인하고, 위반 시점의 담당자를 볼 수 있어야 합니다. 보고서는 팀이 티켓을 너무 빨리 닫도록 유도하기보다 개선이 필요한 업무를 실질적으로 검토하는 데 도움이 되어야 합니다.

에이전트와 관리자를 위한 화면 만들기

에이전트에게는 오래된 티켓으로 가득한 보고서가 아니라 짧은 업무 목록이 필요합니다. 열린 티켓마다 담당자, 팀, 우선순위, 기한, 타이머 상태, 남은 시간을 표시하세요. 티켓이 팀 사이를 이동하면 담당자 변경을 즉시 기록합니다.

타이머 라벨은 쉽게 이해할 수 있게 하세요. «활성»은 다음 조치를 팀이 책임진다는 뜻입니다. «일시 중지, 고객 대기»는 타이머가 멈췄다는 뜻입니다. 활성 시간과 일시 중지 시간을 따로 표시하면 티켓이 며칠 동안 열린 이유를 이해할 수 있습니다.

에이전트 화면에는 다음 4시간 내 기한인 티켓, 기한이 지난 티켓, 고객 답변을 기다리는 티켓, 오늘 재배정된 티켓을 포함할 수 있습니다. 기한 전에 경고를 보내세요. 4시간 응답 목표에는 3일 해결 목표보다 이른 알림이 필요합니다.

관리자에게는 다른 화면이 필요합니다. 주간 보고서에서 기한 초과 티켓을 팀별로 묶고 위반 건수, 달성률, 평균 초과 시간, 기한 후에도 열려 있는 티켓을 보여줄 수 있습니다. 기한이 지난 각 항목에 담당자와 마지막 업데이트도 포함하세요.

정책 변경에 대한 감사 기록을 유지하세요. 운영 팀이 목표를 8시간에서 12시간으로 바꿨다면 누가 언제 변경했는지, 어떤 새 티켓에 새 규칙이 적용되는지 기록합니다. 과거 결과에는 각 티켓이 시작될 때 적용된 규칙을 남겨야 합니다.

AppMaster에서는 에이전트와 관리자를 위한 웹 화면을 따로 만들면서도 두 화면의 기반이 되는 티켓 데이터와 비즈니스 규칙은 공유할 수 있습니다.

SLA 결과를 왜곡하는 실수

기반 규칙이 잘못되면 깔끔한 차트도 잘못된 이야기를 전달할 수 있습니다.

시간 규칙을 문자 그대로 적용하기

계약이 영업시간을 약속했다면 달력 시간으로 계산하지 마세요. 금요일 오후 4시 30분에 열린 티켓의 영업시간 기준 8시간 응답 목표가 토요일 오전 12시 30분에 위반되는 것은 아닙니다. 정책에 정의된 근무시간과 공휴일만 계산하세요.

일시 중지에도 같은 원칙을 적용하세요. «고객 대기» 상태는 팀이 명확한 요청을 보냈고 답변 없이는 진행할 수 있을 때만 SLA를 멈춰야 합니다. 해당 라벨이 붙은 모든 티켓을 일시 중지하면 팀의 지연이 가려집니다.

각 결과를 설명하는 날짜를 보관하세요. 원래 기한, 사용한 정책, 모든 일시 중지 시작 및 종료 시간, 일시 중지 사유, 조정된 기한, 해결 시간, 티켓을 닫은 사람을 기록합니다. 이 이력이 없으면 티켓이 제시간에 처리된 이유를 아무도 확인할 수 없습니다.

담당을 한 번만 집계하기

팀 보고서에는 담당 규칙 하나를 사용하세요. Support가 티켓을 Billing으로 재배정했다면 같은 위반을 두 팀에 모두 집계하지 마세요. 기한이 지났을 때 티켓을 담당한 팀에 결과를 배정하고 인계는 별도로 보고할 수 있습니다.

티켓을 닫기 전에 해결 타임스탬프를 필수로 입력하게 하세요. 닫힘 상태만으로는 업무가 끝난 시간을 알 수 없습니다. 예를 들어 티켓이 오후 2시에 Support에서 Billing으로 이동하고 오후 3시에 위반되었다면, 위반 시점 담당 규칙에 따라 Billing이 책임집니다. 보고서에는 Support의 이전 인계를 표시하되 두 번째 위반을 추가하지 않습니다.

출시 전에 트래커 점검하기

에이전트가 트래커를 사용하기 전에 모든 SLA 정책을 검토하세요. 각 정책에는 4시간 최초 응답이나 영업일 기준 2일 해결처럼 명확한 목표와 적용 캘린더가 필요합니다. 고객, 요금제 또는 우선순위 규칙에 맞지 않는 티켓을 위한 기본 정책도 정하세요.

일반적인 사례뿐 아니라 까다로운 시간 조건도 테스트하세요.

• 업무가 끝나기 직전에 티켓을 만들고 남은 시간이 다음 영업일로 넘어가는지 확인합니다.
• 주말이나 공휴일 직전에 티켓을 만들고 기한이 휴무 기간을 건너뛰는지 확인합니다.
• 고객 답변을 기다리도록 티켓을 일시 중지하고 답변을 추가한 뒤 타이머가 올바르게 재개되는지 확인합니다.
• 티켓을 팀 사이에서 이동하고 이후 위반의 담당 팀이 어디인지 확인합니다.
• 기한이 지난 뒤 티켓을 닫고 트래커가 위반을 기록하는지 확인합니다.

대시보드의 합계를 대시보드 뒤에 있는 티켓 목록과 비교하세요. 보고서에 Team A의 위반이 12건이라고 나오면 레코드를 필터링해 실제로 12건인지 세어 보세요. 이렇게 하면 중복 티켓, 누락된 팀 배정, 두 번 집계된 재오픈 티켓을 발견할 수 있습니다.

출시 전에 접근 권한을 설정하세요. 에이전트는 자신이 처리하는 티켓을 수정하고, 관리자는 팀 보고서를 확인하며, 관리자는 정책 설정을 관리해야 합니다. AppMaster에서는 각 역할을 별도 계정으로 테스트해 관리자가 SLA 위반 보고를 확인하기 위해 시스템 관리자 권한까지 필요하지 않도록 하세요.

작게 시작하고 워크플로 개선하기

티켓 유형 하나와 SLA 정책 하나로 시작하세요. 지원 팀이라면 일반 이메일 요청과 24시간 최초 응답 목표로 시작할 수 있습니다. 이것만으로도 기한, 승인된 일시 중지, 위반 기록을 테스트할 수 있습니다.

몇 명의 고객 운영 담당자에게 일반 사례, 고객 대기 사례, 기한을 놓친 사례를 포함해 실제 티켓을 워크플로에서 처리해 달라고 요청하세요. 구체적인 피드백을 수집합니다. 에이전트는 고객 대기와 다른 팀 대기를 구분하는 별도 상태가 필요할 수 있습니다. 관리자는 «일시 중지»라는 일반 라벨만으로는 정보가 부족하다고 느낄 수 있습니다.

스프레드시트가 프로세스를 제한하기 시작하면 AppMaster에서 트래커를 노코드 애플리케이션으로 만드세요. 티켓 양식을 만들고, 시각적 Business Process Editor에서 타이머 로직을 정의하며, 에이전트와 관리자를 위한 대시보드를 따로 제공할 수 있습니다. 트래커를 공유 테이블 이상의 환경에서 사용해야 한다면 AppMaster가 백엔드, 웹 앱, 네이티브 모바일 앱을 생성할 수 있습니다.

처음에는 보고서를 간단하게 유지하세요. 열린 티켓, 위반이 가까운 티켓, 일시 중지된 티켓, 팀별 위반만 확인하면 됩니다. 샘플 기한을 수동으로 확인하고, 위반 티켓과 일시 중지 기간을 검토하며, 규칙은 한 번에 하나씩 바꾼 뒤 다시 테스트하세요. 직원들이 계산 결과를 신뢰하게 되면 다른 티켓 유형이나 우선순위 정책을 추가하고 같은 점검을 반복합니다.