클라이언트의 ‘확인 대기’로 멈추지 않는 진행 방법: 결정 요청을 전하는 법

지난 회에서는 AI로 만든 안을 2~3개로 좁히고, 고른 이유를 남기는 방법을 다뤘습니다. 좁힌 안은 대부분 클라이언트에게 보여 주고 정해 달라고 하게 됩니다.

제작 프로젝트에서 가장 긴 대기 시간은 대개 클라이언트의 확인입니다. AI로 작업이 빨라진 만큼 이 대기 시간이 점점 더 눈에 띄게 되었습니다. 이 글에서는 확인 요청을 보내는 방법, 기한을 정하는 방법, 클라이언트를 관리 도구에 초대할지 여부, 답을 남기는 방법을 차례로 정리합니다.

참고: 이 글은 GeckoFlag 개발자가 작성했습니다.

확인 대기가 길어지는 5가지 이유

답이 오지 않으면 상대가 바빠서라고 생각하기 쉽습니다. 하지만 요청 방식을 다시 살펴보면, 우리 쪽에서 줄일 수 있는 대기 시간이 꽤 있습니다. 흔한 이유는 다음 5가지입니다.

• 요청을 찔끔찔끔 보낸다: 메신저나 메일로 한 건씩 보내면 클라이언트는 전체를 볼 수 없습니다. 어느 것이 급한지, 앞으로 몇 건이 남았는지 모르는 채 뒤로 미루게 됩니다.
• 무엇을 정해 주기를 바라는지 쓰여 있지 않다: “확인 부탁드립니다”만으로는 봐 주기를 바라는지, 골라 주기를 바라는지, 승인해 주기를 바라는지가 전해지지 않습니다.
• 기한이 없거나, 기한의 이유가 없다: 기한이 없는 요청은 기한이 있는 일에 밀려 뒤로 미뤄집니다. 날짜만 있고 이유가 없으면 클라이언트 담당자도 사내에서 서둘러야 하는 이유를 설명할 수 없습니다.
• 클라이언트 쪽에서 누가 정하는지 모른다: 창구 담당자가 정할 수 있는지, 상사나 임원의 판단이 필요한지. 이 부분이 애매하면 확인은 클라이언트 회사 안에서 멈춥니다.
• 클라이언트 사내의 확인 시간을 고려하지 않았다: 담당자가 상사에게 올리고, 답을 정리해서 돌려주기까지 며칠이 걸리는 것도 드물지 않습니다.

첫머리의 장면도 이 5가지가 겹쳐 있었습니다.

관련메신저나 메일로 부탁한 일이 흘러가 버리는 이유는 입문 연재 「처음 쓰는 프로젝트 관리 도구」 제3회 「메일이나 메신저로 받은 부탁은 왜 흘러가 버릴까」에서도 다루고 있습니다

확인 요청은 ‘정해 주기를 바라는 것의 목록’으로 보낸다

확인 요청은 찔끔찔끔 보내지 말고, 정해진 요일에 모아서 보냅니다. 예를 들어 “매주 화요일 오전에 그 주에 정해 주셨으면 하는 것을 목록으로 보내 드립니다”라고 프로젝트 초반에 클라이언트와 약속해 둡니다.

목록에는 항목마다 다음 내용을 씁니다. 그대로 쓸 수 있도록 템플릿으로 실어 둡니다.

목록을 쓰는 데는 두 가지 요령이 있습니다.

첫째는 ‘추천’을 반드시 덧붙이는 것입니다. 선택지만 늘어놓으면 클라이언트는 처음부터 생각해야 합니다. 추천과 이유가 있으면 “그걸로 부탁드립니다”라고 답하기만 하면 되는 항목이 늘어납니다.

둘째는 ‘기한까지 정해지지 않을 경우’를 미리 정해 두는 것입니다. “기한까지 답을 주시지 않으면 추천안으로 진행하겠습니다”라는 진행 방식은 답을 기다리느라 멈추지 않기 위한 강력한 방법입니다. 다만 이것은 프로젝트 초반에 클라이언트와 합의한 경우, 또는 계약에 그렇게 정해 둔 경우에 한합니다. 합의 없이 일방적으로 진행하면 나중에 “들은 적 없다”는 말이 나오고, 오히려 재작업이 늘어납니다.

주의‘답이 없으면 진행한다’는 킥오프 회의나 견적 단계에서 진행 방식으로 설명하고 양해를 받아 둡니다. 합의가 없는 프로젝트에서는 기한이 지나면 클라이언트에게 전화하는 등 다른 방법을 생각합니다.

기한은 공개일에서 거꾸로 계산해 이유와 함께 전한다

기한은 ‘우리가 답을 받고 싶은 날’이 아니라, 공개일에서 거꾸로 계산해 정합니다. 이때 클라이언트가 사내에서 확인을 돌리는 일수도 고려해 둡니다.

1. 공개일에서, 그 항목이 정해진 뒤의 작업 일수만큼 거슬러 올라간다
2. 다시, 클라이언트 사내에서 확인을 돌리는 일수(예: 3~5영업일)만큼 거슬러 올라간다
3. 그날을 요청을 ‘보내는’ 날로 한다. 기한은 작업을 시작하기 전날로 한다

그리고 기한에는 이유를 덧붙입니다. “11월 6일까지 주시면 11월 20일 공개에 맞출 수 있습니다”라고 쓰면 클라이언트 담당자는 상사에게 서둘러 달라고 할 이유를 설명할 수 있습니다.

또 하나 중요한 것은 클라이언트 사내에서 누가 정하는지를 프로젝트 초반에 물어 두는 것입니다. “디자인의 최종 판단은 어느 분이 하시나요?” “그분께 직접 보여 드릴 자리가 있을까요?” 이것을 물어 두기만 해도 확인 절차가 꽤 보이게 됩니다.

연재확인을 요청한 태스크를 ‘클라이언트 확인 대기’ 상태로 바꾸고, 대기 중인 것을 목록으로 보는 방법은 제3회 「‘판단 대기’를 눈에 보이게 하기」에서 다루고 있습니다

클라이언트를 관리 도구에 초대할까, 초대하지 않을까

확인을 어디서 주고받을지도 정해 두고 싶은 부분입니다. 클라이언트를 관리 도구에 초대해서 그곳에서 주고받는 방법과, 초대하지 않고 목록을 보내는 방법이 있습니다.

어느 쪽이 좋은지는 프로젝트와 상대에 따라 다릅니다. 첫 회의에서 “확인은 어떤 방법이 편하신가요?”라고 클라이언트의 희망을 묻고, 그것을 바탕으로 정합니다. 도중에 바꿀 수도 있습니다.

답을 받으면 정해진 것을 남긴다

답을 받으면 그 항목의 태스크에 다음 내용을 남겨 둡니다.

• 누가 정했는지(클라이언트 쪽 누구의 판단인지)
• 언제 정해졌는지
• 무엇으로 정해졌는지
• 이유(클라이언트가 덧붙여 준 경우에는 그 말 그대로)

메일이나 전화로 받은 답도 요점을 태스크에 옮겨 적어 둡니다. 전화라면 “10월 30일, 클라이언트 홍보 담당자와 통화. A로 진행하기로 결정”처럼 날짜와 상대를 덧붙입니다.

이렇게 해 두면 나중에 “그런 말은 하지 않았다”는 일을 막을 수 있습니다. 담당자가 바뀌어도 경위를 따라갈 수 있습니다. 제2회에서 만든 ‘정하는 태스크’의 ‘정해진 것’과 ‘이유’ 칸이 여기서 채워지는 것입니다.

GeckoFlag에서의 실천 예

GeckoFlag에서 이 진행 방법을 도입하는 예를 소개합니다.

1클라이언트는 ‘게스트’로 초대한다

GeckoFlag의 사용자에게는 ‘관리자’, ‘멤버’, ‘게스트’의 세 가지 역할이 있습니다. 클라이언트를 초대할 때는 게스트로 합니다. 게스트는 관리자가 사용자 관리 화면에서 추가합니다. 클라이언트가 직접 가입하는 방식은 없습니다.

게스트는 참여 중인 프로젝트에서 멤버와 같은 방식으로 이슈·댓글·위키·파일을 다룰 수 있습니다. 열람만 하는 권한이 아니므로 댓글로 답을 받거나 클라이언트가 직접 이슈를 만들게 할 수도 있습니다. 반면 프로젝트를 만들거나 소유자가 될 수는 없습니다. 또한 파일·폴더 추가·삭제나 위키 편집도 할 수 있으므로, 보존해 두고 싶은 자료를 어디에 둘지 신경을 씁니다. 자세한 내용은 매뉴얼의 “역할별 권한”에 정리해 두었습니다.

2정하는 사람을 담당자로, 답변 기한을 마감일로

게스트로 초대한 클라이언트는 이슈의 담당자로 지정할 수 있습니다. 정하는 태스크에서는 클라이언트의 창구 담당자를 담당자로 하고, 답변 기한을 마감일에 넣습니다. 실제로 판단하는 사람이 상사나 임원이라면 설명란의 ‘정하는 사람’에 그분을 적어 둡니다.

이슈의 설명에는 제2회의 템플릿(정하고 싶은 것·멈춰 있는 것·선택지·정하는 사람·기한·정해진 것·이유)에 이 글의 ‘우리의 추천’과 ‘기한까지 정해지지 않을 경우’를 더해서 씁니다. 이 글의 템플릿은 클라이언트에게 보내는 목록을 위한 형태입니다.

3확인 요청은 알림을 보낼 상대를 선택해 댓글로

댓글을 게시할 때 이메일로 알림을 보낼 상대를 선택할 수 있습니다. 확인을 요청하는 댓글에서는 클라이언트를 알림 상대로 선택해 게시합니다. 동시에 상태를 ‘클라이언트 확인 대기’로 바꿔 두면 요청한 내용과 상태 변화가 한 번에 남습니다.

알림은 게시할 때마다 상대를 선택하는 방식입니다. 모두에게 자동으로 전송되는 것은 아닙니다(프로필에서 ‘참여 중인 프로젝트의 이슈에 달린 댓글을 모두 알림 받기’를 선택한 사용자에게는 모든 댓글의 알림이 전송됩니다).

4사내에서만 나눌 이야기는 별도의 프로젝트로 나눈다

GeckoFlag에는 한 프로젝트 안에서 일부 이슈만 게스트에게 숨기는 기능이 없습니다. 견적 상담이나 클라이언트에게 보여 주지 않을 사내 검토는 클라이언트가 참여하지 않은 별도의 프로젝트로 나눠 둡니다. 초대하기 전에 어느 프로젝트에 누가 들어갈지 정해 두면 안심할 수 있습니다.

5해외 클라이언트에게는 표시 언어를 선택하게 한다

화면의 표시 언어는 사용자마다 프로필에서 바꿀 수 있습니다. 해외 클라이언트를 초대하는 경우에도 클라이언트는 자신의 언어로 된 화면에서 이슈를 보고 댓글을 달 수 있습니다. 바뀌는 것은 화면 표시이며, 이슈나 댓글의 본문이 번역되는 것은 아닙니다.

6초대하지 않는 경우에는 답을 댓글에 옮겨 적는다

클라이언트를 초대하지 않는 경우에는 확인 목록을 메일로 보내고, 답을 받으면 해당 이슈의 댓글에 요점을 옮겨 적습니다.

여기서 수고를 줄일 수 있는 것이 “AI로 작성”입니다(v1.9.0부터). 클라이언트가 보낸 답장 메일의 문장이나 채팅 스크린샷을 바탕으로 댓글 초안을 만들 수 있습니다. 사용하려면 Anthropic의 API 키(이용료는 Anthropic에 지불하며 GeckoFlag 가격에는 포함되지 않습니다)와 관리자의 이용 허가가 필요합니다. 스크린샷을 사용하려면 관리자가 이미지 읽기를 켜 두어야 합니다(초기 상태는 꺼짐). “기한을 다음 주로 미뤄 주세요”처럼 분명하게 적혀 있으면 마감일이나 상태 변경도 함께 제안됩니다. 제안된 내용은 사람이 확인하고, 체크한 항목만 양식에 반영됩니다. 저장하기 전까지는 아무것도 바뀌지 않습니다. 자세한 내용은 “AI로 작성” 페이지를 참고하세요.

다만 답장 메일이나 스크린샷에는 클라이언트 측 사람의 이름이나 연락처, 외부에 공개할 수 없는 정보가 들어 있는 경우가 있습니다. 또한 댓글 초안을 만들 때는 그 이슈의 설명과 최근 댓글 5건도 Anthropic에 전송됩니다. AI에 넘겨도 되는 내용인지는 거래처와의 계약이나 사내 규칙에 비추어 확인한 뒤 사용하세요.

연재AI에 넘길 정보의 선 긋기는 제6회 「기록이 있으면 AI가 더 많이 도울 수 있다」에서 자세히 다루고 있습니다

게스트를 추가하는 절차는 매뉴얼의 “사용자 추가 및 편집”과 “역할별 권한”에, 알림의 구조는 “이슈 댓글”에 정리해 두었습니다. 실제 화면은 데모에서 시험해 볼 수 있습니다.

정리

• 확인 대기가 길어지는 이유의 대부분은 요청 방식에 있다. 찔끔찔끔 보낸다, 정해 주기를 바라는 것이 불분명하다, 기한의 이유가 없다, 정하는 사람이 불분명하다, 클라이언트 사내의 시간을 고려하지 않았다
• 확인 요청은 정해 주기를 바라는 것·선택지·추천·기한·기한까지 정해지지 않을 경우를 갖춰서, 정해진 요일에 모아서 보낸다
• ‘답이 없으면 추천안으로 진행한다’는 사전에 합의한 경우에 한한다
• 기한은 공개일에서 거꾸로 계산하고, 클라이언트 사내의 확인 일수를 고려해 이유와 함께 전한다
• 클라이언트를 초대할지는 프로젝트의 길이와 주고받는 양, 상대가 도구에 익숙한지로 정한다
• 답은 ‘누가·언제·무엇으로·왜’의 형태로 그 태스크에 남긴다

클라이언트의 확인은 우리 쪽에서는 앞당길 수 없는 것처럼 보입니다. 하지만 정해 주기를 바라는 것을 상대가 정하기 쉬운 형태로 건네면 대기 시간은 꽤 줄일 수 있습니다.

다음 회에서는 연재의 마무리로, 지금까지 남겨 온 기록을 AI의 도움을 받기 위한 재료로 쓰는 방법을 다룹니다.