앞선 글에서 문제는 알림이 아니라 알림이 읽을 수 있는 형태의 날짜가 없는 것이라고 했다.
만료일은 이미 증서 안에 있다.
그렇다면 남은 문제는 하나다.
문서 안에 있는 날짜를 어떻게 시스템이 사용할 수 있는 데이터로 바꿀 것인가.
증서에서 무엇을 읽는가
고객사 상세 화면의 라이선스 탭에서 증서 PDF를 올린다.
그러면 문서 전체의 텍스트를 읽어 다음 항목을 추출한다.
제품명 · 시리얼 번호 · 만료일 · 수량 · 제품 유형
여기에 문서 상단의 고객사명과 발주 번호도 함께 읽는다.
라이선스 정보만 정확하다고 끝나는 것이 아니기 때문이다.
담당자는 지금 올린 증서가 현재 보고 있는 고객사의 문서가 맞는지도 확인할 수 있어야 한다.
읽어낸 결과는 바로 저장하지 않는다.
먼저 표로 보여준다.
한 장에 여러 건이 들어 있다
증서 한 장에 라이선스 한 건만 들어 있는 경우는 오히려 드물다.
네트워크 라이선스라면 하나의 시리얼 번호에 여러 제품이 묶여 있을 수 있다.
같은 제품에 여러 해의 만료 정보가 함께 들어 있는 경우도 있다.
계약을 갱신할 때마다 이전 기록이 사라지는 것이 아니라, 한 문서 안에 갱신 이력이 누적되는 형태이기 때문이다.
이 내용을 그대로 등록하면 문제가 생긴다.
같은 제품에 대해
2024년에 만료된 행,
2025년에 만료된 행,
2027년에 만료되는 행이
모두 현재 라이선스처럼 들어오게 된다.
과거 기록과 현재 계약을 구분해야 했다.
그래서 판정 기준을 하나 두었다.
같은 제품의 행이 여러 개라면 만료일이 가장 늦은 행만 사용한다.
이때 제품을 구분하는 기준은 이름이 아니라 제품 번호다.
제품명은 문서나 버전에 따라 표기가 조금씩 달라질 수 있지만, 제품 번호는 동일한 제품을 판단하는 기준으로 사용할 수 있기 때문이다.
이 규칙을 적용하면 증서 안에 누적된 갱신 이력 가운데 현재 유효한 정보만 남길 수 있다.
이미 등록된 시리얼은 빼놓는다
갱신 증서에는 기존 시리얼 번호가 다시 들어 있다.
새로운 라이선스가 발급된 것이 아니라, 같은 라이선스의 사용 기간이 연장된 것이기 때문이다.
이를 그대로 등록하면 같은 라이선스가 두 건으로 쌓인다.
앞선 글에서 이야기한 중복 고객사와 성격이 같다.
그래서 등록 화면에서는 해당 고객사에 이미 등록된 시리얼 번호가 있는지 확인한다.
이미 존재하는 항목은 흐리게 표시하고, 체크가 해제된 상태로 보여준다.
여기서 한 가지는 의도적으로 남겨두었다.
중복 항목을 목록에서 아예 없애지 않는 것이다.
예를 들어 담당자가 다섯 건이 들어 있는 증서를 올렸는데 화면에는 세 건만 나타난다고 생각해보자.
나머지 두 건이 중복이라 제외된 것인지,
문서를 제대로 읽지 못한 것인지
담당자는 알 수 없다.
결국 원본 PDF를 다시 열어 하나씩 대조하게 된다.
옮겨 적는 일을 줄이려고 만든 기능이 새로운 확인 작업을 만드는 셈이다.
그래서 제외할 항목도 화면에는 남긴다.
등록하지 않는 것과 보여주지 않는 것은 다른 문제이기 때문이다.
원본을 버리지 않는다
증서에서 필요한 항목을 읽어낸 뒤에도 PDF 파일 자체는 함께 보관한다.
데이터로 바꿨다고 해서 원본의 역할이 끝나는 것은 아니다.
사람이 문서의 내용을 직접 옮겨 적으면 원본과 입력된 데이터 사이에 간격이 생긴다.
그리고 시간이 지나면 이런 질문이 생긴다.
“이 만료일은 어디에서 나온 값이지?”
Linkspace에서는 표에 등록된 만료일과 그 값의 근거가 된 증서를 함께 남긴다.
몇 달 뒤 누군가 값을 확인해야 한다면 해당 고객사의 라이선스 정보에서 원본 문서를 바로 열어볼 수 있다.
표는 검색하고 정렬하고 관리하기 위한 형태이고,
원본은 근거를 확인하기 위한 형태다.
하나를 다른 하나로 대체하는 것이 아니라, 서로 다른 역할을 하는 두 정보를 함께 남기는 것이다.
저장은 사람이 확인한 뒤에 이뤄진다
문서에서 읽어낸 항목은 먼저 표로 보여주고, 담당자가 체크한 항목만 등록한다.
자동으로 읽었다고 해서 자동으로 저장하지는 않는다.
문서 형식은 언제든 달라질 수 있기 때문이다.
발급처가 증서 양식을 바꾸거나 항목의 위치와 표현이 달라지면 읽어낸 값이 예상과 다를 수 있다.
이때 잘못 읽힌 데이터를 그대로 저장해버리면 자동화가 오히려 오류를 빠르게 쌓는 도구가 된다.
그래서 자동화의 범위를 「읽어내는 것」까지로 정했다.
시스템은 사람이 직접 옮겨 적는 일을 대신하지만,
최종적으로 맞는 정보인지 판단하는 과정은 담당자에게 남겨둔다.
그리고 읽어낸 항목이 하나도 없다면 조용히 넘어가지 않는다.
문서를 읽지 못했다는 사실을 화면에서 알린다.
사용자가 결과를 기다리고 있는데 아무 변화도 없는 상태에서는
정상적으로 처리된 것인지,
오류가 발생한 것인지
판단할 수 없기 때문이다.
실패한 것보다 더 불편한 것은 실패했는지조차 알 수 없는 것이다.
그래서 무엇이 달라지나
PDF 안에 있던 만료일이 데이터가 되면 그때부터 시스템이 할 수 있는 일이 달라진다.
만료일 순서로 정렬할 수 있다.
이번 달에 만료되는 계약이 몇 건인지 셀 수 있다.
담당자별로 나눠볼 수 있다.
고객사 목록에서 만료가 임박한 곳을 먼저 찾을 수도 있다.
문서 안에서는 눈으로 찾아야 했던 날짜가
이제는 검색하고 계산할 수 있는 기준이 된다.
하지만 더 중요한 변화는 그다음에 있다.
날짜를 계산할 수 있게 되면, 날짜를 기준으로 다음 행동도 계산할 수 있다.
만료일에서 거꾸로 세면 언제 연락해야 하는지가 나온다.
3개월 전에 무엇을 하고, 1년 전에 무엇을 해야 하는지 정할 수 있다.
이것이 앞선 글에서 이야기한 「연락할 이유를 시스템이 만든다」의 출발점이다.
결국 문서에서 날짜를 꺼내는 일은 단순한 입력 자동화가 아니다.
고객에게 언제, 어떤 이유로 다시 연락할 것인지를 시스템이 판단할 수 있게 만드는 출발점이다.
다음 글에서는
만료일을 확보했다면 그다음 질문은 자연스럽게 이어진다.
언제 연락해야 하는가.
그리고 여기에는 조금 더 어려운 문제가 하나 있다.
이미 만료된 고객에게는 언제 다시 연락해야 하는가.
아직 만료되지 않은 고객과 이미 만료된 고객은 같은 기준으로 관리할 수 없다.
다음 글에서는 이 두 경우의 연락 시점을 어떻게 나눌 것인지 이야기해보려고 한다.
키워드: 라이선스 증서, 라이선스 PDF 자동 등록, 시리얼 번호 관리, 만료일 자동 등록, PDF 데이터 추출, 라이선스 대장, 네트워크 라이선스, 중복 시리얼, 계약 갱신 관리, 라이선스 만료 관리, 유지보수 갱신, B2B CRM, 영업관리 프로그램, Linkspace