Аварийно-диспетчерская служба ЖКХ: заявки, журнал и сроки

Кратко

Журнал заявок диспетчерской (аварийно-диспетчерской службы, АДС) — это запись каждого обращения жителя с адресом, сутью проблемы, временем приёма, сроком реагирования и исполнителем, доведённая до отметки о выполнении. Главное правило журнала — заявка попадает в него в момент звонка, а не после того, как проблема устранена: иначе журнал показывает не реальную работу диспетчерской, а только её удобную часть. Ниже — что обязательно должно быть в журнале, как разделять аварийные и текущие заявки по срокам и какие ошибки чаще всего делают журнал бесполезным при проверке.

Актуально на 23 сентября 2026 года.

Что обязательно должно быть в журнале заявок населения

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

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

Как считать соблюдение сроков по журналу

Доля просроченных аварийных заявок = Аварийные заявки, выполненные позже нормативного срока / Все аварийные заявки за период × 100%

Пример. За месяц диспетчерская приняла 260 заявок, из них 48 отмечены как аварийные. По журналу видно фактическое время выполнения у всех 48: у 44 срок реагирования уложился в норму, принятую в компании для аварийных заявок, у 4 — превышен. Доля просроченных аварийных: 4 / 48 × 100 % ≈ 8,3 %. Отдельно по 212 текущим заявкам просрочка считается тем же способом, но по своей, более длинной норме, — смешивать эти два процента в одну общую цифру нельзя: они означают разные вещи и проверяются разными людьми.

Частые ошибки ведения журнала

• Заявка попадает в журнал только после выезда бригады. Если диспетчер записывает заявку не в момент звонка, а после того как мастер вернулся с объекта, время реакции в журнале занижено, а реальное ожидание жителя невидимо.
• Аварийные и текущие заявки в одном списке без отметки категории. При проверке невозможно быстро отделить, где действительно нарушен срок реагирования на аварию, а где — обычная плановая заявка, которая просто ещё не подошла по очереди.
• Нет записи о том, кто закрыл заявку и на основании чего. Заявка отмечена «выполнено» без подписи жителя или хотя бы записи исполнителя о результате — при жалобе на повторную проблему невозможно доказать, что первый выезд вообще состоялся.
• Бумажный журнал ведётся параллельно с устными договорённостями. Часть заявок жители передают напрямую слесарю на подъезде, минуя диспетчерскую, — эти обращения не попадают в журнал вообще и не участвуют ни в одной проверке.

Как проверить, что журнал заявок ведётся правильно

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

Как это устроено в TehProf.kz Support

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

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

Как вести журнал учёта заявок населения, если звонки принимают несколько диспетчеров посменно?

Все диспетчеры должны писать в один и тот же журнал (электронный или бумажный), а не в личные записи по смене, — иначе при передаче смены часть заявок теряется между сменами вместе с блокнотом предыдущего диспетчера.

Что такое журнал учёта аварийных заявок и чем он отличается от общего журнала заявок?

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

Как составить и вести журнал учёта заявок АДС с нуля?

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

Зачем нужен журнал учёта заявок населения, если диспетчер и так помнит, кто что просил?

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

Связанные статьи

• Как свести все каналы в одну очередь
• Настройка SLA, приоритетов и крайнего срока
• Как оказывать техническую поддержку: путь обращения, сроки и регламент
• Приоритет заявки: как его определяют через влияние и срочность
• Учёт заявок на перевозку: как вести без потерь