Когда клиент хочет отвечать покупателям из своей CRM, с которой нет продуктовой интеграции Fasttrack, а не из чат-центра Fasttrack, перед ним встаёт выбор архитектуры: встроить готовый чат-центр Fasttrack как есть или построить собственный интерфейс поверх данных, которые отдаёт платформа. Внешне обе схемы решают одну задачу — переписка оказывается внутри CRM. Но по сути это два разных ответа на вопрос «Кто владеет интерфейсом чата?», и от этого ответа зависит почти всё остальное: скорость и трудозатраты внедрения, гибкость подключения.
Разберём на примере интернет-магазина косметики «Люблю себя». У него есть своя кастомная CRM, и менеджеры хотят видеть переписку с покупателями из Telegram, MAX, WhatsApp и виджета сайта прямо в карточке клиента, не переключаясь в отдельную вкладку.
Откуда вообще берётся выбор
У любой переписки есть две составляющие: данные (кто что написал и когда) и интерфейс (как это показано на экране, какие есть кнопки, что оператор может сделать). В большинстве интеграций эти две вещи разделены: одна система отдаёт данные, другая рисует интерфейс. Но применительно к чату Fasttrack может отдать CRM либо готовую пару «данные + интерфейс» одним куском, либо только данные — и тогда интерфейс придётся строить самой CRM.
Отсюда и два подхода:
- iframe — CRM получает готовое окно чат-центра целиком, как оно есть на платформе Fasttrack, и просто показывает его у себя на странице. Данные и интерфейс идут вместе, разделить их нельзя.
- нативная интеграция через API и вебхуки — Fasttrack отдаёт CRM только события (пришло сообщение, оператор ответил, чат передали другой команде) и принимает от неё запросы на отправку. Интерфейс — целиком забота CRM.
⚠ Важно: это два взаимоисключающих подхода, а не ступени одной лестницы. Нельзя встроить iframe, а потом «докрутить» его вебхуками, если чего-то не хватит — iframe не отдаёт данные наружу в принципе, это чужое окно, а не поток данных, который можно дополнить.
iframe: платформа думает за вас
Если CRM встраивает iframe, то по факту она делегирует Fasttrack не только доставку сообщений, но и всё, что связано с их отображением. Оператор «Люблю себя» открывает карточку покупателя — и в интерфейсе чат-центра Fasttrack: список сообщений, поле отправки сообщения, переключение между каналами, если у клиента их несколько.
Такой подход встраивания выгоден тем, что разом снимает с CRM целый пласт работы: не нужно проектировать, как отображать разные типы сообщений, что делать с прикреплённым файлом, как организовать отправку сообщений оператора. Это уже решено на стороне платформы — и будет меняться вместе с развитием чат-центра Fasttrack без каких-либо действий со стороны CRM.
Но у этой выгоды есть обратная сторона, которая проявляется не сразу, а по мере роста требований к CRM:
- Интерфейс — не предмет переговоров. Если через полгода бизнесу понадобится добавить в окно чата свою кнопку («оформить возврат прямо из переписки») или изменить логику отображения истории — сделать это нельзя. Интерфейс чат-центра единый для всех клиентов Fasttrack.
- Переписка не оседает в базе CRM. Она физически хранится и обрабатывается на платформе. Если позже понадобится строить отчёты по обращениям, склеивать сообщения с карточкой заказа в собственной аналитике или экспортировать историю — этих данных у CRM просто нет, их негде взять внутри своей базы.
- Права на просмотр истории задаёт Fasttrack, а не CRM. Если в компании появится своя логика доступа — например, стажёр видит только последние три сообщения, а старший менеджер всю историю — реализовать это средствами iframe не получится: он показывает то, что решил показать чат-центр.
Иначе говоря, iframe — это быстрый путь ценой самостоятельности: CRM получает результат почти сразу, но соглашается на то, что дизайн, логика и данные переписки остаются вне её зоны влияния.
Нативная интеграция: CRM отвечает за всё сама
Здесь распределение ролей обратное. Fasttrack сообщает о происходящем в чате — открылась сессия, пришло сообщение, ответил оператор чат-центра — а как это показать оператору «Люблю себя», решает уже сама CRM. Она получает сырые события и данные, а не готовую картинку.
Из этого следует ряд практических последствий:
- Оформление, поведение, доступность истории — решения CRM. Можно показать переписку в любом виде, привязать её к карточке заказа, настроить, кому какая часть истории видна — это уже вопрос архитектуры самой CRM.
- История переписки хранится там, где CRM сама решит её хранить — обычно в собственной базе. Это открывает дорогу к своей аналитике, автоматизациям, интеграциям с другими модулями CRM.
- Ответственность за корректность и полноту интерфейса переходит к CRM. Каждый новый тип сообщения, каждый нюанс отображения (например, что оператор чат-центра Fasttrack уже ответил клиенту, чтобы CRM не продублировала ответ) — CRM должна обработать и показать сама, платформа этого за неё не сделает.
- Развитие чат-центра Fasttrack CRM не наследует автоматически. Если платформа добавит новую функцию в свой интерфейс — в нативной интеграции она не появится сама по себе, потому что интерфейса платформы там просто нет.
То есть нативная интеграция — это путь через самостоятельность: больше работы на старте и в поддержке, но взамен — полный контроль над тем, как выглядит и ведёт себя переписка внутри CRM, и данные, которыми можно распоряжаться свободно.
Как думать о выборе
Оба подхода не «лучше» и «хуже» — они рассчитаны на разные приоритеты. Вопрос, который стоит задать: что для бизнеса важнее — скорость получения результата или контроль над тем, что получится.
Если для «Люблю себя» главное — как можно быстрее дать менеджерам доступ к чатам внутри привычной CRM, а то, как именно выглядит окно переписки, не принципиально — iframe закрывает эту задачу почти без разработки: не нужно ничего проектировать, платформа берёт интерфейс на себя.
Если же в компании уже есть требования, которые интерфейс чужой платформы не может учесть — своя система прав доступа к истории, желание видеть переписку в общей аналитике заказов, кастомный вид чата, — эти требования сами по себе указывают на нативную интеграцию, потому что решить их через готовое окно физически невозможно.
Осторожно: сценарий «начнём с iframe, а если станет мало — дотянем через API» не работает. Выбор архитектуры делается один раз: переход с iframe на нативную интеграцию — это не доработка, а разработка заново, потому что раньше данные не были нужны CRM в сыром виде, а теперь единственный источник переписки — история, которая осталась внутри Fasttrack.