고객 요청 수명 주기: 화면보다 먼저 흐름을 매핑하세요

요청 맵 없이 화면부터 만들면 실패하는 이유

완성도 높은 요청 양식을 만들어도 프로세스가 엉킬 수 있습니다. 팀은 흔히 필드, 버튼, 대시보드부터 정한 뒤 고객이 «제출»을 클릭한 다음 무슨 일이 일어나는지 아무도 합의하지 않았다는 사실을 깨닫습니다.

화면은 개별 순간을 보여 줍니다. 고객 요청 수명 주기는 요청이 어디로 들어오고, 누가 검토하며, 무엇을 결정하고, 언제 업무가 시작되며, 무엇을 완료로 볼지 전체 흐름을 보여 줍니다. 이 맵이 없으면 각 화면은 그 자체로는 말이 되지만 화면 사이에서 실제로 해야 할 일은 불분명해집니다.

상태가 «진행 중»인 지원 양식을 생각해 보세요. 누군가 요청을 읽었다는 뜻일까요? 담당자를 지정했다는 뜻일까요? 고객에게 연락했다는 뜻일까요? 아니면 실제 업무를 시작했다는 뜻일까요? 직원마다 같은 라벨을 다르게 사용할 수 있습니다. 고객은 진행 상황을 거의 알 수 없고, 관리자는 요청이 어디에서 막혔는지 확인하기 어렵습니다.

화면부터 시작하면 인계 과정도 가려집니다. 요청이 지원팀에서 결제팀으로, 다시 어카운트 매니저에게 넘어갈 수 있습니다. 각 단계의 담당자를 정하지 않았다면 모두가 다른 사람이 처리할 것이라고 생각하게 됩니다. 그러면 고객이 다시 문의할 때까지 요청이 공유 큐에 남아 있게 됩니다.

요청 워크플로를 매핑하면 화면 설계를 시작하기 전에 이런 빈틈을 드러낼 수 있습니다. 팀은 다음을 정해야 합니다.

• 요청을 시작하려면 어떤 정보가 필요한가?
• 다음 작업의 담당자는 누구인가?
• 각 결정 뒤에는 어떤 상태가 올 수 있는가?
• 마감일은 언제 시작되고, 일시 중지되며, 끝나는가?
• 요청이 변경되면 누가 알림을 받아야 하는가?

맵은 오해를 부르는 대시보드도 막아 줍니다. «열림» 요청 수에 새 요청, 고객 정보를 기다리는 요청, 다른 팀의 작업 때문에 막힌 요청이 모두 포함되어 있다면 그 숫자만으로는 알 수 있는 것이 거의 없습니다. 상태를 나누면 직원이 같은 언어로 소통할 수 있고 고객에게도 더 정확한 업데이트를 제공할 수 있습니다.

맵은 복잡할 필요가 없습니다. 실제로 사람들이 하는 일을 설명하면 됩니다. 누락된 정보, 거절된 요청, 다시 열린 케이스도 포함해야 합니다. 흐름이 분명해지면 화면 설계도 쉬워집니다. 각 페이지가 정보를 수집하는지, 담당자의 작업을 돕는지, 고객에게 요청의 현재 위치를 보여 주는지 목적이 명확해지기 때문입니다.

요청 하나와 명확한 결과에서 시작하기

팀이 가장 자주 받는 요청부터 시작하세요. 환불 요청, 배송 중 파손 신고, 계정 정보 변경 요청 등이 될 수 있습니다. 모든 고객 요구를 하나의 다이어그램에 담으려 하지 마세요. 범위가 넓은 맵은 금세 모호해집니다.

시작 이벤트를 쉬운 말로 적으세요. 예를 들어 «고객이 지원 양식을 통해 주문에 대한 환불 요청을 제출한다»라고 쓸 수 있습니다. 이렇게 하면 수명 주기가 언제 시작되는지 정할 수 있습니다. 고객이 요청을 보낸 순간인지, 지원팀이 읽은 순간인지, 누군가 티켓을 만든 순간인지 나중에 논쟁하는 일도 줄어듭니다.

그다음 양쪽 관점에서 끝나는 지점을 정하세요. 완료된 환불 요청은 고객이 명확한 결정을 받고, 승인된 경우 결제팀이 환불을 처리한 상태입니다. 지원팀에도 결정 내용, 사유, 금액, 날짜 기록이 필요합니다. «완료»라고 표시된 화면보다 이런 세부 정보가 더 중요합니다.

결과와 인터페이스를 분리하세요. «초록색 성공 메시지를 표시한다»는 화면을 설명합니다. «고객에게 환불 금액과 입금 예정일이 포함된 확인 메시지를 보낸다»는 반드시 수행해야 할 업무를 설명합니다. 재설계 과정에서 화면은 바뀔 수 있습니다. 하지만 웹 포털, 모바일 앱, 이메일 중 무엇을 사용하든 underlying work should remain consistent. 화면이 아니라 실제 업무를 기준으로 정하세요.

짧은 정의만으로도 설계 전에 빠진 규칙을 찾을 수 있습니다.

• 요청 유형: 결제된 주문의 환불
• 시작: 고객이 양식을 제출하거나 지원팀에 문의함
• 종료: 고객이 승인 또는 거절 결정을 받고, 팀이 그 내용을 기록함
• 예외: 결정을 내리기 전에 지원팀이 누락된 주문 정보를 요청함

고객이 월요일에 중복 결제를 신고했다고 해 보겠습니다. 팀이 결제가 중복되었는지 확인하고, 결정을 전달하며, 환불이 있다면 그 내용을 기록한 뒤에야 요청이 끝나야 합니다. 첫 번째 답변을 보낸 뒤 티켓을 닫으면 실제 업무는 해결되지 않은 상태로 남습니다.

시작과 끝이 정확해지면 팀은 추측하지 않고 상태, 담당자, 마감일, 알림을 추가할 수 있습니다. AppMaster를 사용하면 나중에 이 맵을 비즈니스 프로세스와 화면으로 바꿀 수 있지만, 먼저 맵이 업무를 정의해야 합니다.

요청이 들어갈 수 있는 상태 나열하기

상태는 고객 요청이 지금 어디에 있는지 모두에게 알려 줍니다. 모든 작은 작업을 기록하기보다 업무에서 의미 있는 지점만 골라 목록을 간결하게 유지하세요. 직원이 상태를 읽고 다음에 해야 할 일을 알 수 있어야 합니다.

일반적인 지원 또는 서비스 요청에는 다음과 같은 상태가 포함될 수 있습니다.

• 신규: 시스템이 요청을 받았지만 아직 아무도 검토하지 않음
• 검토 중: 팀원이 세부 정보를 확인하고 처리 방법을 결정함
• 고객 답변 대기: 팀이 고객의 답변, 파일 또는 확인을 기다림
• 진행 중: 누군가 업무를 맡아 처리하고 있음
• 승인 또는 외부 작업 대기: 관리자, 공급업체, 결제 제공업체 또는 다른 당사자의 작업에 따라 진행이 멈춤
• 해결됨: 팀이 요청한 업무를 완료함
• 종료: 고객이 결과를 수락했거나, 정해진 기간이 지나 팀이 요청을 종료함

사람들이 이미 사용하는 표현에 맞는 이름을 선택하세요. «입력 대기»보다 «고객 답변 대기»가 분명합니다. «활성»보다 «진행 중»이 보통 더 이해하기 쉽습니다. 고객이 포털에 표시된 상태를 이해하기 위해 내부 용어집을 찾아봐야 해서는 안 됩니다.

대기 상태는 특히 신중하게 정해야 합니다. 이런 상태는 오늘 팀이 할 수 있는 일과 다른 사람에게 의존하는 일을 구분해 줍니다. 환불 요청은 고객이 영수증을 제출해야 할 때 «검토 중»에서 «고객 답변 대기»로 바뀔 수 있습니다. 재무 관리자의 금액 승인이 필요하다면 «승인 대기»로 바뀝니다. 이런 지연에는 서로 다른 알림과 마감일 규칙이 필요합니다.

중복되는 라벨은 피하세요. «열림», «할당됨», «처리 중»은 같은 일반적인 상황을 설명하는 경우가 많습니다. 각 라벨이 담당자, 직원의 작업, 적용되는 마감일을 바꾸는 경우가 아니라면 상태 하나만 남기세요. 상태와 전환이 적고 명확할수록 보고서도 더 신뢰할 수 있습니다.

간단한 질문으로 모든 요청을 테스트하세요. 요청이 동시에 두 상태에 있을 수 있나요? 그렇다면 이름이 겹칠 수 있습니다. 각 상태가 하나의 분명한 조건만 설명할 때까지 수정하세요.

전환을 그리고 누가 작동시키는지 정하기

상태 이름만으로는 워크플로를 설명할 수 없습니다. 요청이 어떻게 이동하는지, 누가 이동시킬 수 있는지, 이동 전에 무엇이 충족되어야 하는지를 기록하세요. 그러면 화면의 버튼이 잘못된 시점에 요청을 바꾸는 일을 막을 수 있습니다.

각 전환을 쉬운 문장으로 쓰세요. 예를 들어 «지원 상담원이 고객이 주문 번호를 포함했는지 확인한 뒤 요청을 신규에서 검토 중으로 변경한다»라고 쓸 수 있습니다. 이 문장에는 행동, 담당자, 조건이 모두 들어 있습니다.

간단한 맵에는 다음과 같은 이동이 포함될 수 있습니다.

• 고객이 요청을 제출하면 신규 요청이 생성됨
• 지원 상담원이 요청을 전문가에게 할당하고 검토 중으로 변경함
• 전문가가 정보가 부족할 때 고객 답변 대기로 변경함
• 고객이 답변하면 검토 중으로 돌아감
• 전문가가 업무를 완료한 뒤 해결됨으로 표시함
• 고객 또는 지원팀 리더가 확인 후 요청을 종료함

모든 화살표에 허용된 담당자를 적으세요. «팀»은 너무 모호합니다. 고객, 지원 상담원, 결제 전문가, 팀 리더, 자동화처럼 역할을 구체적으로 쓰세요. 시스템 규칙이 변경을 작동시킬 수도 있습니다. 예를 들어 정책에 맞는다면 자동화가 답변 없이 14일이 지난 요청을 고객 답변 대기에서 종료로 바꿀 수 있습니다.

예외에는 별도의 전환이 필요합니다. 고객은 신규 요청을 취소할 수 있지만 이미 완료된 요청은 취소할 수 없을 수 있습니다. 문제가 다시 발생하면 팀 리더가 종료된 요청을 다시 열 수 있습니다. 상담원이 실수로 요청을 할당한 경우에만 검토 중에서 신규로 되돌릴 수도 있습니다. 이런 규칙은 요청 담당자를 보호하고 특정 상태 변경이 불가능한 이유를 설명해 줍니다.

화면을 설계하기 전에 상자와 화살표로 흐름을 그리세요. 두 역할이 요청을 서로에게 계속 돌려보내는 것처럼 끝나지 않는 순환을 찾습니다. 막다른 길도 확인하세요. 요청이 승인 대기로 들어간다면 승인자는 누구인지, 승인 또는 거절 뒤에는 무엇이 일어나는지 정해야 합니다.

AppMaster에서는 나중에 이 맵을 비즈니스 프로세스 로직으로 바꾸고, 역할에 따라 각 사용자가 볼 수 있는 작업을 제어할 수 있습니다. 새로운 팀원도 제출부터 종료까지 한 요청을 따라갈 수 있을 정도로 읽기 쉽게 유지하세요.

모든 인계에 담당자 지정하기

업무가 진행 중인 동안에는 요청에 이름이 정해진 담당자가 한 명 있어야 합니다. 그 사람이 모든 작업을 혼자 끝낼 필요는 없습니다. 하지만 현재 상태를 알고, 요청을 앞으로 진행시키며, 누군가 업데이트를 요청했을 때 답할 책임은 져야 합니다. 공동 책임은 아무도 행동하지 않는 결과로 이어지는 경우가 많습니다.

요청이 진행되면서 담당자가 바뀔 수 있습니다. 지원 상담원이 신규 요청을 맡고, 전문가가 조사를 담당하며, 어카운트 매니저가 최종 고객 답변을 맡을 수 있습니다. 직원이 누가 움직여야 하는지 추측하지 않도록 각 변경을 맵에 기록하세요.

요청 담당자와 검토자, 승인자를 구분하세요. 재무 리더가 환불을 승인하더라도 지원 상담원이 요청 담당자로 남을 수 있습니다. 상담원은 승인을 요청하고, 답변을 추적하며, 고객에게 결과를 알려 줍니다. 승인 버튼을 눌렀다는 이유만으로 재무 리더가 모든 후속 업무를 맡아서는 안 됩니다.

각 인계에서 현재 담당자와 팀, 담당자 변경을 일으킨 조건, 다음 전환 전에 필요한 작업, 담당자가 없을 때 인수할 사람을 기록하세요.

지연이 발생하기 전에 부재 상황을 계획하세요. 팀 큐, 지정된 백업 담당자, 일정 기간이 지나면 요청을 재할당하는 규칙을 사용할 수 있습니다. 전문가가 휴가 중이라면 응답할 수 없는 담당자에게 요청을 남겨 두지 말고 다른 사람이 자신의 큐에서 볼 수 있어야 합니다.

애플리케이션에서 담당자를 명확하게 표시하세요. 비공개 채팅과 이메일 스레드는 업무를 지원할 수 있지만 워크플로 자체가 되어서는 안 됩니다. 각 요청 기록에는 현재 담당자, 이전 인계, 할당 시간, 재할당 사유가 표시되어야 합니다. 관리자는 너무 오래 기다린 요청을 찾을 수 있고, 고객 응대 직원은 메시지를 뒤지지 않고도 업데이트를 제공할 수 있습니다.

예를 들어 고객이 결제 오류를 신고하면 지원 상담원이 재무팀의 검토가 필요하다고 확인할 때까지 요청을 담당합니다. 그다음 재무 분석가가 조사를 맡습니다. 재무팀이 결정을 기록하면 담당자는 고객 답변과 종료를 위해 다시 지원팀으로 돌아갑니다. 이렇게 하면 두 사람이 서로 다른 답변을 보내거나 상대방이 답했을 것이라고 생각하는 일을 막을 수 있습니다.

앱에서 워크플로를 만들 때 상태 전환 자체에 담당자 변경을 포함하세요. AppMaster에서는 상태 변경, 할당 규칙, 감사 기록을 하나의 비즈니스 프로세스로 연결할 수 있습니다. 팀이 커져도 담당자를 명확하게 유지하는 데 도움이 됩니다.

업무에 맞는 마감일 설정하기

요청에는 보통 두 가지 마감일이 필요합니다. 응답 마감일은 첫 번째 의미 있는 답변까지의 시간입니다. 예를 들어 지원 상담원이 요청을 읽었고 추가 정보가 필요한지 확인해 주는 시점이 여기에 해당합니다. 완료 마감일은 팀이 요청을 해결하거나 약속한 결과를 전달해야 하는 시점입니다.

이 두 날짜를 분리하면 흔한 문제를 피할 수 있습니다. 고객은 빠르게 접수 확인을 받았지만 요청은 며칠 동안 아무 처리 없이 남는 문제입니다. 접근 권한 요청은 영업일 기준 4시간 안에 답변하고 2영업일 안에 완료해야 할 수 있습니다. 복잡한 결제 분쟁은 하루 안에 답변하되 완료 목표는 더 길게 잡을 수 있습니다.

각 시계가 정확히 언제 시작되는지 적어 두세요. 많은 팀이 시스템이 요청을 받은 순간부터 응답 시간을 계산합니다. 완료 시간은 같은 순간에 시작할 수도 있고, 팀이 작업에 필요한 정보를 모두 받은 뒤 시작할 수도 있습니다. 하나의 규칙을 선택하고 일관되게 적용하세요.

일시 중지 규칙도 같은 수준으로 정해야 합니다. 고객 답변, 승인된 제3자, 예정된 유지보수 시간을 기다리는 동안 시계를 멈출 수 있습니다. 누락된 정보가 도착하거나 장애 요인이 사라지면 다시 시작해야 합니다. 담당자가 바쁘거나 자리를 비웠다는 이유로 마감일을 멈추지는 마세요. 담당자나 관리자가 업무를 재할당해야 합니다.

마감일이 가까워지기 전에 에스컬레이션을 추가하세요. 허용 시간의 75%가 지났을 때 담당자에게 알리면 행동할 시간이 생깁니다. 90%가 지나면 관리자나 다음 책임 팀에 알립니다. 마감일을 넘기면 요청을 기한 초과로 표시하고 다음 행동을 적으세요.

간단한 정책은 다음과 같을 수 있습니다.

• 고객이 요청을 제출하면 응답 시간이 시작됨
• 팀이 구체적인 질문을 하고 요청이 고객 답변 대기로 바뀌면 완료 시간이 일시 중지됨
• 고객이 답변하면 시간이 다시 시작되고 요청은 현재 담당자에게 돌아감
• 마감일이 가까워지면 담당자에게 알림을 보내고, 이후 관리자에게 에스컬레이션함
• 기한이 지난 요청에는 관리자가 복구 계획을 지정하고 고객에게 업데이트함

모두가 그 일정에 동의하는 경우에만 영업시간을 사용하세요. 주 7일 지원을 약속한 팀이 매일 저녁 조용히 시간을 멈춰서는 안 됩니다. 지원팀이 월요일부터 금요일까지 운영된다면 워크플로 규칙에 근무 시간, 휴일, 시간대를 정의하세요. 명확한 규칙은 고객과 직원 모두에게 마감일 알림이 공정하게 전달되도록 합니다.

소음 없이 알림 계획하기

알림은 한 가지 실용적인 질문에 답해야 합니다. 지금 누군가가 알아야 하거나 행동해야 하는가? 그렇지 않다면 요청 기록 안에 업데이트를 남기세요. 시끄러운 받은편지함은 고객과 직원이 중요한 메시지까지 무시하게 만듭니다.

요청이 고객에게 영향을 주는 방식으로 바뀔 때 고객에게 메시지를 보내세요. 일반적인 시점은 접수 확인, 추가 정보 요청, 요청 승인 또는 거절, 약속된 완료일 변경, 업무 완료입니다. 직원이 오타를 고치거나 내부 메모를 추가하거나 예상 결과를 바꾸지 않고 작업을 재할당한 경우에는 고객에게 알리지 않아도 됩니다.

내부 알림에도 담당자와 행동할 이유가 필요합니다. 요청이 «검토 필요»로 바뀌면 검토자에게 알립니다. 고객이 질문에 답변하면 후속 조치를 담당하는 사람에게 알립니다. 두 경우 모두 팀 전체에 알림을 보낼 필요는 없습니다.

메시지는 쉽고 구체적으로 작성하세요. 요청을 식별하고 현재 상태를 알려 주며 다음에 일어날 일을 설명합니다. 예를 들면 다음과 같습니다.

• 고객: «장비 요청 #1842를 접수했습니다. 화요일까지 검토하겠습니다.»
• 검토자: «요청 #1842를 화요일 오후 3시까지 승인해 주세요.»
• 고객: «요청 #1842가 승인되었습니다. 금요일까지 배송 일정을 정하고 업데이트하겠습니다.»

표현만큼 타이밍도 중요합니다. 마감일 알림은 5분 전에 도착하는 것이 아니라 담당자가 행동할 수 있을 만큼 일찍 도착해야 합니다. 검토 기간이 이틀이라면 보통 전날 한 번, 마감일이 지난 뒤 한 번 알리면 충분합니다. 담당자가 업무를 완료하면 앱이 대기 중인 알림을 중지해야 합니다.

맵에서 각 전환 옆에 알림 규칙을 기록하세요. 메시지를 받는 사람, 알림을 일으키는 이벤트, 전달 채널, 앱에 알림이 필요한지를 적습니다. 그러면 누군가 화면을 만들거나 자동화를 작성하기 전에 동작을 분명하게 정할 수 있습니다.

간단한 고객 요청 따라가기

고객이 지원 양식을 통해 중복 결제를 신고합니다. 양식은 상태가 «신규»이고 지원 큐에 할당된 요청 #4821을 생성합니다. 고객은 요청 번호와 팀이 영업일 기준 하루 안에 케이스를 검토한다는 안내가 포함된 즉시 확인 메시지를 받습니다.

지원 상담원이 요청을 열고 주문 및 결제 기록을 확인한 뒤 상태를 «검토 중»으로 변경합니다. 상담원이 요청 담당자입니다. 결제 기록에 정보가 부족하면 «고객 답변 대기»를 선택하고 은행 거래 내역 스크린샷이나 카드 번호 마지막 네 자리를 요청합니다.

이 상태에는 마감일이 필요합니다. 애플리케이션은 3일 뒤 고객에게 알림을 보내고, 7일 동안 답변이 없으면 요청을 종료할 수 있습니다. 고객이 누락된 정보를 추가하면 상담원에게 알림을 보내야 요청이 큐에 묻히지 않습니다.

고객이 답변하면 요청은 «검토 중»으로 돌아가고, 가능하면 같은 상담원에게 다시 할당됩니다. 같은 질문을 새 상담원이 반복하지 않도록 업무의 연속성을 유지하는 것이 중요합니다.

상담원이 중복 결제를 확인하면 요청을 «환불 결정»으로 변경하고 재무 검토자에게 할당합니다. 재무팀에는 환불을 승인하거나 거절할 영업일 기준 2일이 주어집니다. 마감일 하루 전 알림을 보내면 고객이 다시 문의하기 전에 검토자가 행동할 수 있습니다.

재무 검토자가 결정을 기록합니다. 승인된 요청은 «환불 처리»로 이동합니다. 결제팀은 환불을 처리하고 참조 번호를 입력합니다. 거절된 요청은 상담원이 고객에게 명확하게 설명할 수 있도록 사유와 함께 지원팀으로 돌아갑니다.

지원팀은 환불을 처리했거나 거절 사유를 설명한 뒤에만 최종 메시지를 보냅니다. 이후 상담원이 상태를 «종료»로 변경합니다. 고객은 결과가 담긴 종료 안내를 받고, 팀은 담당자, 결정, 마감일, 메시지의 전체 기록을 보관합니다.

이 맵은 한 화면에서는 끝난 것처럼 보이지만 다른 팀의 큐에서는 여전히 작업을 기다리는 요청이 생기는 흔한 문제를 막아 줍니다.

워크플로를 혼란스럽게 만드는 흔한 실수

대부분의 요청 워크플로가 혼란스러워지는 이유는 설계자에게는 라벨이 분명해 보여도 매일 사용하는 사람에게는 그렇지 않기 때문입니다. «대기 중»이라는 상태가 고객 답변을 기다리는 것인지, 관리자의 승인을 기다리는 것인지, 기술자가 부품을 기다리는 것인지 알 수 없다면 각각 다른 다음 단계가 필요합니다.

모호한 라벨을 대기 이유를 설명하는 상태로 바꾸세요. «고객 세부 정보 대기»는 요청자에게 무엇을 해야 하는지 알려 줍니다. «관리자 승인 대기»는 관리자에게 진행을 막고 있는 일이 무엇인지 알려 줍니다. 다음에 누가 행동해야 하는지 말할 수 없다면 상태 이름을 바꾸거나 제거하세요.

담당자도 자주 문제가 됩니다. 요청에 지원팀, 재무팀, 운영팀이 관여할 수 있지만 이름을 여러 개 적는다고 공동 책임이 생기지는 않습니다. 작업이 진행 중인 각 상태에 담당자 한 명을 지정하세요. 담당자는 다른 사람에게 의견을 요청할 수 있지만 요청을 앞으로 진행시키거나 지연을 설명할 책임은 계속 집니다.

마감일에는 연결된 행동이 필요합니다. 아무도 반응하지 않는데 알림만 보내는 기한은 효과가 거의 없습니다. 시간이 다 되면 담당자에게 알릴지, 관리자에게 에스컬레이션할지, 검토 큐로 요청을 옮길지 정하세요. 지연이 미치는 영향에 맞춰 행동을 선택하세요.

유용해 보인다는 이유만으로 화면을 만들지 마세요. 모든 화면은 분명한 작업, 결정, 인계를 지원해야 합니다. «품질 검토» 화면은 누군가 정해진 기준을 확인하고 요청을 승인하거나 사유와 함께 돌려보낼 때만 의미가 있습니다. 그 행동을 쉽게 설명할 수 없다면 불확실성을 다른 페이지 뒤에 숨기지 말고 상태를 제거하세요.

화면을 설계하기 전에 수명 주기의 각 부분을 다음 네 가지 질문으로 테스트하세요.

• 이 상태는 정확히 무엇을 뜻하는가?
• 이 상태에서 요청의 담당자는 누구인가?
• 어떤 이벤트가 다음 상태로 이동시키는가?
• 마감일이 지나면 무엇이 일어나는가?

이 점검은 빈틈을 일찍 찾아 줍니다. 또한 각 상태에 목적, 담당자, 정해진 행동이 있으므로 요청 워크플로를 앱으로 옮기기도 쉬워집니다.

화면 설계 전에 빠르게 점검하기

UI 빌더를 열기 전에 간단한 검토를 통과할 수 있어야 합니다. 바쁜 화요일에 실제 요청을 처리하는 직원이라고 생각하고 맵을 읽어 보세요. 다음에 무엇을 해야 할지 알 수 없다면 화면도 그 문제를 해결하지 못합니다.

모든 상태에 분명한 역할과 최소 하나의 종료 경로를 지정하세요. «고객 답변 대기»는 팀이 정보를 필요로 한다는 뜻이므로 고객이 답변하거나 취소하거나 합의한 답변 기한을 넘겼을 때 이동할 수 있어야 합니다. 팀이 그 상태에서 정확히 어떤 작업을 하는지 모른다면 «진행 중»처럼 일반적인 느낌만 설명하는 상태는 피하세요.

각 전환을 검토하면서 무엇이 작동시키는지, 누가 실행할 수 있는지 물어보세요. 지원 상담원은 답변을 보낸 뒤 요청을 해결됨으로 표시할 수 있습니다. 고객은 요청을 다시 열 수 있습니다. 시스템 규칙은 답변 없이 14일이 지나면 요청을 종료할 수 있습니다. 사람들이 실수로 요청을 변경하지 않도록 이런 권한을 적어 두세요.

다음 목록으로 검토하세요.

• 모든 상태에 목적, 종료 경로, 합리적인 다음 상태가 있음
• 모든 전환에 트리거와 실행할 수 있는 사람 또는 규칙이 지정되어 있음
• 모든 열린 요청에 담당자 한 명과 완료 기한 또는 응답 마감일이 있음
• 상태 변경이 고객에게 영향을 줄 때마다 고객 업데이트가 발생함
• 기한 초과 경로에 알림을 받을 사람과 해야 할 일이 정해져 있음

혼란이 시작되기 쉬운 인계에서 담당자를 확인하세요. 지원 상담원이 기술 문제를 엔지니어링팀으로 보낸다면 요청에는 새 담당자가 지정되어야 합니다. 기존 상담원은 참조자로 남을 수 있지만 두 사람이 서로가 답할 것이라고 생각해서는 안 됩니다.

마감일 알림은 실용적으로 유지하세요. 마감일 전에 내부 알림을 보내고 요청이 계속 열려 있을 때만 에스컬레이션하세요. 고객에게는 입력이 필요할 때, 요청이 다른 팀으로 넘어갈 때, 팀이 요청을 해결하거나 종료할 때 알립니다. 모든 내부 메모를 고객에게 알릴 필요는 없습니다.

맵이 종이 위에서도 명확하게 읽히면 화면의 역할도 분명해집니다. 올바른 사람이 올바른 상태, 작업, 담당자, 마감일을 볼 수 있게 하면 됩니다.

맵을 애플리케이션으로 바꾸기

고객 요청 수명 주기가 분명해지면 맵의 각 부분을 앱의 기능으로 직접 옮길 수 있습니다. 상태는 상태 필드가 됩니다. 담당자는 할당된 사용자 또는 팀이 됩니다. 마감일은 날짜 및 시간 필드가 됩니다. 전환은 «할당», «세부 정보 요청», «해결», «다시 열기» 같은 작업이 됩니다.

첫 버전은 단순하게 유지하세요. 요청 화면에는 보통 고객, 요청 유형, 설명, 현재 상태, 담당자, 마감일, 활동 이력, 파일이 필요합니다. 별도의 큐에서는 각자가 처리해야 할 요청을 볼 수 있습니다.

워크플로는 라벨을 보여 주는 데 그치지 말고 작업을 제어해야 합니다. 지원 상담원은 요청을 «신규»에서 «검토 중»으로 변경할 수 있습니다. 지정된 해결 담당자만 «해결됨»으로 표시할 수 있습니다. 해결된 뒤 고객이 답변하면 앱이 요청을 다시 열어 적절한 큐로 돌려보낼 수 있습니다.

모든 화면을 만들기 전에 실제 요청을 접수하고 해결하는 사람들과 작동하는 초안을 테스트하세요. 일반적인 요청, 긴급한 요청, 정보가 누락된 요청을 처리하게 하세요. 작업을 찾을 수 없거나, 담당자를 알 수 없거나, 질문을 하기 위해 앱 밖으로 나가야 하는 순간을 살펴보세요.

피드백을 사용해 화면뿐 아니라 맵도 수정하세요. 두 팀을 혼란스럽게 하는 인계에는 «승인 대기» 같은 상태가 필요할 수 있습니다. 요청이 너무 오래 머문다면 더 분명한 마감일이나 담당자 알림이 필요할 수 있습니다. 모든 작은 활동을 설명하려고 상태를 추가하지는 마세요. 선택지가 너무 많으면 워크플로를 따라가기 어려워집니다.

AppMaster를 사용하면 이 설계를 노코드 요청 앱으로 바꿀 수 있습니다. Data Designer에서 요청, 사용자, 팀, 마감일, 상태 이력을 모델링할 수 있습니다. Business Process Editor에서는 할당, 상태 변경, 알림, 에스컬레이션을 정의할 수 있고, 웹 또는 네이티브 모바일 화면에서는 요청 큐, 상세 화면, 관리자 보고서를 지원할 수 있습니다.

요청 유형 하나와 소규모 사용자 그룹으로 시작하세요. 이들이 우회 방법 없이 요청을 생성하고, 할당하고, 업데이트하고, 종료할 수 있게 되면 다음 요청 유형을 추가합니다. 그러면 보기 좋은 화면만 있고 사람들이 무엇을 해야 할지 모르는 앱이 아니라, 바쁜 날에도 실제 업무를 지원하는 애플리케이션을 만들 수 있습니다.