Когда история клиентов разбросана по арендованным сервисам, у ИИ-агента нет полной картины. Что бизнесу хранить в одной системе, а что отдать поставщикам.
Содержание5 разделов
Последние двадцать лет малый бизнес работал на арендованных программах и на человеке, который сводил их вместе. Контакты лежали в CRM, переписка в почте, цены в таблице, счета в бухгалтерии. Клиент спрашивал, где его заказ, и кто-то открывал четыре вкладки, сверял имена на глаз и отвечал. Этот человек и был интеграцией. Схема работала, потому что человек помнит, о чём шёл разговор, и держит это в голове, переходя от экрана к экрану, хотя сами экраны друг с другом не связаны.
ИИ-агент так не умеет, и причина простая, механическая. О вчерашнем звонке он ничего не знает, пока звонок не записан там, откуда агент может его прочитать. Что счёт ушёл, он узнает, только если ему сообщит платёжный сервис. Дайте агенту десять сервисов с десятью урезанными API, и он увидит десять обрывков сведений об одном клиенте.
Что нужно агенту и без чего обходился человек
Чтобы довести работу до конца самостоятельно, агент проходит три шага подряд. Сначала он узнаёт, что сейчас происходит: кто клиент, что купил, что ему обещали и к какому сроку. Потом действует: записывает на просмотр, отправляет напоминание, выставляет счёт. Затем проверяет, что получилось, и исправляет ошибки. Последний шаг возможен, только если результат действия попадает туда же, откуда агент читал.
Когда данные разбросаны, ломается каждый шаг. Чтобы прочитать, приходится склеивать выгрузки, где имя клиента записано тремя способами. Действовать можно в пределах того, что разрешает API каждого поставщика, а многие дают читать и не дают писать или разрешают менять одни объекты и запрещают другие. Чаще всего срывается проверка. Подтверждение от платёжного сервиса и ответ в WhatsApp приходят в разные системы, и ничто не связывает их с записью, с которой всё началось.
Насколько бизнес далёк от этого, видно по его собственному сайту. В нашей переписи 26 октября 2026 года из 5 095 работающих сайтов MCP-сервер был у 3,7%, а среди сайтов Бразилии, Аргентины, Чили и Мексики у 1,6% (перепись INITE). Через такой интерфейс ИИ-агент может что-то сделать на сайте, а не только прочитать страницу. Остальные сайты предлагают агенту текст страницы и номер телефона. Перепись по странам и платформам разобрана в статистике готовности к ИИ-агентам.
Каждая интеграция приносит чужие правила
Вначале интеграции кажутся бесплатными. Zapier переносит заявку из формы в CRM, вебхук записывает оплату в таблицу. Через год таких связок набирается десяток, и каждая приносит с собой модель данных сервиса на другом конце: что CRM называет стадией сделки, кого сервис записи считает клиентом, что платёжный провайдер понимает под возвратом. Стоит одному из них переименовать поле или отключить метод, и связка тихо перестаёт работать, а узнают об этом от недовольного клиента.
С каждым новым сервисом эти издержки растут, и условия диктуют поставщики. Бизнес не может поменять то, как арендованная CRM описывает договор аренды. Ему остаётся обходить её ограничения.
Что оставить себе, а что арендовать
Писать для этого свою бухгалтерию, телефонию или эквайринг не нужно. Это сложные и регулируемые вещи, и поставщики справляются с ними хорошо. Бизнесу нужно оставить у себя учёт, который всё это связывает.
В этот учёт входят клиенты, переписка, записи, заказы, платежи как события, обещания каждому клиенту и решения по ним. Туда же относятся правила: кому отвечать ночью, когда разговор передают человеку, какой платёж считать просроченным. Всё это хранится в одной системе на домене компании, и сотрудники и агенты читают и пополняют там одну и ту же историю.
Всё остальное подключается к этому учёту как внешнее устройство. Платёжный сервис принимает карту и сообщает результат, календарь показывает свободное время, бухгалтерия получает счета. Любой из этих сервисов можно заменить другим, потому что история в нём никогда не хранилась.
Представьте, что завтра подписка на CRM закончится. Если для того, чтобы вспомнить, что вы обещали каждому клиенту в прошлом месяце, понадобится выгрузка, которую никто ни разу не делал, история ваших клиентов лежит у поставщика.
Скорость берётся из учёта
Первый выигрыш виден в скорости ответа. В исследовании 1,25 млн онлайн-заявок, которое Harvard Business Review опубликовал в 2011 году, компании, пытавшиеся связаться с клиентом в течение часа, почти в семь раз чаще квалифицировали заявку, чем те, кто ждал дольше (HBR). Агент ответит за несколько минут в 11 вечера в воскресенье, только если видит, кто пишет, что этот человек смотрел и какое время свободно. Открывать перед этим четыре вкладки никому не придётся.
Историю потом не восстановить
Портал можно построить за несколько недель. Что происходило с каждым клиентом за пять лет, потом не восстановить, потому что большую часть этого не записывали в одном месте: почему клиент ушёл, какую скидку пообещали по телефону, как уладили жалобу в чате. Бизнес, который начнёт записывать это в свою систему сегодня, через год получит агента, знающего его клиентов. Тот, кто подождёт, начнёт с пустой таблицы и выгрузок от поставщиков.
Как это выглядит в одной отрасли, показывают два наших разбора: что дают сделать клиенту восемь сайтов подрядчиков и семь сайтов бразильских агентств недвижимости. INITE строит такой учёт в Portal. Это сайт для клиентов, где запись, оплата и переписка складываются в одну историю по каждому клиенту, и ассистент берёт всё, что знает, из этой истории. Домен, тексты и записи о клиентах остаются вашими, а в договоре сказано, как забрать их с собой, если вы уйдёте. Сама память на платформе INITE вынесена в отдельный сервис Brain, к которому другие продукты и агенты обращаются по MCP. Что входит в историю клиента, подробно разобрано в гиде о памяти агента.
Часто задаваемые вопросы
Свой учёт - значит, писать свою CRM или бухгалтерию?
Нет. Бухгалтерия, телефония, эквайринг и календари - сложные и регулируемые вещи, и поставщики хорошо с ними справляются. У бизнеса остаётся учёт, который их связывает: кто клиент, что ему сказали, на что записали, что он оплатил и что ему обещали, плюс правила, что делать дальше. Каждый арендованный сервис сообщает о своих событиях в этот учёт, а сам сервис можно заменить, не потеряв историю.
Почему агенту нужен один учёт, а не несколько API?
Агент работает в три шага: узнаёт, что сейчас происходит, действует и проверяет результат. Если данные разбросаны по сервисам, ему приходится склеивать выгрузки, которые расходятся между собой, делать только то, что разрешает API каждого поставщика, а подтверждение своего действия искать в другой системе. Когда учёт один, агент читает, пишет и проверяет в одном месте.
Что должно храниться в собственной системе бизнеса?
Клиенты, переписка, записи, заказы, платежи как события, обещания каждому клиенту и решения по ним. Там же правила: кому отвечать ночью, когда разговор передают человеку, какой платёж считать просроченным.
Как понять, что история клиентов лежит у поставщика?
Представьте, что завтра подписка на CRM закончится. Если для того, чтобы вспомнить, что вы обещали каждому клиенту в прошлом месяце, понадобится выгрузка, которую никто ни разу не делал, история клиентов лежит у поставщика. Чем дольше ждать, тем больше её там накопится.
