사내 요청 창구를 티켓 시스템으로 옮기면 기대하는 것이 있습니다. 요청이 한곳에 모이고, 누가 무엇을 하는지 보이고, 처리 시간이 측정되는 것.
그런데 도입 3개월 뒤에도 급한 건은 여전히 메신저로 옵니다. 시스템은 깔려 있는데 우회 경로가 살아 있습니다.
원인은 대부분 두 가지입니다. 요청 유형이 정리되지 않아 어디에 넣어야 할지 모르거나, 넣어도 언제 처리될지 모르기 때문입니다.
이 글은 서비스 카탈로그 설계와 SLA 기준 설정을 중심으로 정착까지 가는 순서를 정리합니다. 화면 조작법이 아니라 무엇을 정해야 하는지에 관한 글입니다.
구축의 첫 단계는 시스템 설정이 아니라 목록 작성입니다. 지난 3개월 동안 실제로 들어온 요청을 유형별로 세십시오.
메신저, 메일, 구두 요청을 모두 포함합니다. 이 작업을 건너뛰고 일반적인 ITSM 분류를 그대로 가져오면 우리 조직에 없는 유형이 절반이고 실제로 많은 유형이 빠집니다.
세어 보면 대개 상위 열 개 유형이 전체의 70~80%를 차지합니다. 계정 생성, 권한 요청, 장비 지급, 소프트웨어 설치, 네트워크 장애, 비밀번호 초기화 같은 것들입니다.
이 상위 열 개를 먼저 카탈로그로 만드십시오. 나머지는 '기타 요청' 하나로 받고 운영하면서 분리합니다. 처음부터 완벽한 분류를 만들려다 구축이 멈추는 경우가 많습니다.
ITSM의 기본 구분입니다. 서비스 요청은 '정상적으로 제공되는 것을 달라'는 요청이고, 인시던트는 '되던 것이 안 된다'는 장애입니다.
이 구분이 필요한 이유는 처리 방식과 시간 기준이 다르기 때문입니다. 계정 생성은 절차대로 진행하면 되지만 장애는 즉시 대응해야 합니다.
실무에서는 요청자가 이 구분을 모릅니다. 따라서 포털 화면에서 구분을 강요하지 마십시오. 요청 유형을 고르면 시스템이 자동으로 분류하는 설계가 낫습니다.
예를 들어 '메일이 안 됩니다'는 인시던트, '메일 계정을 만들어 주세요'는 서비스 요청으로 자동 분류되게 하십시오. 요청자는 자기 말로 고르고, 분류는 시스템이 합니다.
카탈로그 항목 하나에 들어갈 요소는 정해져 있습니다. 이름, 설명, 입력 항목, 승인 경로, 처리 담당, 목표 시간.
이름은 요청자의 말로 쓰십시오. '계정 프로비저닝'이 아니라 '새 직원 계정 만들기'입니다. 카탈로그를 IT 용어로 채우면 요청자가 찾지 못해 메신저로 돌아갑니다.
입력 항목은 최소로 두되, 처리에 반드시 필요한 것은 필수로 잡으십시오. 항목이 많으면 제출을 포기하고, 적으면 담당자가 다시 물어야 합니다. 균형점은 '되묻지 않고 처리할 수 있는 최소'입니다.
승인 경로가 필요한 항목은 미리 정하십시오. 장비 지급이나 유료 소프트웨어처럼 비용이 발생하는 요청입니다. 승인자를 개인이 아니라 역할로 지정하면 인사 이동에도 흐름이 유지됩니다.
SLA 설정에서 가장 흔한 실수는 이상적인 목표를 넣는 것입니다. 지키지 못하는 SLA는 없느니만 못합니다. 위반 알림이 계속 울리면 아무도 보지 않게 됩니다.
시작은 현재 실적입니다. 1번에서 센 요청들의 실제 처리 시간을 보고, 그 값에서 약간만 당긴 수준으로 잡으십시오.
우선순위 구간도 단순하게 두십시오. 긴급·높음·보통 세 단계면 충분합니다. 네 단계를 넘으면 판정 기준이 모호해지고 대부분 '높음'으로 몰립니다.
업무 시간 기준도 정해야 합니다. 24시간 기준인지 업무 시간 기준인지에 따라 같은 목표가 전혀 다른 의미가 됩니다. 야간 장애 대응 체계가 없다면 업무 시간 기준으로 잡는 것이 정직합니다.
정착의 관건은 IT 담당자의 편의가 아니라 요청자의 경험입니다. 요청자가 불편하면 메신저로 돌아갑니다.
확인할 것은 세 가지입니다. 첫째, 요청하는 데 몇 번의 클릭이 필요한가. 포털에 들어가 카탈로그를 찾아 폼을 채우는 과정이 1분을 넘으면 길게 느껴집니다.
둘째, 요청 후 상태를 알 수 있는가. 접수됐는지, 누가 보고 있는지, 언제쯤 처리되는지. 이 정보가 없으면 요청자는 메신저로 다시 물어봅니다. 그 순간 시스템을 쓴 의미가 사라집니다.
셋째, 자주 쓰는 요청에 바로 접근할 수 있는가. 상위 다섯 개 요청은 포털 첫 화면에 고정하십시오. 검색해야 나오는 구조면 쓰지 않습니다.
요청 건수를 줄이는 가장 확실한 방법은 스스로 해결할 수 있게 하는 것입니다.
상위 요청 유형별로 안내 문서를 만드십시오. 비밀번호 초기화, VPN 연결, 프린터 설정처럼 반복되는 것들입니다.
중요한 것은 위치입니다. 지식베이스를 별도 메뉴에 두면 아무도 보지 않습니다. 카탈로그 항목을 클릭했을 때 관련 문서가 먼저 뜨고, 그래도 안 되면 요청을 제출하는 흐름으로 설계하십시오.
문서의 효과는 측정 가능합니다. 해당 유형의 티켓 수가 줄어드는지 보면 됩니다. 줄지 않으면 문서가 안 보이거나 도움이 안 되는 것이므로 둘 중 무엇인지 확인하십시오.
Freshservice는 자산 관리 기능을 포함하지만, 처음부터 전 자산을 등록하려 하면 구축이 멈춥니다.
시작 범위를 정하십시오. 실무 권장은 '요청 처리에 필요한 자산'입니다. PC와 노트북, 계정, 라이선스 정도입니다. 케이블과 주변기기까지 넣으면 유지가 안 됩니다.
자산 정보는 등록보다 갱신이 어렵습니다. 갱신 경로를 먼저 설계하십시오. 지급·회수 요청이 처리될 때 자산 상태가 자동으로 바뀌는 구조가 이상적입니다.
수동 갱신에 의존하는 자산 데이터는 6개월이면 신뢰할 수 없게 됩니다. 자동 갱신 경로가 없는 자산 유형은 아예 등록하지 않는 편이 낫습니다.
순서는 이렇습니다. 요청 유형 집계 → 상위 10개 카탈로그 설계 → 자동 분류 규칙 → SLA 설정 → 지식베이스 상위 5건 → 포털 화면 구성 → 파일럿 → 전사 확대.
파일럿을 건너뛰지 마십시오. 한 부서를 대상으로 2주간 운영하면 카탈로그의 빈틈이 대부분 드러납니다.
완료 판정은 '설정했다'가 아니라 '요청이 들어온다'입니다. 파일럿 기간 동안 해당 부서 요청의 몇 퍼센트가 시스템으로 들어왔는지 측정하십시오.
70% 미만이면 확대하지 마십시오. 원인은 대개 카탈로그에 없는 유형이거나 요청 과정이 번거로운 것입니다. 이 상태로 전사 확대하면 우회 경로가 고착됩니다.
세 가지 지표를 보십시오. 첫째, 채널별 유입 비율입니다. 시스템 대 메신저·메일 비율이 개선되는지 확인합니다. 개선되지 않으면 카탈로그나 요청 경험 문제입니다.
둘째, 유형별 건수와 처리 시간입니다. 특정 유형이 몰리면 자동화나 지식베이스로 줄일 여지가 있는지 봅니다.
셋째, SLA 달성률입니다. 낮으면 목표가 비현실적인지 인력이 부족한지 구분하십시오. 목표가 문제면 조정하고, 인력이 문제면 그 근거로 쓰십시오. SLA 데이터는 증원 요청의 가장 강한 근거가 됩니다.
분기마다 카탈로그를 점검하십시오. '기타 요청'에 쌓인 건들을 보면 새로 만들어야 할 항목이 보입니다. 이 작업을 하지 않으면 기타 요청이 전체의 절반이 됩니다.
|
순서 |
단계 |
핵심 결정 |
완료 판정 |
|---|---|---|---|
|
1 |
요청 유형 집계 |
최근 3개월 실제 요청 (메신저·메일 포함) |
상위 10개가 전체의 70% 이상 설명 |
|
2 |
카탈로그 설계 |
이름은 요청자의 말로 · 입력 항목 최소 |
되묻지 않고 처리 가능한 최소 항목 |
|
3 |
자동 분류 |
요청 유형 → 서비스 요청 / 인시던트 |
요청자가 구분을 몰라도 분류됨 |
|
4 |
SLA 설정 |
현재 실적에서 약간 당긴 값 · 3단계 |
위반 알림이 의미를 갖는 수준 |
|
5 |
지식베이스 |
상위 5개 유형 안내 문서 |
카탈로그 클릭 시 문서가 먼저 노출 |
|
6 |
포털 구성 |
상위 5개 요청을 첫 화면 고정 |
요청까지 1분 이내 |
|
7 |
파일럿 |
한 부서 · 2주 |
해당 부서 요청의 70% 이상이 시스템 유입 |
|
8 |
전사 확대 |
파일럿 결과 반영 후 |
— |
7단계에서 70% 미만이면 확대하지 마십시오. 이 상태로 전사 확대하면 우회 경로가 고착됩니다
|
증상 |
실제 원인 |
대응 |
|---|---|---|
|
급한 건은 여전히 메신저로 온다 |
처리 시점을 알 수 없음 |
SLA 표기와 상태 알림을 요청자에게 노출 |
|
요청이 '기타'로만 들어온다 |
카탈로그에 해당 유형이 없음 |
분기별로 기타 건을 분석해 항목 추가 |
|
요청자가 카탈로그를 못 찾는다 |
IT 용어로 작성됨 |
요청자의 말로 이름 변경 · 상위 5개 고정 |
|
폼을 채우다 포기한다 |
입력 항목이 많음 |
필수는 처리에 꼭 필요한 것만 |
|
담당자가 매번 되묻는다 |
입력 항목이 부족함 |
되묻는 내용을 필수 항목으로 추가 |
|
SLA 위반 알림을 아무도 안 본다 |
목표가 비현실적 |
현재 실적 기준으로 재설정 |
|
자산 데이터가 6개월 만에 틀린다 |
수동 갱신에 의존 |
지급·회수 요청과 자산 상태를 연동 |
|
승인이 계속 지연된다 |
승인자를 개인으로 지정 |
역할 기준 지정 · 대리 승인 규칙 |
Q. 요청 유형을 몇 개부터 시작해야 하나요?
상위 10개입니다. 최근 3개월 실제 요청을 세어 보면 대개 상위 10개가 전체의 70~80%를 차지합니다. 나머지는 '기타 요청' 하나로 받고 운영하면서 분리하십시오. 처음부터 완벽한 분류를 만들려다 구축이 멈추는 경우가 많습니다.
Q. 요청자가 서비스 요청과 인시던트를 구분할 수 있을까요?
못 합니다. 그래서 포털에서 구분을 강요하지 마십시오. 요청자는 '메일이 안 됩니다' 같은 자기 말로 유형을 고르고, 시스템이 자동으로 분류하는 설계가 맞습니다. 구분은 처리 방식과 SLA를 나누기 위한 내부 개념입니다.
Q. SLA를 어떻게 정해야 하나요?
현재 실적에서 시작하십시오. 이상적인 목표를 넣으면 위반 알림이 계속 울리고 결국 아무도 보지 않게 됩니다. 실제 처리 시간을 측정한 뒤 약간만 당긴 값으로 잡고, 업무 시간 기준인지 24시간 기준인지도 명시하십시오.
Q. 자산 관리를 어디까지 해야 하나요?
'요청 처리에 필요한 자산'까지입니다. PC·노트북·계정·라이선스 정도면 충분합니다. 핵심은 등록이 아니라 갱신 경로입니다. 지급·회수 요청 처리 시 자산 상태가 자동으로 바뀌지 않는 자산 유형은 아예 등록하지 않는 편이 낫습니다.
이 글은 Freshservice 도입 시 서비스 카탈로그와 SLA 설계를 중심으로 한 구축 순서를 다룹니다. 화면 조작 방법, 개별 설정 항목의 위치, 요금 체계, 변경 관리·릴리스 관리 등 상위 ITSM 프로세스는 다루지 않습니다.
이 글은 P3 구축과 운영 시리즈의 일부입니다.
본문의 원화 환산은 1 USD = 1,380원, 기준일 2026년 9월 12일을 적용했습니다. 요금과 약관은 변경될 수 있으므로 계약 전 공식 페이지에서 재확인하십시오.