- 고객 정보 시스템은 대부분 기록장에 지나지 않습니다. 빠짐없이 기록은 하지만 계약을 더 빨리 따내는 데는 도움이 되지 않습니다.
- 영업팀에 정말 필요한 것은 제안서 초안을 써 주고, 정확한 가격을 넣고, 비슷한 건에서 무엇이 잘 팔렸는지 아는 어시스턴트입니다.
- 먼저 갖춰야 할 것은 가격과 조건의 기준 원본을 한곳에 두는 일입니다. 사람마다 각자 파일을 들고 있으면 안 됩니다.
기존 웹사이트와 앱은 어디에서 멈춰 있을까
많은 회사가 사들인 고객 정보 시스템은 비싼 기록장처럼 돌아갑니다. 영업 직원에게 무슨 이야기를 나눴는지 입력하게 할 뿐, 제안서는 단 한 장도 써 주지 않습니다. 그래서 영업 직원은 여전히 예전 파일을 복사해 한 줄씩 고치고 있습니다.
기존 CRM은 대화가 끝난 뒤의 정보를 저장하지만, 영업 직원은 여전히 여러 파일을 모아 제안서를 만듭니다. 가격, 범위, 예외에 관한 지식은 몇몇 사람에게만 있습니다.
제안서 작업이 느린 이유는 대개 직원의 글솜씨보다, 정보가 예전 프레젠테이션, 가격표, 이메일, 몇몇 사람의 기억에 흩어져 있다는 데 있습니다. 계약을 서두르다 보면 영업팀이 서로 다른 버전의 조건을 쓰거나, 수행팀이 해낼 수 없는 솔루션을 고르거나, 계약서를 모호하게 써서 판매 후에 문제가 터지기도 합니다.
그래서 AI 제안 구성 도구(AI Proposal Configurator)는 브리프를 받는 단계부터 요구를 요구 사항(Requirement)으로 바꾸고, 선택지를 정리하고, 가격을 계산하고, 승인된 문구를 고르고, 예외 승인을 요청하는 단계까지 사람이 생각하고 일관성을 점검하도록 돕는 시스템이어야 합니다. 목표는 근거와 확인한 사람을 거슬러 올라가 볼 수 있는 제안서입니다. 문서를 최대한 빨리 찍어 내는 것은 그다음 문제입니다.
| 기존 방식 | 새로운 AI 제품 방식 |
|---|---|
| 통화 요약, 후속 연락 알림, 이메일 템플릿 생성 | 고객 탐색(Discovery) 내용을 요구 사항 지도(Requirement Map)로 바꾸고, 솔루션 선택지를 만들고, 제품/가격 규칙을 확인해 제안서 초안을 쓰고, 위험도에 따라 승인을 요청 |
AI는 읽고 초안을 쓰는 일을 잘하지만, 가격, 범위(Scope), 계약 조항(Clause)은 검증할 수 있는 시스템과 규칙에서 나와야 합니다. 그래서 CRM, 카탈로그, 요율표(Rate Card), 승인 절차를 연결하는 일이 가장 세련된 문장을 쓰는 모델을 고르는 일보다 중요합니다.
기업이 쓸 수 있는 새로운 기능
정말 쓸모 있는 어시스턴트는 이 고객이 어떤 상황에 있는지, 비슷한 건이 예전에 어떤 제안으로 계약됐는지 압니다. 그리고 실제 시스템에서 가져온 가격으로 첫 초안을 만들어 주므로, 영업 직원은 확인하고 고치기만 하면 됩니다.
프로젝트의 모습
사용자는 CRM의 영업 기회(Opportunity)나 회의록에서 시작합니다. 시스템은 고객의 고충(Pain), 요구 사항, 제약 조건, 이해관계자, 마감일을 뽑아내고, 빈칸을 보여 주어 영업 직원이 채우게 한 다음, 솔루션 모듈을 골라 제안서의 뼈대를 만듭니다. 화면은 사람이 언제든 고칠 수 있어야 하고, 각 요구 사항과 문서 속 문구의 연결을 유지해야 합니다.
주요 기능
기능으로는 고객 탐색 어시스턴트, 요구 사항 매트릭스(Requirement Matrix), 솔루션 구성 도구, 가격/할인 규칙, 조항 라이브러리(Clause Library), 수행 역량 확인, 승인 절차, 문서 생성, 버전 비교가 들어갈 수 있습니다. 관리자는 어느 줄이 표준과 다른지, 어떤 항목이 담당자를 기다리고 있는지 한눈에 봅니다.
기술과 연동
시스템은 CRM, 제품 카탈로그, 요율표, ERP나 수행 역량 데이터, 그리고 버전이 관리되는 문서 저장소와 연결되어야 합니다. AI는 요약하고 문구 초안을 쓰는 일을 돕고, 가격, 호환성, 승인 권한의 로직은 테스트할 수 있는 규칙 엔진(Rule Engine)에 두어야 합니다. 모든 주장은 요구 사항이나 참고 출처로 거슬러 올라갈 수 있어야 합니다.
속도 이상의 효과
영업 직원은 정보를 찾는 시간이 줄고 전략을 고민할 여유가 생깁니다. 경영진은 마진과 예외를 통제할 수 있고, 수행팀은 범위가 더 분명한 일을 넘겨받습니다. 시스템은 코칭 도구로도 쓰여, 신입 직원이 어떤 질문을 해야 하는지, 어떤 제안은 왜 맞지 않는지 보고 배울 수 있습니다.
- 고충, 제약 조건, 결정 기준을 나눠 주는 회의-요구 사항 변환(Meeting-to-Requirement)
- 수행할 수 있는 부분만 조합하는 제안 구성 도구(Proposal Configurator)
- 약속, 범위, 아직 확인되지 않은 정보를 짚어 내는 위험 검토 도구(Risk Reviewer)
- 수주와 실주 이유를 플레이북에 다시 반영하는 Win/Loss 학습
가상 사례
실제로 쓰이는 모습
한 기술 서비스 회사는 에이전트에게 회의 내용을 요약하고 예산에 맞는 선택지 세 가지를 만들게 합니다. 시스템은 제안서 초안을 쓰기 전에 요율표와 수행 역량을 확인합니다. 특별 조건이 붙은 건은 이사의 승인을 받습니다.
이 가상 사례에서는 한 시스템 회사가 여러 지점에 걸친 제안서를 만들어야 합니다. AI는 회의록을 읽고, 고객이 확인한 내용, 가정, 아직 답이 없는 질문을 나눈 요구 사항 매트릭스를 만듭니다. 구성 도구는 영업 직원이 고른 일정이 수행 역량과 맞지 않는다는 것을 찾아내고, 문서가 그대로 나가게 두는 대신 단계별 계획(Phase Plan)을 제안합니다.
영업 직원이 허용 범위를 넘는 할인을 요청하면, 시스템은 블랙박스처럼 거절하는 대신 마진에 미치는 영향과 맞바꿀 수 있는 조건을 보여 줍니다. 범위를 줄이거나 납품 일정을 조정하는 식입니다. 승인권자는 한 화면에서 전체 맥락을 보고, 최종 문서에는 누가 어떤 예외를 확인했는지 기록됩니다.
약속과 수행의 연결 확인(Promise-to-Delivery Check)
제안서의 모든 약속은 책임자(Owner), 수행 역량(Capacity), 가정(Assumption), 인수 기준(Acceptance Criteria)과 연결되어야 합니다.
연결할 수 없다면 확약으로 쓰지 말고 질문으로 표시하십시오.
범위, 위험, 성과 측정 방법
개발팀 참고 · 기술 지표
가격, 법적 조건, 보증 문구를 AI가 확률로 만들어 내게 해서는 안 됩니다. 이런 정보는 책임자와 Version이 분명한 Source에서 가져와야 합니다. 지표로는 Proposal Cycle Time, Rework, Approval Delay, Margin Deviation, 수주 후 Scope Dispute를 보십시오. 빨리 나갔지만 수행 부담을 만드는 문서는 성공으로 치지 않습니다.
AI는 읽기에는 그럴듯하지만 맥락이 틀린 제안서를 만들 수 있습니다. 고객 데이터를 계정 사이에 섞어 쓰지 말고, 가격과 문서의 버전을 남겨 두어야 합니다.
개발팀 참고 · 기술 지표
추적할 지표: Proposal Cycle, Approval Rework, Scope Error, Win Quality, Handoff Completeness
- Discover: 실제 업무를 따라가며 일반 사례와 예외 사례를 모읍니다.
- Assist: AI가 초안을 쓰거나 추천하고, 통제는 사람이 계속 맡습니다.
- Act: 테스트 세트를 통과한 뒤 도구(Tool)를 하나씩 엽니다.
- Scale: 모니터링, 대체 경로(Fallback), 비용, 책임자가 갖춰지면 확대합니다.
문구가 요구 사항으로 거슬러 올라가지 않거나, 가격이 요율표와 맞지 않거나, 수주 뒤에 수행팀이 범위를 자주 고쳐야 한다면 지원 모드(Assist Mode)로 되돌아가야 합니다. 시스템이 아직 최종 문서를 자동으로 만들 준비가 되지 않았다는 뜻입니다.
BUSINESS & PRODUCT READINESS
좋은 제안서는 고객이 원하는 것과 팀이 수행할 수 있는 것을 이어 줍니다
개발팀 참고 · 기술 세부 사항
AI로 Proposal 초안을 쓰기 전에 Pain → Requirement → Solution Component → Assumption → Acceptance Criteria로 이어지는 Traceability를 만드십시오. 책임자나 근거가 없는 부분은 Open Question으로 표시합니다. 그래야 읽기에는 매끄럽지만 Delivery가 한 번도 확인하지 않은 Scope를 파는 Proposal을 막을 수 있습니다.
개발팀 참고 · 기술 세부 사항
Rate Card, Product Rule, Clause, Capacity Signal, 통과한 제안서와 통과하지 못한 제안서의 예시를 준비하십시오. AI가 선택지를 제안할 때 쓰는 정보와 시스템이 정확히 계산해야 하는 규칙을 분리하고, Discount, Data Access, 특별 Timeline처럼 위험도에 따라 Approval을 설정합니다.
개발팀 참고 · 기술 세부 사항
먼저 Pain → Requirement → Solution → Assumption → Acceptance로 이어지는 Traceability Chain을 완성하십시오. Proposal의 문구가 어떤 Requirement에도 답하지 않거나 출처가 없으면, 시스템은 나중에 이유를 지어 붙이지 말고 경고를 띄워야 합니다. 변경을 통제할 수 있도록 표준 문구와 영업 직원이 고객별로 쓰는 부분도 분리해 두어야 합니다.
자주 나오고 구조가 비교적 안정된 제안서 유형부터 시작하십시오. 잘된 예시, 수정이 필요했던 예시, 예외를 승인한 이유를 모은 다음, 처음에는 AI가 지원 모드에서 초안 작성을 돕게 합니다. 팀이 추적 기능과 점검 결과를 믿게 되면 그때 문서 생성이나 자동화된 워크플로를 켭니다.
어떤 약속이 재작업을 자주 일으킵니까?
실제 가격과 조항의 원본은 어디에 있습니까?
제안서를 보내기 전에 수행 역량은 누가 확인합니까?
고객 데이터는 계정별로 어떻게 분리됩니까?
영업 플레이북을 사람의 실력을 가두지 않으면서 생각을 돕는 시스템으로 바꿉니다
DNA Maker는 영업, 프리세일즈, 제품, 수행 팀과 함께 제안 과정 지도(Proposal Journey)와 약속-수행 지도(Promise-to-Delivery Map)를 만듭니다. 뛰어난 직원들이 질문하는 방식, 가격 규칙, 주의할 점을 요구 사항 스키마(Requirement Schema)와 검토 흐름(Review Flow)으로 옮기고, 비즈니스 내용의 승인은 계속 고객사 팀이 맡습니다.
프로토타입 단계에서는 회의 요약, 요구 사항 지도, 솔루션 선택지, 제안서 편집기를 실제 사용자와 시험해, 시스템이 생각을 돕는지 아니면 글만 늘리는지 봅니다. 특히 영업 직원이 가정을 고칠 수 있는지, 수행팀이 아직 확인되지 않은 부분을 볼 수 있는지를 중점적으로 확인합니다.
DNA Maker는 영업 직원이 같은 내용을 두 번 입력하지 않도록 데이터를 연결한 제안 작업 공간(Proposal Workspace)을 설계합니다. 요구 사항, 제품, 가격, 조항, 승인을 위한 데이터 모델을 잡고, 수정할 때마다 그 영향이 사용자에게 보이는 UX를 만들며, 한 고객의 데이터가 다른 계정에 쓰이지 않도록 권한을 정합니다.
저희 작업 범위에는 프로토타입, 연동, 규칙 테스트, AI 평가, 문서 템플릿, 서비스 오픈 후 모니터링이 들어갑니다. 실제 제안서 유형 하나를 골라 브리프 접수부터 승인까지 시뮬레이션해 볼 수 있으므로, 영업, 수행, 재무, 고객사의 계약 담당자가 확대하기 전에 로직을 함께 검토할 수 있습니다.
DNA Maker는 영업 작업 공간(Sales Workspace), 제안 구성 도구, CRM/ERP/문서 연동, AI 검토 도구, 승인과 버전 관리를 개발할 수 있으며, 가격, 범위, 데이터 유출(Leakage)에 대한 평가와 계약 후 인계 패키지(Handoff Package)도 함께 제공합니다.
어떤 제안서 유형이 오래 걸리고 부서 사이를 여러 번 오간다면, 통과한 예시와 반려된 예시를 가져와 이야기해 보십시오. 저희가 규칙을 찾아내고, 사이클 타임(Cycle Time)과 범위의 품질을 함께 재는 프로토타입을 만들겠습니다.
SOFTWARE ENGINEERING GLOSSARY
소프트웨어 엔지니어링 용어집
솔루션 구성, 가격, 버전, 인수 기준을 이야기할 때 쓰는 용어입니다. 경영진은 제안서의 한 군데를 고쳤을 때 마진, 범위, 승인 중 어디에 영향이 가는지 답을 받아 낼 수 있어야 합니다.
| 용어 | 의미 | 쉬운 예시 | 개발팀에 물어봐야 할 질문 |
|---|---|---|---|
| CPQ | 상품 구성, 가격 책정, 견적서 작성을 맡는 시스템. CPQ는 옵션, 가격, 예외를 같은 규칙 아래 두므로, 팔 수는 있지만 수행할 수 없는 제안을 줄여 줍니다. | 패키지를 고르면 규칙에 따라 가격 계산 | 가격 규칙은 어디서 옵니까? |
| Requirement Map | 요구와 제약 조건의 구조. 각 요구를 솔루션, 가정, 인수 기준과 연결해, 제안서의 모든 부분에 근거가 있는지 확인할 수 있게 합니다. | 고객의 고충을 기능과 인수 기준에 연결 | 요구 사항은 누가 확정합니까? |
| Versioning | 여러 버전을 감사할 수 있게 보관하는 일. 수정할 때마다 번호, 수정한 사람, 시각, 달라진 내용을 남겨, 결정한 날 어떤 문서나 규칙을 썼는지 알 수 있게 해야 합니다. | 제안서가 몇 월 가격을 썼는지 확인 | 승인된 버전은 어느 것입니까? |
| Acceptance Criteria | 일이 끝났음을 확인하는 조건. 관찰하거나 테스트할 수 있어야 하고 수행 전에 합의해야 합니다. 그래야 양쪽이 서로 다르게 해석하는 "잘 작동한다" 같은 표현을 피할 수 있습니다. | 시스템이 합의한 형식으로 파일을 내보냄 | 이 기준은 테스트할 수 있습니까? |
| CRM Integration | 고객 관계 관리 시스템과 데이터를 연결하는 일. 데이터를 한 번 보내는 것은 쉬운 부분이고, 좋은 연동은 데이터가 어느 방향으로 흐르는지, 레코드의 주인이 누구인지, 데이터가 충돌하면 어떻게 처리하는지까지 정합니다. | 제안서와 다음 단계(Next Step)를 자동으로 기록 | 절대 덮어쓰면 안 되는 데이터는 무엇입니까? |
더 읽을거리(원문 자료): https://openai.github.io/openai-agents-js/guides/guardrails/