В компании пять программ, а статус заказа всё равно приходится выяснять в чате. Почему?

Представим обычную ситуацию.
Клиент спрашивает, на каком этапе находится его заказ. Менеджер открывает CRM, проверяет таблицу, пишет коллеге и ждёт ответа. В одной программе заказ уже передан исполнителю, в другой он всё ещё числится новым. В результате ответ клиенту зависит не столько от данных, сколько от того, кто сейчас на связи.
Это условный пример. Но он хорошо показывает проблему, с которой стоит начинать разговор об автоматизации.

У каждого инструмента может быть своя задача.
Мессенджер хранит переписку. CRM — карточку клиента. Таблица — расчёты. Приложение исполнителя — перечень текущих работ.
По отдельности всё может функционировать правильно. Проблема возникает в момент передачи информации между ними.
Кто должен изменить статус после выполнения работы? Что произойдёт, если сотрудник забудет это сделать? Какая программа хранит актуальное состояние заказа? Как руководитель узнает, что задача задержалась?
Если на эти вопросы нет однозначных ответов, компания вынуждена компенсировать пробелы ручными сообщениями и повторными проверками. И тогда сотрудники начинают обслуживать не только клиентов и заказы, но и саму систему учёта.

В нескольких инженерных разработках я разбирала отдельные элементы таких процессов.
Delivery Flow Board — небольшое веб-приложение для работы с заказами на доставку. В нём заказ создаётся и проходит четыре статуса: New, Preparing, Out for delivery и Delivered. Важная часть реализации — не просто отображение карточек на доске. У заказа есть идентификатор и состояние, которое хранится в базе данных. Перемещение карточки меняет состояние заказа, а не только его расположение на экране.

Order Tracker — отдельный проект с веб-интерфейсом и API. Он позволяет создать заказ и получить его текущий статус. В проекте предусмотрено сохранение данных между перезапусками контейнера.

TaskFlow Support Requests — табличный прототип учёта обращений. Он показывает более простой уровень организации: у обращения есть идентификатор, дата, описание, приоритет и статус. Для контроля таких данных не обязательно сразу разрабатывать сложное приложение.
Эти три проекта не соединены в одну систему и не являются подтверждёнными клиентскими внедрениями. Но каждый иллюстрирует отдельный инженерный принцип: информацию недостаточно записать — нужно определить, как меняется её состояние и кто отвечает за следующий шаг.

Предположим, в приложении заказ имеет значение «В работе».
Что оно означает для менеджера? Что для исполнителя? Что для клиента?
Менеджер может считать, что заказ передан. Исполнитель — что он получил задание, но ещё не приступил. А клиент — что работа уже выполняется. Одна и та же надпись не устраняет неопределённость, если не согласованы правила переходов. Поэтому при проектировании процесса важно различать три вещи.
Событие: что произошло — например, исполнитель подтвердил получение задания.
Состояние: на каком этапе заказ находится сейчас.
Ответственность: кто должен выполнить следующее действие и что делать при задержке.
Это не обязательно требует искусственного интеллекта. Часто достаточно продуманной модели данных, понятных статусов, корректных прав доступа и правил обновления информации.
AI может быть полезен там, где требуется разобрать неструктурированное сообщение, распознать документ или классифицировать обращение. Но он не заменяет необходимость договориться о том, что для бизнеса означает «заказ выполнен».

Возьмите один реальный заказ, по которому недавно возникал вопрос о статусе. Попробуйте восстановить его путь: где появилась первая запись, кто получил задачу, в какой момент изменилось её состояние и откуда руководитель узнал о завершении.
Особенно полезно посмотреть на моменты, когда сотруднику приходилось писать другому человеку только ради уточнения информации, которая уже должна была быть в системе.
После этого можно измерять конкретные вещи: сколько времени занимает выяснение статуса, сколько заказов остаётся без ответственного и как долго задачи находятся между этапами.
Без этих исходных данных нельзя обоснованно обещать, что автоматизация сэкономит компании определённую сумму.

Проблема компании не всегда в том, что ей не хватает ещё одного инструмента. Иногда у неё уже достаточно программ, но между ними не определены правила работы: откуда берутся данные, кто их проверяет, когда состояние меняется и какой результат считается завершённым.
Поэтому я считаю правильным начинать автоматизацию с разбора самого процесса, а не с выбора нейросети или платформы.

Материалы моих разработок:

В Telegram-канале Maya AI Systems я показываю собственные инженерные разработки, разбираю AI-агентов и объясняю, как устроены рабочие системы.

А в вашей компании откуда руководитель узнаёт настоящий статус заказа — из программы или после сообщения сотруднику?