Связать путь покупателя от сообщения до доставки
Объединить сайт, каталог, четыре канала общения, карточку клиента, заказ, остатки и доставку, чтобы сотрудникам не приходилось переносить сведения между системами вручную.
Сохранить историю и защитить важные действия
Брать цены и наличие из магазина, связывать диалог с клиентом и заказом, не терять контекст между каналами и не повторять списание, заказ или отправку при неопределённом ответе внешней системы.
Проверенная система вместо набора отдельных сервисов
На принятой версии прошли 17 из 17 рабочих сценариев и сверили 15 реальных заказов без тестовых записей между связанными системами. Это подтверждает работу выбранного пути, но не рост продаж.
У магазина уже были сайт, клиенты и рабочие сервисы, но вопрос покупателя, актуальный каталог, карточка клиента, заказ, остаток и доставка жили отдельно. Мы связали их в один проверяемый путь и отдельно защитили действия, где ошибка означает неверную сумму, повторный заказ или потерю истории общения.
Разобрать ваш путь от обращения до заказа
Откроется Телеграм. На первом шаге назовите только каналы и рабочие системы и кратко опишите путь от обращения до заказа. Персональные данные, карточки клиентов и сведения о заказах отправлять не нужно. Мы определим, какой участок пути проверить первым.
Сервисы работали рядом
Сайт, переписки, клиентская база, каталог, учёт и доставка хранили свои части заказа. Историю общения приходилось восстанавливать, а неудачный повтор мог создать дубль.
Один проверяемый путь заказа
Каталог отвечает за цены и наличие, система учёта клиентов связывает человека и диалог, проверенная логика защищает важные записи, а сотрудник видит заказ как одну историю.
Кто отвечал за решение
Проектом руководил Дмитрий: формулировал бизнес-правила, определял границы автоматизации, принимал важные рабочие сценарии и связывал путь покупателя с устройством сайта, клиентской базы и учёта. Разработку, связь систем, проверку и поддержку вела команда.
| Проект | Собственный проект интернет-торговли |
|---|---|
| Ниша | Интернет-продажа мёда и продуктов пчеловодства |
| Регион | Россия; операционный центр в Республике Башкортостан |
| Период основной разработки | С середины июля до конца августа 2026 года |
| Что вошло | Сайт, интернет-магазин, система учёта клиентов, мессенджеры, ИИ-продавец, внутренние помощники, учёт товаров и доставка |
| Что подтверждено | Рабочие версии, сохранённые экраны, проверки на реальных системах и сверки заказов |
Исходная точка
Проект развивался постепенно. Отдельно существовали сайт и интернет-магазин, рабочие диалоги, система учёта клиентов, внешние каналы, склад и внутренний учёт. По мере роста связей проявились проблемы, которые нельзя решить одной инструкцией для ИИ: терялась история общения, сообщение слабо связывалось с заказом, внешняя система могла не подтвердить запись, повторная доставка создавала дубли, а исторические карточки клиентов смешивались с текущими продажами.
Главный риск был не в том, что ИИ ответит слишком длинно. Опаснее, если он назовёт устаревшую цену, объявит запись успешной без надёжного подтверждения, повторит заказ после обрыва связи или объединит двух людей по похожему имени. Поэтому мы начали не с «умного текста», а с правил: каким данным можно доверять, кто имеет право менять заказ и как проверять важные действия.
Диагностика и стратегия
Мы разделили проект на три уровня.
Клиентский уровень. Покупатель пишет в привычном канале и получает один человеческий ответ от ИИ-продавца. Внутренние помощники не выходят к покупателю от своего имени.
Товары и заказы. Каталог, цены, заказы и наличие берутся из интернет-магазина. Система учёта клиентов хранит историю общения и сделки. Учёт и склад отвечают за остатки и движение товаров. Стоимость доставки считается по отдельным правилам.
Уровень безопасности. Свободный текст модели отделён от операций, которые меняют деньги, остатки, заказы и отправления. Неизвестный исход не повторяется автоматически: сначала система проверяет фактический результат в целевой системе.
Это позволило развивать существующий бизнес без рискованной полной переделки. Старые функции подключали поэтапно и после каждого шага проверяли, что они по-прежнему работают.
Что сделали
Собрали единый путь покупателя
Путь начинается не с выбора технологии, а с вопроса клиента. Система должна понять, что человек хочет купить, прочитать живой каталог, сохранить выбранные позиции, уточнить город и доставку, собрать контакты, показать сводку и только после подтверждения передать заказ на запись. Уже известные данные сохраняются между сообщениями.
Создали собственный кабинет управления ИИ
Владелец получил кабинет, где видны помощники, рабочие инструкции, параметры, источники знаний, доступные действия, связи с другими системами и их состояние. Настройка не считается применённой только потому, что значение записано в файл: она должна появиться в кабинете и использоваться рабочей системой.
Связали сообщения с системой учёта клиентов, а не просто сложили их в архив
Для рабочего отдела продаж недостаточно выгрузить переписки. Нужно знать, к какому клиенту относится диалог, какой канал разрешает ответ, где находится сделка и какой источник подтверждает факт. В системе учёта клиентов появились единое окно, карточки, маршруты ответа и правила сопоставления людей. Неоднозначные совпадения не объединяются автоматически.
Перенос старой истории контролировали по сводным числам: отдельно проверяли контакты, сделки, диалоги и сообщения. В отчёте на конкретную дату после переноса было 5 246 карточек контактов и 96 233 сообщения. Эти числа описывают тот отчёт, а не текущий размер базы.
Отдельно фиксировалось, где ответ возможен через бота, где только вручную через личный аккаунт, а где история остаётся только для чтения. Это важнее красивой надписи «канал подключён»: без подтверждённого маршрута система не должна обещать отправку.
Разобрать ваш путь от обращения до заказа
Сделали интернет-магазин источником цен и наличия
ИИ-продавец не хранит цены в свободном тексте. Фасовки, цены, вес и наличие приходят из магазина. Если позиции нет в обычном наличии, система отдельно учитывает разрешённый предзаказ. Состав заказа и стоимость доставки рассчитываются на сервере до ответа покупателю.
Для бизнеса это означает простое правило: разговор с покупателем не живёт отдельно от товарной витрины. Меняется наличие товара — это же изменение должны увидеть сайт, корзина, продавец и другие связанные системы.
Разделили ИИ-продавца и внутренних специалистов
Покупатель общается только с продавцом. Если продавцу не хватает подтверждённого факта, он сразу запрашивает его у внутреннего помощника по складу, учёту или бухгалтерии. Такой запрос может только прочитать данные. Он не может списать товар, провести оплату или изменить заказ.
Изменение данных остаётся отдельным действием. Сначала сотрудник или разрешённый сценарий получает сводку, затем подтверждает конкретное действие, после чего сервер выполняет только заранее предусмотренную команду.
Защитили систему от повторов и неопределённого исхода
У каждого входящего события есть собственный маршрут обработки. У подтверждённой бизнес-операции есть постоянный ключ. У каждой попытки ответа есть отдельная запись доставки. Если внешняя система вернула явный отказ до выполнения, попытку можно повторить. Если действие могло выполниться, но проверяемого ответа нет, система останавливается и требует сверки.
Сервер помнит состояние каждого действия, не даёт выполнить его одновременно дважды, повторяет только безопасные запросы и отправляет сомнительный результат на отдельную сверку. Важные данные хранятся защищённо, а в журнале остаются только сведения, нужные для проверки.
Дали команде рабочий мобильный интерфейс
Часть системы доступна в мобильном приложении: рабочий центр, помощники, диалоги, клиентские карточки и публикации. Сохранённые контрольные экраны показывают интерфейс конкретной версии, но не заменяют свежую проверку работающей системы.
Техническая часть: как устроена система
Бизнес-слой
Для покупателя система выглядит как один продавец. Он видит товар, сумму, доставку и следующий вопрос. Для сотрудника это одна карточка клиента и связанный заказ. Внутри решение разделено на независимые части, чтобы сбой публикаций не останавливал учёт клиентов, а ошибка одного канала не ломала остальные.
Каналы и обработка сообщений
Сообщения и действия с сайта и мессенджеров приводятся к единому внутреннему виду. Рабочая система восстанавливает историю общения, выбирает безопасную последовательность действий и обращается к каталогу или профильному помощнику. На сохранённом снимке работающей версии были активны четыре клиентских канала: сайт, «Макс», «Телеграм» и «ВКонтакте». Это исторический снимок, а не утверждение о состоянии в момент чтения страницы.
Товары, суммы и заказы
Коммерческие правила не зависят от свободного ответа ИИ. Сервер рассчитывает состав заказа, вес, упаковку и допустимую доставку. Интернет-магазин хранит заказ, цены и сведения о товарах; рабочая система связывает склад, оплату, движение и отправление.
Клиентская карточка и сопоставление людей
Система учёта получает источник обращения, историю, карточку клиента и сделку. Человека сопоставляют по проверяемым признакам: телефону, номеру пользователя в мессенджере, учётной записи на сайте и номеру во внешней системе. Совпадение имени само по себе не даёт права объединить записи.
Надёжность и выпуск
Каждый выпуск проходит по зафиксированному списку файлов и контрольным суммам: сначала резервная копия и проверочная среда, затем быстрые проверки, ограниченный запуск и возможность вернуться к прошлой версии. В сохранённом отчёте все предусмотренные проверки взаимодействия частей системы пройдены; это подтверждает конкретную версию, а не обещает вечную безотказность.
Разобрать ваш путь от обращения до заказа
Результат
- В проверке работающей версии единый ИИ-помощник прошёл 17 сценариев из 17. Проверялись многострочный заказ, история общения, поиск покупателя, каталог, доставка и запрет ложного сообщения об успешной записи.
- В отдельной проверке сверили последние 15 реальных заказов без тестовых записей между интернет-магазином, кабинетом, МойСкладом, системой учёта клиентов, таблицей учёта и записью внутри системы. Один реальный разрыв в передаче данных нашли, восстановили точечно и перепроверили.
- Четыре реальные операции владельца сверили между интернет-магазином, системой учёта клиентов, МойСкладом и таблицей учёта; повторная проверка не вернула ошибок.
- Для системы учёта клиентов сохранены безопасные сводные доказательства переноса истории и маршрутов ответа, а снимки со строками клиентов исключены из пакета.
- Мобильное приложение показывает, что владельцу и команде не нужно работать только через служебные журналы на сервере.
Результат не в количестве написанного кода. Он в том, что для пути клиента и важных действий определили источники данных, права доступа, порядок проверки и остановку при неопределённости.
Какие услуги вошли в проект
Автоматизация интернет-продаж
Один путь от обращения покупателя до заказа и доставки.
Интернет-магазин и товарный учёт
Каталог, цены, наличие и заказ работают на общих данных.
Битрикс24 и единое окно сообщений
Диалог связывается с человеком, карточкой и заказом.
ИИ-продавец и связи между системами
Ответы покупателю отделены от действий с деньгами, товарами и заказами.
Похожая задача в услугах недвижимости: как с нуля упаковали переезд на Алтай и связали путь клиента с работой брокера.
Как считали
У каждого числа в кейсе есть источник и дата.
- Набор сценариев взят из проверки работающей версии единого ИИ-помощника. В отчёте отдельно зафиксированы итог и ограничения: реальным покупателям проверочные сообщения не отправлялись.
- Число проверенных заказов взято из того же отчёта. Сверка проходила не по одному экрану, а между интернет-магазином, кабинетом, МойСкладом, системой учёта клиентов, таблицей учёта и записью внутри системы.
- Размер клиентской базы после переноса истории взят из безопасных сводных отчётов. Он не используется как текущий размер базы.
- Число частей системы, доступных действий и правил их взаимодействия взято из сводки по конкретной версии.
- Списки файлов выпуска подтверждают состав и контрольные суммы, но сами по себе не доказывают текущее состояние работающей системы.
Ограничения
- В материалах проекта нет сопоставимых периодов до и после по продажам, доле обращений с заказом и выручке. Мы не заявляем коммерческий рост.
- Снимки экранов показывают проверенные версии на дату их создания. Они помогают понять устройство системы, но не заменяют проверку её текущего состояния.
- Доступ внешнего канала может истечь, а сторонняя система может изменить ограничения. Отметка «работает» в старом отчёте не означает вечную доступность.
- В перенесённой клиентской базе остаются неоднозначные дубли и неполные связи. Их нельзя объединять автоматически без достаточного доказательства личности.
- Устройство системы снижает риск дублей, но внешняя система не всегда позволяет доказать, что действие выполнено ровно один раз. Если надёжного подтверждения нет, система останавливает повтор и переводит событие на сверку.
Следующий шаг
Если у вас сайт, мессенджеры, клиентская база и учёт уже существуют, но работают отдельно, начнём с карты текущего пути клиента. Разберём, где теряется история, какие данные должны стать главным источником и какую связь нужно сделать первой. Это диагностический разбор, а не обещание немедленно заменить все системы.