전화로 온 문의는 어디에 남길까? SmartNexus Other Lead와 Pacific Time 통합

모든 Lead가 BizBuySell 이메일로 들어오는 것은 아닙니다. 전화, 소개, 문자와 현장 대화로 시작한 문의를 이메일 Lead와 다른 곳에 두자 같은 고객의 기록이 두 갈래로 나뉘었습니다. 이번 단계는 출발점이 달라도 하나의 Client History로 모으는 작업이었습니다.

SmartNexus 개발일지 ⑫ · 2026년 9월 13일 · 약 6분

수동 Lead는 이메일 Lead의 불완전한 버전이 아니다

전화 문의에는 이메일 주소가 없을 수 있고 관심 Listing도 통화 뒤에 확인될 수 있습니다. 이메일 Lead와 같은 필수 항목을 강제하면 사용자는 임시 값을 넣거나 아예 기록을 미룹니다. Other Lead는 이름, 연락처와 메모처럼 지금 아는 정보부터 저장하고 나중에 보완하도록 했습니다.

그렇다고 별도의 고립된 고객 목록을 만들지는 않았습니다. 전화번호와 이메일로 기존 Client를 검색해 연결하고, 새 고객이면 같은 Client 구조를 사용했습니다. 문의 경로는 달라도 결국 한 사람이므로 History와 후속 작업은 한곳에서 보여야 했습니다.

관련 Activity를 따라가야 대화의 맥락이 보인다

Other Lead 상세 화면에서 메모만 보면 이전 이메일이나 통화 기록을 다시 찾아야 했습니다. Client와 연결된 Activity를 함께 불러오고, 어떤 Lead에서 만들어진 기록인지 표시했습니다. 같은 고객이 여러 Listing을 문의했을 때 현재 문의와 전체 관계를 구분했습니다.

기존 Client를 선택하는 검색창은 전체 목록을 내려받지 않고 서버 검색을 사용했습니다. 전화번호 표준화 덕분에 괄호나 하이픈이 달라도 같은 후보를 찾을 수 있었습니다. 지난 단계의 검색 기반이 실제 Lead 통합에서 쓰이기 시작한 셈입니다.

Follow-up 날짜를 모를 때도 기록은 먼저

“자료를 받으면 연락”처럼 날짜가 아직 없는 다음 행동도 있습니다. 날짜를 필수로 두면 임의의 날을 선택하거나 메모에만 남겨 Follow-up 목록에서 빠집니다. due date를 선택 사항으로 바꾸고, 날짜 미정 항목을 별도로 찾아 정리할 수 있게 했습니다.

날짜가 없다는 것은 중요하지 않다는 뜻이 아닙니다. 조건, 담당 행동과 생성 시각은 반드시 남겼습니다. 이후 자료가 도착하거나 약속이 정해지면 due date를 추가하도록 했습니다. 빈 날짜와 누락된 기록을 같은 것으로 취급하지 않았습니다.

서버 시간과 사용자가 보는 시간을 분리하기

Railway와 PostgreSQL은 UTC를 기준으로 다루는 것이 안정적이지만, Simon의 실제 업무는 California 시간으로 움직입니다. 화면마다 UTC와 현지 시간이 섞이면 “오늘 들어온 Lead”와 Follow-up 날짜가 자정 전후에 달라집니다.

저장은 UTC 기준을 유지하고 표시와 업무 경계는 Pacific Time으로 변환했습니다. 여름·겨울 시간은 고정된 시차를 더하지 않고 시간대 규칙을 사용했습니다. 정렬과 필터도 같은 기준을 적용해 화면마다 하루의 시작이 달라지지 않도록 했습니다.

상태값은 현재 사용하는 코드만 보여주기

오래된 상태 코드가 드롭다운에 남으면 사용자는 의미를 알 수 없고 잘못된 값을 다시 저장할 수 있습니다. 활성 상태만 선택지에 보여주되 과거 기록은 삭제하지 않았습니다. 현재 입력 규칙과 과거 감사 기록을 분리한 것입니다.

Other Lead는 기능 이름보다 실제 사용 흐름이 중요했습니다. 전화가 끝난 직후 휴대폰에서 최소 정보를 저장하고, 사무실에서 기존 Client와 기록을 보완할 수 있어야 했습니다. 처음부터 완벽한 입력을 요구하지 않는 것이 오히려 데이터 누락을 줄였습니다.

목록의 정렬과 날짜 필터도 표시 시간과 같은 기준을 사용했습니다. 화면에는 9월 13일로 보이는데 검색 결과는 UTC 기준 9월 14일에 들어가면 사용자가 오류로 느낍니다. 하루 범위를 Pacific Time에서 계산한 뒤 DB 조회에는 정확한 UTC 구간으로 변환해, 보이는 날짜와 검색되는 날짜를 맞췄습니다.

수동 입력은 자동 이메일 수집보다 오타 가능성이 높아 저장 후 확인 화면을 바로 보여줬습니다. 전화번호와 이메일이 기존 Client와 유사하면 후보를 제시하되 자동으로 합치지 않았습니다. 같은 이름의 다른 사람을 잘못 연결하는 것보다 사람이 한 번 확인하는 편이 안전했습니다.

날짜 필터도 Pacific Time 경계를 따라야 했다

화면만 현지 시간으로 바꾸고 “오늘” 필터는 UTC 자정을 사용하면 오후 늦게 들어온 Lead가 다음 날 기록으로 분류될 수 있습니다. 사용자가 선택한 Pacific 날짜의 시작과 끝을 먼저 UTC 범위로 변환한 뒤 데이터베이스에서 조회했습니다. 표시, 검색과 집계가 같은 하루를 가리키게 한 것입니다.

일광절약시간이 바뀌는 날에는 하루가 항상 24시간이 아닙니다. 고정된 8시간 차이를 적용하지 않고 시간대 라이브러리가 계산한 경계를 사용했습니다. Follow-up 알림과 Activity 정렬도 같은 기준을 공유해 한 화면에서는 오늘이고 다른 화면에서는 어제로 보이는 일을 막았습니다.

수동 입력은 오타보다 후보 확인이 중요했다

전화로 들은 이름과 번호는 이메일에서 자동 추출한 값보다 오류 가능성이 큽니다. 저장을 막는 강한 검증보다 비슷한 Client 후보를 먼저 보여주고 사용자가 새 고객인지 확인하도록 했습니다. 번호가 불완전해도 메모는 남길 수 있게 하되, 연락 전에 보완해야 할 항목은 눈에 띄게 표시했습니다.

테스트에서는 같은 번호의 다른 표기, 이메일 없는 기존 Client, 여러 Listing을 문의한 한 사람, 날짜 미정 Follow-up을 확인했습니다. 실제 상담처럼 정보가 한 번에 완성되지 않는 순서로 입력해야 Other Lead가 임시 메모장이 아니라 지속되는 고객 기록이 되는지 판단할 수 있었습니다.

실무 체크리스트

FAQ

Other Lead와 Client는 서로 다른 사람인가요?

아닙니다. Other Lead는 문의가 들어온 경로이고, 확인 후 기존 또는 신규 Client와 연결됩니다.

Follow-up 날짜를 비워두면 잊기 쉽지 않나요?

날짜 미정 전용 필터와 조건 메모가 필요합니다. 임의 날짜를 넣는 것보다 미정 상태를 명확히 관리하는 편이 정확합니다.

왜 DB에는 Pacific Time으로 저장하지 않나요?

UTC 저장은 서버와 지역이 달라도 일관적입니다. 사용자 화면과 업무 기준에서 Pacific Time으로 변환합니다.

기존 Client와 잘못 연결하면 어떻게 하나요?

저장 전 이메일·전화번호와 관련 Listing을 함께 확인하고, 연결 변경도 Activity에 남기는 편이 안전합니다.

공식 자료

• Microsoft Learn: TimeZoneInfo
• PostgreSQL: Date/Time Types
• Microsoft Learn: ASP.NET Core Model Binding

관련 글

• Client 검색과 전화번호 표준화
• 이메일과 Follow-up 연결
• 일회성 이메일 템플릿