Санкт-Петербург

Интеграции
сайта

Сайт связывается с тем, чем уже пользуется владелец: учётной системой, CRM, кассой, платёжным сервисом и аналитикой.

Ответдо 15 минутв рабочее время

Начнём работусегодняили завтра

Цена работ2 200 ₽ / часили в абонплате

Доступыостаются у васничего не переносится

Порядок работы с интеграцией и типичные ситуации

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

Разбор текущей системы интеграции

Перед тем как настроить обмен данными, специалист проверяет статус существующих связей сайта с внешними системами. Проверяется, какие сервисы уже подключены, какая версия обработки используется и не осталось ли старых настроек от прошлой разработки. Это даёт понимание, откуда взялась ошибка и какой объём работы предстоит. Отдельно фиксируется, кто отвечает за каждую систему со стороны бизнеса и кто — со стороны технической поддержки. Если находится расхождение, оно фиксируется до начала новой настройки.

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

Ошибки при обработке данных

Частая причина сбоя — расхождение форматов между сайтом и внешней системой: CRM ждёт один набор полей, а сайт передаёт другой. Из-за этого часть информации о клиенте теряется при обработке, а остаток товара расходится с тем, что видит покупатель. Похожая ситуация возникает при переносе заказов в CRM, когда часть полей остаётся пустой. Причиной часто становится изменение структуры полей на стороне внешнего сервиса без предупреждения.

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

Стоимость и объём работы

Стоимость интеграции складывается из количества систем, которые нужно связать, и из того, насколько готова их собственная документация. Готовое техническое решение от поставщика CRM или платёжного веб-сервиса сокращает разработку, а закрытая или устаревшая платформа увеличивает объём настройки. Отдельно оценивается, сколько справочников и типов документов нужно свести к общему формату. У части систем документация закрыта, и тогда оценка строится по тестовым запросам, что расширяет возможности дальнейшей проверки.

Дополнительно на объём влияет то, нужна ли автоматизация регулярных операций вроде синхронизации остатков, или достаточно разового переноса информации. Чем больше процессов бизнеса завязано на обмен данными, тем шире проверка перед итоговой сдачей проекта. Заранее оговаривается, какие данные критичны, а какие можно синхронизировать позже. Планирование учитывает и то, потребуется ли доработка сайта под новый формат обмена.

Различия между интеграцией с 1С, CRM и платёжным сервисом

Интеграция с 1С обычно строится вокруг товарных остатков и обмена документами, поэтому проверяется совпадение справочников и единиц измерения. Интеграция с CRM связана с передачей данных о клиенте и историей обращений, а платёжный сервис требует отдельной проверки статусов операций. Разница заметна и в сроках проверки: 1С требует сверки остатков, а CRM — сверки контактов.

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

Случаи, когда интеграция не подойдёт

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

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

Сценарии, в которых используется интеграция сайта

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

Сценарий продажи и создание сделки

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

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

Уровень доступности для пользователей

У интеграции есть свой уровень доступности для разных пользователей сайта. Менеджеру по продажам обычно доступна карточка сделки и её сведения. Администратор получает более широкий уровень: видит связь систем целиком и может изменить, какие сведения передаются дальше. Такое разделение снижает риск того, что нежелательное изменение затронет чужую систему. Сделать иной уровень доступности для сотрудника можно через панель администратора в любой момент, когда меняется состав команды.

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

Наличие товара на складе и его обновление

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

Проблема возникает, когда учётная программа недоступна ненадолго: тогда сайт показывает последнее известное количество, а не действительное. Чтобы избежать путаницы, для интеграции предусматривают предупреждение о разрыве связи, которое видит администратор. Разрыв связи не означает потерю продажи: заказ на сайте принимается и проводится позже, когда связь восстановится.

Передача сведений в JSON

Большинство систем принимает и отдаёт сведения в виде JSON — компактной записи, понятной и программе, и человеку. Такой способ упрощает создание дополнительных связей: разработчику достаточно один раз описать структуру, и её можно использовать для нескольких систем.

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

Когда готовая интеграция не подойдёт

Интеграция не подойдёт, если у площадки нет постоянного потока продаж. Сведения тогда проще вносить в программу вручную раз в несколько дней. Автоматическая связь в таком примере не окупает себя и добавляет лишний уровень сложности вместо помощи. Решение об отказе от связи принимает сам владелец сайта, глядя на поток продаж за месяц.

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

Что проверяется в любой интеграции

  • Полный путь данных: от действия на сайте до системы
  • Что происходит при сбое — теряются данные или ждут
  • Уведомления, если обмен встал
  • Скорость сайта после подключения
  • Тестовые запросы и заказы перед сдачей
  • Инструкция: где смотреть и что делать, если не пришло

Из практики: EVA Factory — ЭВА-коврики на заказ

evafactory.ru — страница услуги
evafactory.ru — страница услуги · Переезд с Tilda на WordPress
  • Восстановлены канонические адреса. Ошибка в функции темы отключала канонические ссылки на всём сайте. Исправление одной функции вернуло их на 43 адресах; переадресация с http на https проверена.
  • Подтверждение прав в Вебмастере. На страницах пропал код подтверждения прав в Яндекс Вебмастере, из-за чего доступ к данным сайта мог сняться. Код возвращён, счётчик Метрики не задет, кэш сброшен.
  • Переезд с Тильды на WordPress. Сайт переехал с Tilda на WordPress: страницы собраны заново, старые адреса переадресованы, заявки приходят как раньше.

Реакция на задачу — 1 рабочий день. Работа на любой CMS — 1–2 дня. Всё — по договору, доступы остаются у владельца: что в договоре.

Все примеры работ →

«После запуска сайт не заканчивается. Блог, новые страницы под то, что ищут люди, и быстрые правки по заявкам дают больше, чем очередной редизайн.»

— Ведущий специалист поддержки сайтов

Частые вопросы

Сколько это стоит?

Цена работ: 2 200 ₽ / час, или в абонплате.

Как быстро начинается работа?

Ответ: до 15 минут, в рабочее время.

Останутся ли доступы у меня?

Доступы: остаются у вас, ничего не переносится.

Нужна интеграция?

Описание задачи — ответ в течение 15 минут в рабочее время.

Ответ приходит в течение 15 минут в рабочее время. Рассылка не ведётся.