AI Assist
Вопрос «взять готовое или заказать разработку» звучит как вопрос о бюджете. На самом деле это вопрос о том, насколько ваш бизнес похож на средний. Коробочные решения делают для среднего случая — и когда вы в него попадаете, это самая разумная покупка на рынке. Проблема начинается, когда вы в него не попадаете, а понимаете это уже после оплаты годовой подписки.
Разберёмся честно: где граница, сколько на самом деле стоит каждый вариант за два года, какие расходы обе стороны умалчивают и почему самый частый правильный ответ — не «или-или», а третий вариант.
Что такое «готовое решение» на самом деле
Под готовым решением на рынке понимают как минимум три разные вещи, и путаница здесь стоит дорого.
Конструктор сценариев. Вы сами собираете дерево веток мышкой: кнопки, сообщения, условия. Дёшево, быстро, полный контроль над логикой — но логику приходится строить вам, и никакого понимания языка там нет. Классика для FAQ и меню.
SaaS-платформа поддержки. Готовый продукт с собственным интерфейсом оператора, очередями обращений, шаблонами и уже встроенным ИИ-модулем. Вы подключаете каналы, загружаете базу знаний и работаете. Это самый «коробочный» вариант: много функций с первого дня, но вы живёте по правилам платформы.
Отраслевое решение. Бот, сделанный под конкретную нишу — салоны, стоматология, доставка. Внутри уже есть понимание предметной области: понятия «мастер», «слот», «услуга». Если ваша ниша совпадает — это самый быстрый старт из возможных.
Общая черта всех трёх: вы покупаете чужую модель вашего бизнеса. Если она совпадает с реальностью — вы экономите кучу денег. Если нет — вы платите за то, чтобы подгонять свой бизнес под чужую модель.
Что входит в кастомную разработку
Кастом — это не «то же самое, но дороже». Это другой состав работ, и большая часть бюджета уходит не туда, куда ожидают.
Типовое распределение на реальном проекте выглядит так: примерно четверть времени — сбор и структурирование базы знаний, ещё четверть — интеграции с вашими системами, примерно столько же — проектирование сценариев и границ полномочий, и лишь остаток — собственно код бота и интерфейсы. То есть вы платите преимущественно за то, чтобы система знала ваш бизнес и умела работать с вашими данными.
Что вы получаете взамен:
- логику, которая повторяет ваши процессы, а не наоборот;
- интеграции с теми системами, которые у вас реально стоят, включая самописные;
- данные у себя: история диалогов, база знаний и аналитика остаются вашими;
- отсутствие потолка по объёму — стоимость не прыгает, когда обращений становится вдвое больше;
- возможность менять поведение системы, не дожидаясь роадмапа вендора.
Главный недостаток тоже очевиден: больший входной бюджет и более долгий старт. Плюс зависимость от подрядчика, о чём честно поговорим ниже.
Где готовое решение упирается в потолок
По нашей практике бизнес приходит из коробки к кастому по пяти типовым сценариям. Если узнали свой — вы уже на границе.
1. Интеграция, которой нет. Самая частая причина. Платформа поддерживает двадцать популярных CRM, а у вас самописная база, отраслевая система учёта или 1С. Вендор честно говорит «через API можно» — и выясняется, что API либо нет, либо он односторонний, либо доработка стоит как половина разработки.
2. Данные нужны в реальном времени. Коробка умеет отвечать из загруженного текста. Но клиент спрашивает не «какие у вас цены вообще», а «есть ли эта модель в наличии сейчас». Если система не видит остатков в момент разговора, она либо молчит, либо врёт — и второй вариант хуже.
3. Процесс сложнее диалога. Запись к мастеру — это диалог. А вот приём заявки на ремонт, где надо проверить гарантию, подобрать сервисный центр, зарезервировать деталь и сформировать документ — это процесс. Коробочные решения не проектировались под процессы, только под переписку.
4. Объём сделал подписку дороже разработки. Тарифы за диалог выглядят безобидно на тысяче обращений и начинают больно кусаться на десяти тысячах. Это чистая арифметика, и её легко проверить — калькулятор ниже.
5. Бот стал частью продукта. Если вы продаёте услугу, внутри которой работает бот, отдавать его чужой платформе означает отдавать контроль над качеством собственного продукта и данными клиентов.
Пройдите дерево решений — оно ведёт именно этими развилками и показывает не только вердикт, но и путь, которым вы к нему пришли.
Сколько это стоит за два года
Самая распространённая ошибка при выборе — сравнивать разовую стоимость разработки с месячной стоимостью подписки. Это сравнение ни о чём: в первом случае сумма конечная, во втором — ежемесячная и растёт вместе с вами.
Корректный способ — суммарные расходы за фиксированный горизонт. Два года — разумный срок: за меньший период кастом почти всегда проигрывает, за больший почти всегда выигрывает, а двадцать четыре месяца показывают реальную картину для большинства бизнесов.
Подвигайте ползунки под свои цифры. Модель построена на средних рыночных тарифах SaaS-платформ и наших реальных сметах.
Обратите внимание на поведение графика: точка окупаемости смещается влево прежде всего из-за количества диалогов и количества менеджеров в системе. Именно за них платформы берут больше всего. Если у вас небольшой поток и один-два оператора, коробка выигрывает уверенно — и это нормальный результат.
Скрытые затраты готового решения
Ценник на сайте вендора — не вся сумма. Вот что обычно всплывает после старта.
Оплата за места. Большинство платформ считает не только диалоги, но и операторов. Вырос отдел — вырос счёт, даже если нагрузка на бота не изменилась.
Функции за пределами тарифа. Аналитика, несколько языков, расширенные интеграции, выгрузка данных, снятие брендинга вендора — всё это регулярно живёт в старшем тарифе, который оказывается вдвое дороже того, на который вы ориентировались.
Работа с ограничениями. Расход, который никто не планирует: часы вашей команды, потраченные на обходные пути. Выгрузить отчёт руками, потому что нужного нет. Дублировать запись в CRM, потому что интеграция односторонняя. Объяснять клиентам, почему бот не видит их заказ. За год это складывается в заметные деньги, просто у них нет строки в бюджете.
Привязка к вендору. История диалогов, настройки и база знаний живут в платформе. Переезд означает начать часть работы заново, и чем дольше вы на платформе, тем дороже выход.
Скрытые риски кастома
Было бы нечестно перечислить минусы только одного варианта. У разработки свои слабые места, и о них надо знать до подписания.
Зависимость от подрядчика. Главный риск. Если код и документация плохие, а команда исчезла, вы остаётесь с системой, которую никто не может сопровождать. Это решается на этапе договора: код и доступы принадлежат вам, документация сдаётся вместе с проектом, стек — распространённый, а не экзотический.
Более долгий путь к первому результату. Коробка работает завтра, кастом — через месяц. Если деньги горят сейчас, разумно запустить что-то простое параллельно с разработкой, а не ждать.
Риск переусложнить. Классическая ловушка: заказчик хочет автоматизировать всё и сразу, бюджет раздувается втрое, а половина сценариев потом не используется. Лекарство простое — запускать узко, на самых частых обращениях, и расширять по данным.
Поддержка — это тоже статья расходов. Кастом не «сделали и забыли»: меняются API мессенджеров, обновляются модели, появляются новые сценарии. Закладывайте сопровождение в бюджет сразу, иначе система тихо устареет за год.
Четыре мифа о кастомной разработке
Миф первый: это дорого. Дорого — понятие относительное к альтернативе. Разработка агента с двумя интеграциями стоит примерно как два-три месяца работы одного менеджера поддержки. Вопрос не в том, большая ли это сумма, а в том, за сколько месяцев она возвращается на вашем объёме. Для бизнеса с тысячей обращений в месяц это обычно полгода-год, для десяти тысяч — несколько месяцев.
Миф второй: это долго. Долго — когда пытаются запустить всё сразу. Первая работающая версия на самых частых сценариях выходит за две-три недели, и уже она снимает большую часть нагрузки. Остальное достраивается по данным, параллельно с работой. Проекты, тянущиеся полгода, почти всегда страдают не от сложности, а от отсутствия приоритетов.
Миф третий: поддерживать сможет только автор. Это правда только для плохого кода. Нормальный проект сдаётся с документацией, понятной структурой и распространённым стеком — и любой компетентный разработчик входит в него за несколько дней. Закрепите это в договоре, и миф перестанет быть риском.
Миф четвёртый: нужна своя команда разработчиков. Не нужна. Нужен один человек с вашей стороны, который знает ваши процессы и может отвечать на вопросы о них. Это чаще всего руководитель отдела, а не технический специалист: большинство вопросов в таких проектах не о технологиях, а о том, как у вас на самом деле устроена работа.
Из чего складывается смета
Прозрачность здесь полезна обеим сторонам, поэтому покажем структуру расходов на типовом проекте.
Анализ и база знаний. Разбор ваших процессов, сбор документов, приведение прайса и условий к непротиворечивому виду, подготовка материалов для обучения. Часто самая тяжёлая часть, потому что требует вашего времени — но именно она определяет, будет ли система отвечать правильно.
Интеграции. Наиболее предсказуемо оцениваемая часть: стоимость прямо зависит от количества систем и от того, насколько они готовы к подключению. Популярная облачная CRM с документированным API — это несколько дней. Самописная база без документации — это недели, и честный подрядчик скажет об этом сразу.
Сценарии и границы полномочий. Проектирование того, как агент ведёт себя в разных ситуациях, включая плохие: клиент недоволен, данные противоречат друг другу, нужной информации нет. Эта часть редко видна в коммерческом предложении, но именно она отличает систему, которая выдерживает реальность.
Тестирование на реальных диалогах. Прогон системы на вашей настоящей переписке за прошлые месяцы. Дешёвый и самый полезный этап: он показывает ошибки до того, как их увидят клиенты.
Сопровождение. Ежемесячная статья: мониторинг качества ответов, обновление базы знаний, адаптация к изменениям в API мессенджеров. Закладывайте её сразу — система без сопровождения заметно деградирует за год.
Гибрид: третий вариант, о котором редко говорят
На практике самый частый правильный ответ — не «или-или». Готовая платформа и собственная разработка отлично сочетаются, если разделить роли.
Схема первая: коробка как канал, кастом как мозг. Платформа остаётся интерфейсом оператора и точкой подключения мессенджеров — это та часть, которую нет смысла писать самим. А логика ответов, работа с базой знаний и действия в ваших системах выносятся в собственный сервис, который общается с платформой через API.
Схема вторая: коробка на простом, кастом на сложном. Типовые обращения закрывает готовое решение, а сценарии, требующие ваших данных и действий, маршрутизируются в собственного агента. Клиент разницы не замечает.
Схема третья: кастом как прослойка интеграций. Вы оставляете платформу целиком, но дописываете интеграционный слой, который стыкует её с вашими системами так, как штатные коннекторы не умеют.
Гибрид выигрывает тем, что вы платите за разработку только той части, где коробка действительно не дотягивает, а не переписываете с нуля то, что уже работает.
Как потолок выглядит на практике
Опишем собирательный, но типичный сюжет — мы видим его с небольшими вариациями несколько раз в год.
Интернет-магазин подключает коробочную платформу. Первые месяцы всё хорошо: бот отвечает на вопросы о доставке и оплате, снимает с менеджеров десятки одинаковых сообщений, подписка стоит меньше, чем кофе для офиса. Все довольны.
Дальше накапливаются мелочи. Клиенты всё чаще спрашивают не «как у вас с доставкой», а «где мой заказ» — и бот этого не видит, потому что не имеет доступа к системе. Менеджеры начинают дублировать ответы руками. Приходит сезон, поток вырастает втрое, и счёт за диалоги растёт вместе с ним. Маркетинг просит отчёт по источникам обращений, а в платформе такого среза нет — приходится выгружать и сводить в таблице.
Через год картина такая: подписка стоит уже заметных денег, трое людей тратят часы на обходные пути, а бот закрывает всё меньшую долю обращений, потому что самые ценные вопросы требуют данных, к которым у него нет доступа. Формально система работает. Фактически она перестала решать задачу.
Заметить этот момент вовремя помогает одна простая метрика: доля обращений, которые система закрыла полностью, без участия человека. Если она месяц за месяцем падает, а счёт растёт — вы уже под потолком, даже если всё вроде бы работает.
Как перейти с готового на своё без потерь
Если вы уже год на платформе и понимаете, что упираетесь в потолок, миграция не обязана быть болезненной. Порядок действий такой.
Сначала заберите данные. Выгрузите историю диалогов и базу знаний, пока есть доступ. Это самое ценное, что у вас есть: реальные вопросы клиентов своими словами — лучший материал для обучения новой системы, и купить его негде.
Определите, что работает. Из аналитики видно, какие сценарии реально используются. Переносить надо их, а не весь функционал платформы — обычно оказывается, что из тридцати возможностей в деле около пяти.
Запускайте параллельно. Новый агент берёт на себя один канал или один тип обращений, старая система продолжает работать. Сравниваете качество на реальном трафике, а не на демо.
Переключайте постепенно. Канал за каналом, сценарий за сценарием. Подписку отменяете последней — экономия в тысячу долларов не стоит риска остаться без поддержки клиентов на неделю.
Чек-лист перед решением
Семь вопросов, которые стоит закрыть до того, как что-то подписывать.
- Есть ли в готовом решении интеграция именно с вашей системой — и двусторонняя она или только на чтение?
- Сколько будет стоить подписка при удвоении потока обращений и росте команды?
- Можете ли вы выгрузить свои данные из платформы в нормальном формате и не стоит ли это отдельно?
- Какие именно функции входят в ваш тариф, а какие только в старший?
- Если кастом — кому принадлежат код, доступы и документация после завершения проекта?
- Кто сопровождает систему через год и сколько это стоит?
- Что произойдёт с обращениями, которые система не сможет обработать — куда они пойдут?
Последний вопрос самый важный и чаще всего пропущенный. Любая автоматизация должна иметь чёткий план для случаев, когда она не сработала.
Что выбрать: короткий ответ
Готовое решение или кастомная разработка — это выбор не по бюджету, а по тому, насколько ваши процессы похожи на средние. Коробочное решение выигрывает, когда задача типовая: ответы на вопросы, сбор контактов, небольшой поток и популярная облачная CRM — здесь подписка обойдётся дешевле любой разработки, а запуск займёт дни. Кастомная разработка чат-бота становится обоснованной, когда вы упираетесь в один из пяти потолков: нет интеграции с вашей системой, нужны данные в реальном времени, автоматизировать надо процесс, а не переписку, объём сделал подписку дороже разработки или бот стал частью вашего продукта. Сравнивать варианты надо суммарными расходами за два года, а не разовой суммой против месячной, и учитывать скрытые статьи: оплату за места, старшие тарифы, часы команды на обходные пути и стоимость выхода с платформы. И помните о третьем варианте: гибрид, где готовая платформа остаётся каналом, а собственная разработка берёт на себя логику и интеграции, часто даёт лучшее соотношение цены и контроля — вы платите за разработку только той части, где коробка действительно не дотягивает.
Не уверены, в какую сторону склоняться? Мы бесплатно посмотрим на ваши процессы и скажем честно — даже если честный ответ будет «берите коробку». Напишите нам или посмотрите, как мы делаем ИИ-агента по продажам.
