본 사례는 실제 외주 프로젝트 수행 기록을 바탕으로 작성했습니다.
견적서 작성보다 어려웠던 것은 승인값과 고객 PO의 차이를 찾는 일이었습니다
저희는 OO산업장비 제조사의 영업지원팀입니다. 고객의 RFQ(Request for Quotation)가 오면 제품 설명이나 견적 문구는 이미 생성형 AI로 만들고 있었습니다. 하지만 실제 수주 업무에서는 문장이 아니라 이번 거래에 적용할 수 있는 값이 어디에 있느냐가 문제였습니다.
RFQ는 메일로만 오지 않았습니다. 고객 전자구매 포털의 소싱 이벤트에 초대되면 담당자는 이벤트 마감시각과 서버 시간, RFQ 버전, 질의응답, 첨부 규격서를 먼저 확인하고 파일을 내려받아야 했습니다. 고객이 적은 품명은 사내 ERP의 품목명과 달랐고, 현재 단가·가용재고·표준 리드타임은 ERP, 고객별 결제조건과 납품처는 CRM, 기준 할인율을 넘긴 예외 할인은 영업본부장의 승인 메일에 있었습니다. 설치·시운전 범위와 검수조건은 미팅 메모에서 찾아야 했습니다.
견적을 만든 뒤에도 포털의 가격·통화·납기 필드에 다시 입력하고 요구 첨부를 올린 다음, 상태가 초안이 아니라 실제 제출됨으로 바뀌었는지 접수번호까지 확인해야 했습니다. RFQ가 마감 직전에 수정되면 이전 버전으로 만든 견적을 제출할 위험도 있었습니다.
견적 발송 뒤 고객 PO(Purchase Order)가 오면 더 날카로운 문제가 생겼습니다. 고객이 이전 Rev. 견적번호를 적거나, 수량·단가·요청 납기·납품장소·Incoterms·설치 범위를 조용히 바꿔 보내는 경우가 있었습니다. PO 접수 사실만 보고 수주 등록을 하면 승인받지 않은 조건이 ERP에 들어갈 수 있어, 담당자는 최종 견적과 PO를 다시 한 항목씩 대조했습니다.
기존 AI는 문서를 썼지만 ERP·CRM·메일의 현재 상태를 확인하지 못했습니다
일반적인 AI에 RFQ와 과거 견적서를 올리면 그럴듯한 견적 초안은 만들었습니다. 그러나 고객 전자구매 포털에 로그인해 진행 중인 소싱 이벤트와 최신 RFQ 버전을 열고, 첨부를 내려받아 마감시각을 관리하고, 작성된 가격을 필드에 입력해 파일을 업로드한 뒤 제출 성공상태를 확인하지는 못했습니다. 로그인된 ERP에서 현재 단가·재고·리드타임을 조회하거나, CRM의 결제조건과 Ship-to, 메일함의 그 거래 건에 대한 마지막 할인 승인을 함께 찾는 일도 끊겼습니다.
고객 PO가 도착한 뒤에도 마찬가지였습니다. AI는 사용자가 올려 준 두 문서를 비교할 수는 있지만, 어느 파일이 실제 발송된 최종 Rev.인지 찾아오고, PO의 변경 조건을 수주 등록 보류 사유로 남기고, 승인 회신이 올 때까지 거래 상태를 이어서 관리하지 못했습니다. 결국 사람은 AI가 만든 문장 옆에서 여러 시스템에 로그인해 같은 값을 다시 확인했습니다.
yaap에 문의해 RFQ-PO 수주대조 플러그인을 만들었습니다
플러그인의 입력은 고객 전자구매 포털의 RFQ 이벤트와 규격서, ERP 품목·가격·재고 정보, CRM 거래처 조건, 할인 승인 메일, 제출한 최종 견적, 고객 PO였습니다. 출력은 이벤트 마감·버전 현황, 출처가 표시된 견적 준비본, 승인 근거, 제출 접수상태, PO 차이표, 수주 등록 보류 목록이었습니다. 가격이나 계약조건을 임의로 결정하지 않고, 사람의 승인이 필요한 차이를 앞으로 꺼내는 방식으로 설계했습니다.
1. RFQ 이벤트 접수와 버전 고정 — 담당자가 허용한 고객 전자구매 포털 세션에서 소싱 이벤트를 열어 마감시각·RFQ 번호·버전·질의응답과 첨부 규격서를 수집했습니다. 고객명·품목·수량·요청 납기를 CRM 기회와 연결하고, 변경 공지가 오면 기존 준비본을 구버전으로 표시했습니다.
2. ERP·CRM·승인 메일 조회 — 담당자가 허용한 로그인 세션에서 ERP의 품목코드·UOM·단가·재고·리드타임, CRM의 결제조건·납품처·담당자, 메일의 예외 할인 승인 여부를 조회했습니다. 각 값에는 조회 시스템과 시각, 승인 메일을 근거로 붙였습니다.
3. 견적 패키지 입력·제출 준비 — 확정된 값만 승인 템플릿과 포털 입력필드에 맞추고, 모델·사양·수량·단가·통화·부가세·납기·설치 범위가 이어지는 제출본을 만들었습니다. 재고 부족, 단종 품목, 할인 미승인, 필수 첨부 누락은 제출 전 확인 목록으로 분리했습니다. 담당자 승인 뒤 업로드하고 제출됨 상태와 접수번호를 보관했습니다.
4. 고객 PO 차이 검출 — 수신한 PO를 실제 발송된 최종 견적 Rev.와 비교해 수량·단가·납기·Ship-to·결제조건·Incoterms·설치 및 검수 범위의 차이를 표시했습니다. 차이가 있는 건은 자동 수주 등록하지 않고 승인 대기 상태로 남겼습니다.
5. 승인 뒤 수주등록 준비 — 영업 책임자가 변경 조건을 승인하면 ERP 수주등록용 입력본과 계약서·최종 사양서의 수정 항목을 만들었습니다. 실제 고객 발송과 ERP 반영은 담당자가 마지막으로 확인한 뒤 진행했습니다.
전 거래를 다시 읽는 대신 승인 없는 차이만 보게 됐습니다
이전에는 RFQ 포털의 마감과 버전을 따로 적어 두고 ERP·CRM·메일을 차례로 뒤졌으며, 업로드 뒤에도 실제 제출됐는지 다시 로그인해 확인했습니다. 지금은 한 수주 건 안에서 최신 이벤트 버전, 마감, 승인값, 제출 접수상태가 이어지고, 담당자는 재고 부족·할인 미승인·PO 변경처럼 실제 판단이 필요한 항목만 봅니다.
특히 PO 접수 뒤 업무가 달라졌습니다. PO가 왔다는 이유로 바로 수주 등록하지 않고, 최종 견적과 다른 조건이 먼저 보류 목록에 올라옵니다. 영업팀은 가격·납기·계약조건을 직접 승인하면서도 자료 찾기와 버전 대조에서는 벗어났습니다.