구축하지 말고 통합하십시오 – CRM 통합 가이드

모든 산업 분야에서 로봇을 판매하는 스타트업에서 일하고 있다고 가정해 보겠습니다. 다양한 고객으로부터 주문을 받으면 운영 팀이 주문을 평가하고 제3자 제공업체와 협력하여 고객에게 적합한 로봇을 제공합니다.

MVP를 구축하는 것은 스트레스가 많았지만 동시에 재미있었습니다. 당신의 투자자들은 흥분하며 당신에게 돈을 쏟아 붓습니다. 다음 단계가 시작됩니다. 수익성에 대한 더 많은 가시성이 필요하고 더 정교한 송장 발행이 필요한 더 큰 고객을 확보하려고 합니다. 동시에 고수익 로봇의 판매를 가능하게 하는 매우 정교한 제품 로드맵이 있습니다. 자원은 부족하지만 여전히 회사를 계속 운영해야 합니다.

소규모 회사에 대해 자주 설교하듯이, 자신이 잘하는 것에 집중하는 것은 경험의 법칙입니다. 그러나 회사의 일상적인 운영을 유지하는 모든 영역은 어떻습니까? 고객 관계 관리(CRM) 시스템이나 회계 시스템을 구축하고 싶지는 않을 것입니다. 결국, 모든 문제를 해결하는 제품이 많이 있습니다. 그러나 이러한 시스템이 기존 주문 시스템과 함께 어떻게 작동합니까?

이때 타사 통합이 유용합니다. 따라서 몇 가지 일반적인 함정을 피할 수 있는지 살펴보겠습니다.

CRM 통합

로우 터치 판매(콘텐츠 마케팅, 소셜 미디어 광고 또는 뉴스레터) 또는 하이 터치 판매(콜드 콜, 컨퍼런스 참석 또는 전화를 통한 기존 고객 후속 조치)를 하든 CRM 시스템은 많은 것을 제공할 수 있습니다. 기존 고객을 어떻게 처리하고 있고 새로운 고객을 설득하는 데 성공했는지에 대한 가시성.

종종 CRM 시스템의 선택은 대부분 영업 및 마케팅 부서에 맡겨집니다. 일반적으로 문제가 없습니다. 결국 이 사람들은 수익을 늘리는 방법을 가장 잘 알고 있으며 사용 가능한 최상의 지원이 필요합니다. 그러나 최고의 소프트웨어라도 로봇 주문 시스템과 제대로 작동하지 않으면 아무 소용이 없습니다.

결정에 기술 부서 포함

CTO이든 전담 엔지니어이든 관계없이 처음부터 루프에 유지하십시오. 그들은 미래에 두 시스템이 함께 작동하는 방식에 대한 더 많은 통찰력을 제공할 가능성이 매우 큽니다.

엔지니어를 위한 한마디: 타사 솔루션에 대해 열린 마음을 가지십시오. API가 최고가 아니거나 UI가 보기 흉하기 때문에 무시하기 쉽습니다. 그러나 기존 시스템에서 우아한 솔루션을 찾는 것은 매우 보람 있는 일입니다.

그럼에도 불구하고 결정을 내리기 전에 이야기하면 유익할 수 있는 몇 가지 주제가 있습니다. "이것이 전혀 필요합니까?" 와 같은 일반적인 주제 해결해야 합니다. 그러나 범위가 무엇인지 이미 알고 있는 것도 좋은 생각입니다. 양방향 동기화가 필요한가요? 아니면 타사 시스템이 주문 시스템을 따를까요? 범위를 벗어나면 웹훅 또는 API 제한 평가와 같은 구현 세부 사항에 대한 기술적인 논의도 필요합니다.

맞춤형 통합이 필요하십니까?

통합과 관련하여 직면할 가능성이 있는 일부 문제를 해결할 것을 약속하는 기존 플랫폼이 이미 있다는 것은 놀라운 일이 아닙니다. 현재 Zapier와 IFTTT가 가장 유망합니다.

해결하려는 문제에 따라 로봇 주문 시스템이 통합에 관여하지 않을 수도 있습니다. Salesforce 또는 HubSpot과 같은 CRM 시스템을 사용하여 뉴스레터 구독자를 관리하고 있으며 Mailchimp와 같은 이메일 서비스 제공업체를 통해 더 편리한 방법으로 연락하기를 원한다고 가정해 보겠습니다. Zapier에는 이를 도와줄 수많은 기존 통합 기능이 있습니다. 이 시점에서 Zapier 커넥터가 있는 공급자를 선택하는 것이 좋은 방법입니다.

맞춤형 데이터(주문한 로봇 및 가격)를 통합하는 경우에도 Zapier Webhooks는 통합을 위한 중개자 역할을 할 수 있습니다.

반면에 이미 데이터를 제3자에게 보내고 있다면 CRM 시스템으로 직접 보내지 않겠습니까? 동기화하려는 데이터가 많을수록 직접 통합이 더 유용합니다.

이것은 나를 다음 요점으로 안내합니다.

양방향 동기화가 필요하십니까?

일반적으로 통합은 모든 고객을 CRM 시스템으로 가져올 수 있습니까? 와 같은 간단한 요구 사항으로 시작됩니다. , 일반적으로 개별 로봇 주문의 값과 결합되어 클라이언트 세분화 도구를 더 쉽게 활용할 수 있습니다.

그러나 조만간 사람들은 CRM 제품군이 일반적으로 제공하는 연락처 관리 도구를 사용하고 싶어할 것입니다. 여기에는 중복 제거, 소셜 미디어 데이터로 연락처 세부 정보 수정, 배송 주소 정상화 또는 단순히 이전 연락처 삭제와 같은 기능이 포함됩니다.

CRM 시스템에서 연락처를 변경하면 다른 시스템에서 연락처 세부 정보를 변경해야 할 가능성이 높습니다. 즉, 변경 사항은 양방향으로 진행되어야 합니다.

이를 위한 구현 노력은 단순한 단방향 동기화를 훨씬 뛰어넘기 때문에 새로운 시스템을 전략적으로 어떻게 사용하고 싶은지 생각해 볼 수 있는 좋은 포인트입니다.

CRM의 변경 사항을 어떻게 통지받습니까?

양방향 동기화를 사용하기로 결정한 경우 후속 질문 이 있습니다. CRM 측에서 변경된 사항을 어떻게 알 수 있습니까?

대부분의 시스템 제공업체에는 이를 위한 도구가 있지만 즉각적인 변경을 위한 가장 좋은 도구는 웹훅입니다. 본질적으로 관련 변경 사항을 알리도록 구성할 수 있는 HTTP 알림 시스템입니다(일부 시스템의 경우 필드별로). .

시스템에서 웹훅을 제공하지 않는 경우 최소한 최근에 업데이트된 모든 엔터티의 목록을 얻을 수 있는지 확인하십시오. 이렇게 하면 자신의 데이터를 업데이트하기 위해 모든 연락처와 거래를 거칠 필요가 없습니다. 그러나 정기적으로 시스템을 폴링해야 함을 명심하십시오.

이 경우 주문 시스템은 여전히 ​​변경되고 CRM 시스템의 API 호출을 통해 데이터를 생성합니다. 그러나 CRM 시스템의 모든 변경 사항은 정의된 간격으로 폴링됩니다.

주목할 가치가 있는 것은 업데이트가 이 간격으로 제한되고 일시적인 데이터 불일치가 발생할 수 있다는 것입니다. 예를 들어 CRM 시스템에서 주문 시스템으로 하루에 한 번만 동기화하는 경우 주문 시스템에서 보고 있는 데이터는 최대 24시간이 될 수 있습니다.

시스템이 제공하는 기능에 따라 통합 작업의 복잡성과 구현 시간이 달라질 수 있습니다. 미리 시스템이 제공하는 것을 확인하고 구매하려는 계획을 다시 확인하십시오. 예를 들어, 일부 CRM 시스템은 더 높은 유료 계층에서 웹훅을 제공합니다.

예를 들어 HubSpot의 CRM은 일반적으로 Webhook을 제공하지만 Webhook 기능은 Enterprise 패키지에서만 사용할 수 있습니다. 회계 도구 Zoho Books는 가장 낮은 계층에서 5개의 자동화된 워크플로(웹훅 포함)를 제공합니다.

귀하의 데이터는 양호한 상태입니까?

외부 시스템에서 데이터 세트를 생성할 때 데이터가 자신의 시스템에서 어떻게 보이는지 아는 것이 좋습니다. 운 좋게도 연락처와 거래를 표시하는 다른 방법이 많지는 않지만 항상 문제를 일으키는 필드 중 하나는 이메일 필드입니다.

시스템마다 유효한 이메일 주소가 무엇인지에 대한 아이디어가 다르며 여기에 스포일러 경고가 있습니다. 고객이 모든 종류의 잘못된 이메일 주소를 제공했을 수 있습니다. 많은 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 시스템은 통합이 완료되고 사용할 준비가 된 후에만 사용됩니다. 이 사용 사례의 경우 개발 중에 프로덕션 시스템을 사용하는 것이 매력적으로 보일 수 있습니다. 결국 영향을 줄 수 있는 프로덕션 데이터는 없습니다. 개발이 완료되면 생성한 모든 테스트 데이터를 제거하고 초기 마이그레이션을 실행하고 주문 시스템이 이 환경을 가리키도록 합니다.

이 접근 방식에는 몇 가지 문제가 있습니다.

1. 당신은 길을 따라 캔을 걷어차고 있습니다. 라이브가 원활하게 진행되더라도 조만간 통합의 일부를 변경하라는 기능 요청이 있을 것입니다. 기능 요청이 충분히 크다면 다른 테스트 단계가 필요할 것입니다. 이 시점에서 별도의 테스트 시스템은 불가피합니다. 그렇지 않으면 프로덕션 데이터가 엉망이 될 수 있습니다. 그렇다면 첫 번째 기능을 구현하라는 요청을 받을 때까지 설정을 기다리는 이유는 무엇입니까?

2. 지저분한 구성으로 끝납니다. CRM 시스템에는 주문 시스템의 요구 사항에 맞는 구성이 필요할 가능성이 큽니다. 상태 이름을 조정해야 할 수도 있고 일반적으로 사용자 정의 필드를 생성해야 하는 등의 작업이 필요할 수 있습니다. 대부분의 개발자는 CRM 시스템에 익숙해져야 하므로 장기적으로 필요하지 않은 구성이 추가됩니다. 실제로 이 사용되지 않는 구성은 나중에 제거되지 않으며 CRM에 영원히 남을 수도 있습니다. 테스트 시스템에서 프로덕션으로 구성을 복제하는 추가 단계를 수행하면 프로덕션 시스템에서 더 얇은 구성으로 끝날 가능성이 큽니다.
   
   테스트에서 프로덕션 시스템으로 구성을 복사하는 것을 잊어버린 경우에도 이것이 불리하게 작용할 수 있으며 결국 프로덕션 오류가 발생한다는 점에 유의해야 합니다.
   
   구성 항목을 비교하고 복사하는 데 도움이 되는 몇 가지 CRM 시스템이 있지만 일반적으로 중요한 항목을 잊지 않도록 구성을 기록해 두는 것이 좋습니다. 대부분의 CRM은 구성에 API를 제공하므로 이 단계를 자동화할 수 있습니다.

   

3. 프로덕션 데이터를 오염시킬 위험이 더 높습니다. 통합 작업을 하는 두 명의 개발자를 잠시 상상해 보십시오. 로봇 주문 시스템의 스테이징 시스템이 이미 있습니다. 이 스테이징은 CRM에도 연결됩니다. 통합이 제공되면 세 시스템 모두의 연결을 끊는 것을 기억해야 합니다. 그렇지 않으면 (현재) 프로덕션 CRM에서 테스트 데이터를 생성하게 될 수 있습니다.

이러한 모든 문제는 처음부터 테스트 시스템에 대해 개발함으로써 피할 수 있습니다. 프로덕션은 모든 것이 실행되기 직전인 맨 마지막에만 소개됩니다. 이렇게 하면 깔끔한 구성으로 끝낼 수 있고 로컬 시스템 연결을 끊는 것을 잊어버릴 위험이 없으며 새로운 기능을 구현할 때 미리 대비할 수 있습니다.

일치 항목에 대한 ID 정의

이제 실제 통합 코드 작성을 시작하겠습니다. 연락처를 CRM 시스템에 동기화하는 예를 살펴보겠습니다. 아마도 새 연락처를 만들고 기존 연락처를 업데이트해야 할 것입니다. 생성과 업데이트를 구분하려면 두 엔터티를 연결해야 합니다. 이렇게 하면 시스템의 연락처가 외부 시스템에 있는지 확인할 수 있습니다.

이메일 주소(결국 연락처 레코드의 공통 식별자임)를 사용하는 것이 매력적으로 보이지만 모든 레코드에 대해 외부 시스템 보류 및 자체 데이터베이스의 ID와 동기화하는 보다 일반적인 솔루션이 있습니다.

따라서 crm_id 또는 external_id 라는 열로 연락처 테이블을 수정하십시오. 이 접근 방식에는 몇 가지 장점이 있습니다.

• 아이디이기 때문에 (이메일 주소나 전화번호와 달리) 변경되지 않습니다.
• 먼저 API 호출을 수행하지 않고 엔터티를 생성하거나 업데이트해야 하는지 확인할 수 있습니다(외부 id 필드가 비어 있으면 연락처가 존재하지 않는다고 가정할 수 있음).

전에:

후에:

예를 들어, 기존 고객과 신규 고객을 HubSpot에 동기화해야 하는 애플리케이션에서 작업하는 Ruby on Rails 개발자라고 가정해 보겠습니다.

단순화된 코드 예제는 다음과 같습니다.

 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에서 이해하는 일반 해시로 변환하는 맵 메서드를 볼 수 있습니다. 이 특정 사용 사례의 경우 동기화된 항목은 이름뿐입니다. 고급 사용의 경우 더 많은 필드를 포함하고 싶을 수 있지만 좋은 결과를 얻으려면 충분한 추측으로 시작하고 세부 사항에 대해 비즈니스 측과 자주 의사 소통하십시오.

재시도 고려

좀 더 기술적인 수준으로 내려가 보겠습니다. 시스템과 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 또는 송장 발행 시스템과 같은 외부 시스템의 요구 사항을 이해하려고 노력하십시오. 이 제품이 당신의 삶을 어떻게 더 쉽게 만들어 줄까요? 경쟁자를 고려했는가? 왜 작동하지 않습니까?

관련된 다른 모든 사람들을 위해 - 가능한 한 빨리 엔지니어를 참여시키고, 빨간색 선을 지적할 때 엔지니어를 신뢰하고, 통합 구현이 프로젝트에서 훨씬 더 어려워진다는 것을 알 수 있을 때 저렴한 계획을 선택하지 마십시오. 장기적으로.