不要構建，不要集成 - CRM 集成指南

已發表: 2022-03-11

假設您正在為一家在所有行業銷售機器人的初創公司工作。您接受來自各種客戶的訂單，運營團隊評估訂單並與第三方供應商合作，為您的客戶提供合適的機器人。

建立 MVP 壓力很大，但也很有趣。你的投資者很興奮，並用錢給你洗澡。下一階段開始。您需要更多地了解盈利能力，並且希望獲得需要更複雜發票的更大客戶。同時，你有一個非常複雜的產品路線圖，可以銷售利潤率更高的機器人。資源稀缺，但您仍然需要確保公司保持運轉。

正如小公司經常宣揚的那樣，專注於你擅長的事情是一個很好的經驗法則。但是，維持公司日常運營的所有領域又如何呢？您當然不想構建客戶關係管理 (CRM) 系統或會計系統。畢竟，有很多產品可以解決所有問題。但是這些系統將如何與您現有的訂單系統協同工作？

這是第三方集成派上用場的地方。所以，讓我們深入研究一下，看看我們是否可以避免一些常見的陷阱。

客戶關係管理整合

無論您是進行低接觸式銷售（內容營銷、社交媒體廣告或時事通訊）還是高接觸式銷售（電話推銷、參加會議或通過電話跟進現有客戶），CRM 系統都可以為您提供很多了解您在現有客戶方面的表現以及您在說服新客戶方面的成功程度。

通常，CRM 系統的選擇主要由銷售和營銷部門決定。一般來說，這沒有什麼問題。畢竟，這些人最了解如何增加收入，並且需要最好的支持。但是，如果不能與您的機器人訂購系統一起正常工作，即使是最好的軟件也一文不值。

在決策中包括您的技術部門

無論是 CTO 還是專門的工程師，從一開始就讓他們參與進來。它們很可能讓您更深入地了解這兩個系統將來如何協同工作。

對工程師說一句話：對第三方解決方案保持開放的態度。很容易忽略這些，因為它們的 API 不是最好的，或者它們的 UI 很醜。但是，圍繞現有系統找到優雅的解決方案可能會非常有益。

然而，在做出決定之前，有幾個話題可以討論。諸如“我們需要這個嗎？”之類的一般主題需要解決。但是，已經了解範圍是什麼也是一個好主意。是否需要雙向同步，還是第三方系統只會遵循訂單系統？一旦範圍超出了範圍，還需要就實現細節進行技術討論，例如 webhook 或 API 限制的評估。

您是否需要自定義集成？

在集成方面，已經有現有的平台承諾解決您可能遇到的一些問題也就不足為奇了。目前，Zapier 和 IFTTT 是最有前途的。

根據您要解決的問題，您的機器人訂單系統甚至可能不參與集成。假設您正在使用 Salesforce 或 HubSpot 等 CRM 系統管理您的時事通訊訂閱者，並且只想通過 Mailchimp 等電子郵件服務提供商以更方便的方式與他們聯繫，Zapier 擁有大量現有的集成來幫助您。從這一點來看，選擇具有 Zapier 連接器的提供商是一個很好的前進方向。

即使涉及到集成自定義數據（訂購的機器人及其價格），Zapier Webhooks 也可以充當您集成的中間人。

另一方面，如果您已經在向第三方發送數據，為什麼不直接將其發送到 CRM 系統呢？您要同步的數據越多，直接集成就越有用。

這讓我想到了下一點。

您需要雙向同步嗎？

通常，集成從一個簡單的要求開始，例如我們可以讓所有客戶進入我們的 CRM 系統嗎？ ，通常與單個機器人訂單的值相結合，從而更容易使用客戶端細分工具。

但是，遲早，人們可能會想要使用 CRM 套件通常提供的聯繫人管理工具。其中包括重複數據刪除、使用社交媒體數據修改聯繫人詳細信息、規範送貨地址或只是刪除舊聯繫人等功能。

更改 CRM 系統中的聯繫人很可能意味著您需要更改另一個系統中的聯繫人詳細信息，即，更改需要雙向進行。

實現這一目標的工作遠遠超出了簡單的單向同步，因此這是考慮如何戰略性地使用新系統的絕佳點。

您將如何收到來自 CRM 的更改通知？

如果您決定進行雙向同步，還有一個後續問題：您如何知道 CRM 方面發生了變化？

大多數係統提供商都有這方面的工具，但最好的即時更改工具是 webhook——本質上是一個 HTTP 通知系統，可以配置為讓您了解相關更改（對於某些系統，甚至逐個字段） .

如果系統不提供 webhook，至少檢查您是否可以獲得最近更新的所有實體的列表。這樣，您不必通過所有聯繫人和交易來更新您自己的數據。但請記住，您需要定期輪詢系統。

在這種情況下，您的訂單系統仍將通過 CRM 系統上的 API 調用來更改和創建數據。但是 CRM 系統的所有更改都將在定義的時間間隔內進行輪詢。

值得注意的是，更新將被限制在這個間隔內，並可能導致臨時數據不一致。例如，當您每天只從 CRM 系統同步一次到訂單系統時，您在訂單系統中查看的數據可能長達 24 小時。

根據系統提供的功能，集成任務的複雜性和實施時間會有所不同。確保提前檢查系統提供的內容，並仔細檢查您打算購買的計劃。例如，一些 CRM 系統在高薪層提供 webhook。

此處的一個示例是 HubSpot 的 CRM，它通常提供 webhook，但 webhook 功能僅在其 Enterprise 包中可用。會計工具 Zoho Books 將在其最低層提供五個自動化工作流程（包括 webhook）。

您的數據狀況良好嗎？

在外部系統中創建數據集時，最好了解數據在您自己的系統中的樣子。幸運的是，沒有太多不同的方式來呈現聯繫人和交易，但總是會引起麻煩的一個字段是電子郵件字段。

不同的系統對什麼是有效的電子郵件地址有不同的想法，這裡有一個劇透警告——您的客戶可能向您提供了各種無效的電子郵件地址。許多 CRM 系統會拒絕使用無效電子郵件地址創建聯繫人（當然，CRM 提供商會定義什麼是有效的，什麼是無效的）。

提示：如果可能，僅將確認的電子郵件地址同步到您的 CRM。 從長遠來看，這將為您節省很多痛苦。

API 限制

最後，API 限制是需要儘早解決的問題。

假設有一個 API（這基本上是任何集成的必備），看看 API 的局限性是有益的。大多數初創公司可以應對大多數 CRM 系統的基本 API 限制。例如，HubSpot 每 24 小時提供 250,000 次 API 調用，即使在其免費套餐中也是如此。另一方面，它還將調用限制為每秒 10 次（如果使用 OAuth，則為 100 次）。市場領導者 Salesforce 每 24 小時只允許 100,000 個，但提供購買更多。

大多數情況下，您很容易陷入這些限制，但需要考慮一件事：您的初始運行情況如何？一開始，您將向您的 CRM 推送大量聯繫人和交易（如果有問題，可能會多次推送）。因此，您可能會達到每日 API 限制。

為了緩解這種情況，您可以使用小型數據集進行測試，並在整個實施過程中緩慢增加數量以保持在 API 的限制範圍內。對於初始遷移，請計劃好幾天或一個週末。或者，聯繫提供商並讓他們知道您的意圖。當您處於評估階段（並且尚未為系統付費）時，他們可能願意稍微增加您的 API 限額。

客戶關係管理實施

假設你們都同意。您選擇了一款出色的 CRM 工具，工程師們相信它可以很容易地集成。您決定將其範圍限定為僅推送客戶數據並接受機器人訂單。因此，不需要雙向同步，地址更改只會在您自己的訂單系統中處理。

在實施階段仍有一些最佳實踐需要遵循。

在測試環境中嘗試一切

在大多數情況下，只有在您的集成完成並準備好使用後，才會使用 CRM 系統。對於這個用例，在開發過程中只使用生產系統似乎很有吸引力。畢竟，沒有您可能影響的生產數據。開發完成後，您只需刪除您創建的所有測試數據，運行初始遷移，並將您的訂單系統指向此環境。

這種方法有幾個問題：

你只是在路上踢罐子。 即使您的上線順利進行，遲早也會有功能請求來更改您的部分集成。鑑於功能請求足夠大，您可能需要另一個測試階段。在這一點上，一個單獨的測試系統是不可避免的；否則，您最終可能會弄亂生產數據。那麼，為什麼要等到您被要求實現第一個功能時才進行設置呢？
你最終會得到一個混亂的配置。 您的 CRM 系統很可能需要某種配置來滿足您的訂單系統的需求。狀態名稱可能需要調整，通常需要創建自定義字段等等。由於大多數開發人員需要習慣 CRM 系統，因此將添加一個長期不需要的配置。實際上，這種未使用的配置不會在以後刪除，甚至可能永遠保留在您的 CRM 中。通過強制將配置從測試系統複製到生產系統的額外步驟，您很可能最終會在生產系統上獲得更精簡的配置。

應該注意的是，如果您忘記將配置從測試複製到生產系統，這也會對您不利，並且最終會出現生產錯誤。

雖然有一些 CRM 系統可以幫助您比較和復製配置項，但一般來說，寫下您的配置以免忘記關鍵項目會很有用。大多數 CRM 為其配置提供 API，因此可以自動執行此步驟。
污染生產數據的風險更高。 想像一下，兩個開發人員正在進行集成。您已經擁有機器人訂單系統的暫存系統。此登台也與您的 CRM 相關聯。集成交付後，您需要記住斷開所有三個系統的連接，否則，您最終可能會在（現在）生產 CRM 上創建測試數據。

從一開始就針對測試系統進行開發可以避免所有這些問題。製作只在最後介紹，就在一切上線之前。通過這種方式，您最終得到了一個乾淨的配置，不會冒忘記斷開本地系統連接的風險，並且在實施新功能時要注意。

定義匹配實體的 ID

現在，讓我們開始編寫實際的集成代碼。讓我們以將聯繫人同步到 CRM 系統為例。據推測，您將需要創建新聯繫人並更新現有聯繫人。為了區分創建和更新，您需要鏈接這兩個實體。這樣，您可以檢查系統中的聯繫人是否存在於外部系統上。

雖然只使用電子郵件地址似乎很有吸引力（畢竟，它是聯繫人記錄的通用標識符），但有一個更通用的解決方案 - 對於每條記錄，您同步到外部系統保留和您自己數據庫中的 ID。

因此，使用名為crm_id或external_id的列修改您的聯繫人表。這種方法有幾個優點：

因為它是一個 ID，所以它不會改變（與電子郵件地址或電話號碼不同）。
無需先調用 API 即可查看是否需要創建或更新實體（如果外部 id 字段為空，則可以假設聯繫人不存在）。

前：

顧客
大整數	ID
細繩	姓名
細繩	電子郵件

後：

顧客
大整數	ID
細繩	姓名
細繩	電子郵件
細繩	hubspot_id

例如，假設您是一名 Ruby on Rails 開發人員，正在開發一個需要將現有客戶和新客戶同步到 HubSpot 的應用程序。

一個簡化的代碼示例可能如下所示：

 class HubspotSync def sync(customer) hubspot_return = if customer.hubspot_id.present? update(customer, customer.hubspot_id) else create(customer) end customer.update(hubspot_id: hubspot_return['companyId']) end private def create(customer) response = HTTParpty.post("https://api.hubapi.com/companies/v2/companies", map(company)) handle_response(response) end def update(customer, hubspot_id) response = HTTParpty.put("https://api.hubapi.com/companies/v2/companies/#{hubspot_id}", map(company)) handle_response(response) end def handle_response(response) raise RuntimeError, "Unexpected Status code: #{response.code}" if response.code >= 500 JSON.parse(response.body) end def map(company) # mapping code goes here { properties: [ name: 'name', value: company.name ] } end end

請注意我們如何利用保存從 HubSpot 返回的companyId 。它不僅可以幫助我們確定是否要在 HubSpot 上更新或創建公司，而且我們還可以在數據庫表中看到哪些實體已經同步到 HubSpot，哪些實體仍然缺失。

當涉及到映射字段時，去自由式

我見過一些項目，在這些項目實施之前，先創建一個巨大的 Excel 電子表格，定義哪些列在 CRM 系統中的位置，並附有如何轉換數據的註釋。

實際上，只有幾種表示聯繫人和交易的方法。因此，與其花大量時間思考您究竟想如何映射，何不從實驗開始呢？給開發人員一些空間來弄清楚映射，但也要保持聯繫，以便儘早提出問題。

至少對於一般的聯繫人字段（姓名、電子郵件地址、電話號碼、地址），映射會非常簡單，而且轉換通常是微不足道的。

當涉及到交易的狀態映射時，多一點溝通會很有幫助（有時，第一個狀態稱為open ，有時是new ，有時狀態模型不是 100% 匹配，因此您必須將狀態組合在一起）。與其想出完美的解決方案，不如查看您當前的數據，看看它如何最適合 CRM 的數據模型。畢竟，你是一家敏捷公司，對吧？

在上面的示例中，您可以看到將我們的 Rails 模型轉換為 HubSpot 可以理解的常規哈希的 map 方法。對於這個特定的用例，唯一同步的項目是名稱。對於更高級的用法，您可能希望包含更多字段，但為了獲得更好的結果，請從有根據的猜測開始，並經常與業務方溝通以獲取詳細信息。

考慮重試

讓我們深入到技術層面：實現系統和 CRM 之間的實際同步。幾乎可以肯定的是，集成將通過 HTTP 連接進行。大多數係統都提供 HTTP API，所有編程語言都可以讓您非常輕鬆地進行 HTTP 調用。

不幸的是，無論您在 CRM 系統上花多少錢，最終都無法使用。這將在某個時候發生，您對此無能為力。因此，您不妨在開發集成時考慮到這一點。

這在實踐中意味著——無論何時調用 API，確保在出現問題時重試調用（來自另一端的 500 狀態代碼）。實現重試通常由您選擇的語言的第三方庫提供。

除了重試之外，您可能還需要考慮記錄到底發生了什麼。收到有關在第一次重試中已解決的錯誤的通知可能會令人沮喪。

因此，與其用已解決的問題向您的錯誤通道發送垃圾郵件，不如記錄所有帶有重試次數的標註，以了解系統的可靠性——您剛剛花了很多錢購買的系統。

如果我們以我們創建的類為例，並且我們停留在 Ruby on Rails 的上下文中，我們可以簡單地將調用包裝在ActiveJob中，並且相當肯定調用最終會成功。如果出現意外狀態代碼， handle_response方法將引發錯誤，並且ActiveJob將嘗試使用指數退避重試。對於更高級的解決方案，您還應該考慮 4xx 狀態代碼，以便防止重試並引發錯誤消息。

 class HubspotSyncJob < ApplicationJob def perform(customer) HubspotSync.new.sync(customer) end End

確保系統被實際使用

好的，假設您已全部發貨。你為你的工作感到非常自豪，系統上線了。怎麼辦？這僅僅是個開始。因為無論您進行多少測試，總會有錯誤和請求的更改。

問題是，除非您實際使用您的系統，否則您不會知道這些。發生這種情況的原因有很多——銷售部門目前太忙而無法開始使用它，戰略改變了，甚至新系統已經在評估中。

因此，為了避免長期的潛在問題，請確保您已經消除了阻礙系統生產使用的所有障礙。經常在團隊之間進行溝通，以使新需求保持一致。如果您發現該系統不適合您，請關閉集成。這聽起來很刺耳，可能會讓人感到非常沮喪，但它比總是必須修復數據不一致問題和處理變通方法更令人沮喪。

包起來

歸根結底，集成項目是一個地獄項目，有很多事情可能會出錯。由於多種原因，它在工程師中不是很受歡迎，但看到實施對坐在你旁邊的人的生產力產生積極影響可能會很有意義。

因此，對於工程師來說——嘗試通過提出具體問題來了解外部系統（如 CRM 或發票系統）的需求，例如：該產品將如何讓您的生活更輕鬆？ 你考慮過競爭對手嗎？ 為什麼他們不工作？

對於其他所有相關人員 - 儘早讓工程師加入，當他們指出紅線時信任他們，並且當您看到集成的實施將使其變得更加困難時，不要選擇便宜的計劃長跑。