프리랜서를 위한 제안 파이프라인 앱: 초안부터 수주/실패까지

왜 제안이 놓쳐지는가

대부분의 프리랜서가 제안을 잃는 이유는 일의 질이 떨어져서가 아닙니다. 제안이 ‘사라지기’ 때문입니다.

흔한 혼란은 익숙할 겁니다: 문서에 초안이 있고, 최종 PDF는 폴더에 있으며, 마지막 고객 메시지는 이메일이나 채팅에 파묻혀 있고, 유일한 “상태”는 당신이 기억하는 것뿐입니다. 고객 작업을 수행하느라 바쁠 때 누가 견적을 기다리는지, 누가 두 번째 독촉이 필요한지 잊기 쉽습니다.

제안은 다음과 같은 곳에 흩어집니다:

• "Proposal v7 FINAL (2)"라는 Google 문서
• 세 가지 다른 제목의 이메일 스레드
• 후속 날짜가 적힌 휴대폰 메모
• 문맥 없는 캘린더 알림
• 당신의 머릿속(너무 늦을 때까지)

제안이 미끄러지는 이유는 간단합니다: 다음 행동을 보여주는 단일 장소가 없습니다. 10초 안에 “다음에 무엇을 해야 하지, 그리고 어느 클라이언트인가?”라고 답할 수 없다면, 후속이 지연됩니다. 후속이 지연되면 고객이 관심이 있어도 거래를 잃습니다.

그게 파이프라인의 본질입니다: 각 제안이 어디에 있는지와 다음에 무엇을 해야 하는지를 보여주는 적은 수의 명확한 상태입니다. 제안 파이프라인 앱은 화려한 영업 도구가 아닙니다. 점수판이자 할 일 목록입니다.

기대를 현실적으로 유지하세요. 예측, 영업 구역, 절대 읽지 않을 리포트를 가진 복잡한 CRM을 만들려는 것이 아닙니다. 실제 작업 방식에 맞고 “다음 단계”를 명확히 해 주는 경량 도구가 필요합니다.

예를 들어 화요일에 웹사이트 재설계 견적을 보내고 금요일에 후속하겠다고 했습니다. 금요일이 바쁘면 월요일에는 이미 확인했는지 기억하지 못할 수 있습니다. "클라이언트 대기 중(Waiting on client)" 같은 한눈에 보이는 단계와 명확한 다음 후속 날짜를 가진 작은 파이프라인이면 그런 조용한 손실을 막을 수 있습니다.

경량 제안 파이프라인이 해야 할 일

제안 파이프라인 앱의 목적은 단 하나입니다: 모든 제안이 최소한의 노력으로 초안에서 수주 또는 실패로 움직이게 하는 것. 추가 관리자 작업이 생기면, 필요할 때 앱 사용을 멈출 것입니다.

무엇인가를 설계하기 전에, 몇 달 뒤에도 제안에 대해 반드시 알고 있어야 할 것이 무엇인지 결정하세요. 후속, 수입 예측, 무엇이 팔리는지 학습하는 데 도움이 되는 소수의 정보로 줄이세요.

각 제안에 대한 실용적인 최소 항목:

• 클라이언트(사람 또는 회사) 및 연락 방법
• 서비스 유형(예: 웹사이트 리프레시, 모바일 앱, 월간 SEO)
• 예상 금액(또는 범위) 및 예상 시작일
• 다음 후속 날짜
• 현재 상태(초안, 발송됨, 협상 중, 수주, 실패)

그리고 "완료"가 무엇인지 정의해 앱이 신뢰할 만하게 유지되도록 하세요. 제안이 발송됨 상태에 영원히 머물러선 안 됩니다. "완료"는 지연된 항목이 알림을 트리거하고, 답을 받으면 결과가 기록되며, 스프레드시트를 내보내지 않아도 간단한 보고를 볼 수 있다는 뜻입니다.

처음에는 범위를 작게 유지하세요. 한 사용자, 한 작업공간, 단순한 필드가 유지보수하지 않는 큰 시스템보다 낫습니다. 이번 주에 제안서를 세 통 보냈다면(예: "랜딩 페이지 + 카피" 두 건과 "유지보수 지원" 한 건), 다음 후속 날짜와 결과를 강제하는 파이프라인은 어떤 서비스가 더 자주 성사되는지, 어디에서 시간이 낭비되는지를 빠르게 보여줄 것입니다.

실제 워크플로에 맞는 상태 선택하기

상태는 실제 일과를 반영할 때만 도움이 됩니다. 이상적인 프로세스가 아니라 실제로 따를 수 있는 상태를 선택하세요. 카드 이동이 수월하도록 상태 수를 충분히 작게 유지하세요.

실용적인 상태 집합:

• Drafting
• Ready to send
• Sent
• Follow-up due
• Negotiating
• Won
• Lost

이름은 짧고 행동 지향적으로 유지하세요. 상태를 읽고 다음에 무엇을 해야 할지 알 수 없다면 이름을 바꾸세요.

다음으로, 아무 것도 좀비 제안으로 변하지 않도록 몇 가지 간단한 규칙을 설정하세요.

예를 들어:

• 클라이언트, 서비스 유형, 총액, 전달 기간이 없으면 제안은 Sent로 옮길 수 없습니다.
• Negotiating은 클라이언트가 회신했고 범위, 가격 또는 조건이 적극적으로 변경되는 것을 의미해야 합니다.
• Won은 서명된 계약, 선금 결제 또는 서면으로 된 "예" 같은 명확한 신호가 있어야 합니다.

후속 날짜는 또 다른 가드레일입니다. 모든 상태에 알림이 필요한 건 아니지만, 일부 상태에는 필요합니다. 기본값으로는 Sent와 Follow-up due에는 다음 후속 날짜가 있어야 합니다. Negotiating도 다음 단계가 당신에게 있을 때만 요구할 수 있습니다.

간단한 시나리오: 월요일에 웹사이트 재설계 견적을 보냅니다. 목요일까지 답이 없으면 Follow-up due로 표시됩니다. 고객이 "블로그를 빼고 가격을 낮출 수 있나요?"라고 회신하면 Negotiating으로 옮기고 다음 날로 후속 날짜를 설정합니다. 이 정도 구조면 워크플로를 서류 작업으로 바꾸지 않고도 모멘텀을 유지할 수 있습니다.

데이터 설계: 클라이언트, 제안, 서비스, 활동

제안 파이프라인 앱은 데이터에 달려 있습니다. 구조가 너무 느슨하면 필드를 건너뛰게 되고, 너무 엄격하면 사용을 멈춥니다. 신뢰할 수 있는 소수의 레코드 집합을 목표로 하고, 실제로 불편함을 느낄 때만 세부를 추가하세요.

네 가지 핵심 객체로 시작하세요: Clients, Proposals, Services, Activities.

핵심 테이블(그리고 저장하는 항목)

첫 버전은 단순하게 유지하세요:

• Clients: 이름, 연락처, 이메일, 메모(선택적으로 회사 규모)
• Proposals: 제목, client_id, service_type(또는 services), 금액, 상태, 발송일, 다음_후속_날짜, 결과_사유
• Services: 이름(예: "Website refresh", "SEO audit"), 선택적 기본 가격 범위
• Activities: proposal_id, 유형(노트, 알림, 통화, 이메일), 타임스탬프, 세부사항

제안에서 next_follow_up_date는 미래의 당신을 위한 안전장치입니다. outcome_reason은 Won이나 Lost로 표시할 때 중요합니다. 예: "Lost: 가격 때문에"와 "Lost: 일정 때문에"는 서로 다른 해결책을 요구합니다.

제안당 하나의 서비스 vs 여러 서비스

제안당 하나의 서비스 유형은 가장 빠른 설정이며 명확한 패키지를 판매한다면 잘 작동합니다. 여러 서비스를 허용하면 번들(디자인+구축+유지보수)을 다룰 때 유리하지만 복잡성이 늘어납니다. 조인 테이블(예: ProposalServices)이 필요하고 보고도 더 어려워집니다.

타협안은 처음에는 하나의 서비스 유형으로 시작하고, 실제로 혼합 제안이 많아질 때만 여러 서비스를 추가하는 것입니다.

활동(Activities)은 이메일을 뒤지지 않고도 가벼운 히스토리를 제공합니다. 제안을 보낸 후 "v2 발송, 고객이 일정 문의" 같은 간단한 메모를 남기면 나중에 무슨 일이 있었는지 한눈에 볼 수 있습니다.

화면 계획: 보드, 목록, 상세, 리포트

각 화면이 명확한 질문에 답한다면 제안 파이프라인 앱에는 몇 개의 화면이면 충분합니다. 목표는 속도입니다: 열고, 주의를 요하는 것을 보고, 한 가지 업데이트를 하고, 나오는 것.

파이프라인 보드(일일 뷰)

이 화면이 일상적으로 사용하는 화면입니다. 각 열은 상태입니다. 각 카드는 다음 결정에 필요한 최소한만 보여야 합니다:

• 클라이언트 이름
• 제안 금액(또는 예상 월간 유지비)
• 다음 후속 날짜
• 서비스 유형 태그

완벽한 레이아웃보다 빠른 동작이 더 중요합니다. 카드나 작은 상세 드로어에서 상태 변경, 후속 날짜 설정, 노트 추가, 수주/실패 표시를 긴 양식 작성 없이 할 수 있어야 합니다.

제안 목록(검색 및 정리 뷰)

보드는 흐름을 위해 좋지만, 목록은 찾기에 더 좋습니다. 상태, 클라이언트, 서비스 유형, 후속 지연 등으로 필터링 가능한 단순한 테이블 스타일 목록을 사용하세요. 주간 정리할 때 이 뷰가 유용합니다.

상세 페이지(빠른 편집, 서류 작업이 아닌)

필요한 것은 두 개뿐: 제안 페이지와 클라이언트 페이지.

제안 페이지는 타임라인(노트, 상태 변경, 다음 후속 날짜)과 금액, 서비스 유형 같은 핵심 필드용입니다. 클라이언트 페이지는 연락처 정보, 현재 제안, 최근 활동 같은 문맥이 모이는 곳입니다.

후속 날짜 변경에 30초가 걸리면 업데이트를 유지하지 않습니다. 이 페이지들을 한 번의 탭으로 편집하도록 최적화하세요.

간단한 리포트(한 화면)

처음에는 하나의 경량 리포트면 충분합니다: 서비스 유형별 성사율과 평균 성사 시간. 이 리포트는 두 가지 질문에 답해야 합니다: "무엇을 더 팔아야 하는가?" 그리고 "어디서 거래가 멈추는가?"

제로부터 사용 가능 상태까지 구축하기

사용 가능한 제안 파이프라인 앱은 "완전한 CRM"이 아닙니다. 활성이 된 것, 막힌 것, 오늘 후속해야 할 것을 보여주는 장소입니다.

같은 날 사용할 수 있는 첫 버전 만들기

데이터 모델과 몇 개의 더미 레코드로 흐름을 테스트하세요. 클라이언트 하나에 제안 두 건과 서비스 유형 두 가지(예: "Website refresh"와 "Ongoing SEO")를 만드세요.

그다음 두 개의 핵심 화면을 만드세요: 보드(상태별 열)와 제안 상세 폼. 보드는 일일 스캔용입니다. 폼은 정확한 업데이트용입니다.

진행 순서 예시:

• 모델: Client, Proposal, ServiceType, Activity
• UI: 보드 뷰 + 제안 상세 폼(상태, 금액, 발송일, 다음 후속)
• 규칙: 주요 필드가 없으면 상태 이동 차단(예: Sent는 발송일 필요)
• 알림: 후속일에 알림(선택적으로 제안이 처음 Sent가 될 때 알림)
• 대시보드: 상태별 카운트 및 서비스 유형별 성사율 차트

"진행 불가" 검사 추가하기

이게 앱을 신뢰할 수 있게 만드는 요소입니다.

예: 드래그로 제안을 Draft에서 Sent로 옮기려 할 때 클라이언트 이메일이나 금액이 없으면 앱이 막습니다. 그런 작은 마찰이 나중에 엉망인 데이터를 방지합니다.

한 가지 기본 규칙으로 모든 열린 제안에 다음 후속 날짜가 있지 않으면 보드에 경고를 표시하세요.

"사용 가능"의 간단한 정의:

• 제안을 60초 이내에 추가할 수 있다
• 한눈에 오늘 누구에게 후속해야 하는지 알 수 있다
• 상태 변경이 일관적이다(반쯤 보낸 제안 없음)
• 서비스 유형별 성사율이 보인다
• 이미 관리 중인 항목에 대해서는 알림이 시끄럽지 않다

성가시지 않은 상태 기반 알림

알림은 파이프라인의 명확한 순간에 묶일 때 가장 효과적입니다. 상태를 알면 제안이 오래 묵을 가능성이 있을 때만 알림을 보낼 수 있습니다.

많은 트리거가 필요하지 않습니다. 간단한 설정 예시는 다음과 같습니다:

• 제안이 Sent로 옮겨질 때 후속 날짜를 요구한다.
• 후속 날짜에 알림을 한 번 보낸다.
• Sent 상태에서 X일 동안 답이 없으면 자동으로 후속 작업을 생성한다.

알림 문구는 짧고 행동 중심으로 유지하세요. 다음만 포함하세요: 대상과 무엇에 대한 것인지, 그리고 다음 행동

• "{Client}에게 후속: {Proposal} - 짧은 확인"
• "{Client} / {Proposal} - 승인 전 변경사항 여부 확인"
• "{Client} / {Proposal} - 일정 및 시작일 확인"

알림이 소음이 되지 않도록 가드레일을 추가하세요: 제안당 하루에 하나로 제한하고, 스누즈 옵션(1일, 3일, 다음 주)을 포함하세요.

각 알림의 결과도 기록하세요: 완료, 스누즈(언제까지), 건너뜀, 발송됨 같은 작은 결과 로그를 저장합니다.

예: "Website refresh - Acme Co"를 월요일에 Sent로 표시하고 목요일로 후속을 설정하면, 목요일 아침에 알림을 하나 받고 금요일로 스누즈할 수 있습니다. 금요일에 후속을 하고 알림을 완료로 표시하면 "Sent에서 X일 후에도 응답 없음" 타이머가 리셋됩니다.

서비스 유형별 성사율 추적(그리고 수치 활용하기)

제안 파이프라인 앱은 당신이 다음에 무엇을 해야 할지 결정하는 데 도움을 줄 때만 가치 있습니다. 가장 쉬운 방법은 전체가 아니라 서비스 유형별 성사율을 추적하는 것입니다. "웹사이트 재설계"와 "월간 유지보수"는 종종 다른 사업처럼 행동합니다.

먼저 결과를 일관되게 정의하세요:

• Won은 서명된 계약, 선금 결제, 또는 확인된 시작일이 있는 명확한 승낙을 의미합니다.
• Lost는 더 이상 추구하지 않는 경우입니다(고객이 거절, 다른 사람 선택, 또는 충분히 오래 비활성 상태여서 종료로 간주).

하나의 규칙을 정하고 지키지 않으면 숫자가 잡음이 됩니다.

실패 사유는 짧고 일관되게 유지하세요:

• 가격
• 일정
• 범위 불일치
• 무응답
• 경쟁사 선택

그런 다음 실제로 사용하는 기간(최근 30일 또는 90일) 동안 서비스 유형별 성사율을 계산하세요. 예: Brand strategy 제안 12건 중 3건이 성사되면 25% 성사율입니다. Landing page 빌드 6건 중 4건이면 67%입니다. 완벽할 필요는 없고, 꾸준하면 됩니다.

"성사 시간"도 추적해 정직해지세요. 발송일에서 Won 또는 Lost까지의 일수를 기록하면 SEO 감사는 5-10일, 전체 웹사이트 재구축은 30-45일 걸린다는 식의 인사이트를 얻을 수 있습니다. 이는 후속 빈도와 수입 예측에 영향을 줍니다.

간단한 규칙으로 수치를 활용하세요. 서비스의 성사율이 낮고 성사 시간이 길면, 제안을 더 좁히거나(범위, 증명, 가격) 제안 전에 더 엄격히 자격을 확인하세요. 성사율이 높다면 그 작업을 보호하세요: 성공 사례를 재사용하고 가격을 조심스럽게 올리세요.

제안 CRM을 만들 때 흔한 함정

제안 파이프라인 앱을 쓸모없게 만드는 가장 빠른 방법은 혼란스럽게 만드는 것입니다. 프리랜서들은 좋은 의도로 시작하지만 결국 신뢰하지 못하는 도구를 만들곤 합니다.

하나의 함정은 같은 의미의 상태가 너무 많은 경우입니다. "Sent", "Submitted", "Delivered", "In review"의 차이를 한 문장으로 설명할 수 없다면 아마도 하나면 충분합니다.

또 다른 함정은 Sent를 무덤으로 만드는 것입니다. 후속 날짜를 요구하지 않으면 보드를 열었을 때 다음 단계가 없는 제안들이 쌓입니다. 대부분의 문제는 한 가지 규칙으로 고쳐집니다: Sent 상태의 모든 제안은 다음 행동이 스케줄되어 있어야 합니다.

조용히 집중을 깨뜨리는 몇 가지 실수:

• 제안과 일반 리드를 섞어 파이프라인이 무작위 받은편지함이 되는 것
• Lost 사유를 기록하지 않아 동일한 가격 및 범위 실수를 반복하는 것
• 초기에 자동화를 과하게 도입해 알림 조정에 더 많은 시간을 쓰는 것

알림은 지루하고 구체적으로 유지하세요. 후속 날짜에 묶인 한 번의 알림이면 보통 충분합니다. 더 많은 규칙은 한 달간 실제 사용 데이터를 가진 뒤로 미루세요.

세 건 연속으로 "일정이 길다"라는 사유로 잃는다면, 더 작은 첫 단계 제안을 제시하는 것이 해결책이지 상태를 다섯 개 더 추가하는 것이 아닙니다.

신뢰하기 전에 확인할 빠른 체크리스트

제안 파이프라인 앱을 단일 진실 소스로 삼기 전에, 어떤 항목도 애매하게 남아 있지 않고 다음 단계가 명확한지 확인하세요.

파이프라인 뷰를 열고 시간을 재보세요. 오늘의 우선순위를 30초 이내에 이해할 수 있어야 합니다. 여러 제안을 클릭해서 다음 단계를 찾아야 한다면, 설계가 가장 중요한 필드를 숨기고 있는 것입니다.

체크리스트:

• 열린 제안마다 명확한 상태와 다음 후속 날짜가 표시된다. 다음 단계가 없으면 닫으세요.
• "오늘" 뷰는 지금 당장 실행할 수 있는 행동(후속, 발송, 수정)을 보여준다. 단순히 스트레스 목록이 아니어야 합니다.
• Won 또는 Lost가 되면 최종 금액과 짧은 사유를 캡처한다.
• 서비스 유형별 성사율이 최근 기간(30-90일)으로 보인다.
• 알림은 스누즈할 수 있고, 같은 날 같은 제안에 중복 알림이 발생하지 않는다.

작은 스트레스 테스트를 해보세요. 다른 서비스용 샘플 제안 3개를 만들고 상태를 옮기며 알림을 트리거하세요. 5분 안에 쉽게 깨뜨릴 수 있다면, 바쁜 주에는 실제로도 문제가 될 것입니다.

예시: 한 주의 제안 흐름(그리고 배운 것)

월요일에 제안 다섯 건을 보냅니다. 세 건은 웹 재설계 패키지, 두 건은 월간 지원 리테이너입니다. 모든 항목은 초안에서 시작해 이메일 발송 후 Sent로 이동합니다.

수요일까지 상태는 이야기를 말해줍니다:

• 두 건의 재설계 제안이 Viewed(문서 열람)로 이동
• 한 건의 재설계 제안은 여전히 Sent(미열람)
• 한 건의 리테이너는 Negotiating(시간 조정 요청)
• 한 건의 리테이너는 Won(서명됨)

알림이 일을 놓치지 않게 합니다. "열람은 했지만 2일 내 답 없음" 규칙이 금요일 아침에 두 건의 재설계 리드에 대해 후속 조치를 하게 합니다. "발송했으나 3일 내 열람 없음" 규칙은 조용한 건을 잡아내 재발송과 명확한 다음 단계를 유도합니다.

현실은 복잡합니다. 한 고객이 일요일 늦게 "바쁜 주였어요"라며 다음 달 시작을 요청하면 Sent에 그대로 놔두지 않고 On Hold로 옮깁니다. 협상은 계속 활성화되지만 알림은 매일이 아니라 한 번만 확인합니다.

주말이 끝날 무렵 서비스 유형별 성사율은 눈을 뜨게 합니다: 리테이너는 1/2 성사, 웹 재설계는 0/3. 다음 주에는 재설계 범위를 두 단계로 좁히고 피드백 기한을 간단히 추가합니다.

다음 단계: 작은 버전을 출시하고 점진 개선

가장 빠르게 가치를 얻는 방법은 매일 실제로 열어볼 가장 작은 버전을 출시하는 것입니다. 제안 파이프라인 앱은 템플릿, 복잡한 자동화, 초반의 차트가 필요 없습니다. 무엇을 보냈고 무엇이 대기 중이며 다음에 무엇을 해야 하는지 알려주면 됩니다.

상태를 설정할 때 각 상태가 "지금 어떤 행동이 기대되는가?"라는 질문에 답하도록 하세요. 상태를 한 문장으로 설명할 수 없다면, 그 상태는 작업 속도를 늦춥니다.

이번 주에 할 세 가지 행동:

• 상태 5~7개 설정(예: Draft, Sent, Follow-up due, Negotiating, Won, Lost)
• 제안을 초 단위로 상태 사이 이동시킬 수 있는 보드 뷰 만들기
• 중요한 경우에만 알림 켜기(Follow-up due 및 다음 단계가 당신일 때의 Negotiating)

기본 루프가 자연스럽게 느껴지면 한 번에 하나씩 개선을 추가하세요. 권장 순서는 알림(무언가 놓치지 않게) → 리포팅(학습하기) → 템플릿(시간 절약). 한꺼번에 모든 것을 추가하면 무엇이 도움이 되고 무엇이 소음인지 알기 어렵습니다.

코딩을 많이 하지 않고 이것을 만들고 싶다면 AppMaster (appmaster.io)는 실용적인 옵션입니다: 데이터베이스(클라이언트, 제안, 서비스)를 모델링하고 UI와 상태 규칙을 한곳에서 구축해 프로세스가 바뀔 때 반복할 수 있습니다.

작은 변경을 측정 가능한 단위로 유지하세요. 한 주 후: 더 빠르게 후속했는가, 답장을 덜 놓쳤는가? 한 달 후: 어떤 서비스가 가장 잘 성사되는가, 어떤 서비스가 더 나은 제안이나 높은 가격이 필요한가?

첫 버전을 개인 도구처럼 다루세요, 제품처럼이 아니라. 새 제안 추가나 진행에 30초 이상 걸리면 필드와 화면을 단순화하세요. 사용이 수월해지면 실제로 사용하게 되고 데이터가 신뢰할 수 있게 됩니다.