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