고객이 세 번의 현장 방문이 포함된 견적을 수락한 뒤, 마지막 방문을 미뤄 달라고 요청합니다. 서비스팀은 어떤 방문 일정을 잡아야 하는지 알아야 합니다. 재무팀은 어떤 작업이 실제로 완료됐고 고객이 무엇에 대해 비용을 지불하기로 했는지 알아야 합니다. 기존 견적서를 두 팀에 보내면 같은 문서를 공유할 수는 있지만, 이런 판단은 해결되지 않습니다.
영업, 운영, 회계 시스템을 연결하기 전에 각 단계가 다음 팀의 어떤 행동을 허용하는지 합의하세요. 승인된 견적, 작업 수행 권한, 완료된 작업 기록, 청구서 발행 결정은 서로 구분해 관리합니다. 일부 기업은 이 단계를 합치기도 하지만, 연결 과정에서 각 결정의 의미는 그대로 유지해야 합니다.
영업에서 재무까지 한 건의 작업을 따라가 보세요
고객 현장에서 장비를 정비하는 회사를 떠올려 보세요. 고객은 세 번 방문하는 내용이 담긴 견적 2차 수정본을 승인했습니다. 이 가상의 작업에서 회사는 별도의 작업 지시서를 사용하고, 승인된 방문이 끝날 때마다 재무팀이 청구서 초안을 검토합니다. 이는 가상의 회사가 선택한 방식입니다. 실제로는 재무팀과 합의한 시작 조건과 승인 규칙을 사용하세요.
견적, 주문, 청구서에 관한 Microsoft Dynamics 365 Sales 가이드는 이러한 기록을 분리하고 견적 수정 사항을 처리하는 한 가지 방법을 보여 줍니다. 이 작업에서 중요한 점은 각 기록이 다음 담당자에게 무엇을 알려 주는가입니다.
승인된 견적
영업팀은 고객이 승인한 정확한 견적 버전과 합의된 작업 범위를 기록합니다. 이 기록을 바탕으로 작업 지시서를 작성합니다.
작업 수행 권한
운영팀은 작업 범위를 확인하고 일정 담당자가 작업을 배정하도록 승인합니다. 작업 지시서에는 일정을 잡을 수 있는 작업과 보류 중인 작업이 표시됩니다.
완료된 작업
엔지니어가 방문 내용을 기록합니다. 서비스 책임자가 확인한 뒤 인계할 수 있도록 방문 기록을 승인합니다.
재무 검토
회계팀은 승인된 방문 및 관련 조건에 연결된 초안을 받습니다. 재무팀은 청구 정보를 확인하고 발행 여부를 결정합니다.
공통 작업 번호를 사용하면 직원들이 청구서 초안에서 승인된 견적 버전, 작업 지시서, 방문 기록을 추적할 수 있습니다. 각 팀이 실제로 필요한 정확한 정보를 전달하세요. 예를 들어 방문 주소는 엔지니어를 올바른 장소로 보내는 데 도움이 되고, 재무팀에는 별도의 청구 계정이 필요할 수 있습니다. 시스템 간 변환에 관한 Microsoft 가이드는 같은 업무를 설명하는 필드라도 시스템마다 의미가 다를 수 있는 이유를 설명합니다. 값을 복사하기 전에 의미를 확인하세요.
미뤄진 방문은 다음 초안에 포함하지 마세요
엔지니어가 첫 번째 방문을 마쳤고 고객이 세 번째 방문을 미뤄 달라고 요청했다고 가정해 보겠습니다. 영업팀은 합의된 변경 사항을 승인된 견적에 연결해 기록합니다. 일정 담당자는 작업 지시서를 수정해 두 번째 방문은 진행하고 세 번째 방문은 보류합니다. 첫 번째 방문은 완료 상태로 유지하고 승인 기록 및 적용 조건과의 연결도 보존합니다. 기존에 승인된 견적을 남기고 변경 사항을 함께 기록하면 각 시점에 무엇을 합의했는지 확인할 수 있습니다.
이 회사의 규칙에 따르면 재무팀은 첫 번째 방문에 대한 초안만 검토합니다. 두 번째 방문은 일정이 잡혀 있고 세 번째 방문은 새 날짜가 정해지지 않았으므로 어느 쪽도 초안에 포함하지 않습니다. 고객과 일정 담당자가 세 번째 방문 날짜에 합의하면 보류를 해제합니다. 실제 방문이 완료되면 같은 완료 및 검토 절차를 따릅니다. 그러면 한 번의 방문은 완료되어 재무 검토를 기다리고, 한 번은 일정이 잡혀 있으며, 나머지 한 번은 새 날짜가 합의될 때까지 명확히 보류됩니다.
취소도 명확한 절차로 처리하세요. 누가 작업을 취소할 수 있는지, 이미 수행한 작업을 누가 확인하는지, 변경으로 초안이나 발행된 청구서에 영향이 생기면 누가 재무팀에 알리는지 정합니다. 시스템 연동에서 영향을 받는 기록을 검토 대상으로 표시할 수 있습니다. 재무팀은 회사 규칙에 따라 처리 방법을 결정합니다.
거부된 인계는 해결 권한이 있는 담당자에게 전달하세요
회계팀이 고객을 청구 계정에 연결할 수 없어 첫 번째 방문의 초안을 거부하더라도 방문은 완료 상태로 유지합니다. 인계 상태를 거부로 표시하고 어떤 매칭에 실패했는지 재무 담당자에게 알립니다. 이 예시에서는 재무팀이 올바른 계정을 확인하고 매핑을 수정한 다음 다시 전송합니다. 회계팀은 작업 번호가 계속 연결된 첫 번째 방문 초안 한 건만 수락합니다. 청구서를 발행하기 전에 재무팀은 여전히 발행을 승인해야 합니다.
응답이 없는 것은 다른 문제입니다. 초안이 이미 만들어졌을 수 있습니다. 다시 시도하기 전에 회계팀이 무엇을 받았는지 확인하세요. 연동 시스템이 같은 업데이트를 두 번 받으면 어떻게 되는지에 관한 가이드에서 두 번째 전송으로 초안이 중복 생성되지 않게 확인하는 방법을 설명합니다.
공급업체에 시연을 요청할 내용을 정하세요
실제 작업 유형 하나를 골라 간단한 인계 계획을 작성하세요. 각 단계마다 직원이 신뢰하는 기록, 다음 행동을 승인할 수 있는 사람, 수신 팀이 받는 정보, 진행이 막힐 때 인계받을 사람을 명시합니다. 완료된 작업, 회계팀이 수락한 초안, 발행 승인을 받은 청구서를 어떻게 구분할지도 합의하세요.
공급업체에 별도의 테스트 환경에서 동일한 작업을 시연하도록 요청하세요. 가상의 고객과 작업 기록을 사용하고, 실제 작업 지시서, 배차, 일정 작업, 청구서, 결제, 고객 메시지는 비활성화합니다. 승인된 견적 버전이 의도한 작업 지시서를 만드는지 확인하세요. 그런 다음 방문 하나를 미루고 다른 방문은 완료 처리한 뒤, 청구 계정 매칭을 일부러 거부 상태로 만들고 문제를 수정합니다. 기록에 예상한 작업 상태가 표시되는지, 올바른 방문에 대한 초안 하나만 재무팀에 전달되는지, 미뤄진 작업은 초안에서 빠지는지 확인하세요. 영업, 운영, 재무 담당자가 각자 맡은 단계를 확인하게 하세요.
동작이 분명해지면 이를 바탕으로 연동 견적에 실제로 어떤 범위가 포함되는지 비교하세요. 인계 방식과 관련 업무가 정의되면 영업, 작업 지시, 회계 시스템 연결을 도와드릴 수 있습니다.
견적과 청구서 연결에 관한 자주 묻는 질문
견적 승인 후 청구서를 자동으로 보내야 하나요?
재무팀과 회사가 합의한 시작 조건을 사용하세요. 이 예시에서는 승인으로 작업 지시서 준비를 시작합니다. 방문이 승인되면 재무팀 검토용 초안을 만듭니다.
승인 후 변경 사항을 두 팀에 어떻게 전달하나요?
합의된 변경을 승인된 견적 버전에 연결해 기록합니다. 작업 수행 권한을 업데이트하고 영향을 받는 청구 기록을 표시해 재무팀에 알립니다. 완료된 작업의 증거는 그대로 보존하세요.
작업 완료 후 회계팀이 초안을 거부하면 어떻게 해야 하나요?
완료된 작업 기록을 유지하세요. 구체적인 거부 사유와 작업 번호를 재무 담당자에게 전달하고, 문제를 해결한 뒤 회계팀이 인계를 수락했는지 확인합니다.
어떤 판단에는 여전히 사람이 필요한가요?
판단이나 권한이 필요한 결정은 담당자를 정하세요. 이 예시에서는 운영팀이 작업을 승인하고, 서비스 책임자가 완료 여부를 확인하며, 재무팀이 초안을 검토하고 청구서 발행 여부를 결정합니다.