Электрооборудование: 4 разработчика в штате, AI работает — но система упирается в потолок

Проблема

Компания продает электрооборудование и автоматику. 65 000 наименований в каталоге, 500 категорий. Одна позиция может раскладываться на 100–200 вариантов по техническим параметрам.

Команда не пришла с нуля. В штате четыре технических специалиста. За несколько месяцев они сами построили:

• AI-бота, который подбирает товар из каталога. Точность попадания в нужную позицию — 99%
• Ежедневную аналитику менеджеров: время работы, лиды, счета, звонки. Нейросеть ставит оценки и запрашивает объяснения по отклонениям от плана
• Прогнозирование оплаты: нейросеть анализирует сделку и предсказывает вероятность, что счет оплатят
• Базовый анализ звонков: транскрибация и комментарий под каждым звонком

Все работает. Но каждый разработчик строил свой кусок системы отдельно. Общего фундамента нет.

При росте нагрузки система упирается в потолок. Запросы к CRM натыкаются на лимиты API. Все данные стекаются в Google-таблицы — и там тоже лимиты. AI-бот отвечает клиенту за 40 секунд. Для текстового чата терпимо, для голосового агента — нет.

«Здесь важна правильная методология, чтобы мы не наделали ошибок, которые убьют время на исправление.»

Руководитель видит: система работает, но не масштабируется. Нужна архитектура для шести агентов — от заявки до оплаты. И нужен человек, который видел подобные системы не в теории.

Что сделали на консультации

1. Нашли три архитектурных ошибки за первые 10 минут

Попросил у команды доступ к CRM и посмотрел, как устроены рабочие процессы автоматизации.

Google-таблицы как центральная база. Все данные — аналитика менеджеров, сделки, результаты — хранятся в Google Sheets. Руководитель отдела продаж работает с таблицами вместо CRM. Одна операция записи в Google — до 5 секунд. Та же операция в базу данных — 10–15 миллисекунд. Разница в 300–500 раз. При 10 менеджерах и десятках процессов таблицы становятся узким горлом.

Лимиты API CRM. Каждый процесс дергает данные из CRM напрямую. CRM отдает в ответах все поля сделки — десятки лишних параметров. При 10 менеджерах команда упирается в ограничение на количество запросов. Разработчик добавляет паузы между запросами — система замедляется еще больше.

Монолитные процессы. Рабочие процессы автоматизации собраны в монолитные цепочки. Разработчик использует отдельные блоки кода для задач, которые решаются одной строкой. Два блока кода для преобразования даты — вместо одного метода. Чем больше таких процессов, тем сложнее их поддерживать.

2. Спроектировали единый слой данных

Все шесть агентов нуждаются в одних и тех же данных: компании, сделки, звонки, сотрудники. Если каждый агент тянет данные из CRM по отдельности — лимиты, задержки, дублирование.

Решение: один раз выгрузить все данные из CRM в базу данных. Настроить автоматическое обновление через вебхуки — CRM сама сообщает об изменениях. Агенты работают с локальной базой, а не с API.

У команды уже есть PostgreSQL и разработчик, который с ней работает. Фундамент на месте — нужно только перестроить потоки данных.

3. Разобрали конкретный блокер с командой на экране

Разработчик застрял на задаче: нужно обработать несколько файлов-вложений в одном письме. С одним файлом работает, с несколькими — нет. Использует цикл, который не передает бинарные данные.

Показал решение: вместо цикла — вызов подпроцесса. Каждый файл обрабатывается отдельно, параллельно. Проблема решена за 15 минут прямо на звонке.

Заодно показал, как разделить монолитные процессы на модульные. 3–4 небольших процесса вместо одного большого. Каждый можно тестировать и менять независимо.

4. Показали путь от 40 секунд к долям секунды

AI-бот ищет товар из 65 000 позиций. Точность — 99%. Но каждый запрос занимает 40 секунд: бот загружает данные в контекст нейросети, нейросеть ищет.

Альтернатива: семантический и нечеткий поиск внутри базы данных. Запрос идет к базе, база возвращает 3–5 подходящих позиций, нейросеть выбирает из них. Пример из практики: коллега реализовал поиск по 6 миллионам позиций за 42 миллисекунды. Без замены нейросети — за счет правильной работы с данными.

5. Передали готовые инструменты

• Модуль для работы с CRM из AI-инструментов
• Пример аналитики звонков с панелью управления для руководителя
• Скрипт для работы с Google-таблицами без лимитов API

Что получил клиент

Команда ушла с архитектурой и планом. Дальше реализуют сами — люди и компетенции есть.

Ключевой вывод

Когда в штате четыре разработчика и работающие AI-системы — проблема не в технологиях. Проблема в архитектуре.

Каждый разработчик решает свою задачу. Один строит аналитику, другой — бота, третий — парсер почты. Каждый выбирает свой способ хранения данных, свой формат, свои инструменты. Через полгода получается система, которая работает — но не растет.

Признаки:

• Процессы упираются в лимиты API
• Данные хранятся в таблицах, а не в базе
• Каждый новый агент требует нового подключения к CRM
• Бот работает, но медленно — и непонятно, как ускорить

Решение одно: остановиться и спроектировать фундамент. Единый слой данных, модульные процессы, общая архитектура. Это занимает 1–2 недели — но экономит месяцы переделок.