어떤 요청은 하나가 아니라 여섯 가지입니다. “새 동료가 월요일에 출근합니다”는 곧 Windows 계정, 메일함, ERP 접근 권한, 전화, 출입증을 뜻합니다. 각각 다른 팀이 맡고, 각각 담당자가 따로 있으며, 먼저 부서장이 승인해야 합니다. 지금은 누군가 그것을 다섯 번 입력하고 돌아다니며 진행 상황을 확인합니다. 여기서는 흐름을 한 번만 설정합니다. 요청자가 양식 하나를 채우면 시스템이 알맞은 팀에 개별 티켓을 만들고 승인을 받아 두며, 무엇이 끝났는지 한곳에서 보여 줍니다.
요청 하나, 작업 여럿
각 항목이 자기 티켓이 됩니다. 그 일을 맡는 팀에서, 자기 담당자와 자기 진행 시간과 자기 지시 사항을 가집니다. 작업 두 개가 같은 팀으로 갈 수도 있습니다. 애플리케이션 세 개를 돌보는 서비스 데스크는 항목 세 개가 적힌 티켓 하나가 아니라 티켓 세 개를 받습니다. 요청 자체에는 “5개 중 3개 완료”가 표시되고, 각 줄에서 해당 티켓으로 바로 넘어갑니다. 요청은 맨 마지막에 닫힙니다.
요청자는 누가 하는지가 아니라 무엇이 필요한지를 고릅니다
작업마다 항상 실행할지, 미리 선택된 채로 둘지, 일부러 선택해야 할지 정하십시오. 요청자는 양식에서 주문할 수 있는 항목의 목록만 봅니다. 팀 구조는 드러나지 않습니다. “어떤 애플리케이션이 어느 팀에 속하는가”를 위해 관리해야 할 기준 정보를 또 만들 필요도 없습니다. 그 정보는 작업 자체에 들어 있습니다.
승인은 여덟 번이 아니라 한 번
승인은 개별 작업이 아니라 요청에 붙습니다. 계정 여덟 개를 요청해도 부서장에게는 메일이 여덟 통이 아니라 한 통만 갑니다. 이런 흐름이 실제 업무에서 무너지는 지점이 바로 여기입니다. 민감한 작업 하나에 특정 부서의 승인이 더 필요하다면, 그 작업에만 두 번째 단계를 붙이십시오. 두 승인은 동시에 요청되며, 부서가 거절하면 그 작업만 영향을 받고 나머지는 계속 진행됩니다.
부서장에게는 계정이 필요 없습니다
부서장은 링크가 담긴 메일을 받아 누가 요청했고 어떤 작업이 포함되는지 보고 한 번 눌러 결정합니다. 로그인도 없고 담당자 좌석도 차지하지 않습니다. 메일에는 일부러 그 링크 하나만 담고, 바로 승인이 되는 주소는 넣지 않았습니다. 바이러스 검사기와 미리 보기 서비스는 메일 속 모든 주소를 열어 보며, 그렇게 만들어진 승인은 진짜 승인과 구별할 수 없기 때문입니다. 거절할 때는 사유를 적어야 하고, 그 사유는 요청자에게 전달됩니다.
승인 전에는 아무 일도 일어나지 않습니다
작업은 곧바로 나타나므로 전문 팀은 무엇이 올지 미리 볼 수 있습니다. 다만 잠겨 있고, 담당자가 배정되지 않으며, 승인이 없는 동안에는 옮길 수도 없습니다. 화면에서 흐리게만 보이는 것이 아니라 서버가 막습니다. 일괄 작업과 자동화 규칙에도 우회로는 없습니다. 아무도 반응하지 않으면 알림이 나갑니다. 시간이 지나면 자동으로 승인되는 일은 없습니다. 감사에서 문제가 되는 것이 바로 그것이기 때문입니다.
누가 언제 결정했는지가 기록으로 남습니다
각 단계는 승인자, 시각, 의견과 함께 요청에 남습니다. 이런 흐름을 도입하는 본래 이유인 감사 기록입니다. 관리자라도 다른 사람을 대신해 승인할 수 없습니다. 휴가에는 대신 재배정이 있습니다. 관리자가 열려 있는 요청을 대리인에게 보내면 이전 링크는 즉시 죽고, 누가 누구에게서 누구에게로 언제 옮겼는지가 이력에 남습니다.
이번 주 열 번째 비밀번호 재설정에는 새로 쓴 답이 필요하지 않습니다. 팀이 이미 써 둔 좋은 답이 필요합니다. 몇 초 만에, 오후 네 시에 슬며시 끼어드는 오타 없이 나가야 합니다. 답변 템플릿은 본문과 함께 그에 딸린 처리까지 채웁니다. 상태를 바꾸고, 나에게 배정하고, 후속 조치를 겁니다. 보내기 단추는 계속 사람이 누릅니다.
본문과 그에 딸린 처리를 한 번에
템플릿은 본문만 붙여 넣지 않습니다. 그 답에 늘 따라오는 필드 변경을 함께 제안합니다. 상태를 Resolved로, 우선순위를 낮게, 나에게 배정, 사흘 뒤 후속 조치처럼 말입니다. 제안은 저마다 배지로 표시되며 하나씩 뺄 수 있습니다. 이 티켓은 거의 표준 상황이지만 이번에는 아직 닫고 싶지 않을 때가 있기 때문입니다.
보내기 전에는 나가지 않습니다
템플릿을 고르면 편집기가 채워질 뿐입니다. 본문이 눈앞에 놓이고, 고친 다음, 늘 쓰던 그 단추로 보냅니다. 고르는 즉시 실행되는 매크로는 잘못 눌린 순간 진짜 고객에게 엉뚱한 답을 보냅니다. 그리고 보낸 메일은 되돌릴 수 없습니다. 이 1초는 일부러 둔 것입니다.
믿을 수 있는 자리 표시자
“안녕하세요 {requesterName}님”이라고 한 번만 써 두면, 적용할 때마다 알맞은 사람과 티켓 번호, 제목, 보내는 사람의 이름이 채워집니다. 템플릿을 고르는 순간 값이 들어가므로, 완성된 본문은 편집기에서 보는 그대로입니다. 고객의 받은 편지함에서 놀랄 일이 없습니다. 잘못 쓴 자리 표시자는 템플릿을 저장할 때 거부됩니다. 고객이 발견하는 것이 아닙니다.
답은 요청자에게 이메일로 갑니다
한 번만 선택하면 댓글이 이메일로 나갑니다. 받는 사람은 티켓 뒤에 있는 그 사람이며, 시스템이 알아서 찾아 줍니다. 템플릿에 붙여 둔 첨부 파일도 함께 티켓에 추가됩니다. 안내 PDF를 한 번 올려 두면 매번 내려받기 폴더에서 찾을 필요가 없습니다.
좋은 템플릿은 실제 답에서 나옵니다
가장 좋은 템플릿은 방금 쓴 답입니다. 댓글에서 한 번만 누르면 초안 템플릿이 됩니다. 본문은 미리 채워지고, 고객의 이름과 주소와 파일은 일부러 남겨 두지 않습니다. 이름을 붙이고, 새로운 눈으로 한 번 읽고, 그때 비로소 템플릿이 생깁니다. 게시하기 전에는 다른 사람에게 보이지 않습니다.
티켓 템플릿: 되풀이되는 티켓을 입력 없이
신입 직원 입사 절차, 장비 폐기, 전화로 들어온 문의처럼 어떤 티켓은 늘 같은 모양으로 만들어집니다. 티켓 템플릿은 양식을 미리 채웁니다. 제목, 설명, 카테고리, 우선순위, 담당 팀이 들어갑니다. 담당자는 그 건에만 해당하는 내용을 더해 등록합니다. 등록하기 전에는 아무것도 만들어지지 않습니다.
개인 서랍이 아니라 팀의 자산
템플릿은 한 사람의 서랍이 아니라 팀이나 모두에게 속합니다. 누군가 회사를 떠나도 그 사람의 좋은 답은 남습니다. 그리고 적용할 때마다 티켓 이력에 기록됩니다. 몇 주가 지난 뒤에도 그 티켓이 표준 답변으로 해결되었다는 것과 어떤 답변이었는지를 확인할 수 있습니다.
두 에디션 모두에 들어 있습니다
템플릿은 Basic에 온전히 들어 있습니다. 개수 제한도 없고, 상위 에디션에 숨겨 둔 기능도 없습니다. 팀의 일상 시간을 가장 많이 아껴 주는 도구가 유료 장벽 뒤에 있어서는 안 됩니다.
헬프데스크에서 일이 어긋나는 것은 대개 누가 잘못해서가 아니라 아무도 아무것도 하지 않아서입니다. 티켓은 오지 않을 답을 기다리고, 요청은 점심시간 내내 배정되지 않은 채 놓여 있으며, 사안은 해결된 뒤 그대로 잊힙니다. 자동화는 바로 그것에, 곧 행동이 없다는 사실에 반응합니다. 1분마다 확인하고, 알아차렸더라면 직접 했을 일을 대신합니다.
규칙 네 개가 이미 들어 있습니다. 꺼진 채로.
빈 화면에서 시작하지 않습니다. 일상적인 상황을 다루는 예제 네 개가 함께 들어 있습니다. 영업일로 사흘 동안 조용하면 요청자에게 알리기, 열흘 동안 답이 없으면 티켓 닫기, 근무 시간 네 시간 안에 아무도 잡지 않은 티켓의 우선순위 올리기, 일주일 동안 움직임이 없는 티켓에 후속 조치 걸기입니다. 넷 다 꺼져 있습니다. 하나를 켜거나, 숫자를 바꾸거나, 직접 만드는 규칙의 출발점으로 쓰십시오.
쓰는 것이 아니라 고르는 것입니다
모든 값은 고객의 데이터에서 옵니다. 고객의 상태, 우선순위, 팀, 카테고리를 목록에서 고릅니다. 필드 이름을 입력하는 칸도, 질의 언어도, cron 표현식도 없습니다. 규칙은 이렇게 읽힙니다. 언제 무언가가 한동안 일어나지 않았고, 만약 티켓이 이러하면, 그러면 저것을 한다.
규칙이 무엇을 할지 사람 말로 알려 줍니다
편집기 위에 문장 하나가 선택을 따라 함께 바뀝니다. “티켓의 상태가 Waiting for User Response이고 요청자의 답이 영업일로 3일 넘게 없으면, 요청자에게 이메일을 보낸다.” 무언가를 켜기 전에 이 문장을 되읽으십시오. 그 한 문장이, 그러지 않았다면 닫힌 고객 티켓에서야 알아차렸을 설정 실수를 잡아 줍니다.
누구에게 영향이 갈지 미리 봅니다
규칙마다 “지금 이 규칙은 어떤 티켓에 해당하는가?” 버튼이 있습니다. 목록만 나오고 그 밖에는 아무 일도 일어나지 않습니다. 이메일도, 상태 변경도, 기록 한 줄도 없습니다. 한번 해 보는 것과 끝내 못 해 보는 것을 가르는 단계입니다.
알림 하나가 홍수가 되지는 않습니다
“24시간 동안 답 없음”은 24시간이 지난 뒤부터 1분마다 계속 참입니다. 그대로 만들면 하루에 이메일 1,440통입니다. 그래서 규칙은 한 상황에 한 번만 실행되고 그다음에는 가만히 있습니다. 조건이 풀렸다가 다시 생겨야만 또 실행됩니다. 고객이 답하고, 다시 조용해지고, 그때 비로소 다음 알림이 나갑니다.
달력의 날이 아니라 업무 시간을 셉니다
“영업일 3일”은 기한과 같은 업무 시간 달력을 팀별로 씁니다. 금요일 저녁에 들어온 티켓이 월요일 아침에 지연으로 잡히지 않습니다. 흘러간 시간을 그대로 세고 싶다면 분, 시간, 일 단위도 있습니다. 전역 설정이 아니라 조건마다 고르는 것입니다.
실행 횟수 제한은 없습니다
어떤 시스템은 자동화를 실행 횟수로 청구합니다. 월 한도를 주고, 다 쓰면 다음 달 1일까지 모든 규칙이 멈춥니다. 여기에는 그런 계수기가 없습니다. 있는 제한은 한 규칙이 다른 규칙을 고리처럼 깨우지 못하게 막는 티켓별 안전장치뿐입니다. 티켓을 지키려고 있는 것이지 사용량을 재려고 있는 것이 아닙니다.
보이지 않게 일어나는 일은 없습니다
모든 동작은 그것을 일으킨 규칙의 이름과 함께 티켓 이력에 기록됩니다. 티켓이 왜 저절로 닫혔는지 궁금해할 일이 없습니다. 규칙마다 자체 기록도 남습니다. 어떤 티켓에, 언제, 결과가 무엇이었는지가 실패까지 포함해 남습니다. 라이선스가 만료되면 규칙은 그 자리에 그대로 있고 실행만 멈춥니다. 조용히 있는 대신 페이지가 그 사실을 알려 줍니다.
직접 거는 후속 조치는 모든 에디션에 있습니다
티켓에 날짜와 짧은 메모를 남겨 나중에 다시 꺼내 오는 일은, 이를테면 “목요일에 다시 전화”처럼, Basic에 들어 있습니다. 티켓 목록의 Today / This week / Overdue 필터도 함께 들어 있습니다. 요청자에게는 보이지 않습니다. Professional은 담당자가 후속 조치를 거는 데서 시스템이 대신 걸어 주는 데로 넘어가는 단계입니다.
받은 편지함에서는 똑같아 보이지만 전혀 다르게 다뤄야 하는 두 가지 상황이 있습니다. 하나는 같은 사람이 같은 문제를 두 번 신고하는 경우입니다. 메일이 갔는지 확신이 없어 전화로 한 번 더 알린 것입니다. 다른 하나는 스위치 하나가 고장 나 15분 만에 서로 다른 서른 명에게서 신고 서른 건이 들어오는 경우입니다. 각각에 맞는 길이 있고, 그 둘은 일부러 다른 길입니다.
같은 사람, 티켓 두 개
두 줄을 선택하고 어느 티켓을 남길지 정하십시오. 오래된 쪽이 미리 선택됩니다. 기한이 두 번째 시도가 아니라 첫 접촉부터 흐르게 하기 위해서입니다. 두 번째 티켓의 댓글과 첨부 파일과 설명은 첫 번째로 옮겨 가며 잃는 것은 없습니다. 확인하기 전에 이렇게 적혀 나옵니다. “#124를 닫고 #122로 옮깁니다.”
장애 하나, 신고 서른 건
티켓 서른 개를 장애 티켓 하나 아래로 묶으십시오. 각 티켓은 자기 요청자와 자기 상태와 자기 기한을 그대로 지닙니다. 사라지는 티켓은 없습니다. 늦게 들어온 신고는 하나씩 추가할 수 있고, 장애가 진행 중일 때 새 티켓을 여는 사람에게는 찾아보라고 하는 대신 연결 고리를 바로 보여 줍니다.
왜 이 둘이 같지 않은가
그 신고 서른 건을 그냥 병합하면 스물아홉 명이 자기 티켓을 잃고 다시는 아무 소식도 듣지 못합니다. 그리고 스물아홉 건이 답을 한 번도 받지 못한 채 닫히므로, 수치는 실제보다 좋아 보이게 됩니다. 그래서 시스템은 각 티켓 뒤에 누가 있는지 확인합니다. 서로 다른 사람이면 병합을 아예 제안하지 않고 장애 티켓 쪽으로 안내합니다.
서른 번이 아니라 한 번만 답하기
원인을 고치고 나면 해결 내용을 한 번만 씁니다. 연결된 모든 티켓에 그 내용이 댓글로 들어가고 티켓이 닫히며, 영향을 받은 사람마다 자기 앞으로 온 메일을 받습니다. 수신자 목록도 없고, 다른 사람의 주소가 보이지도 않습니다. 그 뒤에 누가 답을 보내면 장애 전체가 아니라 그 사람의 티켓만 다시 열립니다.
티켓 번호를 잃는 사람은 없습니다
병합된 신고는 삭제되지 않습니다. 요청자가 몇 주 뒤에 예전 메일에 답장해도 그 답은 알맞은 티켓을 찾아갑니다. 메시지에 답장하든, 제목에 예전 번호를 남기든, 둘 다이든 마찬가지입니다. 그러지 않으면 답장이 전달되었다고 믿는 동안 그 답은 아무도 보지 않는 닫힌 티켓에 놓여 있게 됩니다.
배너는 저절로 사라집니다
장애는 한 번만 선택하면 공지할 수 있습니다. 그러면 모두에게 배너로 보이고 자동 회신에도 안내로 들어갑니다. 메일로 신고하는 사람은 로그인 화면을 볼 일이 없습니다. 장애를 해결하면 배너는 저절로 사라집니다. 토요일로 공지한 점검 시간은 밀려나지 않고 그 옆에 계속 보입니다.
서비스 수준 협약(SLA)은 약속입니다. “요청에 두 시간 안에 답하고, 여덟 시간 안에 해결합니다”와 같은 약속입니다. 티켓 시스템은 그 약속을 항목별로 나누어 해당하는 모든 티켓에 시계를 붙이고 남은 시간을 알려 줍니다. 기한이 지난 뒤가 아니라 지나기 전에 알려 줍니다.
기한은 업무 시간에만 흘러갑니다
금요일 오후에 시작한 여덟 시간짜리 기한이 토요일 아침에 끝나서는 안 됩니다. 그래서 모든 기한은 업무 시간 달력에 묶여 있습니다. 요일별 영업 시간, 별도의 표준 시간대, 점심시간이나 분할 근무를 위한 하루 여러 구간을 둘 수 있습니다. 자정을 넘기는 야간 근무도 다룹니다. 팀마다 자기 달력을 가질 수 있고, 야간과 주말, 공휴일은 계산에 넣지 않습니다.
공휴일은 저희가 아니라 고객이 정합니다
공휴일은 사용하는 언어가 아니라 있는 곳에 따라 다릅니다. 독일은 16개 주, 스위스는 26개 칸톤, 미국은 50개 주가 각각 다릅니다. 언젠가는 고객 지역과 맞지 않게 될 목록을 넣어 두는 대신, 해당 지역의 공식 .ics 파일을 가져오거나 날짜를 직접 입력하십시오. 가져오기가 끝나면 며칠이 반영되었고 며칠이 건너뛰어졌는지 알려 줍니다. 앞으로 열두 달 동안 휴무일이 하나도 없는 달력이 있으면 설정 페이지가 그 사실을 알려 줍니다. 그러지 않으면 시스템이 모든 공휴일을 조용히 지나쳐 계산하게 됩니다.
무엇이 답변으로 인정되고 무엇이 인정되지 않는가
이 지점에서 지표에 뜻이 생기기도 하고 사라지기도 합니다. 첫 응답 시계는 담당자가 쓴 공개 댓글에만 멈춥니다. 자동 접수 확인은 인정되지 않고, 내부 메모도 인정되지 않으며, 고객이 보낸 이메일은 더더욱 아닙니다. 다르게 만들면 모든 기한이 몇 초 만에 “지켜짐”이 되고, 실제로는 아무도 답하지 않았는데 보고서는 계속 100%를 가리킵니다.
고객을 기다리는 동안에는 시계가 멈춥니다
되물어 보고 요청자를 기다리는 동안에는 기한이 흐르지 않습니다. 통제할 수 없는 대기 시간까지 떠안지는 않습니다. 기한이 멈출지는 목표마다 따로 정합니다. “첫 응답”과 “해결”의 답이 같으리라는 법이 없기 때문입니다. 해결된 티켓이 다시 열리면 새 주기가 시작됩니다. 이전 주기는 곧바로 위반으로 표시되는 대신 보고용 기록으로 남습니다.
기한을 넘겼을 때
기한마다 무슨 일이 일어날지 정하십시오. 기록만 남기거나, 담당자와 참조자에게 알리거나, 티켓을 다른 팀으로 자동으로 넘길 수 있습니다. 1차에서 2차로 넘기는 전형적인 에스컬레이션입니다. 넘기기는 일부러 기본값이 아닙니다. 책임이 옮겨 가고 담당자가 손을 떼게 되기 때문입니다. 첫 위반에서 그런 일이 갑자기 일어나서는 안 됩니다. 무엇을 고르든 다시 시작한 뒤에도 정확히 한 번만 실행됩니다.
어떤 기한이 어떤 티켓에 적용되는가
정책을 만들어 순서대로 놓으면 먼저 맞는 정책이 이깁니다. 조건은 팀, 우선순위, 카테고리이며 드롭다운으로 고릅니다. 먼저 배워야 하는 질의 언어가 아닙니다. 빈 칸은 “없음”이 아니라 “모두”를 뜻합니다. 팀을 지정하지 않은 정책은 모든 팀에 적용됩니다.
그다음에 보이는 것
티켓 목록에 남은 시간이 바로 보이고, “먼저 끝나는 순”으로 정렬하거나 “위반”만 걸러 볼 수 있습니다. 티켓 자체에도 기한이 표시됩니다. 보고서는 준수율, 위반 건수, 기한별 평균 소요 시간을 보여 줍니다. 준수율은 결과가 정해진 기한만 셉니다. 아직 흘러가는 중인 기한은 수치를 흐리지 않습니다. 그러지 않으면 새로 도입한 약속마다 처음에는 참담해 보이다가 저절로 좋아집니다.
정책을 만들기 전에는 아무것도 달라지지 않습니다
활성 정책이 없으면 시계도 없고, 열도 새로 생기지 않으며, 기존 티켓도 그대로입니다. 미리 정해진 목표도 없고, 오래된 사안이 하룻밤 사이에 위반이 되는 일도 없습니다. 기한이 없는 티켓에는 “위반”이 아니라 중립적인 줄표가 표시됩니다.
작업 시간을 청구하는 곳이라면 그 시간을 일이 일어나는 자리, 곧 사안에서 기록해야 합니다. 담당자가 “20”을 입력하거나 미리 정한 단추를 누르면, 월말에는 고객별, 원가 부서별, 계약별 합계가 준비되어 있습니다. 화면의 표로도, 청구서를 위한 CSV로도 나옵니다. 이것이 일부러 아닌 것은 출퇴근 기록입니다. 사안에 들인 시간을 기록할 뿐 사람의 근태를 기록하지 않습니다.
어떤 스톱워치보다 입력이 빠릅니다
기본 방식은 빠른 입력입니다. 마음대로 설정하는 단추 네 개와 “90”, “1.5h”, “1h 30m”을 모두 알아듣는 칸이 있습니다. 3분짜리 사안에서는 스톱워치를 두 번 누르는 것이 숫자를 적는 것보다 오래 걸립니다. 한 번에 오래 일하는 편이라면 타이머도 켜십시오. 타이머는 값을 제안할 뿐이고, 사람이 확인하기 전에는 저장되지 않습니다.
기록한 시간과 청구하는 시간은 따로입니다
반올림 단위와 최솟값은 자유롭게 정합니다. 15분 단위라면 17분은 30분이 됩니다. 다만 반올림되는 것은 청구 값뿐이고, 언제나 항목별이며 합계에 대고 하지 않습니다. 실제로 일한 시간은 그대로 남습니다. 그래서 나중에 반올림 방식을 바꾸어도 지난달 수치가 소급해서 달라지지 않습니다.
회사별, 원가 부서별, 계약별로 청구하기
보고서는 시간을 요청자별, 팀별, 날짜별로 묶습니다. 직접 만든 사용자 지정 필드로도 묶습니다. 그래서 저희가 지어낸 말이 아니라 조직이 실제로 쓰는 말 그대로 청구할 수 있습니다. 화면은 가장 큰 묶음들을 보여 주고, 잘라 냈으면 그렇다고 알려 줍니다. 개별 항목의 CSV 내보내기는 절대 잘리지 않습니다. 잘린 목록에서 뽑은 청구 합계는 부족한 것이 아니라 틀린 것이기 때문입니다.
기간은 티켓이 아니라 작업을 뜻합니다
6월에 만들어졌지만 7월에 작업한 티켓은 그 시간만큼 7월 청구서에 들어갑니다. 보고서는 정확히 그렇게 자릅니다. 티켓이 만들어진 때가 아니라 기록된 날짜로 자릅니다. 당연해 보이지만, 월별 청구서가 조용히 어긋나는 지점이 바로 여기입니다.
여러 담당자, 끝까지 추적 가능
모든 항목에는 날짜, 작성자, 메모, 청구 대상 표시가 붙습니다. 다른 사람의 항목을 고칠 수 있는 권한과, 티켓을 닫은 뒤에도 고칠 수 있는 권한은 서로 다릅니다. 다른 사람의 시간을 고치는 것은 다른 사람의 청구서를 고치는 일이기 때문입니다. 티켓 두 개를 병합하면 시간도 함께 옮겨 갑니다. 닫힌 쪽에 남겨 두어서는 안 됩니다.
담당자별 평가는 끌 수 있습니다
사람별 시간은 성과와 행동에 관한 정보입니다. 그래서 담당자별 집계는 별도의 스위치이고 기본값은 꺼짐이며, 그 차단은 화면이 아니라 서버에 있습니다. 클라우드 제품에서는 이 집계를 아예 끌 수 없습니다. 노사협의회가 있는 조직에서는 그것이 바로 도입할 수 있느냐 먼저 협의해야 하느냐를 가릅니다.
고객에게는 시간이 보이지 않습니다
기본적으로 기록한 작업 시간은 내부에만 남습니다. “5분이요? 그것 때문에요?”는 아무도 원하지 않는 논쟁이며, 숫자가 보였다는 이유만으로 시작됩니다. 달리 하고 싶다면 그 항목을 일부러 공개하십시오. 기본값이 대신 결정하지 않습니다.
팀별로도 켜고 끌 수 있습니다
시간 기록은 기본적으로 꺼져 있습니다. 필요 없다면 항목도, 열도, 타일도 보이지 않습니다. 켜면 모든 팀이 함께 쓰고, 거기서 개별 팀을 빼면 됩니다. 사내 IT 팀은 기록하지 않고, 고객을 상대하는 서비스 팀은 기록하게 할 수 있습니다. 원한다면 닫기 전에 시간 입력을 필수로 만드십시오. 자동으로 닫히는 경우는 영향을 받지 않습니다. 그러지 않으면 아무도 닫을 수 없는 티켓이 생깁니다.
결국 헬프데스크가 일을 잘했는지 아는 사람은 한 명뿐입니다. 도움을 받은 그 사람입니다. 티켓이 닫히면 별 다섯 개가 담긴 메일이 갑니다. 한 번 누르면 끝입니다. 그 평가는 있어야 할 자리로 갑니다. 티켓에, 그 일을 한 사람 앞에, 그리고 보고서에 숫자로 들어갑니다. 조사는 켜기 전에는 꺼져 있습니다. 물어볼지, 언제 물어볼지는 고객이 정합니다.
한 번 누르면 끝, 더 묻지 않습니다
메일에는 별 다섯 개가 링크로 들어 있습니다. 세 번째 별을 누르는 것이 답변의 전부입니다. 계정도, 로그인도, 두 화면에 걸친 양식도 없습니다. 원하는 사람은 그다음 페이지에서 한 문장을 덧붙일 수 있고, 대개 그 문장들이 보고서 전체에서 가장 흥미로운 부분입니다. 별을 잘못 눌렀다면 링크가 살아 있는 동안 고칠 수 있습니다.
응답률은 평균 옆에 있습니다
4.6이라는 숫자는 그것이 400건 중 12건의 답에 기대고 있다고 누군가 옆에 적어 주기 전까지는 아무 뜻이 없습니다. 그래서 보고서는 둘 다 보여 줍니다. 그리고 그 옆에 아예 묻지 않은 닫힌 티켓의 수도 함께 보여 줍니다. 자기 표본을 숨기는 수치는 수치가 없는 것만 못합니다.
직원을 감시하지 않고 측정하기
사람별 평가는 성과와 행동에 관한 정보이며, 많은 회사에서 노사협의회가 다루는 사안입니다. 여기서는 담당자별 평가가 별도의 스위치이고 기본값은 꺼짐이며, 서버가 그것을 지킵니다. 꺼짐은 꺼짐이고 내보내기에서도 마찬가지입니다. 개별 티켓의 평가는 그와 상관없이 보입니다. 그 건을 처리한 동료가 거기서 가장 먼저 배울 수 있는 사람이기 때문입니다.
아무도 파묻히지 않습니다
티켓 하나당 조사는 많아야 한 번입니다. 같은 사람에게 얼마나 자주 물어도 되는지는 고객이 정합니다. 기본값은 7일 안에 많아야 한 번입니다. 한 오전에 다섯 건을 신고한 사람은 메일을 다섯 통이 아니라 한 통 받습니다. 보내는 사람이 매번 다른 고객 창구라면 한도를 0으로 두고 모든 티켓에서 물으십시오. 닫은 직후 티켓이 다시 열리면 아예 나가지 않습니다. 질문은 사안이 정말 끝난 뒤에만 갑니다.
장애가 수치를 왜곡하지 않습니다
장애 티켓에 묶인 신고는 일부러 조사하지 않습니다. “장애 해결”을 한 번 누르는 것으로 한 건의 작업에 대해 조사 200건이 나간다면, 그달의 수치는 서비스가 아니라 그 장애를 설명하게 됩니다. 장애 티켓 자체는 묻고, 영향을 받은 200명에게는 묻지 않습니다.
나쁜 평가는 하나의 사안이지 데이터 한 점이 아닙니다
별 하나짜리 평가는 다음 주 요약에 들어갈 것이 아니라 그날 바로 책상에 올라와야 합니다. 자동화 규칙은 평가가 들어오는 순간 반응할 수 있습니다. 우선순위를 올리고, 팀장에게 배정하고, 메일을 보냅니다. 같은 규칙 엔진에 같은 방식이며, 평가는 조건이 하나 더 늘어난 것일 뿐입니다.
링크는 평가 권한을 주지 열람 권한을 주지 않습니다
조사 페이지에는 티켓 번호와 제목만 나옵니다. 설명도, 댓글도, 첨부 파일도 없습니다. 이런 링크는 전달되기도 하고 공용 메일함에 들어가기도 합니다. 링크를 가진 사람은 평가할 수 있을 뿐 내용을 읽을 수는 없습니다. 30일이 지나면 만료되며, 밖에서는 만료된 링크와 존재하지 않는 링크가 똑같아 보입니다.
바이러스 검사기는 평가하지 않습니다
단지 열리기만 해도 집계되는 별 링크는 대형 메일 제공자의 링크 검사기가 자동으로 누릅니다. 그러면 점수는 순전히 지어낸 값이 되고, 데이터베이스에서 진짜 답변과 구별할 수 없습니다. 여기서는 링크를 열면 페이지가 보일 뿐이며, 사람이 앞에 앉기 전에는 아무것도 저장되지 않습니다. 그 사람에게는 여전히 한 번 누르는 일입니다.
