Otter Beam Workspace의 데이터 흐름

Otter Digital Pte. Ltd. · 2026년 10월 17일 업데이트

Otter Beam Workspace는 Sales & CRM, 구매·조달, 프로젝트 관리를 회사 자체 컴퓨터의 회사 데이터베이스 하나에 모아 둡니다. 한 모듈에서 일어난 일을 다른 모듈이 알아야 할 때 Otter Beam이 자동으로 넘겨 주며, 이를 핸드오프라고 부릅니다. 이 페이지에서는 모든 핸드오프에 대해 무엇이 시작시키는지, 무엇을 만들거나 바꾸는지, 언제 아무것도 하지 않는지, 끝낼 수 없을 때 어떻게 되는지를 설명합니다.

모든 핸드오프의 동작 방식

같은 순간, 같은 데이터베이스. 핸드오프는 이를 일으킨 작업과 같은 데이터베이스 트랜잭션 안에서 실행됩니다. 둘 다 저장되거나 둘 다 저장되지 않으며, 중간까지만 끝난 상태는 누구에게도 보이지 않습니다.
내가 한 작업은 항상 반영됩니다. 핸드오프 자체가 끝나지 못하더라도(예: 공급업체가 보류 상태) 그것을 시작시킨 작업은 그대로 저장됩니다. 견적서 승인은 후속 단계가 실패해도 승인된 상태로 남습니다. 실패한 핸드오프만 따로 되돌려지고 보고됩니다.
기록자는 "Otter Beam"입니다. 핸드오프가 만들거나 바꾸는 레코드는 사람이나 에이전트가 아니라 시스템이 기록하며, 모든 변경은 변경 전/후 값과 핸드오프 번호(F1–F8)를 메모로 달아 감사 로그에 남습니다.
Data health에서 확인할 수 있습니다. 실행할 때마다 OK, Skipped(할 일 없음), Failed 중 하나가 정확한 이유와 함께 기록됩니다. 실패하면 오류도 함께 열립니다. 원인을 해결한 뒤 Data health에서 다시 시도할 수 있으며, 재시도는 아직 끝나지 않은 부분만 처리합니다. 오류는 해결됨으로 표시할 수 있습니다.
연쇄에는 한도가 있습니다. 핸드오프 하나가 다음 핸드오프를 시작할 수 있습니다(승인된 견적서가 판매 주문을 만들고, 판매 주문이 프로젝트를 만드는 식). 연쇄는 네 단계에서 멈추므로 설정 실수로 무한 반복이 생기지 않습니다.
다시 입력할 필요가 없습니다. 만들어진 모든 라인이 원본 라인을 가리키므로, 견적서부터 마지막 결제까지 수량, 가격, 진행 상황을 추적할 수 있습니다.

판매 흐름

#	시작 조건	하는 일	아무것도 하지 않는 경우	실패하는 경우
F1	리드가 전환될 때	리드에 고객이 없으면 고객(법인 또는 개인)을, 리드에 담당자가 적혀 있으면 주 담당자를 만들고, 둘 모두에 연결된 영업 기회를 만듭니다. 리드는 전환 완료로 표시됩니다.	—	레코드를 만들 수 없습니다(이유는 Data health에 표시됩니다).
F2	견적서가 승인될 때	다음 주문 번호로 확정된 판매 주문을 만들고, 견적서의 모든 라인과 현장 주소를 복사합니다. 견적서는 전환 완료로, 영업 기회는 수주로 표시됩니다. 변경 견적서는 대신 원래 주문에 라인을 추가하고 합계를 갱신합니다.	—	주문을 만들 수 없습니다. 견적서는 승인된 상태로 남습니다.
F3	판매 주문이 확정될 때(F2에 의한 확정 포함)	주문에 프로젝트를 시작하는 품목이 있으면 프로젝트(예산은 해당 라인의 소계)와 프로젝트 템플릿의 작업을 만듭니다. 날짜는 순서대로 잡히고, 작업 사이에는 선행 작업이 끝나야 시작할 수 있는 의존 관계가 생깁니다.	주문에 프로젝트 품목이 없거나 이미 프로젝트가 있을 때.	사용할 수 있는 프로젝트 템플릿이 없습니다. 주문은 확정된 상태로 남습니다.
F8	결제가 확정·배정·무효 처리되거나 청구서가 발행·무효 처리될 때	영향을 받는 모든 청구서와 공급업체 청구서의 결제 금액과 미결제 금액을 다시 계산해 부분 결제/결제 완료로 바꾸고, 판매 주문의 "Invoiced x% · Paid y%"와 구매 주문서의 결제 상태를 갱신합니다. 확정된 결제만 반영됩니다.	이 결제는 아직 어디에도 배정되지 않았습니다.	—
—	아직 라인이 없는 판매 주문에서 청구서가 만들어질 때	내용을 미리 채웁니다. 일반 청구서는 아직 청구하지 않은 수량을 복사하고, 선수금 또는 기성 청구서는 합의된 비율의 라인 하나를 추가하되 이전 청구분을 뺍니다.	—	—

구매 흐름

#	시작 조건	하는 일	아무것도 하지 않는 경우	실패하는 경우
F4	프로젝트용 구매 요청이 만들어질 때	요청을 프로젝트에 연결합니다. 가격 없이 추가된 라인은 우선 공급업체의 마지막 가격(우선 공급업체가 없으면 알려진 최저가)으로 미리 채워집니다.	—	—
F5	구매 요청이 확정될 때	요청을 공급업체별로 구매 주문서 초안 한 건씩으로 나누며, 가격은 각 공급업체의 마지막 구매 가격입니다. 모든 라인이 주문서에 들어가면 요청은 주문 완료로 표시됩니다.	—	공급업체가 보류 또는 차단 상태이거나 라인에 공급업체가 없을 때("Vendor Tampines Paint & Coatings is on hold."). 다른 공급업체의 주문서는 그대로 만들어지며, "Retry later"는 빠진 것만 만듭니다.
F6	입고가 등록될 때	받은 수량을 구매 주문서 라인에 더하고, 주문서를 부분 입고/입고 완료로 바꿉니다("Received 90%").	—	—
F7	구매 주문서에서 공급업체 청구서가 만들어지거나, 그 라인이 바뀌거나, 확정될 때	구매 주문서에서 공급업체 청구서의 내용을 미리 채우고, 청구된 수량과 단가를 입고된 내용과 비교합니다(3-way 매칭). 결과는 일치, 수량 불일치("Qty mismatch: billed 40, received 38"), 단가 불일치, 아직 입고 없음 중 하나입니다. 확정하면 구매 주문서에 청구된 내용을 기록합니다.	—	—

프로젝트

시작 조건	하는 일
작업이 시작될 때	의존하는 작업이 아직 끝나지 않았으면 거부됩니다("Waits for: Site survey").
의존 관계가 추가될 때	순환이 생기는 경우에는 거부됩니다.
작업, 배정, 견적 공수, 기록된 시간이 바뀌거나 F3이 작업을 만들 때	영향을 받는 사람별로 앞으로 몇 주의 주간 업무량을 다시 계산하며, Workload 보기에서는 과다 배정이 빨간색으로 표시됩니다.

AI 에이전트가 할 수 있는 일과 할 수 없는 일

에이전트는 데이터베이스에 직접 쓰지 않습니다. 사람과 같은 규칙(같은 검증, 같은 핸드오프, 같은 감사 로그)을 거치는 구조화된 요청을 보낼 뿐입니다. 에이전트가 만든 초안은 승인되기 전까지 업무에 영향을 주지 않습니다. 회사에 구속력이 생기는 작업(확정, 발송, 결제)은 승인 카드에서 대기하며, 사업주가 주로 스마트폰에서 승인하거나 거부합니다. 에이전트의 읽기 권한은 구조화된 읽기 전용 쿼리로 제한됩니다. 개인정보(담당자와 직원의 이름, 이메일, 전화번호)가 담긴 응답에는 그 표시가 붙고, 에이전트는 당장의 작업에만 사용하도록 지시받습니다.