Интеграции EspoCRM и миграция с amoCRM/Bitrix24 без потери истории

Философия интеграций Espo: REST API как главный инструмент

Меня зовут Евгений Семёнов, я технический директор ITfresh — мы обслуживаем компании до 50 рабочих мест в Москве, серверы клиентов держим в дата-центре МТС. Это третья статья серии про EspoCRM: в первой был общий разбор системы, во второй — развёртывание на VPS. Сегодня — то, ради чего CRM вообще внедряют: интеграции с телефонией, почтой, сайтом и 1С, а во второй половине — как мы перевозим клиентов с amoCRM и Bitrix24, не теряя историю сделок.

Начну с принципа, который определяет всё остальное. В EspoCRM главный интеграционный инструмент — REST API, и он полностью входит в бесплатное ядро. Это не мелочь. В облачных CRM доступ к API часто дозируется тарифом: на младших планах он урезан по методам или задушен лимитами запросов, и за право забирать собственные данные приходится доплачивать. В Espo таких искусственных перегородок нет: любая сущность — лид, контакт, сделка, ваша кастомная «Заявка» — доступна на чтение и запись через одинаковые предсказуемые эндпоинты. С версии 9.3 система вдобавок умеет генерировать OpenAPI-спецификацию — удобно отдавать её подрядчику или подключать в Postman.

Аутентификация двух видов: простой API-ключ в заголовке запроса и более строгая схема HMAC, где каждый запрос подписывается секретом. Для внутренних интеграций внутри одного контура нам обычно хватает ключа, для сценариев через публичный интернет берём HMAC. Вторая половина фундамента — вебхуки, тоже в ядре: Espo сам отправляет POST на ваш URL при создании, изменении или удалении записей. То есть связка работает в обе стороны — внешние системы пишут в CRM через API, а CRM сообщает о событиях наружу.

Кейс №1: IP-телефония Asterisk/FreePBX + EspoCRM для отдела продаж

Телефония — интеграция номер один по запросам. Отдел продаж, который звонит «вслепую», теряет контекст на каждом звонке, поэтому связку CRM с офисной АТС мы делаем почти в каждом внедрении.

Зачем это нужно

Четыре эффекта, которые видит клиент в первый же день:

• Поп-ап карточки при входящем. Телефон менеджера ещё звонит, а на мониторе уже открыта карточка: кто звонит, какая компания, какие сделки в работе. Разговор начинается с «Добрый день, Сергей Петрович», а не с «представьтесь, пожалуйста».
• Клик-ту-колл. Менеджер жмёт на номер в карточке — АТС сама соединяет его телефон с клиентом. Ноль ошибок ручного набора.
• Автосоздание активности «Звонок». Каждый разговор фиксируется в истории клиента с длительностью и направлением. Руководитель видит реальную, а не отчётную активность отдела.
• Ссылка на запись разговора прямо в карточке — разбор спорных ситуаций и обучение новичков перестают быть археологией по журналам АТС.

Варианты реализации: платное расширение или своя связка

Официальный путь — платное расширение VoIP Integration (порядка 388 долларов, разовая покупка на инстанс, не подписка). Оно поддерживает Asterisk через интерфейс AMI, а также 3CX, Twilio, Starface, Binotel и iexPBX. Из коробки — клик-ту-колл, поп-ап входящего и исходящего, история и лог звонков, комментарии к ним. Ставится за час, работает предсказуемо — для типового внедрения мы почти всегда рекомендуем именно его: самописный аналог обойдётся дороже одной только зарплатой разработчика.

Второй путь — самописная интеграция: демон слушает события AMI/ARI Asterisk и дёргает REST API Espo. Он оправдан, когда нужна нестандартная логика — умная маршрутизация по ответственному менеджеру, интеграция с экзотической АТС из списка неподдерживаемых, свои сценарии для колл-центра. Бюджет — от недели работы разработчика против часа установки расширения; считайте честно.

Схема нашего типового внедрения

Классическая конфигурация у наших клиентов: FreePBX в офисе или на VPS рядом с CRM, EspoCRM на своём сервере. АТС по событиям сообщает о звонках, коннектор сопоставляет внутренний номер менеджера с его учёткой в CRM — этот маппинг «добавочный 101 = пользователь ivanov» заполняется один раз при настройке и живёт годами. Дальше система по номеру абонента ищет контакт или лид: нашла — поп-ап и привязка звонка к карточке, не нашла — предлагает создать лид, и холодный входящий не теряется.

Подводные камни из нашей практики

• NAT. Если АТС в офисе за роутером, а CRM на внешнем VPS, события через NAT сами не полетят. Мы не открываем порт AMI в интернет никогда — только VPN-туннель или проброс с жёстким ограничением по адресу источника. Открытый наружу AMI — это подарок телефонным фродерам, которые за выходные назвонят вам счёт на международку.
• Формат номеров. АТС отдаёт номер как 84957290000, в CRM он записан как +7 495 729-00-00 — и поиск карточки молча не срабатывает. Лечится нормализацией: на стороне коннектора приводим всё к единому виду +7XXXXXXXXXX, а в CRM заводим правило, что менеджеры вносят номера только через +7. Это самая частая причина «поп-ап не работает» на чужих внедрениях, которые мы забираем на поддержку.
• Дубли контактов по номеру. Один и тот же номер у контакта и у компании, или у двух менеджеров «свои» карточки одного клиента — поп-ап начинает открывать не то. Перед запуском телефонии обязательно чистим дубли, иначе интеграция честно умножает существующий бардак.

Кейс №2: почта как конвейер лидов

Почтовая интеграция в Espo встроена в бесплатное ядро, и мы выжимаем из неё больше, чем «письма видно в CRM». Правильно настроенный ящик — это полноценный канал лидогенерации.

Основа — Group Email Account: общий IMAP-ящик отдела, обычно sales@ или info@. CRM забирает из него входящие и умеет автоматически создавать лид из каждого нового письма с неизвестного адреса. Письмо от действующего клиента при этом прилипает к его карточке, а не плодит мусорные лиды. В результате заявка, пришедшая на почту в субботу вечером, в понедельник утром уже стоит в очереди у менеджера — а не лежит непрочитанной в ящике, пароль от которого знает один человек, ушедший в отпуск.

Дальше — распределение. Раздачу новых лидов по менеджерам по кругу (round-robin) красиво делает Workflow из платного Advanced Pack: правило «новый лид без ответственного → назначить следующему по списку». В бюджетных внедрениях мы обходимся бесплатными formula-скриптами: при создании лида формула вычисляет ответственного — по чётности, по территории, по источнику. Менее наглядно в админке, но работает так же надёжно и стоит ноль рублей.

Персональные ящики менеджеров подключаем отдельно, тоже по IMAP: переписка каждого автоматически привязывается к карточкам по адресу собеседника, и вся история общения с клиентом собирается в одном месте независимо от того, кто и с какого ящика писал. С версии 9.3 для личных ящиков появился маппинг IMAP-папок — удобно, когда у менеджера в почте своя структура каталогов.

Кейс №3: лиды с сайта — Lead Capture и формы

Классика жанра «форма на сайте шлёт письмо, менеджер копирует его в CRM руками» — это потерянные заявки и ошибки перепечатки. В Espo для этого есть штатный механизм Lead Capture, он в бесплатном ядре и не требует программировать backend.

Настройка простая: в админке создаётся точка входа (entry point), для неё выбираются поля будущего лида (Payload Fields) и генерируется API-ключ. Дальше сайт просто отправляет POST-запрос с данными формы на специальный URL с этим ключом — авторизация сверх ключа не нужна. Имена полей передаются в camelCase, как в API. Типовой запрос выглядит так:

curl -X POST 'https://crm.example.com/api/v1/LeadCapture/<api-ключ-формы>' \
  -H 'Content-Type: application/json' \
  -d '{
    "firstName": "Пётр",
    "lastName": "Смирнов",
    "emailAddress": "p.smirnov@example.ru",
    "phoneNumber": "+74957290000",
    "description": "Нужен расчёт обслуживания на 20 рабочих мест"
  }'

Ответ 200 — и лид уже в воронке с заполненными полями. Есть и встроенная веб-форма: её можно включить прямо в карточке Lead Capture и получить готовую страницу формы, если на сайте не хочется верстать свою.

Наши доработки поверх штатного механизма:

• Проксирование через nginx. Форма на сайте шлёт запрос не напрямую в CRM, а на эндпоинт сайта, откуда nginx проксирует его в Espo. CRM не светится в коде страницы, а на прокси висит rate-limit — дешёвая защита от ботов, заливающих форму сотнями запросов.
• Honeypot-поле. Скрытое поле в форме, которое человек не видит и не заполняет, а бот заполняет. Прокси молча отбрасывает такие запросы — до CRM спам-лиды не доезжают.
• UTM-метки в кастомные поля. В сущности «Лид» через Entity Manager заводим поля utmSource, utmCampaign и передаём их с формы. Через месяц-два у клиента впервые появляется честный ответ, какая реклама приносит заявки, а какая — расходы.
• Мгновенное уведомление в Telegram. Вебхук на создание лида дёргает маленький скрипт, тот шлёт сообщение в чат отдела продаж дежурному менеджеру. Скорость первого касания — главный фактор конверсии заявки, и «перезвонили за две минуты» клиенты запоминают.

Кейс №4: обмен с 1С

Для бухгалтерских фирм и торговых компаний связка CRM и 1С — это ответ на вечный вопрос менеджера «оплатил клиент или нет?». Пока ответа нет в CRM, менеджеры ходят к бухгалтеру, бухгалтер отвлекается, все теряют время. Цель интеграции — счета и оплаты видны прямо в карточке сделки.

Технически варианта два. Первый — выгрузка из 1С по расписанию: регламентное задание или внешняя обработка в 1С раз в 15–30 минут отдаёт новые счета и платежи (через OData или свой HTTP-сервис), а скрипт-посредник кладёт их в Espo через REST API — в кастомную сущность «Счёт», связанную со сделкой и компанией. Второй — обратный поток: сделка в CRM переходит в «Выиграна», вебхук уходит посреднику, и в 1С автоматически создаётся заказ или черновик счёта. Менеджер вообще не заходит в 1С.

Наш выверенный опыт: начинайте с одностороннего потока оплат из 1С в CRM. Он даёт 80% пользы при 20% сложности и, главное, ничего не пишет в учётную базу — бухгалтерия спит спокойно. Двусторонний обмен мы строим только клиентам со зрелыми процессами: когда в компании нет единых правил, кто и как заводит контрагентов, синхронизация двух систем превращается в конвейер по производству дублей, только автоматизированный.

Миграция с amoCRM: пошаговый план

Переходим ко второй части — переезду. Чаще всего мы перевозим клиентов именно с amoCRM: подписка за каждого пользователя с ростом штата начинает ощутимо давить на бюджет. Задача переезда всегда одна — сохранить историю продаж и не остановить отдел.

Шаг 1. Что и как выгружаем

Из amoCRM забираем: контакты, компании, сделки по всем воронкам со стадиями, задачи, примечания (вся история общения живёт в них) и файлы. Штатный экспорт отдаёт контакты и сделки в CSV/Excel — этого хватает для базы. А вот примечания, задачи и файлы в выгрузку не попадают — их мы вытаскиваем скриптом через API amoCRM, пока доступ к аккаунту ещё жив. Важно: сначала полная выгрузка всего, и только потом любые работы — резервная копия исходных данных должна лежать у нас до конца проекта.

Шаг 2. Маппинг полей и стадий

До импорта готовим таблицу соответствия и создаём в Espo через Entity Manager все кастомные поля, которых нет из коробки. Типовой маппинг выглядит так:

Отдельная строка работы — стадии воронок: в amo они часто расплодились («Думает», «Думает-2», «Точно думает»), и переезд — удачный момент навести порядок, а не тащить хаос в новую систему.

Шаг 3. Импорт: CSV или API

Контакты, компании и сделки заливаем штатным CSV-импортом Espo — он умеет сопоставлять колонки с полями и, что критично, дедуплицировать по email или телефону: повторный запуск обновит записи, а не задвоит базу. Историю примечаний и связи «кто с кем» CSV не перенесёт — здесь работает наш API-скрипт: он проходит по выгрузке amo и создаёт записи в Stream соответствующих карточек, сохраняя даты и авторов. После него менеджер открывает карточку клиента и видит хронологию за три года, как будто всегда работал в Espo.

Что теряется — говорю честно

Не переносится история изменений полей (кто и когда двигал сделку по стадиям в старой системе) — в Espo журнал начнёт писаться заново с даты переезда. Не переезжают и автоматизации: digital-воронку amo нельзя «скопировать», её логику мы пересобираем заново средствами Espo — формулами, вебхуками, при необходимости Advanced Pack. Мы честно проговариваем это до старта и вносим пересборку автоматизаций в смету отдельной строкой, чтобы сюрпризов не было ни у кого.

Миграция с Bitrix24 и из Excel-учёта

С Bitrix24 механика похожа, но есть своя специфика. Штатный экспорт отдаёт CSV по лидам, контактам, компаниям и сделкам — базовый перенос идёт по той же схеме, что и с amo. Главная особенность — смарт-процессы: если клиент строил на них учёт (заявки на сервис, договоры, объекты), прямого аналога «взять и импортнуть» нет. Мы проектируем в Espo кастомные сущности через Entity Manager под каждый смарт-процесс, повторяя поля и связи, и заливаем данные API-скриптом. По трудоёмкости это самый тяжёлый кусок переезда с Битрикса — оценивайте его до подписания сметы, а не после.

Второй по частоте сценарий — вообще не CRM, а «учёт клиентов в Excel». Такие таблицы прекрасны своим разнообразием: телефон в четырёх форматах (8-495..., +7 (495)..., «спросить Олю»), клиент «ООО Ромашка» тремя строками с разным написанием, половина email с опечатками. Заливать это в CRM как есть — значит начать жизнь в новой системе с грязной базы. Поэтому перед импортом гоняем нормализующий скрипт: приводим телефоны к +7XXXXXXXXXX, чистим пробелы и мусорные символы, склеиваем очевидные дубли по ИНН, телефону и email, размечаем спорные строки для ручного разбора.

Организация переезда без остановки продаж

Самый частый страх клиента звучит одинаково: «Пока вы переезжаете, отдел встанет». Не встанет, если переезд организован по регламенту, который мы отработали на десятках проектов.

1. Параллельная работа 1–2 недели. Разворачиваем Espo, переносим базу, настраиваем интеграции — а отдел продолжает жить в старой CRM как ни в чём не бывало. Менеджеры получают доступ в новую систему и осваиваются на реальных, уже перенесённых данных, без давления «с сегодняшнего дня только здесь».
2. Заморозка и день X. Назначаем дату перехода — мы любим вечер пятницы. С этого момента изменения в старой CRM прекращаются: новые лиды и правки только в Espo.
3. Финальная дельта-синхронизация. За выходные скриптом догоняем всё, что изменилось в старой системе с момента основного импорта: новые сделки, передвинутые стадии, свежие примечания. Дедупликация по email и телефону гарантирует, что дельта обновит записи, а не задвоит их. В понедельник отдел открывает Espo с полностью актуальной базой.
4. Старая CRM — в режим «только чтение» до конца оплаченного периода, как страховка и справочник «а как было в старой системе».

Отдельно про обучение: на него мы закладываем один час на команду. Не потому что экономим, а потому что больше не нужно — интерфейс Espo прямолинейный: воронка, карточка, задачи, почта. Показываем ежедневный маршрут менеджера, отвечаем на вопросы — и люди работают. Ещё неделю после запуска держим чат поддержки, куда менеджеры пишут «а как тут…» и получают ответ за минуты, — это снимает раздражение переходного периода лучше любых регламентов.

Итоговые сроки из нашей практики для компании на 15–25 рабочих мест: 2–4 недели от старта до полного перехода. Две недели — когда база чистая и интеграций минимум; четыре — когда есть телефония, 1С и тяжёлое наследие смарт-процессов. Обещания «переведём за один день» оставляю на совести тех, кто ни разу не разбирал последствия такого дня.

Чек-лист итогов и что дальше

Сведу всё разобранное в одну таблицу — она же чек-лист при планировании бюджета внедрения:

Главная мысль статьи: интеграционный фундамент Espo — API, вебхуки, почта, Lead Capture, импорт — бесплатный. Деньги уходят точечно: на VoIP-расширение, если нужна телефония «из коробки», на Advanced Pack, если нужны визуальные бизнес-процессы, и на руки специалистов для связки с 1С и переноса истории. Это прозрачная, считаемая смета — в отличие от облачной подписки, растущей с каждым нанятым менеджером.

А переезд с amoCRM или Bitrix24 — рутинная инженерная задача со своей технологией: выгрузка, маппинг, пилот на 100 записях, импорт с дедупликацией, дельта-синхронизация в день X. Две–четыре недели, и отдел продаж работает в системе, за которую не нужно платить за каждую голову.

В следующей статье серии — эксплуатация: обновления EspoCRM (актуальная ветка на сегодня — 9.3.10), бэкапы, мониторинг и безопасность self-hosted CRM, чтобы сервер не стал головной болью. А если переезд нужен уже сейчас и без экспериментов на живом отделе продаж — контакты ниже.