수입차 렌트·리스·신차 영업

처음부터 끝까지 읽지 않아도 됩니다.

도입을 결정하는 분과 실제로 구축·운영하는 분의 읽는 순서를 나눴습니다. A안과 B안은 같은 상담 업무를 다른 방식으로 구현하는 선택지입니다.

이 문서는 비발디가 자체 제작한 샘플입니다. 상담·화면·수치는 설명을 위한 가정입니다. 실제 진단에서는 고객사 현황을 확인하고, 구축 후에는 합의한 기준으로 결과를 검증합니다.

확인한 사실과 추정한 원인을 나눠 적습니다.

실제 진단에서는 업무 화면과 자료를 확인하고, 확인된 문제와 추가 검토가 필요한 사항을 구분합니다. 아래 내용은 그 기록 방식을 보여주는 예시입니다.

현재 업무에 걸리는 시간을 먼저 측정합니다.

전후 비교에서 자료를 찾는 시간과 검토·수정 시간을 빼면 개선 효과를 과장할 수 있습니다. 자동화 운영 점검 시간도 따로 기록합니다.

왜 이 안을 권하는지 근거를 남깁니다.

가격이나 도구 선호만으로 A/B안을 고르지 않습니다. 팀 전체 조회, 반영 지연, 동시 수정, 내부 운영 역량을 먼저 확인합니다.

미정인 것은 담당자와 확인 기한까지 정합니다.

설치 버전·자료 처리·계정·운영 담당자가 미정인데 구축 일정부터 확정하면 뒤에서 멈춥니다.

S-001 한 건으로 연결을 확인합니다.

같은 상담이 여러 화면과 기록 사이에서 어떻게 이어지는지 확인합니다. 실제 고객이 아닌 가상 자료로만 실습합니다.

접수 번호와 담당 수락을 확인합니다.

BMW 520i · 장기렌트 · 2026년 9월 출고 희망 · 견적 요청을 입력합니다. 월 단위 희망일을 임의의 날짜로 바꾸지 않습니다.

원문에서 확인한 값만 저장합니다.

“개인사업자, 48개월, 보증금 20%, 연 2만 km, 이번 달 출고, 오늘 오후 2시 연락”이라는 가상 상담을 사용합니다.

알림 뒤에는 연락 결과까지 남깁니다.

TASK-001을 등록하고 약속한 시각에 담당자가 연락합니다. 이메일 발송 성공은 연락 완료가 아닙니다.

운영 PC와 설치 조건을 먼저 확인합니다.

고객사 PC에서 운영하는 구성을 기준으로 설치 조건을 확인합니다. 아래 내용은 설치 전 점검 가이드이며, 설치 방식과 버전·운영체제는 보안 지원 여부와 고객사 환경에 맞춰 확정합니다.

계정 연결 없이 데이터 변환부터 연습합니다.

외부 연결 없이 입력값 검사를 연습하는 3노드 구성을 제안합니다. Code 노드에 필요한 로직과 가상 입력 자료를 준비한 뒤 정상 입력과 반려 결과를 비교합니다.

시트는 저장할 항목부터 정합니다.

아래 표를 기준으로 업무별 탭과 저장할 항목을 정합니다. 실제 자료를 연결하기 전에 새 테스트 통합 문서에서 확인하세요.

질문 제목 대신 질문 ID로 연결합니다.

“이메일”이라는 제목이 바뀌어도 같은 질문의 답을 읽을 수 있도록 질문 ID와 저장할 필드를 연결합니다.

조회·검증을 확인한 뒤 저장을 연결합니다.

처음부터 행 추가(Append)로 상담을 계속 저장하지 않습니다. 같은 응답을 다시 읽었는지, 이전 실행에서 어디까지 저장했는지 먼저 확인합니다.

AI 출력은 초안 탭에만 저장합니다.

source_id를 기준으로 원문을 읽고 음성일 때만 텍스트로 변환합니다. 원문에 없는 내용을 채우거나 확정값을 자동 변경하지 않습니다.

A안 검토는 기존 도구를 나란히 엽니다.

기존 설계 화면처럼 한 화면이 자동으로 생기는 것은 아닙니다. 기본 구성에서는 Sheets·Drive·Google Form을 나란히 사용합니다.

배정·수락·결과를 각각 시험합니다.

담당자를 지정하는 것과 담당자가 맡았다는 것은 다릅니다. 내부 폼의 확인된 직원 이메일과 현재 staff를 대조합니다.

알림은 내부 직원 한 명부터 시험합니다.

수신자는 고객 입력에서 가져오지 않고 staff의 확인된 내부 이메일에서 가져옵니다. 실제 고객에게 자동 영업 메시지를 보내지 않습니다.

재시작 뒤에는 변경 요청부터 확인합니다.

PC 중단 중에도 외부 폼은 요청을 보관할 수 있습니다. 재가동한 뒤 오래된 연락 알림부터 보내면 이미 중단한 상담에 잘못 알릴 수 있습니다.

전체 앱보다 저장 기능 하나를 먼저 완성합니다.

JavaScript·HTTP·DB·로그인 기초를 갖춘 담당자를 대상으로 합니다. 작은 예제로 입력·권한·데이터 버전·중복 저장을 이해한 뒤 전체 설계로 확장합니다.

데이터 한 건을 넣고 관계부터 확인합니다.

운영 데이터가 없는 검증용 DB에서 구조와 관계를 확인합니다. 아래 표는 전체 업무에 필요한 데이터 중 기본 관계를 설명합니다.

AI 없이 목록과 상세를 먼저 연결합니다.

가상 데이터를 읽고 사람이 입력한 값을 저장하는 흐름을 먼저 만듭니다. 로그인과 권한이 빠진 임시 화면을 운영에 공개하지 않습니다.

값과 변경 이력을 함께 저장합니다.

아래 검증 기준은 보증금·선납금 두 필드를 가정합니다. 실제 API로 옮길 때는 전체 corrected_fields와 원문·초안 연결 검사를 추가합니다.

작은 예제를 전체 API 명세에 맞게 확장합니다.

검토 저장은 PATCH /api/consultations/:id/review입니다. 로그인한 테스트 사용자의 요청으로 확인하고, 본문에 적힌 사용자 역할은 신뢰하지 않습니다.

검증 환경에서 배포와 복구를 먼저 해봅니다.

운영 계정에 곧바로 연결하지 않습니다. 앱 버전·DB 변경·원문 보관·인증·작업 실행이 함께 맞는지 확인합니다.

같은 요청을 다시 보냈을 때를 시험합니다.

실패한 뒤 재실행하는 순간이 중요합니다. 처음 한 번 성공하는지만 확인하면 중복 상담·중복 연락을 놓칠 수 있습니다.

AI가 틀리는 입력으로 검토 과정을 확인합니다.

“보증금20%, 선납금은 아직 몰라요”처럼 혼동하기 쉬운 원문을 씁니다. 올바른 JSON이 나와도 사실이 맞는지 따로 봅니다.

담당자가 바뀌면 이전 화면도 시험합니다.

권한 검사는 로그인 직후만 하는 일이 아닙니다. 상세 화면을 열어 둔 뒤 재배정했을 때도 저장과 원문 접근을 확인해야 합니다.

꺼진 동안 받은 중단 요청부터 반영합니다.

테스트 n8n을 끄고 외부 폼에서 연락 중단을 요청합니다. 다시 켰을 때 연락 알림보다 중단 처리가 먼저 반영되는지 봅니다.

복구본을 열어봐야 복구할 수 있는지 압니다.

백업 파일이 있다는 사실만으로 완료 처리하지 않습니다. 자동 발송을 막은 테스트 사본에 실제로 복원하고 연결을 대조합니다.

담당자가 매일 확인할 곳을 정합니다.

자동화가 처리한 건수가 0인지, 자동화가 아예 멈춘 것인지 구분할 수 있어야 합니다. 영업 시작과 마감의 확인 책임을 남깁니다.

한 항목을 바꾸면 연결된 곳도 함께 고칩니다.

예를 들어 희망 색상을 추가하면 입력란만 늘리는 것으로 끝나지 않습니다. 실제로 저장·검토·조회되는 경로를 따라 수정합니다.

적용 뒤의 추가 작업까지 함께 셉니다.

기록 시간이 줄었더라도 오류 수정과 운영 점검이 늘 수 있습니다. 전후 조건을 맞추고 순수하게 줄어든 작업을 확인합니다.