---
# System prepended metadata

title: TopSales(CRM) ERD

---

# TopSales(CRM) ERD
|icon|Description|
|--|--|
|==A==|色塊，客製化欄位，天下團隊專用|
|FK|外部資料，需要參考其他資料表|
|UK|該表格的唯一值|
|PK|該表格的主鍵|
|int|數字|
|string|字串|
|text|文字，通常指大量文字區塊，避免在此建立索引欄位|
|!|必填欄位|
|?|非必填欄位|
|[ ]|複數資訊，例如[task]=tasks|



### 名片檔

個資進入CRM的第一個物件。

名單匯入、名片辨識、活動後台匯入、EDM發信，相關個資同步進入CRM時，皆會建立一筆資料，爾後透過比對機制，將名片關聯到聯絡人及公司，因此名片檔視為聯絡人與公司多對多關係的依據。

名片上可能不會有統編跟公司全銜，能作為歸戶的只能是聯絡人姓名跟手機、Email。

因此在商機80%以下的階段，不要求完成名片資訊的歸戶，商機顯示的是聯絡人及其名片上關聯到的客戶(April(iKala))，尚未有正式的合約客戶。

直到商機80%以上時，開立委刊單，這時候業務才需要正式將合約客戶、商機與聯絡人的正式關係建立起來(April(iKala),愛卡拉互動媒體股份有限公司,53342456)。

若是名片上的公司直到80%才發現是現有客戶，則需要做資料合併。

名片檔資料來源：
1. CRM名單上傳
2. CRM名片上傳
3. 活動後台同步報名資訊
4. SendGrid聯絡人同步機制


更新規則：
1. 系統收到名片請求時，先紀錄系統Log，接著送進Queue處理。
2. Queue Worker的任務是將資料依據以下流程進行處理。
3. **比對名片是否重複？** 查詢「聯絡人姓名+聯絡人電話+聯絡人Email＋聯絡人職稱+公司統編+公司名稱」or「聯絡人姓名+聯絡人電話+聯絡人Email＋聯絡人職稱+公司統編+公司暱稱」，如果沒有重複就新增一張名片。
4. **比對聯絡人是否存在？** 若是名片上的資訊無法找到聯絡人(姓名+Email、電話+Email、姓名+電話)，就建立新的聯絡人資訊，然後建立關聯
5. **比對客戶是否存在？** 若是名片上的資訊無法找到客戶(統編、公司名稱)，就建立新的客戶資訊，然後建立關聯



```
雙向同步：
https://www.twilio.com/docs/sendgrid/api-reference/contacts/search-contacts

{
  "query": "updated_at <= now() and updated_at > now() - interval 3 day"
}
```

### 名單活動 card_activities

|column|欄位|說明|
|--|--|--|
|id|名單ID||
|card|名單檔名、活動名稱|
|sales_id|業務|寄信用|
|status|名單處理狀態||


### 名片 cards

|column|欄位|說明|
|--|--|--|
|＊contact_name|聯絡人名稱|客戶PK，如果是英文名，可以直接打在一起，例如Iris Kao
|email|Email|聯絡人PK
|personal_phone|手機|聯絡人PK
|＊customer_name|公司名稱|客戶PK，例如：愛卡拉互動媒體股份有限公司
|vat_number|公司統編|客戶PK
|customer_nickname|公司暱稱|選填，例如：iKala，作為比對條件
|group_name|集團名稱|非必填|
|customer_phone|公司電話
|customer_address|公司地址
|first_name|名|如果名片上有英文的話(不做比對)
|last_name|姓|如果名片上有英文的話(不做比對)
|department|部門|
|＊title|職銜|作為比對條件
|namecard_url|影像檔|如果是上傳名片的話，存放在GCS的位置
|source|來源|名片、名單、活動、Google聯絡人同步|
|sales_id|業務||
|parent_card_id|重複名片ID||
|status|狀態|default: 0 比對中(1、重複(2、在職(3、離職(4|
|tag|標籤|
|card_activity_id|名片活動ID:FK|

```mermaid
---
title: 名片物件
---
erDiagram
    NAMECARD }o--o| CONTACT : "belong to"
    NAMECARD {
        string contact_name "聯絡人名"
        string email "Email"
        string personal_phone "聯絡人個人電話"
        string customer_name "客戶名稱(名片上的)"
        string vat_number "客戶統編(非必填)"
        string source "來源：名單、名片、活動、EDM"
        string department "部門"
        string title "職稱"
        string status "狀態：在職、離職、EDM"
        string CONTACT FK "一個聯絡人"
        string[] CUSTOMER FK "客戶"
    }     
    CONTACT {
        string name "姓+名"
        string email "Email"
        string personal_phone "手機"
        string[] NAMECARD FK "名片"
    }     
    NAMECARD }o..o{ CUSTOMER : "belong to"
    CUSTOMER {
        string name "公司名稱"
        string vat_number "統編"
        string phone "公司電話"
        string[] NAMECARD FK "名片"
    }    
```









### 字典 Dictionary

- 字典檔，解釋每個欄位
- 前端透過物件、物件ID，將資訊整合到前端的物件中


|Column|Name|type|Description|
|--|--|--|--|
||物件|string|標籤|
||物件ID|string|標籤的流水號(PK)：123|
||資料建立的方式|string|使用者選取|
||物件描述|string|僅限公司同事可存取之內部公開資料，如：公司公告、教育訓練文件、操作手冊|
||使用的標準|[FK]|選取標籤時的說明|
||建檔人|FK|建立資料的人|
||建檔時間|datetime|建立資料的時間|
||異動人|FK|異動資料的人|
||異動時間|datetime|異動資料的時間|

舉例，定義標籤物件的「機密等級_2公司內部」的字典檔，透過id=123設定好物件描述，由前端進行介面上的整合，因此在介面上也要設定該物件的id。
![image](https://hackmd.io/_uploads/rkccsLwWC.png)


### 潛客名單 Prospect

- 指的是一個可能對你的產品或服務感興趣的個人或組織。
- Prospects 通常是通過市場研究、社交媒體、活動參與等方式識別出來的。
- 雖然他們可能對你的產品或服務有興趣，但還沒有表達明確的購買意向。

|Column|Name|type|Description|
|--|--|--|--|
|id|SN|PK|
|topic|潛客名單名稱|string|可以描述進攻的產品，讓業務能理解
|sales|負責的業務|[FK!]|建立名單時，可以指定業務，預設是建立名單的人|
|due_date|名單到期時間|datetime|名單到期後，會變成灰色|
|customers|涵蓋客戶|[FK]|僅作關聯
|contacts|涵蓋聯絡人|[FK]|僅作關聯
|leads|潛客|[FK]|
|privilege|使用權限|string|Private, Public|
|tags|標籤|[FK]|名單被建立起時，可以設定標籤，預設帶入名單查詢用的條件|
|memo|潛客名單被建立的條件|string|如果可以的話，將名單被建立的條件儲存起來或是直接轉入標籤|
|createdBy|建檔人|FK|建立資料的人|
|createdAt|建檔時間|datetime|建立資料的時間|
|updatedBy|異動人|FK|異動資料的人|
|updatedAt|異動時間|datetime|異動資料的時間|

### 潛客 Leads (0-30%)

潛客名單Prospecs建立後，有幾個「聯絡人」系統就應該建立起幾筆潛客檔。
表示每個機會開發的結果。

潛客階段的開發重點是目標客戶有意願得到更多資訊、試用、簡報等等。
進到30％之後，會由負責的業務進行更深入的訪談活動。

場景1: EDM，透過API取得客戶是否開信、是否點擊、留下資料，將其寫入活動紀錄（Email聯繫)，可以透過表單取得BANT參數後，自動轉換成30%商機。

場景2: 電銷名單，由電銷同仁溝通後更新溝通細節(活動)到潛客上，主管可以追蹤名單成效。

場景3: 雲姐給四組的TOP20名單，由業務或行政建立潛客名單，業務團隊可以共同開發潛客，將潛客與商機分開管理。

潛客轉換(複製)成商機後，便將潛客所有的資料(包含標籤)帶去商機。

預設的商機名稱：潛客名單+客戶名稱

- 一個更進一步的階段，通常是指已表達了對你的產品或服務感興趣的潛在客戶。
- Leads 可能已經與你的公司建立了某種形式的聯繫，例如填寫了表單、訂閱了郵件列表或與銷售團隊進行了溝通。
- Leads 被認為比 prospects 更有可能成為實際的客戶，因為他們已經表達了明確的興趣。

|Column|Name|type|Description|
|--|--|--|--|
|prospect|潛客名單|FK!||
|sales|負責的業務|[FK!]||
|customer|客戶|FK|客戶檔|
|contacts|聯絡人|[FK]|客戶端的聯絡對象|
|activities|拜訪活動|[FK]|凡業務推進的活動，皆留存在此|
|memo|拜訪摘要|string|儲存推進過程中，業務對於該潛客的註記|
|motive|潛客的動機|int|開發過程中，可以回饋該潛客對於產品的成交動機|
|convert_status|潛客轉換結果|string|轉換商機失敗|
|opportunity_at|轉換商機時間|datetime|轉換商機的時間|
|Opportunity|商機|FK|如果轉換成商機，則將潛客欄位複製成商機|
|createdBy|建檔人|FK|建立資料的人|
|createdAt|建檔時間|datetime|建立資料的時間|
|updatedBy|異動人|FK|異動資料的人|
|updatedAt|異動時間|datetime|異動資料的時間|


## 商機 Opportunity

業務推進商機的資訊，Column空白的話，是我考慮移除的欄位。

|TopSales|CRM|Name|type|Description|
|--|--|--|--|--|
|LegalType|legal_type|==法人==|FK!|建立時預設帶入當前使用者資訊，跟組別重複定義應移除|
|||==部門==|FK!|同上|
|||==組別==|FK!|取代上述兩個欄位，因為業務有時候需代理不同組別的角色，因此會需要==改變該活動對應到的組別==|
||sales|業務|FK|負責的業務|
||company_sales|陪訪業務|[FK]|陪訪的業務，用以計算活動|
||push_sales_group|助攻組別|[FK]|助攻的組別，用以認列業績|
||lead|潛客|FK|來自哪一個潛客|
||name|商機名稱|FK!|為此商機定義一個名稱|
||stage|商機階段|FK!|商機推進的階段|
||change_logs|商機階段推進歷程|[FK]|紀錄商機推進階段變更的時間|
||customer|公司|FK?|客戶|
||contacts|商機聯絡人|[FK?]|聯絡人資訊|
||==商機起始日==|string|商機起始日，是否作為目標業績的認列月份？|
||預計結案日|string|商機結案日，是否作為目標業績的認列月份？|
||==實際結案日==|string|商機實際結案日，需確認實際上的用途，因為銷售階段已經完成，實際結案日是執行階段的資訊，拋轉回來是比較大的工作|
||==列管專案==|string|內部進行中的通案，確認Ｂ端會員模式是否對應多個專案|
||==銷售產品==|string|目前以會計科目為選項，可透過這個結構，重新定義預算與認列業績的方式|
||==預估成交月份==|string|重新定義預算與認列業績的方式|
||==預估數量==|string|重新定義預算與認列業績的方式|
|budget|預估金額|string|重新定義預算與認列業績的方式|
||==開發評分==|FK|潛客開發時的評分，建議是改存到潛客名單內，一樣可以顯示|
|memo|備註|text||
||==預估金額拆帳、攤提==|string|紀錄是平均攤提或是指定月份認列業績，其實都是拆帳|
||==商機金額拆帳月份==|[FK]|指定商機金額拆帳月份|
||files|附加檔案|[FK]|商機聯繫的相關檔案|
||activities|活動(拜訪紀錄)|[FK]|與活動Activities關聯|
||createdBy|建檔人|FK|建立資料的人|
||createdAt|建檔時間|datetime|建立資料的時間|
||updatedBy|異動人|FK|異動資料的人|
||updatedAt|異動時間|datetime|異動資料的時間|





### 標籤 Tag

定義標籤資訊

|Column|Name|type|Description|
|--|--|--|--|
||標籤名稱||
||使用權限||
||預設到期時間||
||建檔人|FK|建立資料的人|
||建檔時間|string|建立資料的時間|
||異動人|FK|異動資料的人|
||異動時間|string|異動資料的時間|


### 活動(拜訪紀錄) Activity

業務日常拜訪活動

|TopSales|CRM|Name|type|Description|
|--|--|--|--|--|
|CustVisitOrganization.LegalType|legal_type|==法人==|FK!|建立時預設帶入當前使用者資訊，跟組別重複定義應移除|
|CustVisitOrganization.Unit||==部門==|FK!|同上|
|CustVisitOrganization.Team|group_id|==組別==|FK!|取代上述兩個欄位，因為業務有時候需代理不同組別的角色，因此會需要==改變該活動對應到的組別==|
|CustVisit.CustId|customer_id|對應客戶 id|FK?|聯絡人客戶|
|CustVisit.ContactID|contact|聯絡人|[FK?]|聯絡人資訊|
|CustVisit.ADCustId|ad_id|==廣告商==|FK?|廣告商（待理解）|
|CustVisit.ADContactID|ad_contact_id|==廣告商聯絡人==|FK?|廣告商聯絡人（待理解）|
|CustVisit.FormOfVisit|contact_form_id|活動的接觸形式|FK!|接觸形式|
|CustVisit.PurposeOfVisit|contact_purpose_id|==活動的接觸目的==|FK!|接觸目的，結合接觸形式用來計算==活動量分數==，分數用來計算目標達成率|
|??CustVisit.isDel??|status|狀態|FK?||
|CustVisit.SalesUser|visit_by|拜訪(人)時間=>拜訪人|FK|建立時預設帶入當前使用者資訊|
|CustVisit.VisitDateStart|visit_at|拜訪時間|string||
|CustVisit.NextVisitDate|??visit_at??|下次拜訪時間|string|儲存時自動建立行程，重複行程則忽略|
|CustVisitAccompany||==陪訪人==|[FK]|業務人員清單|
|CustVisitAssistUnit||==助攻單位==|[FK]|業務組清單|
|CustVisit.ReqDesc|focus|??工作重點??|text|建立時預設帶入當前使用者資訊|
|CustVisit.ProposalAmount|proposal_amount|提案金額|string!|建立時預設帶入當前使用者資訊|
|CustVisit.Fare|fare|==車資==|string!|建立時預設帶入當前使用者資訊|
|CustVisit.VisitPurpose|remarks|??工作重點??|text|填寫紀錄，考量在訊息中tag人的用法，資料中會參考google chat訊息, ==@陳世彥==會記錄成<sales\|sales_id>, ==聯絡人== 紀錄成<contact\|contact_id>，資料取出後，再由AP層用正規式取出，替換成資料庫中的名稱，便於帶入超連結前往該物件的詳細頁面。|
|CustVisitResponses|feedback|==主管回應==|text|考慮可以改成[==意見回饋==]<br> ==實際上會有多==|
|CustVisitResponses|supervisor_id|==回應主管==|text|同上|
|CustVisitResponses|response_time|==回應時間==|text|同上|
|CustVisitTodoList||待辦事項|[FK]|自己或是主管建議的待辦事項清單|
|CustVisitBusiness.CustBusinessId|opportunity_id|商機|FK|該活動推進的商機|
||lead_id|潛客|FK|與活動關聯的潛客，潛客轉換成商機時，同時將活動建立起商機關聯|
|CustVisit.CreateUser|created_by|建檔人|FK|建立資料的人|
|CustVisit.CreateDate||建檔時間|string|建立資料的時間|
|CustVisit.UpdateUser|updated_by|異動人|FK|異動資料的人|
|CustVisit.UpdateDate||異動時間|string|異動資料的時間|


### 待辦事項 TodoItem

|TopSales|CRM|Name|type|Description|
|--|--|--|--|--|
|CustVisitTodoList.CustVisitId|activity_id|拜訪紀錄|FK!||
|CustVisitTodoList.SalesUser|sales_id|業務|FK!||
|CustVisitTodoList.CustId|customer_id|公司|FK?|聯絡人客戶|
||contact_id|聯絡人資訊|FK?|聯絡人資訊|
|CustVisitTodoList.DoWhat|task_description|工作事項|text||
|CustVisitTodoList.DoDate|due_date|到期時間|datetime||
|CustVisitTodoList.DoneDate|completion_date|完成日|datetime||
|CustVisitTodoList.CreateUser|assigned_by|指派人|FK!||
|||建檔時間|string|建立資料的時間|
|||異動時間|string|異動資料的時間|


### Brief
GPT: 在 CRM 系統中，Brief 通常指的是客戶簡介或簡報。它是對客戶的基本信息和重要資訊進行簡潔概述的文件或部分。
Actual: 這是商機成立後，提案的摘要內容。
|Column|Name|type|Description|
|--|--|--|--|
|customer|客戶|FK!|
|customer_department|客戶部門|string|
|customer_contact|客戶窗口|string|
|decision_maker|客戶決策者|string|
|project_name|專案名稱|string|
|start_date|走期起日|string|
|end_date|走期迄日|string|
|opportunity|商機|[FK]|
||建檔人|FK|建立資料的人|
||建檔時間|string|建立資料的時間|
||異動人|FK|異動資料的人|
||異動時間|string|異動資料的時間|




### Memo


|形式|目的|實際|分數|
|--|--|--|--|
|親身拜訪|提案比稿/聽brief|去客戶那裡提案或是聽Brief|8|
|親身拜訪|合作執行/記者會|去客戶那裡提案或是聽Brief|4|
|親身拜訪|提案修改/報價|去客戶那裡提案或是聽Brief|2|
|親身拜訪|行政日常|去客戶那裡提案或是聽Brief|0.8|
|Concall線上會議|提案比稿/聽brief||6|
|Concall線上會議|合作執行/記者會||3|
|Concall線上會議|提案修改/報價||1.5|
|Concall線上會議|行政日常||0.6|
|電訪或社群媒體溝通|提案比稿/聽brief||4|
|電訪或社群媒體溝通|合作執行/記者會||2|
|電訪或社群媒體溝通|提案修改/報價||1|
|電訪或社群媒體溝通|行政日常||0.4|
|Email|提案比稿/聽brief||2|
|Email|合作執行/記者會||1|
|Email|提案修改/報價||0.5|
|Email|行政日常||0.2|
|未接觸|提案比稿/聽brief||1|
|未接觸|合作執行/記者會||0.5|
|未接觸|提案修改/報價||0.25|
|未接觸|行政日常||0.1|


## 客服系統

### Case 客服個案

存放個案的通用資訊

|Column|Name|type|Description|
|--|--|--|--|
|id|流水|PK||
|category|個案類型|enum|1.個資刪除, 2.權益查詢, 3.申請改址, 4.申請補寄|
|status|個案狀態|enum|1.處理中, 2.完成, 3. 異常終止|
|stage|個案處理階段|enum|1.建立處理中, 2.完成, 3. 異常終止|
|info|個案資訊|text|個案的處理資訊|
|createdBy|建檔人|FK|建立資料的人, 如為API更新，在系統中建立一個API User作為參照|
|createdAt|建檔時間|datetime|建立資料的時間|
|updatedBy|異動人|FK|異動資料的人|
|updatedAt|異動時間|datetime|異動資料的時間|

### Case_Backorder 客服補寄個案

存放補寄單個案的專用資訊，可以直接查補寄個案，也可以reference到通用個案

|Column|Name|type|Description|
|--|--|--|--|
|id|流水|PK||
|case_id|個案|FK|
|customer_no|客戶編號|string
|backorder_address|補寄地址|address
|order_no|訂單編號|string
|erp_backorder_no|ERP補寄單編號|string
|backorder_status|補寄單狀態|string
|backorder_at|補寄時間|datetime
|createdBy|建檔人|FK|建立資料的人, 如為API更新，在系統中建立一個API User作為參照|
||createdAt|建檔時間|datetime|建立資料的時間|
||updatedBy|異動人|FK|異動資料的人|
||updatedAt|異動時間|datetime|異動資料的時間|

