構築しない、統合する–CRM統合のガイド

公開: 2022-03-11

あなたがすべての業界でロボットを販売するスタートアップで働いているとしましょう。さまざまなクライアントから注文を受け取り、運用チームが注文を評価し、サードパーティプロバイダーと協力して、クライアントに適切なロボットを提供します。

MVPの構築はストレスがたまりましたが、とても楽しかったです。あなたの投資家は興奮し、あなたにお金を浴びせます。次のフェーズが始まります。収益性についてより多くの可視性が必要であり、より洗練された請求書を必要とするより大きなクライアントを獲得したいと考えています。同時に、利益率の高いロボットの販売を可能にする非常に洗練された製品ロードマップがあります。リソースは不足していますが、それでも会社を運営し続けることを確認する必要があります。

中小企業でよく説かれているように、得意なことに焦点を当てることは大まかな経験則です。しかし、あなたの会社の日常業務を継続しているすべての分野についてはどうでしょうか？あなたは確かに顧客関係管理（CRM）システムや会計システムを構築したくありません。結局のところ、すべての問題を解決する製品はたくさんあります。しかし、これらのシステムは既存の注文システムとどのように連携しますか？

ここで、サードパーティの統合が役立ちます。それでは、飛び込んで、いくつかの一般的な落とし穴を回避できるかどうかを見てみましょう。

CRM統合

ロータッチ販売（コンテンツマーケティング、ソーシャルメディア広告、ニュースレター）でもハイタッチ販売（コールドコール、会議への参加、電話による既存のクライアントへのフォローアップ）でも、CRMシステムは多くのことを提供します。既存のクライアントでどのように行っているか、そして新しいクライアントを説得することにどれだけ成功しているかについての可視性。

多くの場合、CRMシステムの選択は、ほとんどの場合、営業およびマーケティング部門に任されています。一般的に、それは何も悪いことではありません。結局のところ、これらの人々は収益を増やす方法を最もよく知っており、利用可能な最高のサポートを必要としています。しかし、最高のソフトウェアでさえ、ロボット注文システムと適切に連携しなければ、何の価値もありません。

技術部門を決定に含める

CTOであろうと専任エンジニアであろうと、最初から彼らをループさせてください。これらは、2つのシステムが将来どのように連携するかについてより多くの洞察を与える可能性が非常に高いです。

そしてエンジニアへの一言：サードパーティのソリューションに対して心を開いてください。 APIが最適ではないか、UIが醜いため、これらを簡単に却下できます。ただし、既存のシステムの周りに洗練されたソリューションを見つけることは非常にやりがいがあります。

それでも、決定を下す前に話し合うことが有益なトピックがいくつかあります。 「これは必要ですか？」などの一般的なトピック対処する必要があります。しかし、スコープが何であるかをすでに知っていることも良い考えです。双方向の同期が必要ですか、それともサードパーティのシステムは注文システムに従うだけですか？スコープが邪魔にならないようになったら、WebhookやAPI制限の評価など、実装の詳細について技術的な議論を行う必要もあります。

カスタム統合が必要ですか？

統合に関しては、遭遇する可能性のある問題のいくつかを解決することを約束する既存のプラットフォームがすでに存在していることは驚くべきことではありません。現在、ZapierとIFTTTが最も有望なものです。

解決しようとしている問題によっては、ロボット注文システムが統合に関与していない場合もあります。 SalesforceやHubSpotなどのCRMシステムを使用してニュースレターの購読者を管理していて、Mailchimpなどの電子メールサービスプロバイダーを介してニュースレターの購読者に連絡するためのより便利な方法が必要な場合、Zapierにはそれを支援する既存の統合が多数あります。この時点から、Zapierコネクタを備えたプロバイダーを選択することは良い方法です。

また、カスタムデータ（注文したロボットとその価格）の統合に関しても、ZapierWebhookは統合の仲介者として機能できます。

一方、すでにサードパーティにデータを送信している場合は、CRMシステムに直接送信してみませんか？同期するデータが多いほど、直接統合がより便利になります。

それは私の次のポイントに私をもたらします。

双方向同期が必要ですか？

通常、統合は、すべてのクライアントをCRMシステムに組み込むことができるかなどの単純な要件から始まります。、通常は個々のロボット注文の値と組み合わせて、クライアントセグメンテーションツールの利用を容易にします。

ただし、遅かれ早かれ、CRMスイートが通常提供する連絡先管理ツールを利用したくなる場合があります。これには、重複排除、ソーシャルメディアデータを使用した連絡先の詳細の修正、配送先住所の正規化、または単に古い連絡先の削除などの機能が含まれます。

CRMシステムで連絡先を変更すると、別のシステムで連絡先の詳細を変更する必要があります。つまり、変更は双方向で行う必要があります。

このための実装作業は、単純な一方向の同期をはるかに超えているため、新しいシステムを戦略的にどのように使用するかを考えるのに最適なポイントです。

CRMからの変更はどのように通知されますか？

双方向の同期を行うことにした場合は、フォローアップの質問があります。CRM側で何かが変更されたことをどのように知っていますか？

ほとんどのシステムプロバイダーにはこのためのツールがありますが、即時変更に最適なのはWebhookです。基本的に、関連する変更について通知するように構成できるHTTP通知システムです（一部のシステムでは、フィールドごとに）。。

システムがWebhookを提供していない場合は、少なくとも、最近更新されたすべてのエンティティのリストを取得できるかどうかを確認してください。このように、あなたはあなた自身のデータを更新するためだけにすべての連絡先と取引を通過する必要はありません。ただし、定期的にシステムをポーリングする必要があることに注意してください。

この場合でも、注文システムは変更され、CRMシステムのAPI呼び出しを介してデータが作成されます。ただし、CRMシステムからのすべての変更は、定義された間隔でポーリングされます。

注目に値するのは、更新がこの間隔に制限され、一時的なデータの不整合につながる可能性があることです。たとえば、CRMシステムから注文システムに1日1回だけ同期する場合、注文システムで表示しているデータは最大24時間前のものになる可能性があります。

システムが提供する機能に応じて、統合タスクの複雑さと実装時間は異なります。事前にシステムが提供するものを確認し、購入する予定のプランを再確認してください。たとえば、一部のCRMシステムは、高額の階層でWebhookを提供します。

ここでの例は、HubSpotのCRMです。これは、一般にWebhookを提供しますが、Webhook機能はEnterpriseパッケージでのみ使用できます。会計ツールのZohoBooksは、最下位層に5つの自動ワークフロー（Webhookを含む）を提供します。

データは良好ですか？

外部システムでデータセットを作成する場合、自分のシステムでデータがどのように表示されるかを知っておくとよいでしょう。幸いなことに、連絡先や取引を提示する方法はそれほど多くありませんが、常に問題を引き起こすフィールドの1つはメールフィールドです。

システムが異なれば、有効な電子メールアドレスについての考え方も異なります。これがネタバレ警告です。クライアントから、あらゆる種類の無効な電子メールアドレスが提供された可能性があります。多くのCRMシステムは、無効な電子メールアドレスでの連絡先の作成を拒否します（もちろん、CRMプロバイダーは何が有効で何が無効かを定義します）。

ヒント：可能であれば、確認済みのメールアドレスのみをCRMに同期してください。 これにより、長期的には多くの苦痛を軽減できます。

APIの制限

最後に、APIの制限は、できるだけ早く対処する必要があるものです。

API（基本的に統合には必須）があると仮定すると、APIの制限を確認することは有益です。ほとんどのスタートアップは、ほとんどのCRMシステムの基本的なAPI制限に対処できます。例として、HubSpotは、無料枠でも24時間あたり250,000のAPI呼び出しを提供します。一方、呼び出しは1秒あたり10に制限されます（OAuthを使用する場合は100）。マーケットリーダーのSalesforceは、24時間ごとに100,000しか許可していませんが、さらに購入することを提案しています。

ほとんどの場合、これらの制限の範囲内に簡単に収まりますが、考慮すべきことが1つあります。最初の実行についてはどうでしょうか。最初は、多くの連絡先や取引をCRMにプッシュします（問題がある場合は複数回プッシュすることもあります）。その結果、1日あたりのAPI制限に達する可能性があります。

これを軽減するために、小さなデータセットでテストし、APIの制限内にとどまるように、実装全体で数をゆっくりと増やすことができます。最初の移行では、複数日または週末に計画を立てます。または、プロバイダーに連絡して、あなたの意図を知らせてください。あなたが評価段階にあるとき（そしてまだシステムにお金を払っていないとき）、彼らはあなたのAPI許容量を少し増やしても構わないと思っているかもしれません。

CRMの実装

あなたがすべて同意しているとしましょう。あなたは素晴らしいCRMツールを選びました、そしてエンジニアはそれがかなり簡単に統合されることができると確信しています。顧客データと受け入れられたロボットの注文のみをプッシュするようにスコープを設定することにしました。したがって、双方向の同期は必要なく、アドレスの変更は独自の注文システムでのみ処理されます。

実装フェーズで従うべきベストプラクティスがまだいくつかあります。

テスト環境ですべてを試してみてください

ほとんどの場合、CRMシステムは、統合が完了して使用できるようになった後でのみ使用されます。このユースケースでは、開発中に本番システムを使用するだけで魅力的に見えるかもしれません。結局のところ、影響を与える可能性のある本番データはありません。開発が完了したら、作成したすべてのテストデータを削除し、初期移行を実行して、注文システムにこの環境を指定するだけです。

このアプローチにはいくつかの問題があります。

あなたはただ缶を蹴っているだけです。 稼働がスムーズに進んだとしても、遅かれ早かれ、統合の一部を変更するための機能リクエストがあります。機能要求が十分に大きいことを考えると、おそらく別のテストフェーズが必要になります。この時点で、別のテストシステムは避けられません。そうしないと、本番データを台無しにしてしまう可能性があります。では、最初の機能を実装するように求められるまで、セットアップを待つのはなぜですか？
設定が乱雑になってしまいます。 CRMシステムには、注文システムのニーズに合わせて何らかの構成が必要になる可能性が非常に高くなります。ステータス名の調整、カスタムフィールドの作成などが必要になる場合があります。ほとんどの開発者はCRMシステムに慣れる必要があるため、長期的には必要のない構成が追加されます。実際には、この未使用の構成は後で削除されず、CRMに永久に残る可能性があります。テストシステムから本番システムに構成を複製する追加の手順を強制することにより、本番システムの構成がよりスリムになる可能性があります。

テストから本番システムに設定をコピーするのを忘れた場合にも、これが不利になる可能性があり、本番エラーが発生することに注意してください。

構成アイテムの比較とコピーに役立つCRMシステムがいくつかありますが、一般に、重要なアイテムを忘れないように構成を書き留めておくと便利です。ほとんどのCRMは構成にAPIを提供するため、このステップを自動化することができます。
本番データを汚染するリスクが高くなります。 統合に取り組んでいる2番目の2人の開発者を想像してみてください。ロボット注文システムのステージングシステムがすでにあります。このステージングは、CRMにも接続されています。統合が出荷されたら、3つのシステムすべてを切断することを忘れないでください。そうしないと、（現在の）本番CRMでテストデータを作成してしまう可能性があります。

これらの問題はすべて、最初からテストシステムに対して開発することで回避できます。プロダクションは、すべてが公開される直前の最後にのみ導入されます。このようにして、クリーンな構成になり、ローカルシステムの切断を忘れるリスクを冒さず、新しい機能を実装する際に注意を払うことができます。

エンティティを照合するためのIDを定義する

それでは、実際の統合コードを書き始めましょう。連絡先をCRMシステムに同期する例を見てみましょう。おそらく、新しい連絡先を作成し、既存の連絡先を更新する必要があります。作成と更新を区別するには、2つのエンティティをリンクする必要があります。これにより、システムの連絡先が外部システムに存在するかどうかを確認できます。

メールアドレスを使用するのは魅力的ですが（結局のところ、連絡先レコードの一般的な識別子です）、より一般的な解決策があります。すべてのレコードについて、独自のデータベースの外部システムホールドとIDに同期します。

したがって、 crm_idまたはexternal_idという列で連絡先テーブルを修正します。このアプローチにはいくつかの利点があります。

IDであるため、変更されません（メールアドレスや電話番号とは異なります）。
最初にAPI呼び出しを行わずにエンティティを作成または更新する必要があるかどうかを確認できます（外部IDフィールドが空の場合は、連絡先が存在しないと見なすことができます）。

前：

お客様
BigInt	id
ストリング	名前
ストリング	Eメール

後：

お客様
BigInt	id
ストリング	名前
ストリング	Eメール
ストリング	hubspot_id

たとえば、既存および新規の顧客をHubSpotに同期する必要があるアプリケーションに取り組んでいるRubyonRails開発者であるとします。

簡略化されたコード例は次のようになります。

 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に既に同期されているエンティティとまだ欠落しているエンティティを確認することもできます。

フィールドのマッピングに関しては、フリースタイルに移行してください

実装の前に、CRMシステムのどの列をどこに配置するかを定義する巨大なExcelスプレッドシートを作成し、データをどのように変換するかを注釈で示すプロジェクトを見てきました。

実際には、連絡先や取引を表す方法はいくつかあります。ですから、どの程度正確にマッピングしたいかを考えるのではなく、実験から始めてみませんか？開発者にマッピングを理解するためのスペースを与えるだけでなく、質問が早期に発生するように連絡を取り合ってください。

少なくとも一般的な連絡先フィールド（名前、電子メールアドレス、電話番号、住所）の場合、マッピングは非常に単純であり、変換は通常簡単です。

取引のステータスマッピングに関しては、もう少しコミュニケーションが役立ちます（最初のステータスはopenと呼ばれることもあれば、 newこともあります。また、ステータスモデルが100％一致しないこともあるため、ステータスをグループ化する必要があります。）。完璧なソリューションを考え出す代わりに、現在のデータを見て、それがCRMのデータモデルにどのように最適であるかを確認してください。結局のところ、あなたはアジャイル企業ですよね？

上記の例では、RailsモデルをHubSpotが理解できる通常のハッシュに変換するmapメソッドを見ることができます。この特定のユースケースでは、同期されるアイテムは名前だけです。より高度な使用法の場合は、おそらくより多くのフィールドを含める必要がありますが、優れた結果を得るには、知識に基づいた推測から始めて、詳細についてビジネス側と頻繁に連絡します。

再試行を検討する

より技術的なレベルに取り掛かりましょう。システムとCRM間の実際の同期を実装します。統合がHTTP接続を介して行われることはほぼ当然のことです。ほとんどのシステムはHTTPAPIを提供し、すべてのプログラミング言語でHTTP呼び出しを非常に簡単に行うことができます。

残念ながら、CRMシステムにいくらお金をかけても、最終的には到達できなくなります。これはある時点で発生し、それについてできることは何もありません。したがって、統合を開発するときに、これを考慮に入れることもできます。

これが実際に意味することは、APIを呼び出すときはいつでも、問題が発生した場合に呼び出しが再試行されることを確認してください（反対側からの500ステータスコード）。再試行の実装は、通常、選択した言語のサードパーティライブラリによって提供されるものです。

再試行するだけでなく、正確に何が起こったかをログに記録することを検討することをお勧めします。最初の再試行ですでに解決されているエラーに関する通知を受け取ることは、イライラする可能性があります。

したがって、解決された問題でエラーチャネルにスパムを送信する代わりに、再試行回数を含むすべてのコールアウトを記録して、システムの信頼性を把握します。これは、多額の費用を支払ったばかりのシステムです。

例として作成したクラスを取り上げ、Ruby on Railsのコンテキストにとどまる場合、呼び出しをActiveJobでラップするだけで、呼び出しが最終的に成功することをかなり確信できます。 handle_responseメソッドは、予期しないステータスコードの場合にエラーを発生させ、 ActiveJobは指数バックオフで再試行を試みます。より高度なソリューションの場合は、4xxステータスコードも検討して、再試行が防止され、代わりにエラーメッセージが表示されるようにする必要があります。

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

システムが実際に使用されていることを確認する

OK、すべてを出荷したとしましょう。あなたは自分の仕事に非常に誇りを持っており、システムは稼働します。それで？これは始まりにすぎない。どんなに多くのテストを行っていても、常にバグや要求された変更があります。

問題は、実際にシステムを使用しない限り、これらについて知ることができないということです。そして、これはさまざまな理由で発生します。営業部門は現在忙しすぎて使用を開始できない、戦略が変更されている、または新しいシステムでさえすでに評価されています。

したがって、長期的に潜在的な問題を回避するために、システムの実稼働での使用を妨げるすべての障害を排除したことを確認してください。チーム間で頻繁に通信して、新しい要件を調整します。また、システムが機能しないことがわかった場合は、統合をオフにしてください。耳障りで非常にイライラすることもありますが、データの不整合の問題を常に修正して回避策に対処するよりもイライラすることはありません。

まとめ

結局のところ、統合プロジェクトはプロジェクトの地獄であり、うまくいかないことがたくさんあります。さまざまな理由でエンジニアの間であまり人気がありませんが、実装が隣に座っている人々の生産性にプラスの影響を与えることを確認することはやりがいのあることです。

したがって、エンジニアの場合は、CRMや請求システムなどの外部システムのニーズを理解するために、次のような具体的な質問をしてみてください。この製品はどのようにあなたの生活を楽にしますか？ 競合他社を検討しましたか？ なぜ彼らは働かないのですか？

関係する他のすべての人にとっては、エンジニアをできるだけ早く受け入れ、赤い線を指摘するときにエンジニアを信頼し、統合の実装によって統合が非常に困難になることがわかった場合は、安価な計画を選択しないでください。ロングラン。