B Builder로그
Builderlog ·운영 시스템·플레이북 ·빌더로그 필드 매뉴얼 ⑨ ·2026.08.02 ·5 분 읽기

문의 한 건을 한 행으로 관리하는 영업 리드 추적표

#영업관리#리드추적#스프레드시트#문의관리#업무자동화

2026-08-02 기준으로 이 글에서 확인할 수 있는 것은 단순합니다. 영업 문의는 한 건을 한 행에 두고, 담당자·상태·다음 행동·기한·예외를 같은 화면에서 관리하면 됩니다. 무료 스프레드시트만으로 시작할 수 있고, 자동화는 필요하지 않습니다. 다만 이 템플릿의 매출이나 전환 성과는 검증되지 않았습니다.

연락처 목록만으로는 다음 일이 보이지 않았다

문의 관리표를 처음 만들면 이름, 연락처, 회사 같은 정보부터 채우기 쉬웠어요. 저도 그 구성이 자연스러워 보였습니다. 문제는 연락처를 모으는 일과 영업을 진행하는 일이 다르다는 데 있었어요.

누가 답해야 하는지, 지금 어디에서 멈췄는지, 다음에 무엇을 할지 보이지 않으면 표는 주소록에 가까워집니다. 메모 칸에 모든 내용을 넣는 방식도 오래 버티기 어려웠어요. 같은 문장 안에 요청, 일정, 판단, 예외가 섞이기 때문입니다.

리드 추적표의 중심은 고객 정보가 아니라 다음 행동이었습니다.

한 행에 남겨야 할 최소 구조

제가 초심자용 표를 다시 본다면 아래 열부터 확인하게 됐어요.

담는 내용비어 있을 때 생기는 문제
문의무엇을 요청했는지 알아볼 짧은 이름행의 대상을 구분하기 어려움
연락 경로이메일, 소개, 문의 양식 같은 유입 경로답변 맥락을 놓치기 쉬움
담당자다음 판단을 맡은 사람서로 처리했다고 생각할 수 있음
상태신규, 확인 중, 회신 대기, 종료 같은 현재 위치진행과 정지를 구분하기 어려움
다음 행동실제로 이어질 작업상태만 바뀌고 일이 멈출 수 있음
기한다음 행동을 다시 볼 시점우선순위가 기억에 의존함
예외보류 이유, 승인 조건, 연락 제한 같은 특이사항일반 절차로 처리하면 안 되는 건이 섞임
근거원문이나 관련 문서의 위치판단을 재검토하기 어려움

상태와 다음 행동은 비슷해 보여도 역할이 달랐어요. 상태는 현재 위치이고, 다음 행동은 앞으로 움직일 동사입니다. 예를 들어 회신 대기는 상태이고 요청 범위를 확인해 답변 초안 작성은 다음 행동입니다.

담당자는 직책보다 실제로 다음 행동을 이어받는 사람으로 적는 편이 명확했어요. 혼자 운영한다면 담당자 열이 불필요해 보일 수 있습니다. 그래도 나중에 협업하거나 외부 확인을 기다릴 때 책임 경계가 드러나는 장점이 있었어요.

합성 문의를 넣어 보니 빈칸의 의미가 달라졌다

아래는 실제 고객 기록이 아닌 가상 예시입니다. 편의점 행사 알림 서비스의 제휴 문의를 가정했습니다.

문의연락 경로담당자상태다음 행동기한예외근거
행사 정보 제휴 문의문의 양식운영 담당확인 중제공 가능한 정보 범위를 내부 확인미정가격표보다 데이터 사용 범위를 먼저 확인문의 원문 링크
공동 안내문 요청이메일콘텐츠 담당회신 대기상대 측 수정 의견 확인상대 회신 후공개 전 문구 승인 필요초안 문서 링크
지원 범위 밖 요청소개운영 담당종료 검토종료 사유 기록해당 없음개인정보가 포함되면 별도 보관 금지요청 요약 링크

기한을 억지로 채우지 않고 미정, 상대 회신 후, 해당 없음처럼 이유가 보이게 두는 편이 나았어요. 빈칸은 누락인지 의도인지 구분되지 않지만, 이런 값은 현재 조건을 설명합니다.

[이미지 캡션: 담당자·상태·다음 행동·기한·예외 열이 한 화면에 보이고, 합성 문의가 행 단위로 정리된 스프레드시트 예시]

빈칸을 없애는 것보다 빈칸의 이유를 남기는 편이 더 유용했습니다.

검증은 화려한 기능보다 행의 완결성을 보는 일이었다

검토일은 2026-08-02입니다. 조건은 무료 스프레드시트에서 초심자가 수동으로 문의를 기록하는 상황으로 한정했습니다. 실제 매출, 사용자 수, 전환율, 비용, 운영 기간은 제공되지 않았기 때문에 이 표가 성과를 높인다고 판단할 근거는 없습니다.

검증 과정에서는 합성 문의마다 같은 질문을 대입했습니다.

  • 이 행만 읽어도 문의 대상을 구분할 수 있는가
  • 현재 상태와 다음 행동이 서로 다른 정보로 적혀 있는가
  • 다음 행동의 담당자가 드러나는가
  • 다시 확인할 시점이나 그 시점이 없는 이유가 보이는가
  • 일반 절차에서 벗어나는 조건이 예외 열에 남아 있는가
  • 판단의 근거로 돌아갈 위치가 있는가

한 행을 읽고 다음 움직임을 설명할 수 없다면 열이 많아도 추적표는 완성되지 않았습니다.

실패하기 쉬운 지점과 이 표의 한계

가장 먼저 막히는 방식은 상태를 자유 문장으로 적는 경우였어요. 표현이 제각각이면 같은 단계의 문의를 함께 보기 어렵습니다. 반대로 상태 종류를 지나치게 세밀하게 나누면 갱신 자체가 일이 됩니다.

예외를 메모 전체처럼 사용하는 것도 경계가 필요했어요. 예외 열에는 평소 절차와 달라지는 조건만 남고, 긴 대화 내용은 근거 링크 쪽에 있는 편이 읽기 쉬웠습니다.

이 템플릿은 문의를 놓치지 않도록 구조를 만드는 출발점입니다. 복잡한 권한 관리, 대량 발송, 계약 승인, 개인정보 보관 정책까지 대신하지는 못합니다. 민감한 정보가 들어온다면 무료 표에 그대로 옮기는 판단부터 다시 검토할 필요가 있습니다.

제가 남긴 세 줄 요약

  • 문의 한 건은 한 행에 모였을 때 책임과 진행 상태가 함께 보였습니다.
  • 상태만으로는 부족했고, 다음 행동·담당자·기한이 이어져야 했습니다.
  • 예외와 근거를 분리하니 특이사항과 원문을 다시 확인하기 쉬웠습니다.

최종 판단은 단순했다

초심자에게 필요한 것은 복잡한 영업 시스템보다 다음 행동이 비어 있지 않은 한 행이었습니다. 문의가 많다는 이유만으로 자동화를 먼저 붙일 근거는 없었어요. 이 구조를 수동으로 갱신하기 어렵거나 권한과 보관 규칙이 복잡해질 때가 다음 도구를 검토할 경계로 보였습니다.

제가 시작점으로 택할 산출물은 문의 | 연락 경로 | 담당자 | 상태 | 다음 행동 | 기한 | 예외 | 근거라는 빈 헤더 한 줄입니다. 첫 문의를 이 구조에 옮겨 보면서 어떤 열이 실제 판단에 쓰이는지 확인하는 것이 이 글의 유일한 제안입니다.

이어지는 기록

한 줄로 정리하면

영업 문의는 한 건을 한 행에 두고 다음 행동의 주인과 시점을 함께 남길 때 추적 가능한 일이 됩니다.

다음 편에서는 이 표에서 회신 대기와 내부 지연을 구분하는 검토 규칙을 다룹니다.