오두 CRM·영업 모듈 설정 — 견적에서 수주까지

할인 승인은 표준 기능이 아닙니다. 이것이 플랜을 결정합니다

오두 영업 모듈 구축에서 가장 자주 발견되는 문제는 기능 부족이 아니라 순서 착오입니다. 견적서 양식부터 만들기 시작하면, 가격표가 정해지지 않은 상태라 양식을 세 번 고치게 됩니다.

그리고 구축 중반에 반드시 나오는 요구가 하나 있습니다. '할인율이 높으면 팀장 승인을 받게 해 주세요.' 이 요구가 나오는 시점이 문제입니다. 플랜이 이미 결정된 뒤라면 선택지가 좁아집니다.

공식 Sales 기능 페이지를 확인해 보면 승인 워크플로에 대한 언급이 없습니다. 유사한 기능으로 특정 고객이나 품목에 대해 견적 발송 전 경고를 띄우는 'Sales Warnings'가 있을 뿐입니다. 승인 규칙은 Odoo Studio 문서에 기술되어 있고, Studio는 Custom 플랜에서 제공됩니다.

이 글은 표준에 있는 것과 없는 것을 구분하고, 그 구분 위에서 설계 순서를 제시합니다. 금액 예시는 공개 정가로 산출한 가상 시나리오입니다.

표준 Sales 범위를 먼저 확인했습니다

공식 Sales 기능 페이지에 명시된 내용을 인용하겠습니다. 견적 템플릿은 '맞춤 견적 템플릿을 몇 번의 클릭으로 설계하고 재사용해 시간을 절약'하는 기능으로 설명됩니다.

견적 작성 도구(Quotation Builder)는 '사전 정의된 품목, 가격표, 템플릿을 사용해 올바른 가격을 견적에 즉시 적용'하는 기능입니다. 가격표(Pricelists)는 '지역이나 가격 등급 같은 고객 조건에 따라 올바른 가격을 산출'하며, 고객 세그먼트별·수량·기간 조건을 기반으로 합니다.

할인(Discounts)은 '견적 항목에 할인을 적용하고 그 할인을 고객에게 표시하거나 숨길지 선택'하는 기능입니다. 쿠폰과 프로모션은 별도로 존재합니다. 그리고 전자 서명으로 견적을 온라인에서 확정받을 수 있습니다.

> 공식 문서 목차로도 확인됩니다

오두 19 Sales 문서 목차에 다음 페이지들이 존재합니다. 견적 템플릿, 선택 품목, 주문 확정용 온라인 서명, 견적 유효기간, 마진, PDF 견적 작성기, 가격표, 할인, 할인·로열티 프로그램.

즉 견적에서 수주까지의 기본 흐름은 표준 범위에서 충분히 구성됩니다. 문제는 그 흐름에 통제 단계를 넣으려 할 때입니다.

승인 워크플로가 표준에 없습니다

공식 Sales 기능 페이지에는 견적 승인이나 할인 승인 워크플로에 대한 언급이 없습니다. 유사한 기능으로 'Sales Warnings'가 있는데, 이는 특정 고객이나 품목에 대해 견적을 발송하기 전 경고를 표시하는 기능입니다. 경고는 알림이고 승인은 통제이므로 성질이 다릅니다.

승인 규칙(Approval rules)은 Odoo Studio 문서에 별도 페이지로 기술되어 있습니다. 그리고 공식 가격 페이지 기준으로 Studio는 Custom 플랜에서 제공되는 기능입니다. Standard 플랜에는 포함되지 않습니다.

앱스토어에는 이 공백을 메우는 서드파티 모듈이 존재합니다. 'Sale Order Discount Approval'(기술명 sale_order_discount_approval, Ciranta IT Services 발행, 11.71달러, 오두 18 호환)이 '지정된 할인 수준을 초과하는 견적에 승인 요건을 강제'한다고 설명합니다. 동종 모듈이 여러 버전으로 검색됩니다.

> 분명히 밝혀 둘 것

'표준 Sales 앱에 할인·견적 승인 워크플로가 없다'는 진술의 근거는 공식 기능 페이지의 미언급과 Studio 승인 규칙 문서의 존재까지입니다. 오두 공식 문서 중 할인 설정 페이지와 가격표 페이지의 본문은 접근 제약으로 확인하지 못했으므로, 문서 본문에 의한 직접 확인은 하지 못했습니다.

그러므로 승인 워크플로가 요건이면 공급사에 '표준 범위에서 구현 가능한지, 불가하면 Studio·서드파티·코드 중 어느 방식인지'를 서면으로 확인하십시오. 이 확인이 플랜 선택을 결정합니다.

설계 순서 1 — 가격표부터 정합니다

견적서 양식을 먼저 만들면 세 번 고치게 됩니다. 가격이 어떻게 결정되는지 정해지지 않은 상태에서 양식을 만들기 때문입니다.

가격표는 고객 조건에 따라 가격을 산출합니다. 공식 설명에 지역, 가격 등급, 고객 세그먼트, 수량, 기간 조건이 언급되어 있습니다. 그래서 먼저 답해야 할 질문이 있습니다. 우리 회사의 가격은 무엇에 따라 달라지는가.

전형적인 답은 네 가지입니다. 고객 등급(대리점·직거래·특별가), 수량(구간별 단가), 기간(계약 기간 할인), 그리고 지역이나 통화. 이 중 실제로 쓰는 것만 가격표로 만드십시오.

> 가격표를 많이 만들지 마십시오

가격표를 열 개 만들면 영업 담당이 어느 것을 쓸지 매번 판단해야 하고, 판단이 틀리면 잘못된 가격으로 견적이 나갑니다. 고객 등급별로 셋, 수량 구간은 그 안에 넣는 구성이 실무에서 안정적입니다.

그리고 가격표 적용 규칙을 문장으로 적어 두십시오. '거래처 등록 시 등급을 지정하고, 견적은 그 등급의 가격표를 자동 적용한다. 예외 가격은 할인으로 처리한다.' 이렇게 적어 두면 영업 담당이 판단할 일이 없어집니다.

설계 순서 2 — 견적 템플릿을 역할별로

가격표가 정해지면 견적 템플릿을 만듭니다. 템플릿을 만드는 기준은 '함께 나가는 품목 묶음'입니다.

제품군마다 템플릿을 하나씩 두고, 선택 품목(Optional products) 기능으로 추가 제안 항목을 넣는 구성이 효율적입니다. 공식 문서 목차에 선택 품목 페이지가 있으므로 표준 범위입니다.

템플릿에는 유효기간도 함께 설정합니다. 공식 문서에 견적 유효기간 페이지가 있습니다. 유효기간을 두면 오래된 견적이 파이프라인에 남아 금액을 왜곡하는 문제가 줄어듭니다.

> PDF 양식은 마지막에

견적서 PDF 양식은 가장 마지막에 손대십시오. 공식 문서에 PDF 견적 작성기 페이지가 있어 양식 구성이 가능하지만, 가격표와 템플릿이 확정되기 전에 양식을 만들면 항목이 바뀔 때마다 다시 손대야 합니다.

그리고 양식 작업은 끝이 없습니다. 로고 위치와 글꼴, 약관 문구를 두고 논의가 길어집니다. 이 작업을 구축 초기에 시작하면 다른 설정이 밀립니다. '기능이 다 되고 나서 양식'이라는 순서를 지키십시오.

설계 순서 3 — 할인 정책을 정합니다

할인은 공식 기능 페이지에 명시된 표준 기능이고, 고객에게 표시하거나 숨길지 선택할 수 있습니다. 설계에서 정해야 할 것은 기능이 아니라 정책입니다.

먼저 할인의 종류를 구분하십시오. 가격표로 처리할 것(등급·수량·기간에 따라 자동 적용되는 가격)과 할인으로 처리할 것(건별 협상 결과)입니다. 둘을 섞으면 '왜 이 가격인가'를 나중에 설명할 수 없게 됩니다.

그리고 할인 표시 여부를 정하십시오. 고객에게 할인율을 보여 줄지, 할인 적용된 최종가만 보여 줄지. 업종과 거래 관행에 따라 다르고, 한 번 정하면 바꾸기 어렵습니다.

> 여기서 승인 요구가 나옵니다

할인 정책을 정하는 자리에서 거의 항상 나오는 요구가 '일정 비율 이상은 승인'입니다. 앞서 짚은 대로 이것이 표준 범위 밖이므로, 이 시점에 선택을 해야 합니다.

선택지는 셋입니다. 첫째, 승인을 시스템이 아니라 운영 규칙으로 처리합니다. 할인 한도를 문서로 정하고 월별로 초과 건을 점검합니다. 비용이 들지 않지만 사후 통제입니다. 둘째, Custom 플랜으로 Studio 승인 규칙을 씁니다. 셋째, 서드파티 모듈을 씁니다. 다만 서드파티 모듈을 쓰려면 Odoo Online이 제외되므로 호스팅도 함께 바뀝니다.

첫 번째가 과소평가됩니다. 할인 초과 건이 월 몇 건인지 세어 보고, 그 건수가 적다면 사후 점검으로 충분합니다. 시스템 통제의 값은 건수에 비례합니다.

CRM 단계와 Sales의 경계

오두에는 CRM(영업 기회)과 Sales(견적·주문)가 분리되어 있습니다. 경계를 정하지 않으면 같은 거래가 양쪽에 존재합니다.

실무에서 쓰는 기준은 '견적을 발송했는가'입니다. 발송 전은 CRM의 기회로, 발송 후는 Sales의 견적으로 관리합니다. 그러면 CRM 단계는 리드 발굴부터 견적 발송 직전까지가 되고, 그 뒤는 Sales에서 추적됩니다.

CRM 단계는 다섯에서 일곱 개로 두십시오. 열 개를 넘으면 영업 담당이 단계를 정확히 올리지 않고, 그러면 파이프라인 금액이 신뢰를 잃습니다. 그리고 각 단계로 넘어가는 조건을 외부에서 관찰 가능한 사건으로 정의하십시오.

> 검증 방법

영업 담당 세 명에게 임의의 기회 다섯 건을 보여 주고 단계를 지정하게 하십시오. 세 명의 답이 같으면 정의가 섰습니다. 다르면 정의문을 다시 쓰십시오. 이 검증을 건너뛰면 3개월 뒤에 파이프라인 숫자를 아무도 믿지 않습니다.

그리고 필수 입력은 세 개로 제한하십시오. 예상 금액, 예상 종료일, 다음 활동. 필수 항목이 많으면 담당자는 아무 값이나 넣고, 그러면 숫자가 있는데 틀린 상태가 됩니다.

수주 이후 재고·생산과의 연결

견적이 주문으로 확정되면 재고와 생산으로 넘어갑니다. 이 연결이 ERP를 쓰는 이유의 핵심이고, 동시에 구축에서 가장 많은 시간이 드는 부분입니다.

연결 설계에서 먼저 정할 것은 '주문 확정이 무엇을 자동으로 일으키는가'입니다. 재고 출고 예약을 자동으로 만들 것인가. 재고가 부족하면 발주를 자동으로 제안할 것인가. 제조 품목이면 작업지시를 자동으로 생성할 것인가.

자동화 범위를 넓게 잡으면 초기에 혼란이 생깁니다. 주문이 확정될 때마다 문서가 여러 개 생기고, 그 문서들이 맞는지 확인할 사람이 없으면 잘못된 문서가 쌓입니다.

> 단계적으로 켜십시오

1단계는 주문 확정이 출고 예약만 만들게 둡니다. 2주 운영해 출고 예약이 정확한지 확인한 뒤, 2단계에서 재고 부족 시 발주 제안을 켭니다. 3단계에서 제조 품목의 작업지시 생성을 켭니다.

각 단계의 완료 판정은 '생성된 문서가 수정 없이 그대로 처리되는 비율'입니다. 이 비율이 80%를 넘으면 다음 단계로 갑니다. 넘지 않으면 품목 마스터나 재고 수량에 문제가 있으므로 그것을 먼저 고치십시오. 자동화를 더 켜면 잘못된 문서가 더 많이 생길 뿐입니다.

계산 예시 — 플랜 선택이 갈리는 지점

영업 12명, 월 견적 발송 150건, 할인 승인이 필요한 건이 월 20건인 조직을 가정합니다. 공개 정가로만 계산한 가상 시나리오입니다.

선택 A — 운영 규칙으로 처리. Standard 플랜 12명이면 12 × 24.90달러 = 월 298.80달러, 원화로 약 41만 2천 원입니다(1 USD = 1,380원, 기준일 2026년 10월 8일). 할인 한도를 문서로 정하고 월 20건의 초과 건을 점검합니다. 점검에 월 1시간이 든다고 보면 됩니다.

선택 B — Custom 플랜으로 Studio 승인 규칙. 12 × 49.00달러 = 월 588달러, 약 81만 1천 원입니다. 선택 A 대비 월 289.20달러, 약 39만 9천 원이 더 듭니다.

선택 C — 서드파티 모듈. 모듈 비용은 일회성 11.71달러 수준으로 작지만, 커스텀 모듈을 쓰면 Odoo Online이 제외되어 Custom 플랜 + Odoo.sh 또는 온프레미스가 됩니다. 결과적으로 선택 B와 비슷한 라이선스 비용에 호스팅 비용과 모듈 유지 부담이 추가됩니다.

> 판단

월 20건의 할인 승인을 사전 통제하기 위해 월 약 40만 원을 더 쓰는 것이 값을 하는가. 할인 초과가 실제 손실로 이어진 금액이 월 40만 원을 넘는다면 값을 합니다. 넘지 않는다면 운영 규칙으로 충분합니다.

다만 Studio는 승인 규칙만을 위한 도구가 아닙니다. 다른 설정 기반 커스터마이즈 요구가 함께 있다면 Custom 플랜의 값이 올라갑니다. 요구 목록을 전부 모아 놓고 판단하십시오.

요약 — 다섯 가지

표준 범위에 있는 것. 견적 템플릿, 견적 작성 도구, 가격표(지역·등급·수량·기간 조건), 품목별 할인(표시·숨김 선택), 선택 품목, 견적 유효기간, 마진, PDF 견적 작성기, 온라인 전자 서명.

표준 범위에 없는 것. 할인·견적 승인 워크플로입니다. 공식 Sales 기능 페이지에 언급이 없고, 승인 규칙은 Studio 문서에 있으며 Studio는 Custom 플랜에서 제공됩니다. 유사 기능인 Sales Warnings는 알림이지 통제가 아닙니다.

설계 순서는 가격표 → 견적 템플릿 → 할인 정책 → 승인 필요 여부입니다. 양식(PDF)은 가장 마지막입니다. 순서를 바꾸면 같은 작업을 세 번 합니다.

CRM과 Sales의 경계는 '견적을 발송했는가'로 두십시오. CRM 단계는 5~7개, 필수 입력은 예상 금액·예상 종료일·다음 활동 세 개입니다.

수주 이후 자동화는 단계적으로 켜십시오. 출고 예약 → 발주 제안 → 작업지시 순서이고, 각 단계의 판정은 '생성 문서가 수정 없이 처리되는 비율 80%'입니다.

표준 범위에 있는 것과 없는 것

전제와 기준: Odoo 공식 Sales 기능 페이지, Odoo 19 Sales 문서 목차, Odoo Studio Approval rules 문서, Odoo 공식 가격 페이지 2026년 10월 8일 확인. 오두 공식 문서 중 견적 템플릿·가격표·할인 각 페이지의 본문은 접근 제약으로 확인하지 못했으므로, '승인 워크플로가 표준에 없다'는 진술의 근거는 공식 기능 페이지의 미언급과 Studio 문서의 존재까지입니다. 요건이면 공급사에 서면 확인을 받으십시오.

할인 승인을 처리하는 세 가지 선택 (영업 12명 가상 시나리오)

전제와 기준: Odoo 공식 가격 페이지 표기 금액(Standard US$24.90, Custom US$49.00)으로 계산한 가상 시나리오이며 특정 고객사의 계약 금액이 아닙니다. 전제: 영업 12명, 월 견적 150건, 할인 승인 필요 월 20건. 공식 페이지의 연간·월간 결제 매핑을 확정하지 못했으므로 견적 단계에서 결제 조건별 단가를 서면 확인하십시오. 선택 C는 커스텀 모듈을 쓰므로 Odoo Online이 제외되고, Custom 플랜의 Odoo.sh 호스팅 비용은 구독에 포함되지 않습니다. 환율 1 USD = 1,380원, 기준일 2026년 10월 8일.

독자가 자주 묻는 질문

Q. 오두로 할인 승인을 못 하는가

표준 Sales 범위에서는 공식 기능 페이지에 언급이 없습니다. 승인 규칙은 Odoo Studio 문서에 기술되어 있고 Studio는 Custom 플랜에서 제공됩니다. 서드파티 모듈도 존재합니다. 다만 월 승인 건수가 적다면 할인 한도를 문서로 정하고 사후 점검하는 운영 규칙이 비용 대비 합리적인 경우가 많습니다. 시스템 통제의 값은 건수에 비례합니다.

Q. 가격표를 몇 개 만드는 것이 적정한가

고객 등급별로 셋 정도가 실무에서 안정적입니다. 수량 구간은 그 안에 넣습니다. 가격표를 열 개 만들면 영업 담당이 어느 것을 쓸지 매번 판단해야 하고, 판단이 틀리면 잘못된 가격으로 견적이 나갑니다. 그리고 '거래처 등급으로 가격표가 자동 적용되고 예외는 할인으로 처리한다'는 규칙을 문장으로 적어 두십시오.

Q. 견적서 PDF 양식을 먼저 만들면 안 되는가

권하지 않습니다. 가격표와 템플릿이 확정되기 전에 양식을 만들면 항목이 바뀔 때마다 다시 손대야 합니다. 그리고 양식 논의는 끝이 없습니다. 로고 위치와 글꼴, 약관 문구를 두고 시간이 길어지고 다른 설정이 밀립니다. '기능이 다 되고 나서 양식'이라는 순서를 지키십시오.

Q. 수주 후 자동화를 처음부터 다 켜면 안 되는가

켤 수 있지만 권하지 않습니다. 주문이 확정될 때마다 출고 예약·발주 제안·작업지시가 동시에 생기고, 그 문서들이 맞는지 확인할 사람이 없으면 잘못된 문서가 쌓입니다. 출고 예약만 켜고 2주 운영해 '생성 문서가 수정 없이 처리되는 비율'이 80%를 넘는지 확인한 뒤 다음을 켜십시오. 비율이 낮으면 품목 마스터나 재고 수량 문제이므로 그것을 먼저 고쳐야 합니다.

이 글이 다루지 않는 것

이 글은 설계 순서와 표준 범위 구분을 다룹니다. 오두 공식 문서 중 견적 템플릿·가격표·할인 각 페이지의 본문은 접근 제약으로 확인하지 못했으므로 설정 경로와 세부 옵션명을 단정적으로 쓰지 않았습니다. 또한 재고·생산 모듈의 상세 설정, 세금 처리와 전표 연동, 서드파티 모듈의 실제 품질 검증은 다루지 않습니다. 이 글은 세무·회계 자문이 아닙니다.

출처와 확인일

가격·에디션·정책은 공급사가 예고 없이 변경할 수 있습니다. 계약 전 위 공식 페이지에서 직접 재확인하십시오. 원화 환산은 1 USD = 1,380원, 기준일 2026년 10월 5일을 적용했습니다.

함께 읽으면 좋은 솔바인드9 글