BORNLI / о разработке по делу
ИИ для диспетчерской: связать обращения и проверить передачу.
Одна проблема может прийти по телефону и из личного кабинета. Разбираем, как предложить связь, сохранить исходники и увидеть, что исполнитель действительно принял задание.
Ограниченный пилот
Начать с повторных обращений и подтверждённой передачи.
ИИ для диспетчерской управляющей компании можно применить к конкретной операции: сопоставить сообщения об одной проблеме, показать основания связи сотруднику и проверить, что созданное задание принято исполнителем. Такой пилот подходит команде с действующим учётом обращений. Он не заменяет аварийную службу и не поручает модели определять безопасность ситуации.
Сначала проверьте существующее ПО: есть ли поиск похожих обращений, связь с объектом, журнал решений и подтверждение исполнителя. Если задача решается настройкой готового продукта, отдельная разработка не обязательна. Кастомный процесс стоит рассматривать, когда обращения приходят из нескольких каналов, идентификаторы не совпадают или передача между системами оставляет непонятный статус.
Ниже — самостоятельная концепция для российского рабочего процесса. Её задача — связать несколько сообщений с одним инцидентом, сохранив каждое обращение. Это отличается от общего расписания выездных специалистов: здесь важнее основания связи, срочность и подтверждение принятия.
Открытый кейс · проверен 07.11.2026
Что показал Student Quarters — и что ещё нужно проверить у себя.
В кейсе EliseAI для Student Quarters поставщик сообщает о 533 часах, сэкономленных на обслуживании в I квартале 2025 года. Описаны обращения по нескольким каналам и настройка ответов под особенности объектов. Это данные американского оператора студенческого жилья, опубликованные поставщиком решения. Подробная методика расчёта и независимая проверка на странице не представлены.
Внешний результат не является результатом BORNLI и не обещает аналогичную экономию российской УК. В собственном сценарии мы выбираем другую границу: AI помогает сопоставить сообщения, а диспетчер проверяет связь и срочность. Инструкции жильцу по самостоятельному ремонту в этот пилот не входят.
Модельный сценарий · концепция BORNLI
Три сообщения, два вида проблемы, ни одного удалённого исходника.
Для статьи мы собрали работающий демонстрационный кабинет. Дом, жители, обращения и события в нём условные; внешняя диспетчерская и реальные исполнители не подключены. Это прототип логики, а не внедрение у клиента.
По условному дому 4 поступили три сообщения. J-317 по телефону: не горит свет на площадке третьего этажа второго подъезда. J-318 из личного кабинета описывает ту же площадку. J-319 касается дверей лифта. Совпадение дома и подъезда не делает третье сообщение дублем первых двух.
Предлагаем сохранять оригинальный текст, канал, время получения, объект и автора записи. Если адреса недостаточно, система должна запросить уточнение у сотрудника, а не угадывать квартиру или этаж. Если используется распознавание звонка, диспетчеру нужен доступ к исходному материалу в пределах установленных прав. Номер обращения остаётся устойчивым при исправлении распознанного текста.
Объяснимое предложение
AI показывает совпадения. Не объявляет проблему закрытой.
В концепте модель предлагает связать J-317 и J-318: совпадают дом, подъезд, этаж и описание освещения. Экран показывает значения из каждого источника рядом. Диспетчер видит, почему возникло предложение, и может его отклонить. Условный процент уверенности не заменяет объяснение.
J-319 остаётся отдельным обращением. По нему нужно проверить срочность по действующему регламенту; ожидание решения по освещению не должно задерживать такую проверку. Модель не подтверждает, что ситуация безопасна, и не назначает нормативный срок реакции.
Для первого пилота предлагаем разделить три исхода: найден подходящий инцидент, найдено несколько кандидатов, совпадение не подтверждено. Во втором случае сотрудник выбирает запись, в третьем создаёт новую. Само сходство текста не должно удалять сообщение или автоматически закрывать запрос жителя.
Контроль человеком
Проверка связи и проверка срочности — разные решения.
Диспетчер открывает исходники J-317 и J-318, подтверждает, что речь об одной проблеме, и отдельно проверяет срочность по регламенту компании. Основание решения сохраняется рядом с проектом инцидента I-084. Обращение J-319 про лифт в этот инцидент не включено.
В прототипе создание задания заблокировано, пока не отмечены обе проверки и не заполнено основание. Это демонстрация последовательности действий, а не доказательство того, что сотрудник фактически изучил ситуацию. В рабочем продукте нужны права, журнал изменений и процедура проверки качества решений.
Если сотрудник выяснил, что сообщения относятся к разным площадкам, связь нужно отменить с сохранением истории. Если после согласования изменилось существенное поле — адрес, категория или содержание, — предлагаем заново запросить проверку. Прежнее подтверждение не должно автоматически распространяться на другую проблему.
Принимающая система
«Задание создано» ещё не означает «Исполнитель принял».
После подтверждения модель создаёт W-084 по инциденту I-084. J-317 и J-318 сохраняют свои номера и связь с заданием. Принимающая система вернула номер записи, однако исполнитель ещё не подтвердил принятие. Поэтому кабинет показывает «Ожидает принятия», а не «В работе» или «Выполнено».
В демонстрации повторная проверка по ключу I-084-v1 находит то же W-084. Нового задания не возникает. Реальный обмен нужно спроектировать отдельно: согласовать идентификатор операции, поиск результата, обновление существующей записи и обработку отказов.
Если ответ потерялся, задача могла быть создана на другой стороне. Перед повторной отправкой нужно выяснить результат прежнего запроса. Если принимающая система не поддерживает надёжный поиск и защиту от дублей, такой повтор следует передать сотруднику. Наличие API само по себе не гарантирует правильный исход.
Отдельное событие подтверждает принятие исполнителем. Если его нет, ответственность остаётся у назначенного контролёра; сроки и порядок эскалации задаются процессом компании. Этот кабинет не устанавливает универсальные нормативы реагирования.
Результат демонстрации
Одна задача по двум обращениям. Ремонт ещё не завершён.
На последнем экране условный исполнитель принял W-084. Все три исходника сохранены: J-317 и J-318 связаны с одной задачей, J-319 остаётся отдельно. Факт ремонта не подтверждён. Это проверяемый результат демонстрации учёта, но не измеренная экономия, не завершённая работа и не клиентский результат BORNLI.
Для будущего пилота предлагаем сначала собрать обезличенную выборку обычных обращений, настоящих повторов и похожих, но разных проблем. Проверять нужно не только успешные связи. Ошибочное объединение может скрыть самостоятельную задачу, поэтому качество решения важнее красивого числа автоматически обработанных сообщений.
| Показатель | Как измерять | Что проверять отдельно |
|---|---|---|
| Время до принятия | От получения до подтверждения исполнителя | Ожидание человека и работа системы — разные части времени |
| Ошибочные связи | Число неверных объединений на проверенной выборке | Разные этажи, категории и повторное возникновение проблемы |
| Повторные задания | Записи после сбоя и повторной отправки | Одна задача в интерфейсе может скрывать две в принимающей системе |
| Пропущенные срочные обращения | Разбор решений по утверждённому регламенту | Распознавание, передача и действия сотрудника |
В нашем концепте эти показатели отмечены как «Не измерено». Результат пилота нужно сравнить с исходным процессом и учесть стоимость моделей, проверки исключений и сопровождения. Часы из внешнего кейса не подставляются в этот расчёт.
Что подготовить
Один поток обращений, одна система заданий, явные правила.
Для первой оценки нужны каналы поступления, обезличенные примеры сообщений, справочник объектов, правила проверки срочности и описание передачи исполнителю. Полезно показать обычное обращение, повтор, похожую другую проблему, неясный адрес и потерянное подтверждение. Сначала определим, что уже умеет существующее ПО и какой конкретно участок остаётся ручным.
Пилот можно ограничить одним типом плановых обращений и работой под контролем диспетчера. Автоматические советы по ремонту, самостоятельные решения о безопасности, обзвон жителей и изменение аварийного регламента требуют отдельного проектирования; они не добавляются незаметно к разбору очереди. Стоимость и срок AI-проекта определяются после проверки систем и правил обмена.
Разобрать мой процесс с BORNLI — опишите в форме, откуда приходят обращения и где теряется подтверждение. Для первого контакта достаточно названия системы и задачи, без персональных данных жителей, записей звонков и доступа к рабочему кабинету.
От ручной работы к понятному процессу
Разберём один процесс вашего бизнеса.
Опишите, что сотрудники делают вручную и какими системами пользуются. Уточним входные данные, контроль человеком и границы пилота. Состав работ и стоимость согласуем до старта.
Разобрать мой процесс ↗