Бот, который читает 50 домовых чатов вместо живого сотрудника
Как автоматизация обращений жильцов избавила УК «Добрые соседи» от найма отдельного диспетчера и превратила хаос в чатах в прозрачную систему заявок
"Постановление обязало нас мониторить домовые чаты. Мы понимали, что посадить человека читать 50 чатов 24/7 — нереально. Нужно было решение, а не костыль."
Проблема: закон обязал, но не объяснил как
Вышло постановление: все управляющие компании обязаны мониторить домовые чаты в мессенджере MAX и реагировать на обращения жильцов наравне с обращениями через ГИС ЖКХ. Штрафы, сроки реагирования — всё серьёзно.
Когда домов один-два, это просто добавляет нагрузку на диспетчера. Но когда домов 10, 20, 50 — это уже отдельная должность. Человек, который целый день сидит в чатах и читает сообщения: «у меня протечка», «нет света в подъезде», «сломался домофон».
- Диспетчер вручную читает 50 чатов
- Обращения теряются в потоке сообщений
- Нет фиксации — нет ответственности
- Жильцы не знают, принято ли обращение
- Штрафы за пропущенные обращения по закону
- Бот мониторит все чаты автоматически 24/7
- Каждое обращение зафиксировано и передано
- Жилец получает подтверждение и статус заявки
- УК имеет доказательную базу по каждому обращению
- Один человек управляет всем потоком заявок
Простая математика, неудобный ответ
Прежде чем идти к нам, УК считала затраты на ручной мониторинг чатов
50 домовых чатов — это поток сообщений 24/7. Диспетчер уже не справляется: у него и без чатов хватает работы. Значит — новый сотрудник.
Минималка не привлечёт толкового человека. Реальная рыночная зарплата — 50 000 ₽/месяц. Это нижняя планка.
50 000 × 12 = 600 000 ₽. Без налогов, отпускных, больничных, оборудования. И это один человек на одну смену.
2 года — 1,2 млн. 5 лет — 3 млн. И каждый год — риск, что сотрудник уволится, заболеет, или просто не заметит важное обращение.
"Зачем читать вручную? Пусть бот читает."
Решение: начали с простого, выросли в платформу
Задача декомпозировалась на два уровня: бот в чатах, который реагирует на обращения жильцов, и внутренняя система для сотрудников УК, которая управляет потоком заявок.
Версия 1: бот-детектор обращений
Бот читает все сообщения в домовых чатах. Если видит ключевые слова или паттерны — мгновенно реагирует: информирует жильца и предлагает кнопку для оформления заявки.
Ограничение: сформированное обращение приходило представителю УК в виде сообщения, и он вручную заводил заявку. Воронка есть, но «дырявая».
Версия 2: полноценная CRM для УК
Веб-интерфейс для сотрудников УК с приёмом заявок напрямую из бота, назначением исполнителей, статусами и уведомлениями через тот же мессенджер MAX.
Итог: замкнутый цикл от обращения жильца до отметки о выполнении — без ручного переноса данных между системами.
Как бот распознаёт обращения
Первичная оценка обращений — кластер паттернов по 5 категориям. Срабатывание не чаще раза в 15 минут на тип, чтобы не засорять чат.
Если есть возможность — перекройте воду.
Для оперативной реакции оформите аварийную заявку.
При необходимости создайте заявку для передачи электрику.
Для передачи информации специалистам оформите заявку.
Для передачи ответственным службам требуется заявка с описанием и фото.
Круглосуточная АДС: +7 861 207-07-90
Сайт: ds-krd.ru
Как жилец подаёт заявку через бота
После нажатия кнопки в чате открывается диалог с ботом. Процесс идентификации и создания заявки занимает 2–3 минуты.
Идентификация жильца
Лицевой счёт абонента ЖКУ + номер прибора учёта (счётчик холодной/горячей воды или электричества). Двойная проверка исключает подбор чужого счёта методом перебора.
Выбор категории обращения
Жилец сам категоризирует проблему из 10 вариантов — чтобы заявка сразу попала к нужному специалисту.
Описание и фото/видео
Жилец описывает проблему текстом, при необходимости прикрепляет фото или видео. Всё это передаётся в CRM вместе с заявкой.
Заявка создана — жилец получает уведомления
После подтверждения заявка появляется в CRM сотрудников УК. Жилец получает уведомления в мессенджере на каждом этапе:
Что увидел диспетчер УК
Первая версия пересылала обращения сообщением — диспетчер вручную создавал заявку. Это была воронка с дырой. Доработали до полноценной CRM.
Приём заявок из бота и вручную
Заявки из домовых чатов попадают в CRM автоматически. Диспетчер может создать заявку и вручную — при звонке или личном обращении.
Назначение исполнителя
Диспетчер назначает мастера на заявку. Мастер получает уведомление в мессенджере MAX — тот же канал, не нужна отдельная система.
История изменений и статусы
Полная история каждой заявки: кто принял, кто назначил, когда приступили, когда завершили. Доказательная база для регулятора.
Диалог с жильцом от имени УК
Через веб-интерфейс диспетчер ведёт переписку с жильцом прямо в мессенджере MAX — не переключаясь между приложениями.
Заказ деталей мастером
Если для ремонта нужны детали, мастер создаёт запрос прямо из заявки. Статус «Заказ деталей» видит и жилец — никакой неопределённости.
Отчёты по формам УК
Формирование отчётов по заявкам и ремонтам в форматах, предоставленных УК — для сдачи регулятору и внутренней аналитики.
Управление автоответами бота
Интерфейс для редактирования автоматических сообщений, категорий заявок и паттернов распознавания — без разработчика.
Передача показаний счётчиков
Через того же бота жильцы передают показания приборов учёта. Данные сразу в системе — ни звонков, ни бумажных квитанций.
Результаты
Для жильцов
- Заявка в 2–3 клика, без звонков на горячую линию
- Уведомления о каждом изменении статуса
- Понятно, кто и когда придёт
- Передача показаний счётчиков через тот же бот
Для УК
- Не нужен отдельный сотрудник для мониторинга чатов
- Все обращения зафиксированы — доказательная база
- Мастера получают задания в тот же мессенджер
- Отчёты в нужных форматах автоматически
Почему не взяли готовый продукт
На рынке есть сервисы для ЖКХ. Но у каждой УК — своя специфика, свои регуляторные требования и свои интеграции.
Интеграция с конкретным мессенджером
Закон требует именно MAX. Готовые решения для ЖКХ не интегрированы с MAX API или требуют доработки, которая стоит дороже кастомного решения.
Идентификация по приборам учёта
Логика верификации жильца через лицевой счёт + номер счётчика специфична для этой УК. Типовое решение такого не поддерживает.
Отчёты в нужных формах
УК обязана сдавать отчётность в конкретных форматах. Готовые продукты дают выгрузку «вообще», а не под требования регулятора.
Единый канал для всех участников
Жилец, диспетчер, мастер — все работают через MAX. Не нужно учить три разных приложения. Скорость внедрения — недели, не месяцы.
У вашей УК похожая ситуация?
За 30 минут разберём, сколько стоит мониторинг чатов вручную у вас и что можно автоматизировать уже сейчас.
АК