GTD 업무 관리를 영업에 적용한다면 고객의 구매 단계 옆에 내가 할 일과 기다리는 답을 따로 적어야 합니다. 고객이 검토 중이어도 제가 보낼 자료는 남아 있을 수 있습니다. 딜 전체를 대기로 치우면 그 일까지 놓치게 됩니다. 여기서 제안하는 CRM 기록표는 GTD의 개념을 영업에 옮긴 적용안이며, 실제 성과를 검증한 사례는 아닙니다.
GTD 업무 관리에서 고객 이름만 적으면 왜 다시 생각해야 할까요?
GTD는 Getting Things Done의 줄임말로, 해야 할 일을 모으고 뜻을 정한 뒤 실행·검토할 수 있게 관리하는 방법입니다. 고객 이름 옆에 실제로 시작할 수 있는 행동을 적는 데서 영업 적용을 시작해 볼 수 있습니다.
회사에서 GTD 이야기를 나눴습니다. 듣다 보니 영업사원 머릿속에 쌓여 있는 딜들이 떠올랐어요. 견적서를 보내야 하는 곳, 제안서를 고쳐야 하는 곳. 고객이 내부에서 검토하고 있는 곳도 있고, 예산이 잡힐 때까지 기다려야 하는 곳도 있습니다. 그런데 전부 ‘내가 챙겨야 할 고객’이라는 이름으로 머릿속에 남아 있죠.
‘A사 팔로업’이라고 써놓으면 다시 열었을 때 또 생각해야 합니다. 메일을 보내야 하나, 전화해야 하나, 무슨 얘기를 해야 하나.
예를 들어 ‘A사 담당자에게 수정 견적서 보내기’라고 적으면 바로 시작할 수 있습니다. 견적 수정부터 필요한 상황이라면 첫 행동을 ‘수정할 견적 항목 확인하기’로 더 작게 적습니다. ‘B사 제안 준비’도 ‘지난 미팅에서 요청받은 도입 일정표 초안 작성하기’로 바꾸고요. A사·B사는 설명용 가상 예시입니다.
David Allen Company의 정의에서 Next Action은 눈에 보이는 구체적인 다음 행동입니다. 고객과의 거래를 통째로 끝낼 수는 없어도, 지금 손댈 일은 정할 수 있습니다.
고객 회신 대기와 나중에 검토할 일은 어떻게 다른가요?
이미 요청한 답을 기다리는 일은 Waiting For, 지금 실행을 약속하지 않은 가능성은 Someday/Maybe입니다. 전자는 누구에게 무엇을 기다리는지 적고, 후자는 앞으로 다시 볼 가능성을 보관합니다. 기다리는 시간이 길다는 이유로 같은 목록에 넣지는 않습니다.
처음에는 고객 손에서 오래 걸리는 딜은 전부 Maybe로 빼두면 되겠다고 생각했습니다. 그런데 GTD의 분류로 보면 고객의 답변이나 내부 검토 결과를 기다리는 일은 Waiting For에 해당합니다.
둘을 섞어두면 결재를 기다리는 고객과 아직 아무 약속도 없는 잠재고객이 같은 목록에 들어갑니다. 그럼 다시 연락해야 할 곳이 빠질 수 있겠죠.
| 설명용 상황 | 기록할 곳과 내용 |
|---|---|
| 고객이 수요일까지 검토 결과를 주기로 함 | 고객 회신 대기: 담당자·기다리는 답·약속 날짜 |
| 고객에게 목요일 오전에 확인 전화를 하기로 함 | 날짜가 정해진 일: 목요일 오전 확인 전화 |
| 그 전에 내가 도입 일정표를 보내야 함 | 내 다음 행동: 도입 일정표 초안 작성하기 |
| 고객이 언젠가 필요할 수 있다고만 말함 | 추후 검토: 진행하지 않는 이유·다시 볼 조건 |
약속한 회신 날짜와 제가 다시 확인할 날짜는 같지 않을 수 있습니다. 고객이 수요일에 답을 주고 목요일에 함께 살펴보기로 했다면 두 약속을 각각 남깁니다. 날짜는 상대와 합의한 내용을 기록하며, 위 요일이 권장 연락 간격이라는 뜻은 아닙니다.
2분 규칙은 모든 연락에 바로 반응하라는 뜻인가요?
GTD의 2분 규칙은 받은 일을 정리할 때 필요한 짧은 행동을 처리하는 기준입니다. 종일 들어오는 알림을 따라다니라는 지시로 읽으면, 따로 시간을 들여야 하는 일을 하기 어려워집니다.
이미 있는 자료의 링크를 보내거나 미팅 시간을 확인하는 답장이라면 정리하는 자리에서 끝낼 수 있습니다. 나중에 다시 읽고 무슨 일이었는지 떠올리는 수고를 덜 수 있죠.
물론 고객별로 내용을 고쳐야 하는 제안서를 2분 만에 대충 보내자는 뜻은 아닙니다. 그건 따로 시간을 잡아야 할 일이고, 작성할 내용부터 정해둬야겠죠.
공식 2분 규칙 설명도 받은 일을 분류하는 상황과 지금 무엇을 실행할지 선택하는 상황을 구별합니다. 전화가 오면 무조건 받기, 메일이 오면 무조건 답하기로 바꾸지 않습니다.
같은 고객에게 내 할 일과 기다리는 답이 함께 있어도 되나요?
서로 독립적으로 할 수 있는 일이라면 함께 남겨도 됩니다. 고객이 내부 회의 결과를 정리하는 동안 저는 도입 일정표를 만들 수 있습니다. 고객의 답을 받아야만 수정할 수 있는 견적서는 답이 오기 전 실행 목록에 올리지 않고 필요한 자료와 함께 남깁니다.
프로젝트 관리에 대한 공식 안내는 서로 병렬로 실행할 수 있는 다음 행동을 허용하고, 선행 작업이 끝나야 가능한 일과 구별합니다. 고객 대기와 내 행동을 딜 전체의 배타적인 상태로 나누지 않는 이유입니다.
CRM에서 ‘제안 중’, ‘협상 중’ 같은 딜 단계는 그대로 필요합니다. 그와 별개로 내가 할 일, 고객에게 기다리는 답, 다시 확인할 날짜가 보이면 좋겠어요. 같은 ‘제안 중’이어도 한 곳은 내가 제안서를 고쳐야 하고, 다른 곳은 고객이 회의에 올린 결과를 기다리고 있을 테니까요.
고객이 계약에 얼마나 가까워졌는지는 영업 파이프라인의 단계 기준으로 확인합니다. 이 글의 기록표가 자세해졌다는 이유로 구매 진척이 확인된 것은 아닙니다.
GTD 업무 관리 기록을 언제 다시 보나요?
고객과 정한 날짜가 오면 해당 항목을 확인하고, 목록 전체는 주기적으로 검토합니다. 대기 날짜가 지났거나 답변이 들어왔다면 제가 할 다음 행동을 다시 정합니다. 날짜가 지난 항목을 계속 같은 대기 목록에 남겨놓지 않습니다.
주간 검토는 GTD의 공식 안내에 포함된 방법입니다. 영업에 적용할 때는 이 주기와 별개로 고객에게 약속한 날짜도 지켜야 합니다. 금요일이 주간 검토 날이어도 수요일 회신 약속을 금요일까지 미룬다는 뜻은 아니죠.
- 지금 제가 시작할 구체적인 행동이 적혀 있는지
- 누구의 어떤 답을 기다리는지
- 고객과 약속한 날과 제가 다시 확인할 날이 남아 있는지
- 지금 진행하지 않는 고객을 다시 볼 조건이 있는지
이 항목들은 행사 명단을 CRM에 등록할 때도 함께 쓸 수 있습니다. 답이 없을 때 보낼 문장 자체는 후속 연락 예시에서 다뤘습니다.
이렇게 한다고 담당할 수 있는 고객 수가 무한히 늘지는 않을 겁니다. 제안서를 쓰고 고객을 만나는 데 드는 시간은 여전히 필요하니까요. 다음에 ‘고객 검토 중’이라고 적을 때는 누구의 무슨 답을 기다리는지, 언제 다시 확인할지도 같이 적어보려고 합니다.
자주 묻는 질문
- GTD 업무 관리를 영업에 어떻게 적용하나요?
- 고객별 다음 행동과 상대에게 기다리는 답을 따로 적습니다. 날짜가 정해진 약속과 지금 진행하지 않는 가능성도 구별합니다. 딜 단계 옆에 담당자·할 일·답변 약속·재확인 날짜를 함께 두는 것은 이 글의 영업 적용안입니다.
- 고객 검토 중인 딜은 Someday/Maybe인가요?
- 이미 요청한 검토 결과나 회신을 기다린다면 Waiting For에 해당합니다. Someday/Maybe는 현재 실행하기로 약속하지 않았지만 나중에 다시 검토할 가능성입니다. 오래 걸린다는 이유만으로 같은 곳에 넣지 않습니다.
- 2분 규칙은 연락이 올 때마다 바로 답하라는 뜻인가요?
- 받은 일을 정리할 때 짧게 끝나는 필요한 행동을 처리하는 기준입니다. 종일 알림에 반응하라는 뜻은 아닙니다. 새 제안서를 만드는 일은 실행할 시간을 따로 정합니다.
- 고객 답을 기다리면서 내 할 일도 있을 수 있나요?
- 있습니다. 고객은 검토 결과를 준비하고, 나는 도입 일정표를 작성할 수 있습니다. 서로 독립적으로 할 수 있는 일이라면 같은 고객 아래 대기 항목과 내 행동을 함께 남깁니다.
- CRM의 딜 단계를 바꿔야 하나요?
- 이 글은 딜 단계 변경을 제안하지 않습니다. 고객의 구매 진척을 나타내는 단계와 담당자의 작업 기록을 함께 보는 방법입니다. 자료를 보냈다는 이유만으로 계약 단계가 올라가지는 않습니다.