CRM/SFA應用用途
CRM/SFA設計用于銷售代表、銷售經理、客戶服務代表管理公司中銷售和客戶服務,主要功能:
• 跟蹤銷售潛在客戶
• 識别銷售潛在客戶并将此轉換成客戶
• 跟蹤客戶的聯系
• 輸入和跟蹤商機的開始到結束
• 管理客戶報價
• 建立和檢視客戶/聯系人銷售訂單
• 生成銷售預測
• 管理客戶案例 (客服服務請求)
• 發送電子郵件
• 管理活動和做過的工作,包括會議、電話、電子郵件
• 跟蹤市場活動如:客戶調查
關于ID值
貫穿整個CRM/SFA應用,你都将看到像“Account Party Id”、 “Lead Party Id”、 “Opportunity Id”這樣帶有ID的菜單,注意:這些ID值是由系統生成,并不是賬戶、潛在客戶、商機等的實際名字。可以根據實際名稱或其它屬性來檢視ID值。
建立新會員
注意:一個會員可以擁用多個使用者登入,登入系統的應用時用的是使用者登入名而不是會員名。
建立新會員需要在Party Manager中操作,進入點選[Party] > [Create]建立一個新的人員。至少為其配置設定一個以下角色:“Account manager”, “Account Rep”, “CSR”。注意每個使用者可以擁有其它的角色如“Employee”、但CRM/SFA應用中要以上三個角色才能使用,下一步建立一個使用者登入并且為其配置設定安全組:SALES_MANAGER, SALES_REP, 或 SALES_REP_LIMITED, 或 CSR
注意:在party manager中的角色與CRM/SFA中的角色是不同的,在party manager中,角色僅定義為一些人或組面對另一些人或組時的身份。在CRM/SFA中,角色意味在客戶銷售關系中的扮演的角色,而且它也暗指着一組對應的權限。
如果使用者忘記自己密碼,可以通過“忘記密碼”功能将新密碼郵至原來預設的個人主要郵件位址(PRIMARY_EMAIL)中。
使用者簡介
在CRM/SFA應用界面中的頂部[簡介]連結位居使用者名與[登出]按鈕之間。點選此連結可通路使用者簡介頁面,你可以在此頁面中修改使用者名稱,修改密碼,增加聯系方式資訊(如:電郵、郵政位址、電話等)。注意你不可能在這裡更改使用者登入資訊(這隻能在Party Manager中操作)。此頁還可以檢視使用者過往的通路曆史。
帳号組
CRM/SFA應用中的帳号組是通常用于工作于同一組角色和權限組合的團隊, 一個組在它建立時可以被配置設定一個帳号。接着,帳号組管理者或帳号所有者可以重新配置設定組成員或他們的責任,這樣很大程度不同于“軍事機關”組,通常那些組是一直擁有固定的上司、成員的。
為了建立一個組,你需要使用Party Manger。在[Party] > [Create] >> [Create New Party Group]并給你的組命名。然後在[Roles]處配置設定一個[Account Team]角色給它。然後在[Relationships]處加上你的組成員。以下資訊項必段輸入:
• 組PartyId
• 組成員角色 (Account Manager, Account Rep, 或 CSR), 基于早先建立的使用者所配置設定的角色.
• “Is a” 字段必須設定為“Assigned To”
• 組角色應該設定為 “Account Team”
• 設定起時日期
• Party Relationship Security 必須是你的組安全權限. 在 Party Manager, 一長串安全組将會顯示,選擇一個與CRM/SFA 應用相關的安全組. (檢視 “Security Documentation.”)
聯系資訊
系統允許你為每個人/組建立多重的聯絡方式資訊,你的帳号、潛在客戶、聯系人都可以根據你的需求輸入任意多的電話号碼、位址、電子郵件位址。每個聯絡資訊都需要辨別出它的用途。
當你使用[建立聯系人]、[建立潛在客戶]、[建立帳号],系統将基于你的表單輸入建立以下聯系資訊:
• 位址資訊将被做為“一般信函位址”與“一般收貨位址”
• 電話号碼将做為“主電話号碼”
• 電子郵件将做為“主電子郵件位址”
• 網站位址将做為“主網站位址”
但你在建立聯系資訊時,你應當建立電子郵件作為主電子郵件位址及位址做為一般收貨位址。主電子郵件位址将用于發送自動通知郵件。一般收貨位址用于訂單發貨。
電話号碼和電子郵件在所列帳号、潛在客戶、聯系人的主電子郵件和主電話号碼。
你可以點選任何的列在聯絡系統中的電子郵件位址來發送電子郵件,檢視下面的“發送電子郵件”
便箋(notes)
在CRM/SFA應用中,可以為各種各樣的事情或記錄建立便箋,便箋菜單通常都在頁面的底部。
潛在客戶、聯系、賬戶概述
CRM應用的一個核心功能是跟蹤将一個希望或潛在客戶轉化成客戶的過程。在opentpas CRM應用中,希望首先在[Leads]表中被建立為潛在客戶。一個潛在客戶是一個公司的一個人,它沒有與另外的聯系(contacts)聯合起來。然後,當這個潛在客戶已經變成客戶,你就可以将你的潛在客戶轉轉化成一個賬戶(account)和一個聯系(contact),之後,你便可以增加另外更多的聯系在這個賬戶上。
注意:如果你在同一個公司上有多個潛在客戶,系統允許你作為不同的潛在客戶來分别建立它們,然後,将它們轉為同一個賬戶(account)。潛在客戶轉化為賬戶的頁面允許先擇已經存在的賬戶。
對于潛在客戶什麼時候有資格或者什麼時候能轉化為賬戶,這裡沒有什麼正式的要求。當你覺的它适合你公司的需求時,你就可以在任何時候轉化它。
技術要點:如果一個會員(party)被看作是一個賬戶、一個潛在客戶或者聯系,那麼它必須擁有“Account”, “Contact”或者“Prospect”這些成員角色,同時在這些角色中同其它會員有有效的關系(PartyRelationship)。是以,如果會員沒有上面的那些成員角色或者沒有定義與其它會員的關系将不被看作是一個賬戶(account)、潛在客戶或者聯系。當然,一個賬戶(account)是一個會員組(PartyGroup),一個潛在客戶或者聯系是一個人。
賬戶(account)
在0.9.1版之前,賬戶擁有者預設就能管理賬戶團隊,但沒有權力為此賬戶建立機會。是以,在你建立一個賬戶之後,你會發現在除了建立機會外,可以做其它任何事情。建立一個賬戶團隊,同時你也擁有讀寫(full member)權限,那麼你就可以為其建立機會。
在0.9.1版之後,賬戶擁有者便可以為其賬戶建立機會了。
每個賬戶一次可以擁有一個父賬戶。在建立賬戶的時候可以指定其父賬戶,也可以通過更新[Update]按鈕更改其父賬戶。
賬戶目錄是以賬戶名稱存儲的。
聯系
聯系一但被建立,它便可以通過賬戶頁面的[New Contact]按鈕或者聯系頁面的[New Account]按鈕添加給一個賬戶。
聯系目錄先存儲名,然後姓。
潛在客戶
潛在客戶是聯系/賬戶的早期階段,當一個潛在客戶被轉化時,一個聯系各一個賬戶被建立。
潛在客戶也同樣可以有條父親,這個父親必須是一個已經存在的賬戶。
潛在客戶首先配置設定給他的建立者并處于已配置設定“Assigned”狀态。
當你确認了一個潛在客戶,點選确認潛在客戶[Qualify Lead]來标記其為有資格的。
當你轉化一個潛在客戶時,将會把你帶入一個頁面,然後問你想将這個潛在客戶轉化為一個新賬戶還是轉化為一個已存在賬戶的一個聯系。如果這個潛在客戶的公司已經存在,那麼就選擇已存在的賬戶。否則,那個域就留為空白,潛在客戶人将變成一個聯系。如果選了已存在賬戶,這個潛在客戶将變成這個賬戶的一個聯系。如果沒有選擇已存在的賬戶,那麼将基于這個公司的資訊建立一個新賬戶,同時,這個潛在客戶會轉化為這個新賬戶的一個聯系。
當潛在客戶包含公司名稱時,它便隻能轉化為聯系/賬戶。
注意:如果你選了已存在的賬戶,這個潛在客戶的所有公司資訊将會丢失,如:公司名、年收入、行業、SIC代碼、所有權、父公司等。
當一個有機會與其聯合的潛在客戶被轉化時,這個機會便同時與潛在客戶轉化成的賬戶和聯系聯合。
如果你從潛在客戶建立了賬戶,那麼這個潛在客戶的聯系資訊(位址、電話、Email)也變成這個賬戶的聯系資訊。如果将潛在客戶轉化為一個已存在的賬戶的聯系,潛在客戶的聯系資訊會保留在潛在客戶/聯系,但不會複制到賬戶。
當潛在客戶還沒有被确認或者轉化時(仍處于“new”、"Assigned"狀态)可以被删除。在0.9.1版之前,隻要潛在客戶有任何活動(事件、任務、emails)與之關聯是不通被删除的。
潛在客戶目錄可以以公司名、潛在客戶名排序。
合并潛在客戶/聯系/賬戶
從0.9.1版開始,可以合并潛在客戶/聯系/賬戶和重複記錄。點頁面左邊的[合并--]快捷菜單進入後,選擇from--和to-- 潛在客戶/聯系/賬戶的會員ID,然後一個頁面會讓你确認。如果你确認此次合并,那麼form--潛在客戶/聯系/賬戶的資料将被複制到to-- 潛在客戶/聯系/賬戶,然後
form--潛在客戶/聯系/賬戶的資料将從系統中移除。是以執行此項操作時要特别小心,删除資料不能被恢複。
如要潛在客戶/聯系/賬戶建立了大量的資料,合并可能不成功。
機會
當機會最初被建立的時候,這個階段被用來建立機率。機率能在以後更改,但是,當機會處于另一個新階段的時候,機率将被這個新階段的機率複寫。機會需要估計結束時間,是以能做出預測。
一個機會隻能為一個賬戶建立,但時可以有許多聯系。
編輯或更新機會,你必須處于它的賬戶團隊。你為一個賬戶建立了機會,那麼你便能更改它。當更改機會時,需要你填入更改便箋。
自衆0.9.1版,可以為一條已經确認的潛在客戶建立機會,當這個潛在客戶被轉化時,這個機會同時與潛在客戶轉化而來的賬戶各聯系結合。
注意:機會的估計結束日期實際上被存儲為date-time格式(java 時間戳),這是因為預測的時間周期是java時間周期(24時制),是以如果沒有一個估計時間,月度機會的開始或結束時間便會進入一個錯誤的時間周期。系統自動在接近23:59:59.999重置小時。(子夜(24:0:0)前一毫秒)
機會的每個階段的機率存儲在SalesOpportunityStage.defaultProbability域中。
案例(Cases)
建立一個案例至少關聯一個賬戶或者聯系。一個案例可以有多個聯系或賬戶與之關聯,雖然目前系統還沒有相應接口去做這件事。
我的"my cases"顯示配置設定給你的賬戶、聯系的所有案例。目前,将案例配置設定給使用者被隐去了,如果你被配置設定到一個帶有案例的賬戶,那麼那個案例便是你的。
更新一個案例,你必須擁有這個案例的聯系或贓物團隊的相應權限。
關閉一個案例需要專門的權限。
發郵件
在賬戶、聯系、潛在客戶的聯系資訊裡,你點選任何郵件位址後一個頁面會彈出來,你可以輸入一個不同的郵件位址或者找出一個機會或者案例。當你準備好郵件後,可以點發送[Send]按鈕來發送或者點儲存[Save For Later]按鈕以便稍後發送。儲存[Save For Later]按鈕将郵件做為收信人的一個待決活動(pending activity)。一旦發送,郵件就變成活動曆史的一部份。
如果郵件位址不是收件人的,你将得到一個錯誤資訊。
注意:[text]和[HTML]按鈕将在text各html格式之間切換,但是目前HTML編輯器還沒有內建在系統中,是以,如果你要發送HTML格式的郵件,必須從其它地方粘貼過來。一個內建的
HTML編輯器在計劃當中。
Sorting Incoming Emails
排列收到的郵件
自0.9.1版開始,CRM/SFA應用将排列收到的郵件,作為系統溝通事件存儲,并關聯到使用者、聯系、賬戶或者潛在客戶。要配置排列收到的郵件,首先按照Configuration and Setup中的方法配置郵件容器,然後編輯下面這個檔案
hot-deploy/crmsfa/servicedef/smcas.xml
将收件的domain改成你自己的,重起opentaps服務後,系統将會監聽你郵件伺服器并存儲新郵件,然後檢查每封由到郵件的發送位址,并與你賬戶、潛在客戶、聯系比對,同進将郵件的接者位址、抄送位址與CRM使用者比對。
當收到新郵件,系統便在溝通事件中做記錄,如果郵件的發送方位址與會員(賬戶、潛在客戶、聯系)比對,便記錄為來自比對的那個會員;如果郵件的接收位址與另外一個會員比對,便記錄為這封郵件發送給比對的會員。(技術要點:CRM/SFA用opentaps的storeIncomingEmail服務,但是wraps a WorkEffort around it and associates the recipients as parties of the WorkEffort.)
新收郵件被同時建立為會員(賬戶、潛在客戶、聯系)和收件人的未決活動,當你登入CRM/SFA
應用時,你将在未決活動“Pending Activities”清單中看到新收郵件,并在賬戶/潛在客戶/聯系的未決活動中看來是誰發來的。你可以點選”活動“來檢視郵件,接着标記開始,當你完成後标記完成。(技術要點:當你始各完成活動時,CRM/SFA應用會郵件的溝通事件标記為未決“pending”)
活動Activities
有兩種活動:任務(tasks)和事件(envents)。事件(如會議)會在月曆上顯示,任務(如電話、郵件或者普通工作)将不會在月曆上顯示。在你剛進入CRM應用時,首頁"my home"将顯示未決活動清單,包括任務和事件。
可以通過月曆(點選月曆上的日期)或通過賬戶、潛在客戶、案例、機會的頁面來建立事件。而任務隻能通過任務清單來建立。
當建立活動(事件或任務)時,你可以寫入預定的開始日期、時間及持續多久。如果使用者在某段時間比較忙,則選擇“Busy” 或“Away”;如果這段時間裡已經預定了活動,将會有錯誤資訊提示;但如果你堅持“Busy” 或“Away”,則忽略計劃沖突。當你更新一個事件且此事件與另一個事件沖突,則必須設定成忽略計劃沖突。
事件日志是為了記錄一些事件已經發生了。當建立那些已完成的活動時,使用者可以輸入實際的開始和結束時間。
建立一個活動(事件或任務)來計劃某事,使用者可以輸入預定開始和到期時間。事件首先是計劃“Scheduled” 狀态,然後可以确認“Confirmed.”。一旦确認,你就可以為此事件添加會員或發送郵件邀請他們。添加會員自動确認;發送郵件邀請他們時,輸入資訊,郵件會帶有兩個連結(一個是接受邀請另一個是放棄)被發送出去。
如果一個會員在一個時間段已經被配置設定了事件或任務,并且狀态是“Busy.”,那麼另外一事件便不能在此時間段配置設定給這個會員。如果沒有設定狀态,那麼此時間間隙便假設為可以。
當完成了你的事件,你可以記錄此事件的實際時間(開始和結束時間),并标記為完成。
一個任務同樣建立時是計劃“Scheduled”狀态,當使用者開始此活動後,更新此任務為開始"started"狀态并輸入實際開始時間。如果沒有時間被輸入,系統預設填入目前時間作為開始時間。同樣的,當使用者已經已經标記次活動為完成"completed",使用者也沒輸入結束時間時,系統預設填入目前時間作為結束時間。
注意:這不同與需要分别獨立輸入的實際時間和賬單時間。(現在Workeffort Manager也許能處理了)
在一個EMAIL案例中,當你點選發送郵件[Send Email],系統便記錄你郵件的開始時間,當郵件寫完你真的點選發送[send],系統便記錄完成時間。如果你點儲存稍後再發,此時活動不會記錄為完成至到你真的把郵件發送出去。
當檢視活動時,你會在頂部看到活動的詳細資訊,在中間看到關聯的會員(賬戶、聯系、潛在客戶、團隊)清單,然後,如果是郵件,下面便是郵件。注意opentaps設計為允許每個工作效果(work effort)有許多溝通事件,但是,每個活動隻顯示一個溝通。這個觀念在這裡有點落後:在opentaps中,你建立工作效果(work effort)作為項目“projects”并且許多郵件等與之關聯。在這裡,workeffort被當做一個分散的任務,比如發送一封郵件。你仍然可以繼續建立workefforts作為項目,但是這包含建立分散的子任務。目前在Workeffort Manager中已經支援,但是還沒有CRM/SFA應用中便用。
當記錄一個電話或者郵件,“INBOUND/OUTBOUND” 标記決定
When logging a phone call or email, the “INBOUND/OUTBOUND” flag determines to to/from parties in question.
會員清單将顯示會員(賬戶、聯系、潛在客戶)和任務或事件的參與者。目前,隻有月曆的擁有者(如活動的建立人)才更新、增加、删除參與者的狀态,這在以後可能會改變。
查詢活動将顯示活動(任務或事件)清單及這些活動是否完成。
一旦一件事件被取消,月曆上便不在顯示它。
預測Forecasts
銷售預測使用機會的機率和計算一個公司在一個時期内所預期的銷售總量。預測是從機會計算而來。每個銷售人員的預測都是基于在一定時期内此銷售人員所擁有的賬戶和潛在客戶的機會。
與這個銷售人員任何關聯的賬戶或已确認的潛在客戶都将被用來計算預測。這将導緻所有銷售人員的預測總量會大于公司的預測總量。這是因為多個銷售人員可能關聯同一個賬戶。為了得到一個公司的預測,請為每個賬戶和已确認的線過添加一個且僅一個銷售經理。
每個銷售代表都能為他自己建立預測,并輸入他自己的committed amount。隻有銷售經理才能為團隊或領域建立預測。目前,每個銷售人員都隻能為其自己建立預測。
要為你自己建立預測,選擇[Create Forecast]然後選擇與此預測關聯的季度。但是季度沒被正式關閉,至今還沒達到結束時間,那麼便沒有預測可用。
然後會提醒你為此季度按月輸入你的報價(quotas),點選[Create]完成後,你的報價将存入系統同時每月、每季度的預測便被建立好了。每月的預測基于以下幾條計算:
1.結束總額(closed Amount) = 當月已經結束的機會總和
2.最佳案例總額(Best Case Amount)= 當月計劃結束的機會總和(不管機會處于什麼階段
3.預測總額(Forecast Amount) = 機率總和*每個預測的最小機率極限。最小極限在crmsfa.properties檔案中配置計算。
季度預測是月度預測的總和。
要檢視任何人的預測需要特殊的權限。
否則,你隻被允許檢視你自己的預測。
如果你有限檢視他人的預測,點選搜尋預測[Find Forecasts],你将會搜尋到他人的預測。然後,你可以基于團隊成員或一定時期内來搜尋,得到的預測清單結果是以季度形式傳回。
預設的,隻有銷售經理或者超級使用者才能修改已經存在的預測。修改預測,點選月預測度,輸入要修改的報價的值,填入為什麼改變的記錄,然後點[更新][Update]後,月度和季度預測便更新好了。
每次預測更新時,老版的預測會存入曆史。每當檢視一個預測時,你便能看到它的老版的更改時間、報價、best case和總量。
一旦一個時期被正工關閉或者過期,預測便不能再被更新。
當建立新的機會或者已有機會被更新時,預測會自己更新。與被更新機會相關聯的所有團隊成員預測也會自動更新。如果機會的估計結束時間從一個時期改變為另一個時期,相應預測也跟随改變,然而,如果機會的估計結束時間從一個時期改變到另一個還沒有建立預測的時期,那麼一個新的預測會自動被建立。
夥伴Partner
夥伴是外部會員,同樣可以是賬戶團隊的一員。這個功能還沒有實作,所在現在它的制表被禁止了。
報價Quotes
報價制表允許你檢視和為你的客戶建立報價。關鍵是可以基于報價的名稱、類型或狀态來搜尋,建立報價;并且可以從報價建立訂單。注意:這些頁面與訂單管理(Order Manager)裡面的報價頁面是一樣的。以下是報價的主要功能:
搜尋報價[Find Quote] – 搜尋報價
檢視報價[View Quote] – 檢視報價的概要資訊
報價[Quote] – 管理報價的頭資訊,包括那個客戶、産品商店
報價項[Quote Items] – 添加或者删除報價項并改變它們的價格。
建立訂單[Create Order] – 從報價建立訂單
訂單Orders
**********product store的意思待确定
訂單制表允許你從CRM/SFA 應用檢視訂單或者建立新訂單。
0.9.x版的訂單制表是從OFBiz訂單管理導入的基本訂單輸入系統。關于其它更多的訂單輸入資訊,請檢視“Order Manager”檔案裡的“Order Entry”文檔或者“General Overview.”裡的“Sales Order to General Ledger Process Narrative”.
1.0.x版本以後,重寫了訂單制表以支援訂單輸入和查詢。你可以通過訂單制表為賬戶建立訂單,查找已存在的訂單。
我的訂單“My Orders”制表顯示已輸入的訂單。
建立新訂單:可以在賬戶詳細資訊頁面或者訂單制表裡用快速建立訂單項來建立新訂單,或者點選建立訂單[Create Order]連結來建立訂單。
如果用快速建立訂單來建訂單,必須輸入賬戶、訂單名稱和最遲送貨日期,輸入産品辨別(可選),将會将一個機關的産品加入你的訂單。
注意:“desired delivery date"與訂單管理子產品(Order Manager)裡的“ship before date”一樣都是最遲送貨日期。但這裡的“desired delivery date"值不是來來自訂單管理子產品,現在還不支援。
當你将訂單項輸入完後,點選完成訂單[Finalize Order],一個頁面會提醒你為每個訂單項選擇送貨位址和送貨方式。系統會為每個位址組合和送貨方式分别建立送貨組并最終讓你确認。
剩下的訂單輸入頁面與訂單管理子產品裡的一樣。
訂單輸入的産品商店(product store)在config/crmsfa.properties檔案中配置,目前CRM裡訂單輸入系統隻支援産品商店(product store),還不支援産品目錄。
市場Marketing
市場制表打算有許多與市場相關的功能,目前它隻列出所有的調查(surveys)和允許你檢視這些調查的反應。
提供調查Serving Up Surveys
這兒有個分開的網頁應用,它允許你給客戶提供調查或詢問。目前,它隻一個相當簡單的網頁應用,允許你提供一個調查,收集響應然後給你的客戶說“Thank you” 。
你可以在内容管理(Content Manager)中建立調查,然後像下面的URL位址一樣釋出:
http://www.mysite.com/surveys/control?surveyId=${surveyId}
${surveyId}是你在内容管理裡面建立的調查ID。
你可以編緝crmsfa/webapp/surveys/下面的檔案來定制相關調查。
OFBiz
你可以通過把crmsfa.properties檔案中的“crmsfa.tab.ofbiz.show”屬性設定為true或false來允許或阻止連結回OFBiz。如果是允許,你将會在末端看到“OFBiz”制表。“OFBiz”這個文字和這個制表的URL位址同樣可以在crmsfa.properties裡配置。
你需要為你的使用者設定安全以便讓他們能通路OFBiz應用。詳細資訊請檢視Security文檔。
技術要點:應與其它應用內建。
TECHNICAL NOTE: Integrating with the Other Applications
報價、訂單和市場 制表實際上是訂單管理子產品和内容管理子產品的重用。是這樣實作的:
The Quotes, Order, and Marketing tabs actually reuse screens from the Order Manager and Content Manager (for Surveys.) This is done by:
1.Creating a decorator page for these tabs in the CRM/SFA application
2.Parametrizing those applications’ main-decorator-location to whatever is defined in web.xml, so when their screens are called from CRM/SFA application, it will use the decorator and layout of the CRM/SFA application instead of their screens.
3.Copying over view- and request-maps from their controller.xml to the CRM/SFA application’s controller.xml
4.In case of the order entry features, parametrizing the customer link so that in the Order Manager, the links go to Party Manager, but in CRM/SFA, they go to the Accounts tab.
____________________________________________________________________________________
author:overrun