← 블로그 전체 글
구현 방법

이메일로 받은 주문·문의, 접수부터 회신까지 자동화하려면

담당자별 이메일로 들어오는 주문과 문의를 AI가 읽고 등록·배정·회신까지 처리하는 업무 흐름. 자동 처리할 조건, 예외와 도입 전 확인할 내용을 설명합니다.

핵심 정리

  • 이메일과 첨부 파일을 읽고, 회사가 정한 조건을 충족한 요청은 등록·업무 배정·회신까지 자동 처리하는 구조를 만들 수 있습니다.
  • 거래처·품목·가격·수량을 검증하고, 할인 승인이나 주문 변경처럼 판단이 필요한 요청은 담당자에게 전달합니다.
  • 실제 메일로 결과를 검증한 뒤 자동 실행 범위를 넓히며, 연결 오류와 처리 누락도 확인할 수 있어야 합니다.

고객이 영업 담당자에게 주문서를 보냅니다. 담당자는 첨부 파일을 열고 품목과 수량을 확인한 뒤 ERP에 입력합니다. 재고나 납기를 확인할 사람에게 내용을 전달하고 고객에게 접수 답장을 보냅니다. 신규 문의가 섞여 있다면 담당 부서를 찾고 회신할 자료도 준비해야 합니다.

이 흐름에서 사람이 반복하는 작업을 어디까지 줄일 수 있을까요? 메일을 읽고 회사의 기준에 맞는 요청을 등록·배정·회신까지 처리하는 자동화를 목표로 할 수 있습니다. 직원은 새로 결정할 사안과 확인이 필요한 예외를 맡습니다.

다만 사용하는 메일·ERP의 연결 조건과 업무 규칙에 따라 가능한 범위가 달라집니다. 아래는 고객 업무에 맞춰 구축할 수 있는 처리 흐름의 예시입니다.

반복 주문 한 건이 자동으로 처리되는 모습을 생각해봅니다

기존 거래처가 평소 구매하던 부품 100개를 주문했다고 가정해보겠습니다. 거래처와 품목을 확인할 수 있고, 계약 단가와 주문 단위가 일치하며, 별도 승인이 필요한 조건도 없다면 다음 흐름을 설계할 수 있습니다.

메일마다 처리 결과를 남깁니다 처리 화면 예시
영업 1 · 영업 2 · 대표 메일함접근을 허용한 주문·문의 수집
AI가 내용을 읽고, 업무 규칙으로 검증거래처 · 품목 · 계약 단가 · 중복·변경 확인
자동 처리 완료기존 거래처의 반복 주문

센서 A 100개 · 계약 단가 일치

처리 기록
수주 등록 → 자재 확인 업무 생성 → 접수 회신
담당자 검토할인을 요청한 주문

메일 단가가 계약 단가와 다름

다음 처리
원본과 차이를 보여주고 가격 승인 요청
복구 확인 필요ERP 응답이 없는 주문

전송 후 등록 여부를 확인하지 못함

다음 처리
기존 등록 여부 확인 후 미완료 단계 재처리
요청마다 완료 여부와 다음 할 일을 남깁니다. 자동 회신은 등록 결과를 확인한 뒤 보내며, 납기 확약에는 별도 승인 기준을 적용합니다.

시스템은 주문서를 읽어 거래처·품목·수량 등을 추출하고 기준 정보와 대조합니다. 검증을 통과하면 연결 가능한 ERP나 업무 시스템에 주문을 등록합니다. 이어서 회사가 정한 규칙에 따라 자재 확인이나 출하 검토 업무를 만들고, 고객에게 주문 번호와 접수 결과를 보냅니다.

이 구조를 구현하면 직원이 주문마다 파일을 열고 옮겨 적고 전달하는 작업을 줄일 수 있습니다. 자동으로 처리할 주문의 비중은 실제 메일과 예외를 검증한 뒤 확인해야 합니다.

담당자마다 다른 주소로 받아도 한곳에서 처리할 수 있나요?

회사가 허용한 담당자별 업무 메일을 연결하고, 수집한 내용을 하나의 처리 목록으로 모으는 방식을 검토할 수 있습니다. 고객은 기존 주소로 메일을 보내고, 회사는 담당자의 부재와 관계없이 접수 여부를 확인하는 구조입니다.

연결에는 메일 서비스가 지원하는 기능과 계정 접근 권한이 필요합니다. 어떤 메일을 가져올지, 원본과 첨부 파일을 누가 볼 수 있는지도 정합니다. 개인적인 내용이나 다른 부서의 민감한 자료까지 모두 공유하는 방식으로 설계하지 않습니다.

주문·문의 메일을 분류할 때는 놓치는 요청이 없는지가 중요합니다. 거래처 주소나 정해진 수신함처럼 명확한 규칙을 활용하고, AI가 분류한 결과 중 애매한 건은 확인 목록에 남깁니다. 제목에 ‘주문’이라는 단어가 없다는 이유로 자동 제외하지 않도록 실제 메일 표현을 살펴봅니다.

같은 메일을 여러 직원이 받으면 하나의 접수 건으로 연결할 수 있어야 합니다. 기존 주문의 수정본인지, 새로운 주문인지도 구분합니다. 잘못 묶인 대화는 담당자가 나누거나 연결을 수정할 수 있도록 합니다.

AI가 읽은 내용을 어떤 기준으로 믿고 실행하나요?

AI는 서로 다른 양식과 표현에서 필요한 정보를 읽는 역할을 맡을 수 있습니다. 읽어낸 값으로 실제 주문을 처리하려면 회사의 기준에 맞는지 검증해야 합니다.

확인할 항목 자동 처리 전에 정할 기준
거래처 등록된 거래처와 주문 권한을 확인할 방법
품목 고객의 품목명과 사내 코드의 연결 기준
수량·단위 필수값, 허용 단위와 포장 수량 변환
가격 계약 단가, 적용 기간과 예외 승인 조건
중복·변경 기존 주문과 비교할 번호·품목 행·변경 내용
납기 요청일과 확정일의 구분, 약속할 수 있는 조건

예를 들어 ‘10 BOX’라고 적혀 있다면 해당 품목의 포장 수량을 확인해야 합니다. 거래처가 쓰는 품목명이 여러 사내 품목과 일치한다면 임의로 하나를 선택하지 않고 확인을 요청합니다. 메일에 적힌 단가가 계약과 다르면 승인 절차로 보냅니다.

자동 실행은 검증한 항목과 허용된 작업 범위 안에서만 진행합니다. 메일 본문에 계좌 변경이나 자료 전송을 요구하는 문장이 있어도 그 내용이 곧 실행 권한이 되지는 않습니다. 중요한 조건 변경에는 별도의 확인 절차를 둡니다.

문의도 내용에 따라 후속 처리까지 연결합니다

문의는 종류별로 처리할 수 있는 범위가 다릅니다. 회사가 승인한 자료와 최신 업무 데이터로 답할 수 있는 요청부터 자동 회신을 검토할 수 있습니다.

들어온 요청 자동화할 수 있는 처리의 예 담당자가 판단할 내용
제품 자료 요청 허용된 자료 선택·전달과 이력 기록 비공개 자료의 공유 승인
견적 문의 품목·수량·조건 정리, 부족한 항목 확인 요청 신규 가격과 할인 조건
주문 접수 확인 등록 결과와 주문 번호 조회·안내 등록 오류나 거래처 확인
납기 문의 확인된 계획과 최신성 검사 새로운 일정 확약과 변경 협의
주문 변경·취소 기존 주문과 변경 내용 비교 생산·발주 진행분의 처리 결정

답변할 근거가 없으면 담당자에게 검토를 요청하도록 만듭니다. 필요한 정보를 고객에게 다시 묻는 회신도 질문 내용과 발송 조건을 정해 자동화할 수 있습니다.

처음에는 회신 초안을 담당자가 확인하고, 충분히 검증한 문의 유형부터 자동 발송을 허용하는 방식이 가능합니다. 다른 거래처의 가격이나 주문 정보가 섞이지 않도록 조회 권한과 수신자를 함께 확인해야 합니다.

주문 접수와 납기 확정은 따로 처리합니다

고객에게 ‘주문을 접수했습니다’라고 알리는 것과 ‘요청한 날짜에 납품하겠습니다’라고 약속하는 것은 책임이 다릅니다. 자동 회신에는 실제로 확인한 결과만 담습니다.

ERP 등록에 성공했다면 주문 번호를 안내할 수 있습니다. 생산·자재 조건을 아직 검토하지 않았다면 납기는 확인 중이라고 알려야 합니다. 재고가 있다는 이유만으로 검사·예약·배송 조건을 확인하지 않고 출하를 확약하지 않습니다.

낮은 위험의 반복 주문에 자동 확정 규칙을 둘 계획이라면 대상 제품, 거래처, 수량과 재고 기준 등을 따로 합의합니다. 어떤 조건이 바뀌면 자동 처리를 멈출지도 함께 정합니다.

등록 실패와 미회신도 시스템이 추적해야 합니다

메일을 잘 읽어도 ERP 연결이 끊기면 처리가 끝나지 않습니다. ‘읽기 완료’, ‘검증 통과’, ‘등록 확인’, ‘회신 완료’처럼 각 단계의 결과를 확인할 수 있어야 합니다.

등록 도중 응답을 받지 못했다면 이미 주문이 만들어졌는지 확인한 뒤 재처리합니다. 같은 주문을 다시 등록하거나 접수 메일을 반복 발송하지 않도록 처리 기록을 관리합니다. 등록은 성공했는데 회신만 실패했다면 실패한 단계부터 다시 처리할 수 있어야 합니다.

메일 연결 자체가 멈추는 상황도 대비합니다. 계정별 마지막 동기화 시각과 오류를 표시하고, 복구 후 빠진 요청을 다시 가져오는 방법을 마련합니다. 업무 목록이 비어 있다는 이유만으로 새 문의가 없다고 판단하지 않도록 합니다.

담당자가 보는 화면에는 자동 처리 완료, 검토 필요, 오류·미완료를 구분합니다. 대표는 전체 요청 중 무엇이 처리됐고 어디에 지원이 필요한지 확인할 수 있습니다.

처음부터 자동 실행할 범위를 크게 잡지 않습니다

최종 목표를 전체 처리 자동화로 정해도, 실제 권한은 검증한 범위에 맞춰 확대합니다. 도입은 다음처럼 진행할 수 있습니다.

  1. 실제 메일 표본으로 결과를 비교합니다. 정상 주문, 수정본, 문의와 무관한 메일 등으로 분류·추출 결과와 누락을 확인합니다. 이 단계에서는 실제 주문이나 고객 회신을 실행하지 않습니다.
  2. 담당자 승인 아래 처리합니다. 시스템이 만든 등록 내용과 회신을 확인하고, 수정한 이유를 기록합니다. 처리 실패와 재시도도 검수합니다.
  3. 조건을 충족한 요청을 자동 실행합니다. 검증한 거래처·양식·업무부터 적용하고, 예외와 오류는 담당자에게 전달합니다. 문제가 생기면 승인 방식으로 되돌릴 수 있게 합니다.

자동 처리율만 높이는 것을 목표로 삼지 않습니다. 놓친 요청, 잘못 등록한 값, 수정에 든 시간과 고객에게 다시 설명한 건수를 함께 확인합니다. 담당자의 검토 시간과 운영 비용을 포함해 실제로 업무 부담이 줄었는지 판단합니다.

무엇을 준비하고 어떤 결과물을 받나요?

상담에서는 사용하는 메일 서비스와 ERP, 주문·문의가 들어오는 주소, 대표적인 처리 순서를 알려주시면 됩니다. 자료는 공유 범위를 협의한 뒤 민감한 값을 가린 표본부터 살펴볼 수 있습니다.

앞선시스템즈는 합의한 범위에 따라 메일 연결, 업무 접수 목록, 문서 해석과 검증 규칙, 시스템 등록, 회신과 오류 처리 절차를 설계합니다. 자동 실행을 허용할 작업과 담당자가 확인할 작업도 명시합니다.

ERP가 외부 등록이나 파일 가져오기를 지원하지 않으면 끝까지 자동 처리할 방법을 별도로 검증해야 합니다. 안정적인 방법을 찾기 어렵다면 제약과 남는 작업을 설명합니다. 기존 공유메일함·고객지원 도구로 충분히 해결할 수 있는 범위도 먼저 확인합니다.

운영 비용에는 서버 외에 메일·AI·자동화 도구의 이용료와 연결·양식 변경에 대한 관리가 포함될 수 있습니다. 처리할 메일 수와 첨부 파일 규모, 보관 기준과 지원 범위를 확인한 뒤 검토합니다.

자주 묻는 질문

직원이 쓰던 이메일 주소를 바꿔야 하나요?

현재 메일 서비스에서 필요한 연결과 권한을 지원하면 기존 주소를 활용할 수 있습니다. 계정별 연결이 어렵다면 공용 접수 주소나 전달 방식도 검토합니다. 사람이 직접 전달해야만 접수되는 구조에는 누락 가능성이 남는다는 점을 함께 고려합니다.

AI가 애매한 내용까지 알아서 처리하게 하면 안 되나요?

주문 수량·가격·납기처럼 실제 책임이 따르는 값은 검증 기준이 필요합니다. 애매한 요청은 원본과 확인 사유를 담당자에게 전달합니다. 반복해서 확인하는 예외에 명확한 기준을 만들 수 있다면 다음 자동화 범위로 검토합니다.

어떤 요청부터 사람의 확인 없이 처리할 수 있나요?

품목·단가·단위와 처리 절차가 명확한 반복 주문부터 검토할 수 있습니다. 실제 표본으로 정확도와 예외를 확인하고, 자동 실행할 조건과 중단 기준을 정합니다. 새 품목이나 조건 변경 등 검증 범위를 벗어난 요청은 담당자 확인으로 보냅니다.

프로젝트 상담에 메일을 받은 뒤 직원이 하는 일을 순서대로 알려주세요. 읽기·입력·전달·회신 중 반복되는 작업과 자동 실행에 필요한 조건을 함께 확인합니다.