흑백과 디지털

 Deal 에서 가장 중요한 것은 status 이다. 이 status 는 won, lost, open 을 갖는다. Deal 이 성공해서 계약 또는 판매 완료 되면 won이고, 계약이 실패하면 lost 이다. lost 일 경우, lost_reson 필드에 해당 원인을 정리한다. 

Deal 의 개념을 funnel 분석에 적용하기 위해 stage 라는 field 를 갖는다. 이 값은 계약, 판매 라는 won 을 갖기 위해 적용되는 중간 과정을 stage 로 지정한다. (예를 들어 보험판매의 경우, 제안/고객미팅/최종제안/계약준비/계약 이라는 상태로 분류 할 수 있다. )

 하나의 Deal은 여러개의 Product 포함 할 수 있다. 다양한 고객이 존재할 수 있기 때문에 여러 Person 과 여러 Organization 을 가질 수 있다. 여러개의 Activity 를 가질 수 있다. 

Activity는 거래를 위해 활동한 모든 사항이다. 제안, 온라인 상담, 오프라인 상담, 방문 상담, 계약 등 시간적인 약속을 하면서 이루어진 모든 행위를 Activity 라고 할 수 있다. Activity 는 타입을 가진다. 이 타입으로 제안, 온라인 상담 같은 것을 구별 할 수 있다. 
그리고 행위의 대상인 person 과 행위시간이라는 datetime 을 가진다. 기본적으로 약속이 이루어지는 사람과 약속시간이라고 생각하면 편할 것이다.  그래서 status 는 planned/done/cancel 이 있다. 

 Web Application 을 만들다 보면, DB의 테이블을내 공통적인 column 들을 가지고 만들게 된다. 

* create_user, modify_user, create_datetime, modify_datetime 
  - 일반적으로 Admin을 운영하다보면 히스토리 관리를 해야 한다. 운영을 하다보면 실수를 하게 되는데 그 실수의 원인을 파악하기 위해서는 누가, 언제 고쳤는지에 대한 히스토리를 알고 있어야 한다. 
* audit log table
  - 위의 create_*, modify_* 의 경우, 데이터의 처음과 끝 사용자와 시간만 있다. 데이터가 변경된 흐름이 없다. 따라서 이럴 때는 실제로 변경된 데이터를 기준으로 하는 audit log table 을 만들어야 한다. 
  - 이 때 가장 쉽게 하려면 DB 단계에서 이 정보를 기록해야 하고, 잘 갖춰진 Postgresql 트리거가 https://github.com/m-martinez/pg-audit-json  이다. 
 * onwer_user, onwer_group
  - 데이터의 permission을 관리하기 위해서는 해당 데이터의 주인과 주인그룹이 있어야 한다. 데이터의 그룹과 group 이 데이터 마다 있어야 한다. 

 내가 회사에서 사용하고 있는 CRM 툴의 경우 기본적으로 Deal, Activity, Person, Organization이라는 모델을 사용하고 있다. 
  * Deal : 판매를 하려는 일련의 동작. 보험의 경우 하나의 보험을 팔기 위한 여러 과정들을 묶은 가상의 개념으로 결과적으로 판매에 성공하면 Won 이고 실패하면 Lost 고 거래가 진행중이면 Open 상태로 구별된다. 어떤 툴의 경우 opportunity 라고 하기도 한다. 
     판매가 아닌 구매에 대해서도 Deal 개념을 적용할 수 있다. 
  * Activity : 판매를 하려는 과정 중에 발생하는 미팅, 회의, 제안, 계약 같은 행위들. Activity 는 type 을 가지고 있고 보통 고객과의 약속시간을 남기게 된다. CRM 툴에서는 이 약속 시간을 google calendar 와 공유되면서 시간 알림 기능도 제공하기도 한다. 
  * Person : 일반적으로 고객. 경우에 따라서는 협력회사 직원 일 수도 있고, 수수료를 제공하는 중간 판매자일 수도 있다. 
  * Organization : 그냥 회사(조직)라고 생각하면 된다. 하나의 Person 은 하나의  Organization 을 가질 수도 있다.  하나의 Deal도  하나의 Organization 을 가질 수 있다. 
  * Product : 판매하는 상품. Deal 의 경우 여러 상품을 한 번에 팔 수 있다. 그리고 상품은 해당 상품을 취급하는 전문 담당자가 있을 수도 있다. 
  * Note : 모든 model 에 대한 설명을 적을 수 있다. 

 이들 관계를 대략적으로 설명했는데, 이런 모델은 사용하는 업체에 맞게 잘 설계되어서 사용되어야 한다. Sales CRM 툴이 개발자 없이 운영 되는 것 처럼 판매를 하지만 사실 이건 어느 정도 모델이 갖쳐진 DB와 Admin이다. 이를 운영하는 마케터나 운영자가 어느 정도 개발 기획적인 마인드를 갖춰어야 사용할 수 있다.