銷售昨天看過一條辦公室搬遷需求今天又在“新線索”里看到它。如果對方已經(jīng)暫停搬遷第二次出現(xiàn)帶來的只是一次重復閱讀如果需求范圍變了沿用昨天的溝通準備還可能問錯問題。星河卓越旗下意客AI根據(jù)業(yè)務描述尋找匹配需求將需求原文和相關依據(jù)積累到銷售線索庫供銷售繼續(xù)開發(fā)客戶。線索庫越積越多產(chǎn)品就越需要回答一個具體問題哪些材料可以復用哪些判斷必須重做本文結(jié)合意客AI的原文入庫與匹配實現(xiàn)拆開同一來源的重復、內(nèi)容變化和業(yè)務范圍變化。關鍵在于復用已經(jīng)取得的原文不把舊需求狀態(tài)當成今天的新機會。方法圖解同一頁面更新后本輪匹配不回退到更容易命中的舊版本。同一頁面為什么不能先做關鍵詞過濾例如一家企業(yè)IT服務商要找辦公室搬遷和網(wǎng)絡調(diào)整需求確認的搜索表達包含“辦公室 網(wǎng)絡”。同一頁面先后保存了兩份原文原文觀察保存的內(nèi)容與搜索條件的關系較早一次辦公室要搬到新樓層想找人調(diào)整網(wǎng)絡包含“辦公室”和“網(wǎng)絡”較晚一次搬遷暫緩暫不找服務商了不再包含這組搜索詞如果先篩出包含關鍵詞的版本再從篩選結(jié)果里取最新一條較晚的內(nèi)容會先被丟掉。系統(tǒng)最后選中較早的原文銷售看到的仍是“正在找人調(diào)整網(wǎng)絡”。意客AI的CandidatePoolMatchStore.match_task()把順序反過來先為每個來源選擇最新觀察再對這份原文做文本過濾。查詢中的順序可以從兩處看出來SELECTDISTINCTON(o.source_id)o.source_id,o.version_id,o.observation_id,o.observed_at,o.received_at,s.source_identity,v.content-- 原代碼此處拼接原文庫關聯(lián)與賬號條件ORDERBYo.source_id,o.observed_atDESC,o.received_atDESC,o.observation_idDESC這部分先生成latest集合外層查詢隨后才檢查關鍵詞、排除詞并限制本輪返回量。前面的例子因此不會回退到舊版本。這里的“最新”是庫中已保存的最新觀察排序依據(jù)是觀察時間、接收時間及觀察ID。它不表示系統(tǒng)已經(jīng)發(fā)現(xiàn)網(wǎng)頁上所有后續(xù)變化也不能替代采購有效期。原文今天再次讀到里面提到的項目仍可能是去年的。一份原文要分清來源、版本和觀察把一次頁面讀取直接存成一個新客戶線索庫很快就會膨脹。意客AI在candidate_ingestion.py中分別保存這些關系保存對象解決的問題來源source_id本次讀取是否來自已知的同一個來源內(nèi)容版本version_id保存的內(nèi)容是否出現(xiàn)了新的版本觀察observation_id這一次何時讀到材料、對應哪份內(nèi)容候選candidate_id在當前業(yè)務畫像與策略范圍內(nèi)銷售處理的是哪條候選入庫時代碼先查來源身份再查該來源的內(nèi)容版本存在的來源與版本繼續(xù)使用原ID。一次新的觀察有自己的記錄不必因此創(chuàng)建一個新來源。這對銷售線索統(tǒng)計很關鍵同一頁面讀了三次不應當直接被計成三個新客戶原文改了服務地點也應保留變化而不是覆蓋過去的材料后讓同事失去比較依據(jù)。新研究可以復用候選內(nèi)容變化則推進版本候選的復用還有業(yè)務范圍。匹配代碼按賬號、業(yè)務畫像版本、策略版本與來源一起查找候選實際使用的范圍是scope(tenant,claims.user_id,task[profile_version_id],task[strategy_version_id],original[source_id])因此同一來源在同一業(yè)務范圍內(nèi)再次命中時可以延續(xù)已有candidate_id。它仍是一條可追溯的候選本輪匹配有新的match_id用來記錄這次任務為什么帶回它。如果保存的原文版本變化代碼在合適的觀察順序下推進候選的revision并指向新版本。相同內(nèi)容版本則保留當前候選觀察綁定不為每次重復讀取都創(chuàng)建新候選。業(yè)務畫像或策略版本變了不能只沿用舊范圍里的適配結(jié)論。例如IT服務商從北京擴展到天津或者停止承接服務器運維原文與新業(yè)務的關系就需要重新判斷。材料值得保存不意味著以前的“適合我們”永遠有效。這一機制處理的是來源身份與業(yè)務范圍內(nèi)的復用。不同網(wǎng)站轉(zhuǎn)載了同一件事仍需要額外判斷它們是否指向同一需求不能把這里的來源去重解釋成跨平臺語義重復全部消失。查詢完成以后還要防一次并發(fā)變化還有一個不容易在正常演示里出現(xiàn)的問題匹配查詢?nèi)〉昧税姹続準備保存候選時采集端已經(jīng)收到同一來源的版本B。如果只相信第一次查詢結(jié)果本輪仍可能保存舊版本。match_task()會取得與入庫端一致的來源事務鎖在等待結(jié)束后再查一次最新觀察。核心判斷是cursor.execute(SELECT o.observation_id _POOL_FROM AND o.source_id%s ORDER BY o.observed_at DESC,o.received_at DESC, o.observation_id DESC LIMIT 1,(tenant,claims.user_id,original[source_id]))ifcursor.fetchone()!(original[observation_id],):continue最新觀察與第一次選擇不一致時這條舊選擇不繼續(xù)寫入本輪候選。此處選擇保守跳過不把等待鎖之前取得的內(nèi)容當作仍然最新。這比在界面里簡單提示“數(shù)據(jù)已更新”更靠前它約束的是本次匹配究竟依據(jù)哪份原文后續(xù)解釋和銷售閱讀才有一致的材料可以依賴。銷售接手時仍要讀最新原話版本篩選修正了順序問題關鍵詞篩選仍有自己的邊界。假如最新原文寫著“辦公室網(wǎng)絡已解決不再找人”它還包含兩個關鍵詞。沒有相應排除條件時字符串匹配仍可能命中后續(xù)就需要根據(jù)最新原話繼續(xù)評估需求狀態(tài)。因此銷售接手一條線索時先看當前原文再看它與自己業(yè)務的關系。對仍在尋找服務商的搬遷需求可以準備布線安排、設備沿用和實施時間的問題原文已經(jīng)寫明暫停就不繼續(xù)使用昨天的開場草稿。意客AI線索庫承擔的是尋找和整理需求材料的工作讓銷售從具體問題開始開發(fā)客戶。原文復用減少已經(jīng)取得材料的重復整理版本與業(yè)務范圍保留判斷依據(jù)新的研究繼續(xù)尋找與這項業(yè)務有關的需求。銷售拿到的材料應該能解釋“為什么這一條值得繼續(xù)了解”而不是只展示又多了多少條記錄。關于按周期繼續(xù)尋找需求可接著閱讀AI獲客如何持續(xù)監(jiān)控銷售線索意客AI的周期任務設計。意客AI產(chǎn)品團隊北京星河卓越科技有限公司