Один из моих клиентов — крупная федеральная компания, представленная в 15 городах России. Компания продолжает активно развиваться, и количество городов постоянно увеличивается.
Генеральный директор (он же — основатель) достаточно глубоко погружён в операционную работу и многие ключевые решения принимает самостоятельно.
Кроме того, в компании существует служба контроля качества (далее — СКК). Она занимается всеми вопросами, связанными с качеством работы: как внутренними, так и возникающими при взаимодействии с внешними клиентами.
В какой-то момент сложилась ситуация, при которой генеральный директор узнавал о проблемах на местах уже после того, как всё, по сути, случилось. Возможности увидеть проблему в момент её появления, вовремя подключиться и помочь с её разрешением у него не было.
Чтобы изменить эту ситуацию, решили протестировать гипотезу. В качестве пилотного города выбрали Хабаровск. Сотрудников попросили каждый день присылать ежедневный отчёт.
В отчёте нужно было обозначить несколько моментов:
свою фактическую занятость в течение рабочего дня
проблемы, с которыми столкнулся сам сотрудник, даже если они кажутся небольшими и незначительными
проблемы коллег, о которых ему стало известно
собственные достижения и успехи за день
Важный смысл, который транслировался сотрудникам: «ежедневный отчёт — не формальная отчётность, а инструмент раннего обнаружения проблем и контроля загрузки».
Отчёт можно было отправить в удобном для сотрудника мессенджере. Все сообщения получал специалист СКК.
После получения каждого сообщения сотруднику вручную отправлялось подтверждение о получении отчёта.
Для учёта специалист СКК создал отдельный реестр в Google-таблице. В нём изо дня в день сохранялись сведения по сотрудникам и отмечалось, кто прислал отчёт вовремя, кто сделал это с опозданием, а кто не прислал его вообще.
Также в конце дня специалист СКК вручную анализировал всю полученную информацию и готовил для генерального директора сводку.
В неё входила общая информация о занятости сотрудников, обнаруженных проблемах и достижениях, а также о том, кто предоставил ежедневный отчёт, а кто этого не сделал.
Сводка отправлялась непосредственно генеральному директору.
Гипотеза подтвердилась, результат оказался положительным, было принято решение масштабировать процесс на все города присутствия.
Однако довольно быстро стало понятно, что ручная обработка занимает слишком много времени. До двух часов в день уходило на обслуживание этого процесса в одном-единственном Хабаровске.
Поэтому коллеги задумались об оптимизации процесса.
С этим запросом они обратились ко мне: описали существующую ситуацию, продемонстрировали артефакты, примеры отчётов и попросили предложить, как Битрикс24 может помочь автоматизировать ежедневные отчёты и подготовку сводки.
В процессе анализа я рассмотрел разные варианты. Изначально хотел предложить частичную автоматизацию, однако постепенно стало понятно, что единственным правильным решением будет автоматизировать полный ежедневный цикл бизнес-процесса.
Система должна самостоятельно:
принимать и учитывать все сообщения
помогать сотрудникам составлять корректные отчёты
подтверждать приём отчётов
вести дневной реестр
определять статусы
собирать данные
формировать сводку и отправлять её генеральному директору
Это позволит снять со специалистов СКК всю рутинную работу, связанную с ежедневными отчётами. В результате они смогут сконцентрироваться на действительно важных задачах:
работе с проблемами и предложениями
подключении новых сотрудников и городов
помощи сотрудникам в вопросах отчётности
отработке значимых сигналов под контролем генерального директора
Первым принципиальным вопросом было то, как сотрудники будут передавать отчёты в систему. Просить их заходить в отдельную форму или осваивать новый инструмент не хотелось: это усложнило бы внедрение и потребовало бы менять уже сложившийся порядок работы.
Поэтому я решил сохранить привычный для сотрудников способ: отчёт по-прежнему можно отправить обычным сообщением в мессенджере.
Для приёма и учёта сообщений я запланировал создать чат-ботов для Битрикс24 и MAX. Именно через эти мессенджеры подавляющее большинство сотрудников присылало отчёты.
Через этих же ботов планировалось отправлять сформированные сводки.
Второй принципиальный вопрос заключался в том, как формировать итоговую сводку. Простого объединения сообщений было недостаточно: генеральному директору требовался не набор ежедневных отчётов, а краткая картина происходящего — информация о занятости сотрудников, проблемах, достижениях и сигналах, требующих внимания.
Сотрудники описывали события рабочего дня в свободной форме, поэтому формировать такую сводку с помощью жёстких правил и шаблонов было бы сложно. Для анализа отчётов я решил использовать ИИ.
Сначала рассмотрел два варианта: локальное развёртывание модели и использование готового сервиса. После сравнения решил остановиться на сервисе GenAPI https://gen-api.ru
Ранее с этим сервисом я не работал, но был приятно удивлён количеством доступных моделей.
Для проверки я сформировал тестовый промпт:
в системной части указал инструкции для нейросети по анализу данных и генерации сводки
в пользовательской части передал имитацию реального массива ежедневных отчётов
И затем протестировал взаимодействие с GenAPI через API с помощью Postman.
По соотношению цены и качества ответов выбрал Qwen 3.6 Plus.
Таким образом, определилась общая концепция решения: сотрудники продолжают отправлять отчёты привычным способом, чат-боты принимают и учитывают сообщения, а ИИ анализирует собранные данные и формирует сводку. После этого можно было переходить к проектированию структуры данных и составлению плана разработки.
На этом этапе уже было понятно, как должен выглядеть процесс в целом:
Оставалось определить, где хранить данные, как сопоставлять пользователей разных систем, контролировать отсутствующие отчёты и связать между собой все этапы процесса.
Первым делом я решил отказаться от отдельной Google-таблицы. После автоматизации она превратилась бы в ещё одно хранилище, которое пришлось бы синхронизировать с Битрикс24. Это только усложнило бы систему и создало риск расхождения данных.
Поэтому все сведения я решил хранить непосредственно в Битрикс24. Для этого запланировал создать два смарт-процесса:
«Ежедневные отчёты» — для хранения сотрудников, отчётных дат, исходных сообщений, каналов получения и текущих статусов
«Ежедневные сводки» — для хранения готового текста сводки и результатов её отправки
Для сопоставления двух учётных записей я предусмотрел в профиле пользователя дополнительное строковое поле «ID пользователя в MAX».
Сложность заключалась в том, что сотрудники не знают своих идентификаторов в MAX. Поэтому я предусмотрел простой сценарий первоначального подключения. Если сотрудник пишет боту, а система не находит в Битрикс24 пользователя с таким идентификатором, бот сообщает об этом, предлагает обратиться к администратору и одновременно показывает сотруднику его ID в MAX.
Полученный идентификатор затем вручную записывается в профиль пользователя Битрикс24. После этого система может связать все следующие сообщения из MAX с конкретным сотрудником и обрабатывать их на общих основаниях.
Для подключения нового города специалист СКК составляет список сотрудников и выясняет у каждого, через какой мессенджер ему удобнее отправлять ежедневные отчёты.
Тем, кто выбирает MAX, передаётся инструкция: сотруднику нужно написать боту, получить в ответ свой ID и сообщить его специалисту СКК.
После этого специалист СКК собирает общий список сотрудников с выбранными каналами и идентификаторами MAX и отправляет его мне.
Я заполняю необходимые поля в профилях пользователей Битрикс24:
указываю рабочий город в штатном поле WORK_CITY
устанавливаю признак «Требуется ежедневный отчёт» в созданном мной дополнительном поле
указываю ID пользователя в MAX, если сотрудник выбрал этот мессенджер
На этом подключение города завершается, и его сотрудники могут начинать работу с системой ежедневных отчётов.
Просто сохранять поступившие сообщения было недостаточно. В этом случае система видела бы только тех, кто прислал отчёт, но не могла бы определить, от кого сообщение ожидалось, но так и не поступило.
Поэтому на каждый рабочий день система должна заранее создавать реестр сотрудников, обязанных предоставить отчёт. Для каждого сотрудника создаётся отдельная запись с первоначальным статусом «Не получен».
При формировании реестра система проверяет кадровый график отсутствий. Если сотрудник находится в отпуске, на больничном или в командировке, его запись получает статус «Не ожидается» с указанием основания в отдельном поле смарт-процесса. Благодаря этому человек не попадает в перечень не отчитавшихся при формировании сводки.
После получения сообщения статус меняется на «Получен вовремя» или «Получен с опозданием». На одного сотрудника за одну дату принимается только один отчёт: первое корректное сообщение сохраняется, а последующие считаются повторными и не изменяют уже принятую запись.
Весь процесс должен запускаться автоматически по расписанию. В начале нового рабочего дня система формирует реестр на текущую дату, после чего закрывает предыдущий рабочий день: собирает данные, передаёт их на анализ, сохраняет готовую сводку и отправляет её в групповые чаты Битрикс24 и MAX.
В анализ должны попадать не только тексты полученных отчётов, но и сведения о тех, кто не отчитался или официально отсутствовал. Только в этом случае генеральный директор получает полную картину дня, а не выборку из поступивших сообщений.
Оба канала отправки должны работать независимо. Если сводку не удалось отправить в один мессенджер, система всё равно пытается доставить её во второй. Информация об ошибке фиксируется, а администратор получает уведомление по электронной почте.
При этом состав сводки фиксируется на момент обращения к AI-сервису. Если сотрудник пришлёт запоздалый отчёт уже после её формирования, запись в реестре обновится, но готовая сводка автоматически пересобираться не будет.
На этапе проектирования я также зафиксировал ограничения первой версии. Система принимает только текстовый отчёт, отправленный одним сообщением с определённым префиксом. Голосовые сообщения, изображения и файлы не обрабатываются. Напоминания сотрудникам и автоматическая постановка задач по обнаруженным проблемам также пока не предусмотрены.
Проверку содержания отчёта и помощь сотруднику в его составлении я решил вынести в отдельный этап развития модуля. Сначала требовалось запустить и проверить основной ежедневный цикл.
Чтобы не собирать весь модуль целиком и только после этого приступать к проверке, разработку я разделил на последовательные этапы:
создание каркаса модуля, настроек и двух смарт-процессов
приём и сохранение отчётов из Битрикс24 и MAX
формирование дневного реестра с учётом рабочего календаря и графика отсутствий
подключение AI-сервиса и формирование сводки по данным закрываемого дня
автоматическое закрытие отчётного дня и сохранение результата
отправка сводки в групповые чаты Битрикс24 и MAX
сквозная проверка всего процесса
Моя цель была как можно скорее отдавать полезный результат, чтобы сократить время специалиста СКК на ненужную ручную работу.
Каждый этап должен был завершаться отдельной проверкой на рабочем портале. Это позволяло обнаруживать ошибки сразу, не перенося их на финальную приёмку всей системы.
После фиксации структуры и плана я приступил к разработке модуля.
Основная логика модуля к этому моменту уже была определена на этапе проектирования, поэтому здесь остановлюсь только на моментах, которые появились непосредственно в процессе разработки и тестирования.
Во время тестирования выяснилось, что повторные сообщения бывают двух видов. В первом случае сотрудник сам повторно отправляет отчёт за ту же дату. Во втором мессенджер повторно доставляет одно и то же событие из-за технического сбоя.
Для первого случая достаточно проверить сочетание сотрудника и отчётной даты. Для второго пришлось дополнительно сохранять идентификатор исходного сообщения. Благодаря этому повторная техническая доставка не создаёт новую запись и не запускает обработку заново.
Также я зафиксировал отдельное правило: если сообщение получено, но сохранить отчёт в Битрикс24 не удалось, отчёт считается непринятым. Сотруднику предлагается повторить отправку позднее, а администратору приходит письмо с описанием ошибки.
Ещё одна проблема возникла после того, как MAX перенёс Bot API со старого адреса platform-api.max.ru на новый — platform-api2.max.ru. Внешне это выглядело как сбой обработки вебхуков: событие приходило, но ответный запрос модуля к MAX обрывался ещё на этапе установки защищённого соединения, до обычного HTTP-запроса.
Сертификат нового домена подписан корневым сертификатом удостоверяющего центра Минцифры — «Russian Trusted Root CA». На сервере клиента этого корня не оказалось в системном хранилище доверенных сертификатов, поэтому проверить подлинность нового адреса не удавалось.
Чтобы не зависеть от настроек конкретного сервера, я добавил официальный корневой сертификат непосредственно в состав модуля и настроил HTTP-клиент на его использование только при обращении к MAX. Доверие к этому сертификату не распространяется на весь сервер и остальные внешние запросы.
В процессе разработки выяснилось, что в Битрикс24 есть два похожих источника данных: кадровый График отсутствий и личный календарь сотрудника.
Я решил использовать только кадровый График отсутствий. Если учитывать личный календарь, сотрудник мог бы самостоятельно исключить себя из отчётности обычным событием. Кадровый график, напротив, содержит официальные сведения и контролируется ответственными сотрудниками.
При подключении GenAPI выяснилось, что сервис поддерживает синхронный и асинхронный режимы. Основным я выбрал асинхронный: сервис принимает запрос и возвращает его идентификатор, после чего отдельный фоновый агент проверяет готовность результата раз в минуту.
Всего предусмотрено пять попыток. Если за это время ответ не получен, система фиксирует ошибку и отправляет письмо администратору. При этом остальной ежедневный процесс не зависает в ожидании ответа внешнего сервиса.
Во время проверки отправки обнаружилось ещё одно ограничение: у Битрикс24 и MAX разная максимально допустимая длина сообщения. Поэтому длинную сводку пришлось автоматически делить на части — сначала по границам абзацев, затем строк и слов. Каждая часть получает номер, чтобы сообщения можно было прочитать в правильной последовательности.
От автоматической повторной отправки в первой версии я отказался. При некоторых ошибках связи невозможно точно определить, было ли сообщение доставлено. Автоматический повтор в такой ситуации мог бы создать дубликат в групповом чате, поэтому система фиксирует ошибку и уведомляет администратора.
Каждый этап я проверял отдельно на рабочем портале. После завершения разработки провёл сквозную приёмку всего процесса: от сообщения сотрудника до появления готовой сводки в обоих групповых чатах.
Проверялись отчёты из Битрикс24 и MAX, повторные сообщения, отчёты с опозданием, официальные отсутствия, формирование сводки и её отправка. Отдельно создавались ошибки AI-сервиса и каналов доставки, чтобы убедиться, что доступная часть процесса продолжает работать, а администратор получает уведомление.
После сквозной проверки к модулю начали постепенно подключать новые города и сотрудников. Специалист СКК объяснял правила работы, собирал сведения для настройки профилей и помогал тем, у кого возникали вопросы на старте.
На момент написания этого кейса модуль работает около месяца. К системе уже подключены сотрудники четырёх городов.
Сейчас система самостоятельно выполняет весь основной ежедневный цикл.
Ошибки фиксируются в журнале модуля, а администратору отправляются уведомления. Таким образом, основной процесс работает без ручной обработки сообщений со стороны специалиста СКК.
До автоматизации на обработку отчётов одного Хабаровска уходило до двух часов ежедневно. Теперь специалисту СКК не нужно обходить несколько мессенджеров, подтверждать получение каждого сообщения, переносить данные в Google-таблицу, искать не отчитавшихся сотрудников и вручную составлять итоговую сводку.
Это не означает, что работа специалиста с ежедневными отчётами исчезла полностью. Из неё ушла именно механическая часть. Сейчас время требуется на другие задачи:
подключение новых городов и сотрудников
объяснение правил работы с системой
помощь тем, у кого возникают сложности
работу с проблемами, предложениями и значимыми сигналами из сводки
Главный эффект заключается даже не только в экономии одного-двух часов. Раньше объём ручной работы увеличивался вместе с количеством городов. Теперь новый город добавляет системе новые данные, но не создаёт для службы качества ещё один ежедневный поток ручной обработки.
Генеральный директор при этом получает общую картину по подключённым городам и может направлять внимание на конкретные проблемы, не перечитывая весь массив исходных сообщений.
Получившееся решение привязано к конкретному процессу клиента, но сам подход применим гораздо шире. Он подходит для ситуаций, в которых сотрудники регулярно отправляют однотипную обратную связь, а ответственному человеку приходится вручную собирать сообщения и искать среди них значимые отклонения.
Например, похожим образом можно обрабатывать:
ежедневные отчёты магазинов, филиалов и представительств
отчёты руководителей смен
обратную связь выездных сотрудников
сообщения сервисных подразделений о сбоях и происшествиях
регулярные отчёты участников франчайзинговой сети
Основной признак здесь один: руководству важны проблемы, повторяющиеся сигналы и отклонения, а не необходимость каждый день перечитывать десятки однотипных сообщений.
После начала эксплуатации у участников процесса начали появляться новые идеи по развитию модуля.
Ближайшая доработка — AI-проверка содержания отчёта в момент приёма. Сейчас система проверяет формат сообщения, дату и право сотрудника предоставлять отчёт, но не оценивает его полноту. В новой версии бот сможет передать текст на отдельную проверку и сообщить сотруднику конкретные замечания.
Также среди возможных направлений развития — административные действия для повторного запуска неудавшихся операций, аналитика по городам и периодам, выявление повторяющихся проблем, автоматическая постановка задач по обнаруженным сигналам и подключение дополнительных каналов.
Модуль уже решает первоначальную задачу, но его развитие на этом не заканчивается. Обо всех следующих крупных этапах и результатах их внедрения я буду писать в отдельных кейсах.
В этой истории ручной процесс не был ошибкой. Он позволил компании на одном городе проверить управленческую гипотезу и убедиться, что ежедневная обратная связь действительно помогает раньше замечать проблемы.
Автоматизация появилась уже после того, как польза процесса была подтверждена. При этом автоматизировали не отдельную Google-таблицу и не только подготовку сводки, а весь ежедневный цикл — от сообщения сотрудника до доставки результата руководству.
В результате служба качества сохранила работу со смыслом, но избавилась от механической обработки сообщений. Процесс, который вручную удавалось обслуживать только в одном городе, сейчас работает в четырёх и может масштабироваться дальше без пропорционального увеличения трудозатрат.