대량 복사

배경

단가나 처리장이 바뀌면 기존 계약의 일부만 수정해 여러 건을 다시 맺는 일이 잦았습니다. 하지만 대량등록은 신규 계약만 지원해, 재계약도 일단 신규로 등록한 뒤 개발팀에 건별로 변경을 요청해야 했습니다.

기존 계약 정보를 불러오는 데는 PO·온보딩팀의 지원이 필요했습니다. 수거 매뉴얼·특이사항·태그는 수기로 옮겨야 했고, 인계 서류(올바로 배출처리계획)는 복사되지 않아 빠뜨리기 쉬웠습니다. 일부 정보만 바꾸려는 일인데도 자료 준비부터 등록 후 수정 요청과 검수까지 매번 반복해야 했습니다.

대량 수정이 아니라 복사로 접근했습니다

현업에 필요한 것은 여러 계약의 값을 고치는 기능보다, 기존 정보를 빠짐없이 이어받아 재계약을 만드는 흐름이었습니다.

온보딩 업무에서 반복되는 요청을 기준으로 대량 수정과 복사 기반 재계약의 우선순위를 비교했습니다. 대부분은 기존 계약의 일부만 바꿔 새 계약을 맺는 일이었기에, 원본을 다시 입력하고 개발팀에 사후 수정을 요청하는 단계를 줄이는 쪽으로 방향을 정했습니다.

회계팀·CX팀과 정산·계약 운영에 필요한 조건을 확인하고, 디자인팀·개발팀과 엑셀로 여러 계약을 처리하는 방식과 실패 건을 보여 주는 방식을 정했습니다. QA에서는 계약별 변경 내용과 이관 옵션이 의도한 대로 반영되는지 확인했습니다.

대상은 배출 계약으로 한정했습니다. 이전 계약을 선택하면 계약 정보와 수거 매뉴얼·특이사항·태그를 함께 복사하고, 작업량 이관과 스케줄 배정에는 재계약 프로세스 개선에서 정한 정책을 적용했습니다. 복사할 정보뿐 아니라 수정 가능한 항목, 자동 이관 조건, 일부 계약이 실패했을 때의 처리와 결과 확인까지 함께 기획했습니다.

입력 방식도 전부 일괄 수정하는 형태로 만들지는 않았습니다. 재계약 시작일은 여러 계약에 공통으로 적용하는 경우가 많지만, 단가는 계약마다 다를 수 있기 때문입니다. 공통 값은 한 번에 바꾸고 예외는 계약별로 조정할 수 있게 해, 반복 입력을 줄이면서도 개별 조건을 유지하도록 했습니다.

복사와 자동 이관의 조건을 나눴습니다

계약을 복사할 수 있다는 것과 작업량·스케줄까지 자동으로 옮겨도 된다는 것은 다릅니다. 변경된 정보에 따라 자동 이관 허용 여부를 따로 판단하도록 정의했습니다.

계약 이름이나 체결일을 바꾸는 것과 폐기물 종류·배출 업체 신고 정보를 바꾸는 것은 영향이 다릅니다. 폐기물이나 신고 정보가 달라지면 기존 수거 실적과 올바로 인계정보를 새 계약에 그대로 적용해도 되는지 다시 확인해야 합니다. 그래서 화면에서 수정 가능한 항목이라도, 이전 실적과 배차를 자동으로 옮길 수 있는지는 별도 조건으로 검사했습니다.

처리업체를 추가하는 경우는 기존 실적의 처리 경로가 유지되지만, 교체·삭제하면 실제 작업에 기록된 처리장이 새 계약에서 빠질 수 있습니다. 그래서 기존 업체를 유지하는 추가만 허용했습니다. 봉투배송과 다른 요금제 사이의 전환도 작업·청구 방식이 바뀌는 경우여서 자동 이관에서 제외했습니다.

위 표는 화면의 수정 가능 여부가 아니라 작업량·스케줄 자동 이관의 검증 기준입니다. 처리업체는 기존 업체에 추가하는 경우에만 허용하고, 봉투배송과 그 외 요금제 사이의 변경은 자동 이관에서 제외합니다.

자동화 옵션

계약을 미리 만들어 두더라도 작업량과 스케줄을 바로 옮겨야 하는 것은 아닙니다. 복사할 때 각각의 이관 여부를 선택할 수 있게 했습니다.

새 계약을 만드는 시점과 미청구 실적·앞으로의 배차를 넘길 시점이 항상 같지는 않습니다. 계약은 먼저 준비하되 실제 이관 여부는 운영 상황에 맞게 선택하도록 했습니다. 또 같은 이전 계약의 작업량과 스케줄을 여러 자계약이 동시에 가져가면 소속이 충돌하므로, 자동 이관을 받을 자계약은 한 건으로 제한했습니다.

올바로 배출처리계획은 계약 정보만 복사했을 때 놓치기 쉬운 후속 정보였습니다. 새 계약이 만들어져도 계획이 빠지면 인계서 작성이 이어지지 않을 수 있어 복사를 필수로 시도하되, 실패 여부를 계약 생성 결과와 별도로 확인하도록 했습니다.

작업량·스케줄 자동 이관은 이전 계약당 자계약 1건에만 적용해 같은 실적과 스케줄이 여러 계약으로 잘못 연결되는 것을 막았습니다.

일부 실패해도 나머지 계약은 처리되도록

한 건의 실패로 전체를 다시 등록하지 않도록 계약별 처리 결과를 분리하고, 계약 생성과 인계 서류 복사의 성공 기준도 구분했습니다.

한 계약의 오류로 전체를 되돌리면 정상 계약까지 다시 등록하고 검수해야 합니다. 각 계약을 독립된 트랜잭션으로 처리해 실패한 계약이 나머지에 영향을 주지 않도록 했습니다. 계약 생성과 서류 복사 결과도 따로 남겨, 서류 복사에 실패하더라도 이미 만든 계약은 유지했습니다.

실행 중에는 진행 상태를, 완료 후에는 전체·성공·실패 건수를 확인할 수 있게 했습니다. 결과 엑셀에는 이전 계약과 새 계약, 실패 사유, 변경된 스케줄과 이관된 작업 내역을 담았습니다. 담당자는 어떤 계약이 생성됐고 작업량과 스케줄이 어디로 옮겨졌는지 대조할 수 있습니다.

조건에 맞지 않아 자동 이관을 하지 않은 경우와, 이관을 시도했지만 실패한 경우도 구분했습니다. 담당자가 계약의 변경 내용을 다시 확인해야 하는지, 처리 중 발생한 오류를 확인해야 하는지 알 수 있어야 했기 때문입니다.

계약 정보를 다시 입력하고 수정 요청하던 과정을 줄였습니다

기존 계약을 선택해 필요한 정보만 바꾸면, 수거 매뉴얼·특이사항·태그를 함께 가져와 재계약을 만들 수 있게 됐습니다. 담당자가 정보를 다시 입력하고 개발팀에 사후 수정을 요청하던 비효율을 줄였습니다.

조건에 맞는 작업량과 스케줄도 생성된 계약으로 옮기고, 계약별 처리 결과와 실패 사유를 엑셀에서 확인할 수 있게 했습니다. 배포 후 수기 지원 감소는 함께 적용한 재계약 프로세스 개선의 공동 성과로 집계했습니다.