상황
제안서는 90%가 똑같고, 10%만 매번 달랐다
고객 이름, 수량, 기간, 금액. 바뀌는 건 몇 개뿐인데 담당자는 매번 지난 제안서를 열어 통째로 복사하고, 바꿔야 할 곳을 눈으로 찾아 하나씩 고친다.
그러다 한 곳을 놓쳐 예전 고객 이름이 남거나, 단가를 잘못 옮겨 적어 견적이 틀린 채 나간다.
고객 이름, 수량, 기간, 금액. 바뀌는 건 몇 개뿐인데 담당자는 매번 지난 제안서를 열어 통째로 복사하고, 바꿔야 할 곳을 눈으로 찾아 하나씩 고친다.
그러다 한 곳을 놓쳐 예전 고객 이름이 남거나, 단가를 잘못 옮겨 적어 견적이 틀린 채 나간다.
손으로 채우는 문서 하나가 실제로 얼마를 흘려보내는지, 숫자로 보면 이렇다.
"요청만 받으면 AI가 제안서 만들어서 고객한테 바로 보내면 되지 않나?" 이 유혹부터 검토했다.
금액이 걸린 문서는 실패 비용이 크다. 단가·할인·조건을 잘못 채운 제안서가 그대로 나가면 손해를 물거나 신뢰를 잃는다. 값이 애매하면 지어내지 않고 비워 두고, 사람이 채워야 한다.
"틀을 불러와 요건을 넣고 표준 단가로 계산하는" 90%를 자동화한다. 비표준 조건은 확인 필요로 표면화하고, "이 금액·조건으로 보낼지" 10%만 사람이 쥔다.
네 단계를 따라가 보세요. 마지막, 금액 확정과 발송만 사람의 몫입니다.
고객·품목·수량·기간 같은 바뀌는 값만 넣는다.
요청 유형에 맞는 표준 템플릿을 불러와 값을 꽂는다.
표준 단가로 견적을 계산하고 제안서 초안을 채운다. 비표준은 확인 필요로.
채워진 초안 상태에서, 금액과 조건을 확정하고 보낼지만 사람이 쥔다.
말로 하면 여기까지다. 이제 직접 눌러보세요. 아래는 데모 데이터로 만든 실제 동작 화면입니다.
요건이 표준 템플릿에 꽂히고 견적이 자동 계산됩니다. 할인처럼 비표준 조건은 지어내지 않고 확인 필요로 남습니다.
같은 제안, 작성 전과 작성 후. 바뀐 건 문서가 아니라, 요청에 답하는 속도다.
바뀌는 값은 이미 꽂혔고, 확인할 것만 사람이 본다. 문의가 식기 전에, 제안이 먼저 도착한다.
