Интеграции: почему CRM, складской учет и телефония нужно закладывать в проект до начала дизайна
Классическая ошибка заказчика при заказе разработки сайта звучит так: «Сначала сделаем красиво, запустим MVP, а потом прикрутим все сервисы». В реальности такой подход почти всегда оборачивается двойными тратами и срывом сроков. Дизайн (UI) — это лишь визуальная оболочка. Ее форма напрямую зависит от того, какие данные через нее проходят и куда они направляются. Если вы строите дом, вы сначала прокладываете трубы и проводку, а уже потом выбираете цвет обоев. С сайтом то же самое. Разбираем на пальцах, что ломается, когда интеграции становятся «сюрпризом» на этапе сдачи проекта
Миф о «простом подключении за час»
Представьте ситуацию
дизайнер нарисовал макет формы заявки из 5 полей. Верстальщик сверстал его. Программист настроил отправку писем. Сайт готов. А за неделю до запуска выясняется, что:
У вас стоит CRM-система, где карточка клиента требует еще 3 скрытых поля (источник трафика, ID посетителя, сегмент), которых нет в дизайне. Дизайн едет, сетка ломается.
Заявки с сайта должны создавать сделку и ставить задачу менеджеру. Но логику распределения заявок никто не продумывал. Кто будет брать заявку? Самый свободный? Или старший менеджер? Система зависает.
Кнопка «Заказать звонок» должна инициировать вызов через IP-телефонию. Но виджет колбэка конфликтует со скриптом онлайн-чата, который тоже был заложен в дизайн.
Итог
программист начинает писать костыли прямо по чистовому дизайну, сроки сдвигаются, бюджет растет.
Почему архитектуру интеграций нужно проектировать вместе с прототипом:
Полям нужны хозяева (сквозные данные)
Каждое поле на сайте должно иметь зеркальное отражение в вашей системе учета. Если на сайте есть выбор «Удобное время звонка», в CRM у менеджера должен появиться соответствующий выпадающий список, а не просто текст в примечании. Это называется маппингом (сопоставлением) полей. Если спроектировать это заранее, разработчик сразу использует правильные типы данных, которые корректно передадутся в бэкенд.
Складской учет диктует логику каталога
Если ваш сайт связан со складом, остатки товаров меняются в реальном времени.
Если заложить это сразу
пользователь видит актуальный статус («В наличии», «Осталось 2 штуки», «Под заказ»).
Если сделать потом
вам придется либо мириться с тем, что клиенты заказывают товар, которого нет, либо переписывать всю логику карточки товара и корзины. Также интеграция склада влияет на расчет стоимости доставки и работу калькуляторов.
Телефония начинается с номера телефона
Современная интеграция телефонии делает из него мощный инструмент аналитики:
Динамический Call Tracking
номер на сайте подменяется в зависимости от того, по какому рекламному объявлению пришел клиент. Чтобы это работало, место под номер в шапке и футере должно быть адаптивным.
Click-to-call
нажатие на мобильную версию номера вызывает набор одним кликом. Это требует специфической верстки.
Запись звонков
ссылка на аудиозапись разговора должна автоматически падать в карточку сделки в CRM. Эту цепочку нельзя настроить за пять минут после релиза, она проектируется на уровне серверных настроек.
Сквозная аналитика умирает без правильных ссылок
Чтобы понимать, окупилась ли реклама, маркетологу нужны UTM-метки. Они должны передаваться из ссылки, через которую зашел пользователь, в форму заявки, затем улетать в CRM и там склеиваться с фактом оплаты. Если верстальщик обернул кнопку отправки формы неправильным тегом или забыл передать скрытое поле метки, ваша аналитика покажет ноль продаж. Исправлять это в готовом коде дороже, чем написать правильно с нуля.
Технический долг: цена отложенных решений
Когда интеграции пытаются прикрутить к готовому сайту, возникает технический долг. Вместо использования нативных методов системы разработчики пишут сложные связки через сторонние сервисы-посредники (Zapier, Albato). Это работает медленнее, чаще ломается при обновлениях систем и обходится ежемесячно в оплату подписок за эти самые сервисы. Чистая архитектура, заложенная в начале, позволяет сайту обмениваться данными напрямую через API и вебхуки, что надежнее и быстрее.
Как мы работаем
На этапе создания прототипа (до любого рисования кнопочек) наши специалисты составляют карту связей
Источник
Где пользователь вводит данные?
Трансформация
Что с ними происходит (нужно ли проверять валидность телефона, рассчитывать скидку)?
Приемник
Куда уходит заявка (CRM, Email, Slack, Таблица)? Какую задачу это создает?
Обратная связь
Что видит пользователь (страница Thank You Page, SMS-подтверждение, письмо с номером заказа)?
Только понимая весь путь, можно рисовать интерфейс, который будет готовым рабочим инструментом бизнеса.
Давайте обсудим архитектуру вашего проекта уже сегодня! Опишите ваши текущие бизнес-процессы, и мы подготовим схему необходимых интеграций
