Не создавайте, интегрируйте — руководство по интеграции с CRM

Допустим, вы работаете в стартапе, который продает роботов во всех отраслях. Вы принимаете заказы от разных клиентов, а операционная группа оценивает заказы и работает со сторонними поставщиками, чтобы предоставить вашим клиентам только подходящего робота.

Создание MVP было напряженным, но и очень веселым. Ваши инвесторы взволнованы и осыпают вас деньгами. Начинается следующая фаза. Вам нужно больше информации о прибыльности, и вы хотите привлечь более крупных клиентов, которым требуется более сложное выставление счетов. В то же время у вас есть довольно сложная дорожная карта продукта, позволяющая продавать роботов с более высокой маржой. Ресурсов мало, но вам все равно нужно следить за тем, чтобы компания работала.

Как часто говорят небольшим компаниям, сосредоточьтесь на вещах, в которых вы хороши, — отличное эмпирическое правило. Но как насчет всех областей, обеспечивающих повседневную работу вашей компании? Вы, конечно, не хотите создавать систему управления взаимоотношениями с клиентами (CRM) или систему учета. В конце концов, есть много продуктов, которые решают все проблемы. Но как эти системы будут работать вместе с вашей существующей системой заказов?

Вот где сторонняя интеграция пригодится. Итак, давайте погрузимся и посмотрим, сможем ли мы избежать некоторых распространенных ошибок.

CRM-интеграция

Независимо от того, занимаетесь ли вы продажами с минимальным контактом (контент-маркетинг, реклама в социальных сетях или информационные бюллетени) или продажами с большим количеством контактов (холодные звонки, посещение конференций или общение с существующими клиентами по телефону), CRM-система может дать вам множество преимуществ. видимость того, как вы работаете с существующими клиентами и насколько успешно вы убеждаете новых клиентов.

Часто выбор CRM-системы в основном остается на усмотрение отдела продаж и маркетинга. В общем, ничего страшного в этом нет. В конце концов, эти люди лучше всех знают, как увеличить доход, и нуждаются в самой лучшей поддержке. Но даже самое лучшее программное обеспечение ничего не стоит, если оно не работает должным образом вместе с вашей системой заказа роботов.

Включите свой технический отдел в решение

Будь то технический директор или специальный инженер, держите их в курсе с самого начала. Скорее всего, они дадут вам больше информации о том, как две системы будут работать вместе в будущем.

И слово для инженеров: будьте открыты для сторонних решений. Их легко отклонить, потому что их API не самый лучший или их пользовательский интерфейс уродлив. Однако поиск элегантных решений для существующих систем может быть очень полезным.

Тем не менее, есть пара тем, о которых может быть полезно поговорить, прежде чем принимать решение. Общие темы вроде «А нужно ли нам это вообще?» необходимо обратиться. Но также неплохо иметь представление о масштабах. Есть ли необходимость в двусторонней синхронизации, или сторонняя система будет просто следовать системе заказов? После того, как область действия будет устранена, также необходимо провести техническое обсуждение деталей реализации, таких как веб-перехватчики или оценка ограничений API.

Нужна ли вам индивидуальная интеграция вообще?

Когда дело доходит до интеграции, неудивительно, что уже существуют существующие платформы, которые обещают решить некоторые проблемы, с которыми вы, вероятно, столкнетесь. В настоящее время наиболее перспективными являются Zapier и IFTTT.

В зависимости от проблемы, которую вы пытаетесь решить, ваша система заказов роботов может даже не участвовать в интеграции. Допустим, вы управляете своими подписчиками на новостную рассылку с помощью CRM-системы, такой как Salesforce или HubSpot, и вам просто нужен более удобный способ связаться с ними через поставщика услуг электронной почты, такого как Mailchimp. У Zapier есть множество существующих интеграций, которые помогут вам в этом. С этого момента выбор провайдера, у которого есть коннектор Zapier, является хорошим шагом вперед.

И даже если речь идет об интеграции пользовательских данных (заказ роботов и их цена), Zapier Webhooks может выступить посредником для вашей интеграции.

С другой стороны, если вы уже отправляете данные третьей стороне, почему бы не отправить их напрямую в CRM-систему? Чем больше данных вы хотите синхронизировать, тем полезнее будет прямая интеграция.

Что подводит меня к следующему пункту.

Вам нужна двусторонняя синхронизация?

Обычно интеграция начинается с простого требования, такого как Можем ли мы привлечь всех наших клиентов в нашу систему CRM? , обычно в сочетании со значениями отдельных заказов роботов, что упрощает использование инструментов сегментации клиентов.

Однако рано или поздно может случиться так, что люди захотят использовать инструменты управления контактами, которые обычно предлагает пакет CRM. К ним относятся такие функции, как дедупликация, изменение контактных данных с данными из социальных сетей, нормализация адресов доставки или просто удаление старых контактов.

Изменение контактов в системе CRM, скорее всего, будет означать, что вам нужно будет изменить контактные данные в другой системе, т. е. изменения должны быть двусторонними.

Усилия по реализации для этого выходят далеко за рамки простой односторонней синхронизации, поэтому это отличный повод подумать о том, как вы хотите стратегически использовать новую систему.

Как вы будете уведомлены об изменениях в CRM?

Если вы решите использовать двустороннюю синхронизацию, возникает дополнительный вопрос: как вы узнаете, что что-то изменилось на стороне CRM?

У большинства системных провайдеров есть инструменты для этого, но лучше всего для немедленных изменений являются веб-перехватчики — по сути, система уведомлений HTTP, которую можно настроить, чтобы сообщать вам о соответствующих изменениях (для некоторых систем, даже на основе поля за полем). .

Если система не предлагает веб-перехватчики, по крайней мере проверьте, можете ли вы получить список всех объектов, которые были недавно обновлены. Таким образом, вам не нужно просматривать все контакты и сделки только для обновления собственных данных. Но имейте в виду, что вам нужно будет регулярно опрашивать систему.

В этом случае ваша система заказов по-прежнему будет изменяться и создавать данные через вызов API в системе CRM. Но все изменения из CRM-системы будут опрашиваться через определенный интервал.

Стоит отметить, что обновления будут ограничены этим интервалом и могут привести к временной несогласованности данных. Например, если вы синхронизируете данные из CRM-системы в систему заказов только один раз в день, данные, которые вы просматриваете в своей системе заказов, могут быть старше 24 часов.

В зависимости от того, какие функции предлагает система, задача интеграции может различаться по сложности и времени выполнения. Обязательно заранее проверьте, что предлагает система, и дважды проверьте план, который вы собираетесь купить. Например, некоторые CRM-системы предлагают вебхуки на более высокооплачиваемых уровнях.

Примером здесь является CRM HubSpot, который предлагает веб-перехватчики в целом, но функция веб-перехватчика доступна только в их корпоративном пакете. Бухгалтерские инструменты Zoho Books будут предлагать пять автоматизированных рабочих процессов (включая веб-перехватчики) на самом низком уровне.

Ваши данные в хорошем состоянии?

Когда дело доходит до создания наборов данных во внешней системе, полезно знать, как эти данные выглядят в вашей собственной системе. К счастью, существует не так уж много разных способов представления контактов и сделок, но одно поле, которое всегда вызывает проблемы, — это поле электронной почты.

Различные системы имеют разные представления о том, что такое действительный адрес электронной почты, и вот предупреждение о спойлере — ваши клиенты могли предоставить вам недействительные адреса электронной почты всех видов. Многие системы CRM отклонят создание контакта с недействительным адресом электронной почты (и, конечно, поставщик CRM определяет, что является действительным, а что нет).

Совет. Если возможно, синхронизируйте с CRM только подтвержденные адреса электронной почты. Это сэкономит вам много боли в долгосрочной перспективе.

Ограничения API

Наконец, ограничения API — это то, что нужно решать как можно раньше.

Предполагая, что есть API (который в основном необходим для любой интеграции), полезно взглянуть на ограничения API. Большинство стартапов могут справиться с базовыми ограничениями API большинства CRM-систем. Например, HubSpot предлагает 250 000 вызовов API в сутки даже на бесплатном уровне. С другой стороны, он также ограничивает вызовы до 10 в секунду (100, если вы используете OAuth). Лидер рынка Salesforce разрешает только 100 000 каждые 24 часа, но предлагает купить больше.

В большинстве случаев вы легко попадете в эти ограничения, но есть одна вещь, которую следует учитывать: как насчет вашего первоначального прогона? Вначале вы будете отправлять в CRM много контактов и сделок (и, возможно, несколько раз, если возникнут проблемы). В результате вы можете достичь дневного лимита API.

Чтобы смягчить это, вы можете протестировать небольшой набор данных и постепенно увеличивать число на протяжении всей реализации, чтобы оставаться в пределах ограничений API. Запланируйте первоначальную миграцию на несколько дней или на выходные. В качестве альтернативы обратитесь к провайдеру и сообщите ему о своих намерениях. Когда вы находитесь на этапе оценки (и еще не заплатили за систему), они могут немного увеличить вашу надбавку за API.

Внедрение CRM

Допустим, вы все согласны. Вы выбрали отличный CRM-инструмент, и инженеры уверены, что его можно легко интегрировать. Вы решили ограничить его только отправкой данных о клиентах и ​​приемом заказов роботов. Следовательно, двусторонняя синхронизация не требуется, а изменения адреса будут обрабатываться только в вашей собственной системе заказов.

Есть еще несколько рекомендаций, которым нужно следовать на этапе реализации.

Попробуйте все в тестовой среде

В большинстве случаев система CRM будет использоваться только после того, как ваша интеграция будет завершена и готова к использованию. Для этого варианта использования может показаться привлекательным просто использовать производственную систему во время разработки. В конце концов, нет производственных данных, на которые вы могли бы повлиять. Как только разработка будет завершена, вы просто удалите все созданные вами тестовые данные, запустите первоначальную миграцию и направьте свою систему заказов на эту среду.

Есть несколько проблем с этим подходом:

1. Вы просто пинаете банку по дороге. Даже если ваш ввод в эксплуатацию пройдет гладко, рано или поздно появится запрос на изменение части вашей интеграции. Учитывая, что запрос функции достаточно велик, вам, вероятно, понадобится еще один этап тестирования. На этом этапе отдельная система тестирования неизбежна; в противном случае вы можете испортить производственные данные. Так зачем ждать с настройкой, пока вас не попросят реализовать первую функцию?

   

2. В итоге вы получите беспорядочную конфигурацию. Вполне вероятно, что ваша CRM-система нуждается в какой-то настройке, чтобы удовлетворить потребности вашей системы заказов. Возможно, потребуется изменить имена статусов, обычно необходимо создать настраиваемые поля и т. д. Поскольку большинству разработчиков потребуется привыкнуть к CRM-системе, будет добавлена ​​конфигурация, которая не понадобится в долгосрочной перспективе. На самом деле эта неиспользуемая конфигурация не удаляется в дальнейшем и может даже навсегда остаться в вашей CRM. Принуждая к дополнительному шагу репликации конфигурации из тестовой системы в рабочую, вы, скорее всего, получите более тонкую конфигурацию в своей производственной системе.
   
   Следует отметить, что это также может сыграть вам на руку, если вы забудете скопировать конфигурацию из тестовой системы в рабочую систему, и в итоге вы получите ошибки в рабочей среде.
   
   Хотя есть некоторые CRM-системы, которые помогут вам сравнить и скопировать элементы конфигурации, в целом будет полезно записать ваши конфигурации, чтобы не забыть важные элементы. Большинство CRM предоставляют API для своей конфигурации, поэтому этот шаг можно автоматизировать.

3. Вы подвергаетесь более высокому риску загрязнения производственных данных. Представьте на секунду двух разработчиков, работающих над интеграцией. У вас уже есть промежуточная система системы заказов роботов. Эта постановка также связана с вашей CRM. После того, как ваша интеграция будет отправлена, вам нужно будет не забыть отключить все три системы, иначе вы можете создать тестовые данные в своей (теперь) рабочей CRM.

Всех этих проблем можно избежать, разрабатывая с самого начала тестовую систему. Производство представлено только в самом конце, прямо перед тем, как все выйдет в эфир. Таким образом, вы получите чистую конфигурацию, не рискуете забыть отключить локальные системы и заранее будете готовы внедрять новые функции.

Определить идентификатор для сопоставления сущностей

Теперь давайте начнем писать реальный код интеграции. Возьмем пример синхронизации контактов с CRM-системой. Предположительно, вам нужно будет создать новые контакты и обновить существующие контакты. Чтобы отличить создание от обновления, вам необходимо связать две сущности. Таким образом, вы можете проверить, существует ли контакт в вашей системе во внешней системе.

Хотя кажется привлекательным просто использовать адрес электронной почты (в конце концов, это общий идентификатор для записи контакта), есть более общее решение — для каждой записи вы синхронизируете ее с удержанием внешней системы и идентификатором в своей собственной базе данных.

Итак, добавьте в таблицу контактов столбец с именем crm_id или external_id . У этого подхода есть пара преимуществ:

• Поскольку это идентификатор, он не изменится (в отличие от адреса электронной почты или номера телефона).
• Вы можете увидеть, нужно ли вам создать или обновить объект, не выполняя сначала вызов API (если поле внешнего идентификатора пусто, вы можете предположить, что контакт не существует).

До:

После:

Например, предположим, что вы — разработчик 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

Обратите внимание, как мы используем сохранение companyId , возвращаемого HubSpot. Это не только помогает нам определить, хотим ли мы обновить или создать компанию в HubSpot, но и увидеть в таблице базы данных, какие объекты уже синхронизированы с HubSpot, а какие еще отсутствуют.

Когда дело доходит до картирования полей, идите вольным стилем

Я видел проекты, в которых реализации предшествует создание гигантской электронной таблицы Excel, определяющей, какие столбцы и куда помещаются в системе CRM, с аннотациями о том, как следует преобразовывать данные.

На самом деле существует всего несколько способов представления контактов и сделок. Поэтому вместо того, чтобы тратить много времени на размышления о том, как именно вы хотите составить карту, почему бы не начать с эксперимента? Дайте разработчику некоторое пространство, чтобы разобраться с отображением, но также поддерживайте связь, чтобы вопросы могли возникнуть раньше.

По крайней мере, для общих контактных полей (имя, адрес электронной почты, номер телефона, адрес) сопоставление будет очень простым, а преобразования обычно тривиальны.

Когда дело доходит до сопоставления статусов для сделок, полезно немного больше общения (иногда первый статус называется 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 или система выставления счетов, задав конкретные вопросы, например: Как этот продукт облегчит вашу жизнь? Вы рассматривали конкурентов? Почему они не работают?

Для всех остальных участников: привлекайте инженеров как можно раньше, доверяйте им, когда они указывают на красные линии, и не выбирайте дешевый план, когда вы видите, что внедрение интеграции значительно усложнит задачу в будущем. длинный пробег.