房產(chǎn)公司傭金管理系統(tǒng),要如何搭建?(房產(chǎn)公司傭金管理系統(tǒng),要如何搭建平臺)
從業(yè)務維度來看,房產(chǎn)公司的傭金管理可以分成多個維度。此時,如何搭建合理的傭金管理系統(tǒng),就成為了關鍵之處。本篇文章里,作者結合自己的看法,對傭金管理系統(tǒng)的初步框架進行了總結,感興趣的話就來看看吧。
今天和大家分享的是房地產(chǎn)公司傭金管理系統(tǒng)的框架模型,希望能對初次接觸傭金管理系統(tǒng)搭建的小伙伴有所幫助&啟發(fā)。
文章結構:
- 傭金管理系統(tǒng)業(yè)務場景&整體框架;
- 基于框架模型的傭金管理系統(tǒng)設計;
一、房地產(chǎn)傭金管理系統(tǒng)業(yè)務場景&整體框架
房地產(chǎn)傭金管理根據(jù)其業(yè)務可分為多種維度。本文主要講述兩個維度的傭金管理:
1)以房地產(chǎn)公司作為甲方的維度,講述其如何給渠道結傭
房地產(chǎn)公司銷售渠道一般分為以下幾種:房產(chǎn)公司自營的內(nèi)部銷售公司,這種代理類型一般被稱為內(nèi)部一手代理,與此相對應的還有外部一手代理,內(nèi)外部一手代理公司主要是全盤負責某個樓盤的房源銷售。
除了一手代理公司,房地產(chǎn)公司還會與二手代理公司簽訂外部渠道,比如像Q房網(wǎng)、鏈家等中介渠道商,二手代理公司主要負責給案場帶客。
除了簽訂渠道公司之外,房地產(chǎn)公司還會開拓一些個人渠道,比如全民營銷、內(nèi)外部拓客等,這種渠道主要是靠個人來給案場推薦客戶。
總結下來,房地產(chǎn)公司作為甲方,在其傭金管理方面,主要是管理兩種類型的結傭:一種對公,結給公司;一種對私,結給個人。
2)以房地產(chǎn)營銷公司的維度,講述怎么給內(nèi)部銷售人員進行結傭
給內(nèi)部銷售人員結傭,主要是指給內(nèi)部銷售總監(jiān)/經(jīng)理/銷售員、簽約崗等崗位人員結算傭金。
1. 業(yè)務全景分析——給誰結傭?結什么?怎么結?
1)業(yè)務場景一
中大型的地產(chǎn)公司大部分在全國設有分公司,每個分公司負責不同的項目,根據(jù)業(yè)務的需要,其傭金制度難以從總部層面來進行統(tǒng)一,同時業(yè)務周期又較長,導致傭金制度變化快。
業(yè)務存在的問題:
- 由于計算標準不統(tǒng)一,線下計算匹配標準與計算傭金,工作量大,計算難,且容易出錯;
- 計算標準會隨市場、政策的變動而變動,導致計算難,容易出錯;
- 傭金計算業(yè)務周期長,制度變化直接影響結算流程。
2)業(yè)務場景二
結傭?qū)ο蠖啵瑐蚪鹨?guī)則差異化大。
業(yè)務存在的問題:
- 不同銷售階段、考核指標、跳點方式的不同;
- 不同的銷售形式,銷售組織,需要結傭的團隊各不相同。
一般有內(nèi)部的自營營銷團隊、代理公司、外部的二手代理(中介)、拓客、全民營銷等各種渠道;不同的崗位、代理公司、外場轉(zhuǎn)介在業(yè)績標準、發(fā)放標準、扣傭條件上均存在差異。
3)業(yè)務場景三
存在多種特殊業(yè)務。
業(yè)務存在的問題:由于認購后退房、簽約后退房、退換房價格變動等導致的已結傭需要退還、業(yè)績變化導致的點位變化、特批合同等各種特殊業(yè)務。
4)業(yè)務場景四
銷售人員變動大,導致傭金交接難。
業(yè)務存在的問題:
- 人員調(diào)崗時,根據(jù)是否繼續(xù)負責客戶后續(xù)事宜,確定傭金是否交接以及交接比例;
- 人員離職時,需確定未結傭金的交接對象及比例,預留的傭金是否需要退還等。
在沒有上線傭金管理系統(tǒng)之前,房地產(chǎn)公司的傭金管理基本都是用excel的形式來記錄,在保留歷史數(shù)據(jù)、進行數(shù)據(jù)分析、經(jīng)營營銷費用等方面可以說是非常繁瑣和落后,上線傭金系統(tǒng),對于整體業(yè)務的管理還是益處多多。
2. 整體框架——如何進行上下游系統(tǒng)應用的集成?
傭金系統(tǒng)在地產(chǎn)整個銷售管理鏈條中處于中間位置,前面是需要基礎數(shù)據(jù)的支撐如成交數(shù)據(jù)、人員數(shù)據(jù)、風控數(shù)據(jù)等,傭金系統(tǒng)則是配置傭金規(guī)則、計算邏輯,通過對基礎數(shù)據(jù)、規(guī)則進行計算之后,得出來的計算結果則輸向下游消費系統(tǒng),供財務付款、HR發(fā)傭。
第一步:傭金計算的數(shù)據(jù)可來自HR、ERP、營銷系統(tǒng)或二手房等多個系統(tǒng)。引入MQ保證數(shù)據(jù)傳遞的實時、可靠性。
第二步:傭金方案的制定、規(guī)則的設定、傭金發(fā)放的審批等業(yè)務操作涉及到審批流,與OA進行集成。
第三步:數(shù)據(jù)經(jīng)傭金系統(tǒng)處理完,得出傭金結果,提供給下游業(yè)務系統(tǒng)使用。
二、基于框架模型的傭金管理系統(tǒng)設計
1. 應用架構
主要考慮上下游系統(tǒng)與本系統(tǒng)之間的交互。
2. 功能架構
重點描述系統(tǒng)的功能性需求,包括功能模塊、核心關鍵的用例圖、與外部系統(tǒng)的接口設計等。
3. 業(yè)務流程簡介
全渠道傭金業(yè)務流程介紹。
1)核心業(yè)務流程——傭金方案制定流程
① 傭金方案制定
傭金方案制定流程如下所示:
② 傭金方案評審
傭金方案制定后,必須走審批流程,由相關人員和領導對傭金方案進行評審。
③ 傭金方案發(fā)布
傭金方案評審通過后,便可對傭金方案進行發(fā)布。在傭金方案的有效時間范圍內(nèi),傭金方案生效。對發(fā)布后的傭金方案必須進行歷史版本管理。傭金方案版本的更新,需重新走發(fā)布評審流程。
重點:
a)傭金規(guī)則靈活配置
- 支持配置傭金規(guī)則庫;
- 支持各項目對規(guī)則進行參數(shù)的靈活配置;
- 支持對多種維度的指標進行設置固定點位;
- 支持根據(jù)判斷維度設置完成比例并進行跳點;
- 支持根據(jù)不同業(yè)態(tài)進行跳點;
- 支持根據(jù)發(fā)放條件設置發(fā)放比例;
b)傭金方案個性化設置
- 支持各項目根據(jù)業(yè)務需求設置個性化傭金方案;
- 配置方案有效期間;
- 配置方案業(yè)績目標及權重設置;
- 配置方案基礎傭金規(guī)則;
- 配置方案特殊(促銷、退換房等)規(guī)則;
- 支持傭金方案在線審批。
2)核心業(yè)務流程——傭金計算及發(fā)放流程
① 傭金計算及發(fā)放包括: 傭金計算、傭金調(diào)整、傭金審批、傭金追溯、傭金發(fā)放。
傭金計算及發(fā)放流程如下所示:
② 傭金計算。 包括應發(fā)傭金計算和可發(fā)傭金計算。應發(fā)傭金總額的計算依據(jù)是傭金計算規(guī)則,可發(fā)傭金的依據(jù)是傭金發(fā)放規(guī)則。在執(zhí)行傭金方案時,會觸發(fā)傭金計算。
具體流程如下所示:
創(chuàng)建計算任務→執(zhí)行規(guī)則→計算預計傭金(根據(jù)規(guī)則結果類型及具體數(shù)值,以計算規(guī)則為單位計算各費項對應的傭金及明細。具體的實現(xiàn)跟費項、規(guī)則結果類型有關。)→計算應發(fā)傭金
③ 傭金補點。因業(yè)務需要對傭金點位調(diào)整后的預計傭金和應發(fā)傭金進行重新計算的過程。
④ 傭金計算調(diào)整。指在計算結果的基礎上,結合特殊的場景,對傭金計算結果進行調(diào)整。傭金計算調(diào)整,建立在傭金計算結果無誤的前提下。如果確認是計算結果有誤,應該拒絕審核傭金結果,重新進行生成操作。
⑤ 傭金審核。傭金審核包括包括傭金計算及調(diào)整審核、傭金發(fā)放審核。
⑥ 傭金追溯。對于某條傭金計算結果記錄,可進行追溯,查找出該傭金結果如何產(chǎn)生。
⑦ 傭金發(fā)放。根據(jù)生成的應發(fā)傭金,進行實發(fā)。
重點:
a)傭金計算按周期生成
- 支持根據(jù)傭金方案周期自動生成傭金計算結果、發(fā)放結果、傭金明細;
- 支持查詢代理公司應發(fā)、實發(fā)等傭金臺賬數(shù)據(jù);
- 支持查詢置業(yè)顧問應發(fā)、實發(fā)等傭金臺賬數(shù)據(jù);
- 支持以房源為維度查詢每一套房子所產(chǎn)生傭金比例金額;
- 支持特殊規(guī)則下的傭金調(diào)整計算、發(fā)放。
三、總結
以結傭?qū)ο鬄橹黧w,整合企業(yè)內(nèi)外部各系統(tǒng)數(shù)據(jù),圍繞交易數(shù)據(jù)打造線上結傭平臺,實現(xiàn)傭金規(guī)則與業(yè)務關聯(lián)、傭金與流程、財務、人資等系統(tǒng)打通,通過線上自動計算及生成傭金,有效提高銷售人員督促客戶按時履約的積極性,倒逼案場營銷規(guī)范管理,同時減少線下繁雜的復核流程,提高結傭效率,實現(xiàn)全線上快速結傭的閉環(huán)管理。
本文僅僅對傭金管理系統(tǒng)的整體框架結構做了一個總結,供初次接觸傭金管理系統(tǒng)的小伙伴們參考。
本文由 @星野二姐 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載
題圖來自Unsplash,基于CC0協(xié)議
該文觀點僅代表作者本人,人人都是產(chǎn)品經(jīng)理平臺僅提供信息存儲空間服務。
版權聲明:本文內(nèi)容由互聯(lián)網(wǎng)用戶自發(fā)貢獻,該文觀點僅代表作者本人。本站僅提供信息存儲空間服務,不擁有所有權,不承擔相關法律責任。如發(fā)現(xiàn)本站有涉嫌抄襲侵權/違法違規(guī)的內(nèi)容, 請發(fā)送郵件至 舉報,一經(jīng)查實,本站將立刻刪除。