Управляющая компания: заявки жильцов, диспетчерская и запись разговоров у себя

MAATRIX

Управляющая компания на десяток многоквартирных домов живёт заявками жильцов: прорвало трубу, не горит лампа в подъезде, не открывается домофон, течёт кровля после дождя. Каждую заявку нужно принять, передать бригаде, проконтролировать выполнение и суметь показать историю, если жилец пришёл с претензией или пришла проверка ГЖИ. На практике приём заявок, диспетчеризация бригад и запись телефонных разговоров почти всегда разъезжаются по разным местам: заявки в WhatsApp-группе, наряды на бумаге у диспетчера, звонки нигде не пишутся или пишутся в облаке стороннего оператора связи. Разберём, как собрать всё это на одном собственном сервере УК — без разрозненных подписок и без данных жильцов на чужой инфраструктуре.

Три потока, которые УК обычно держит порознь

Управляющая компания редко выбирает разрозненность осознанно — она складывается исторически, по мере роста числа домов и штата. К моменту, когда УК обслуживает 10-15 домов, обычно уже накопилась такая картина:

• Заявки жильцов идут отовсюду сразу: звонок на диспетчерский телефон, сообщение в общедомовой чат, бумажное заявление на стойке офиса, иногда — заявка через сайт или приложение ГИС ЖКХ. Единого журнала нет, каждый источник живёт своей жизнью.
• Диспетчеризация бригад держится на человеке, который помнит (или ведёт в тетради или в Excel), какая бригада на каком доме, кто свободен, у кого сколько заявок в очереди. При отпуске или болезни этого диспетчера система на день-два просто останавливается вместе с ним.
• Записи телефонных разговоров либо не ведутся вообще, либо идут через облачную АТС по подписке — и тогда разговор о протечке или аварии физически хранится на серверах стороннего оператора связи, с которым у УК нет договора именно как с обработчиком этих данных.

Каждый поток по отдельности решаем — можно найти сервис под заявки, отдельный под АТС. Проблема в том, что УК платит за несколько подписок сразу и всё равно не получает единой картины: заявка из чата не связана со звонком, который её породил, а диспетчер держит в голове то, что должно быть в системе.

Чем оборачивается разрозненность на практике

Пока домов немного, разрозненность терпима — диспетчер и так всё помнит. Проблемы начинаются на масштабе, когда счёт идёт на сотни квартир и десятки заявок в день.

Спор с жильцом «я звонил ещё в понедельник, никто не приехал» превращается в неразрешимую ситуацию, если заявка нигде не зафиксирована с датой и временем, а звонок не записан. УК не может ни подтвердить, ни опровергнуть — и по умолчанию оказывается неправа, потому что бремя доказательства фактически на стороне, у которой нет системы учёта.

Проверка со стороны государственной жилищной инспекции обычно требует показать журнал заявок и сроки их исполнения — норматив на устранение аварийных неисправностей в большинстве регионов исчисляется часами, а на плановые работы — сутками. Если заявки лежат вперемешку в мессенджере и тетради диспетчера, свести их в единый реестр за прошедший квартал — отдельная муторная работа перед самой проверкой, а не в моменте.

Данные жильцов — ФИО, номер квартиры, телефон, а нередко и содержание жалобы («затопило санузел», «протечка у соседей сверху») — при разрозненной схеме проходят через несколько сторонних сервисов сразу: мессенджер, облачную АТС, стороннее приложение для заявок. Это не то, что подразумевает статус УК как оператора персональных данных жильцов, отвечающего за них перед конкретными людьми, а не перед абстрактным «облаком». Где по закону можно держать такой сервер, разобрано отдельно: 152-ФЗ — где законно держать сервер с персональными данными.

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

Альтернатива: единая система на своём сервере

Смысл перехода не в том, чтобы найти одно волшебное приложение «для УК», а в том, чтобы собрать приём заявок, диспетчеризацию и запись звонков на одном сервере, которым владеет и управляет сама УК. Технически это связка из нескольких открытых компонентов, а не единый монолитный продукт:

• Тикет-система — например, osTicket или Zammad, развёрнутые на вашем сервере. Оба варианта существуют много лет, оба с открытым кодом и умеют главное для УК: принимать заявки по разным каналам в одну очередь и хранить полную историю по каждой.
• Своя АТС на базе Asterisk (обычно через панель FreePBX) — принимает звонки жильцов на диспетчерский номер и пишет каждый разговор на диск сервера.
• Общая база — заявка, созданная по звонку, хранит ссылку на запись этого звонка, а не существует отдельно от него.

Про установку osTicket есть отдельный пошаговый разбор с нуля: как установить и настроить osTicket на VPS. Схема телефонии с записью разговоров на своём сервере подробно разбиралась для похожей задачи в другой сфере — принцип тот же, отличаются только детали хранения: своя АТС и запись разговоров в медцентре.

Важная оговорка: ни osTicket, ни Zammad не написаны специально «для УК» — это универсальные тикет-системы. Диспетчерскую логику (дом, подъезд, тип неисправности, назначенная бригада, статус выполнения) вы настраиваете поверх них через кастомные поля, отделы и статусы. Готового отраслевого решения «диспетчерская УК из коробки» с открытым кодом на практике нет — лучше признать это сразу, чем обещать несуществующую коробочную магию.

Приём и обработка заявок жильцов

Задача первого узла — собрать заявки из всех реальных каналов в одну очередь, а не заставить жильцов резко сменить привычки.

Источники заявок, которые стоит подключить к тикет-системе:

• Электронная почта — отдельный ящик вида zayavki@вашдомен.ru, тикет-система подключается к нему по IMAP и создаёт тикет из каждого письма автоматически.
• Веб-форма на сайте УК — «адрес, квартира, телефон, суть проблемы», создаёт тикет напрямую.
• Телефонный звонок диспетчеру — при интеграции с АТС входящий звонок можно связать с тикетом вручную или через API.
• Мессенджер — если жильцы привыкли писать в общедомовой чат, полностью закрывать его не обязательно, но стоит явно объяснить: официальная заявка регистрируется через форму или звонок, а не через сообщение, которое диспетчер может пропустить.

Дальше заявку классифицируют кастомные поля тикет-системы: дом и подъезд (лучше выпадающий список, а не свободный текст — иначе получите десяток вариантов написания одного адреса), тип неисправности (сантехника, электрика, лифт, кровля, домофон), приоритет (аварийная или плановая).

Пример структуры отделов в osTicket под УК на несколько домов:

Отдел: Аварийные заявки       (приоритет по умолчанию — высокий, SLA — часы)
Отдел: Плановые заявки        (приоритет — обычный, SLA — сутки/несколько суток)
Отдел: Вопросы по начислениям (не техническая заявка, отдельная очередь)

SLA-модуль (есть и в osTicket, и в Zammad) считает время с момента поступления заявки и подсвечивает просроченные — это тот самый журнал сроков исполнения, который спрашивает жилищная инспекция, только собирается он автоматически, а не вручную перед проверкой.

Отдельно стоит продумать уведомления: жилец должен получить подтверждение, что заявка принята (автоматическое письмо или SMS с номером тикета), а не гадать, дошло ли обращение.

Диспетчерская: координация выездных бригад по статусам

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

Базовый набор статусов для заявки, который закрывает реальный рабочий цикл УК:

1. Новая — заявка поступила, диспетчер её ещё не разобрал.
2. Назначена — диспетчер определил бригаду или конкретного сотрудника, тикет переведён на него.
3. В работе — бригада выехала или приступила к устранению.
4. Выполнена — работа сделана, ожидает подтверждения (иногда — обратного звонка жильцу для проверки, что всё в порядке).
5. Закрыта — жилец подтвердил или прошёл контрольный срок без повторного обращения.

Назначение ответственного — это агент (пользователь) тикет-системы, привязанный к тикету; у каждого сотрудника выездной бригады свой логин, через который он видит список своих заявок. Доступ к веб-интерфейсу тикет-системы через мобильный браузер обычно достаточен для работы в поле — специальное приложение не обязательно, хотя удобство, конечно, ниже.

Диспетчер видит общую доску: сколько заявок в статусе «новая» по каждому дому, кто из бригад перегружен, а кто свободен. В Zammad есть представления с фильтрами и группировкой — можно настроить экран «все аварийные заявки за сегодня по дому», что закрывает основную потребность диспетчера без стороннего софта.

Заявки на несколько домов удобно сразу разносить и по территориальной привязке: если у УК есть диспетчеры или бригады, закреплённые за конкретными домами, кастомное поле «дом» с маршрутизацией на нужного диспетчера экономит минуты на каждой заявке, а на масштабе в сотни заявок в месяц это ощутимо.

Отдельная история — аварийные заявки в нерабочее время. Если есть дежурный диспетчер по ночам и выходным, стоит настроить эскалацию: заявка с приоритетом «аварийная», оставшаяся без назначенной бригады дольше заданного времени (например, 30 минут), должна слать уведомление дежурному, а не просто висеть в очереди до утра.

Запись разговоров с жильцами: зачем и как хранить

Запись телефонных разговоров с жильцами для УК — не про тотальный контроль, а про конкретные ситуации, в которых слово против слова ничего не решает:

• Аварийный звонок ночью. «Труба прорвала, звоню диспетчеру, а он говорит — подождите до утра» — если разговор записан, легко проверить, что реально было сказано и когда поступил звонок, вместо пересказа с обеих сторон постфактум.
• Спор о начислениях. Жилец утверждает, что ему по телефону обещали пересчёт, диспетчер говорит, что ничего подобного не говорил. Запись закрывает вопрос за минуту.
• Жалобы на грубость сотрудников. Разбор реальной записи — единственный способ понять, кто прав, вместо «он сказал — она сказала».

Технически запись строится на той же АТС, что принимает звонки: модуль MixMonitor в Asterisk пишет каждый разговор (или выборочно, по внутреннему номеру диспетчерской линии) в файл на диске сервера — сразу после включения модуля в диалплане.

Практические шаги, которые стоит сделать сразу, а не откладывать:

• Голосовое уведомление в начале звонка — «этот разговор записывается в целях контроля качества» через IVR-приветствие или проговаривается диспетчером в первые секунды. Это обязательное условие корректной записи, а не техническая мелочь.
• Каталог записей с ограниченным доступом — не весь ИТ-персонал и не все диспетчеры должны иметь возможность прослушать любую запись, доступ выдаётся по должности.
• Политика хранения по срокам. Обычные разговоры — на разумный срок, определённый внутренним регламентом, записи, приложенные к разбору жалобы или аварии — дольше, до закрытия вопроса. Удаление по истечении срока разумно делать автоматически:

# пример cron-задачи: удалить обычные записи звонков старше 180 дней
0 3 * * * find /var/spool/asterisk/monitor -name "*.wav" -mtime +180 -delete

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

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

Экономика: сколько это стоит на несколько домов

Возьмём условную УК на 12 домов: диспетчерская служба из 3 диспетчеров, 15-20 сотрудников выездных бригад с доступом к своим заявкам. Дальше — не прогноз точных сумм (у каждого провайдера своя тарифная сетка, гадать её здесь бессмысленно), а структура сравнения, которую стоит приложить к своим реальным счетам.

Разница особенно заметна на горизонте роста УК. Каждый новый дом на обслуживании — это новые жильцы, заявки, звонки; в подписочной модели с оплатой за агента или за объём это почти всегда означает рост ежемесячного счёта пропорционально штату. Сервер под связку тикет-система плюс АТС такой пропорциональности не создаёт: очередной диспетчер не добавляет отдельной строки в расходах, пока сервер справляется по ресурсам — а нагрузка от текстовых заявок и голосового трафика на современном сервере умеренная по сравнению, например, с видеонаблюдением.

Есть и вторая сторона, не менее важная, чем деньги: предсказуемость. Облачный сервис заявок или АТС может в любой момент поменять тариф, ограничить бесплатный объём хранения записей — и УК узнаёт об этом постфактум, из письма провайдера. Договор аренды сервера такой неожиданности не создаёт: вы платите за вычислительные ресурсы по заранее известной цене, а не за чужую бизнес-модель.

Частые вопросы