Как принимать заявки из WhatsApp и Telegram без потерь?

Заявки из WhatsApp и Telegram перестают теряться только тогда, когда чат больше не считается рабочим реестром. Житель может писать туда, куда ему привычно, но каждое обращение должно за несколько секунд стать отдельной записью с адресом, сроком, ответственным и историей действий.

Это особенно важно для ОСИ и управляющих компаний, которые принимают дома после старых КСК. Вместе с домом часто достаются несколько телефонных номеров, домовые группы, личные чаты председателя и устные обещания мастеров. Если оставить эту схему как есть, новая команда наследует долги по коммуникации: жильцы помнят, что писали, а управляющий не может ни найти заявку, ни доказать, что с ней происходило.

Чат не заменяет реестр заявок

WhatsApp и Telegram хорошо доставляют сообщения, но плохо управляют работой по дому. В одном потоке сосед присылает фотографию течи, председатель публикует объявление, мастер отвечает голосовым сообщением, а через десять минут начинается спор о парковке. Нужная реплика уезжает вверх. Даже если диспетчер ее заметил, в чате нет обязательной связи между сообщением, исполнителем, сроком и результатом.

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

Я видел типичный провал много раз. В пятницу вечером житель пишет в общую группу о воде возле стояка. Диспетчер ставит реакции и пересылает фото сантехнику. Сантехник отвечает председателю лично, что зайдет утром. В субботу сменяется диспетчер, а мастер едет на другой адрес. К понедельнику в группе уже сотни новых сообщений. Для команды работа как будто не существует, хотя у жильца есть исходное сообщение и обещание исполнителя. В споре обе стороны по-своему правы.

Поэтому полезно разделить четыре сущности, которые обычно смешивают:

• канал приема показывает, откуда пришел сигнал;
• карточка обращения описывает проблему и ее текущее состояние;
• рабочее задание говорит исполнителю, что и когда сделать;
• переписка сохраняет уточнения и уведомления.

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

Закон Республики Казахстан «О жилищных отношениях» и Правила по управлению объектом кондоминиума не объявляют мессенджер реестром эксплуатационных заявок. Они возлагают на орган управления конкретные обязанности по содержанию общего имущества, документам и отчетности. Правила, например, требуют составлять дефектный акт при текущем ремонте с участием совета дома. Это хороший ориентир: чат может запустить процесс, но результат работы должен жить в записи, которую можно найти, проверить и связать с документом.

У каждого обращения должна быть одна запись

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

Адреса «у нас в подъезде» недостаточно. Для портфеля домов нужны дом, подъезд, этаж, помещение или участок общего имущества. Номер квартиры нужен не всегда: течь в подвале относится к общему имуществу, но контакт заявителя все равно нужен для доступа и обратной связи. Поле описания должно сохранять исходный смысл сообщения, а не догадку диспетчера. «Пахнет горелым возле щитка на шестом этаже» лучше, чем преждевременный диагноз «неисправность автомата».

Ниже минимальный внутренний формат, который можно использовать как требования к таблице, форме или системе заявок. Это не установленная законом форма и не API конкретного продукта. Его задача проста: не позволить команде принять обращение без управляемого следующего действия.

{
  "request_id": "A-2026-004187",
  "received_at": "2026-07-29T18:42:11+05:00",
  "channel": "whatsapp",
  "source_message_id": "wamid.example",
  "building_id": "AST-014",
  "location": "подъезд 2, этаж 6, электрощитовая",
  "resident_contact": "+7XXXXXXXXXX",
  "summary": "запах горелого возле щитка",
  "priority": "emergency",
  "status": "assigned",
  "assignee": "дежурный электрик",
  "next_action_due_at": "2026-07-29T18:47:11+05:00",
  "resident_visible_status": "Исполнитель направлен",
  "attachments": ["photo_1.jpg"],
  "events": [
    {
      "at": "2026-07-29T18:43:02+05:00",
      "type": "assigned",
      "actor": "диспетчер 07"
    }
  ]
}

Поле source_message_id помогает вернуться к исходному сообщению и отсечь технические повторы. Оно не заменяет собственный request_id: сообщение может исчезнуть из канала, а внутренний номер нужен для поиска и разговора с жильцом. Время надо хранить вместе с часовым поясом. Портфель, где дома находятся в разных регионах Казахстана, быстро получает спорные просрочки, если система записывает только часы и минуты.

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

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

Автоматика принимает сообщение, человек понимает ситуацию

Прием из WhatsApp и Telegram стоит автоматизировать до создания черновика заявки и подтверждения жителю. Классификацию срочности, объединение неоднозначных дублей и технический диагноз должен контролировать человек. Полная ручная перепечатка теряет обращения в часы нагрузки, а полная автоматизация уверенно ошибается там, где цена ошибки выше удобства.

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

После регистрации житель получает короткое подтверждение: «Обращение A-2026-004187 принято. Уточняем адрес и срочность». Эта фраза делает две работы. Житель понимает, что сообщение не осталось среди разговоров, а диспетчер может ссылаться на один номер при звонке. Подтверждение не должно обещать ремонт к конкретному часу, пока команда не определила категорию и исполнителя.

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

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

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

Когда адрес неизвестен, бот или диспетчер задает один вопрос за раз. Сначала дом, затем подъезд или место, затем доступ. Длинная анкета в чате снижает шанс получить ответ, особенно когда человек стоит возле воды в подвале. Если контакт уже связан с одним домом, можно предложить подтверждение: «Заявка относится к дому по адресу ...?» Нельзя молча подставлять старый адрес.

Дубли требуют осторожности. Десять сообщений о неработающем лифте могут описывать одну неисправность, но десять сообщений о запахе газа нельзя автоматически склеить без проверки места и времени. Система может предложить диспетчеру вероятный общий инцидент по дому, категории и близкому времени. Решение об объединении принимает сотрудник, а каждая связь с заявителем сохраняется, чтобы все получили статус.

Голосовые сообщения нельзя оставлять отдельной «папкой на потом». До появления надежной расшифровки сотрудник должен прослушать запись, кратко перенести факты в карточку и прикрепить оригинал. Слова «там опять шумит» сами по себе бесполезны. Диспетчер уточняет, где именно шум, когда он начался, постоянный ли он и есть ли видимая опасность.

Вложения надо проверять как часть обращения, а не как украшение переписки. Фотография без подписи может относиться к прошлой неделе или к другому подъезду, видео не всегда показывает источник звука, а документ может содержать лишние персональные данные. Сотрудник сохраняет оригинал, записывает пояснение заявителя и связывает файл с карточкой. Если для решения хватает текстового описания, не надо требовать фотографию просто ради заполненного поля.

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

Срочность определяет маршрут, а не громкость чата

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

Разумно отделить аварийный сигнал от срочного и планового обращения. Аварийный означает возможную непосредственную угрозу людям, пожару, затоплению, электробезопасности, газовой безопасности или быстрому повреждению общего имущества. Срочный требует реакции в текущем дежурстве, но не несет признаков немедленной угрозы. Плановый можно поставить в график осмотра или ремонта. Категории должны соответствовать реальным договорам, аварийным службам и ресурсам конкретного дома.

Официальная памятка по ЖКХ на gov.kz описывает базовый порядок при прорыве труб: обратиться в аварийную службу КСК или управляющей компании, после чего диспетчер фиксирует обращение и направляет ремонтную бригаду. Я бы не сокращал этот порядок до «переслать сантехнику». Фиксация идет раньше направления бригады, иначе после выезда нельзя надежно восстановить время сигнала, адрес и принятое решение.

У аварийной карточки должны быть два разных срока. Первый показывает, когда диспетчер обязан оценить сигнал и направить нужного исполнителя. Второй относится к следующей контрольной точке: прибытие, локализация опасности или сообщение о задержке. «Закрыть аварию за час» часто невозможно и провоцирует ложные закрытия. Гораздо честнее отдельно измерять прием, передачу, прибытие, локализацию и окончательный ремонт.

Скрипт первичной оценки должен быть коротким и предметным:

1. Есть ли сейчас опасность для человека, огонь, дым, запах газа, искрение или быстро прибывающая вода?
2. Где точно находится источник или заметный признак?
3. Можно ли безопасно ограничить ущерб без самостоятельного ремонта?
4. Нужен ли доступ в квартиру, подвал, щитовую или другое закрытое помещение?
5. Как связаться с человеком на месте до прибытия исполнителя?

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

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

Приоритет нельзя снижать только потому, что житель перестал отвечать в чате. Сигнал о дыме в электрощитовой требует проверки даже без дальнейшей переписки. А просьба заменить лампу может ждать уточнения точного места. Матрица помогает отделить недостаток информации от отсутствия риска.

Срок без ответственного ничего не меняет

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

Срок ремонта и срок ответа жителю нельзя хранить в одном поле. Для замены детали может понадобиться осмотр, смета, решение собственников или закупка. Это не оправдывает тишину. Команда может честно пообещать осмотр завтра, сообщить результат после осмотра и назвать дату следующего обновления, даже если дата окончательного ремонта пока неизвестна.

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

Полезный набор внутренних состояний невелик:

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

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

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

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

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

Жильцу нужен понятный статус, а не внутренняя переписка

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

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

Фраза «заявка в работе» почти ничего не сообщает. Она может означать, что мастер уже на месте, что подрядчику отправили письмо или что карточку просто открыл диспетчер. Лучше писать: «Электрик получил задание и должен прибыть до 19:20» или «Осмотр завершен, опасность локализована, до 12:00 сообщим срок замены детали». Здесь есть действие и контрольная точка.

Внешние уведомления удобно привязать к событиям, а не писать вручную каждый раз. Регистрация, запрос уточнения, назначение, перенос срока, временное устранение опасности и закрытие создают разные шаблоны. Диспетчер дополняет факты, но не изобретает формулировку в разгар аварии. При переносе система обязательно требует новую дату и краткую причину, которую можно показать жильцу.

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

При этом не надо превращать обычное плановое обновление в серию звонков по всем известным номерам. Для каждой категории команда определяет, когда сбой доставки требует немедленного резервного действия, а когда достаточно показать уведомление в кабинете и повторить отправку. Аварийная безопасность, доступ мастера и перенос срочного визита требуют более настойчивой связи, чем сообщение о включении заявки в месячный план.

Нельзя отправлять в общий домовой чат адрес квартиры, телефон, фотографию из помещения или подробности доступа. Массовый инцидент можно объявить общим сообщением без персональных данных: «В доме зарегистрировано отключение холодной воды, аварийная бригада уведомлена, следующая информация в 16:30». Ответ по индивидуальной заявке идет заявителю в тот канал, который связан с карточкой.

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

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

История видимого статуса должна сохраняться. Если срок изменился три раза, последний срок без предыдущих обещаний выглядит аккуратно только на экране. В реальности именно переносы объясняют недовольство. Руководитель должен видеть полную цепочку, а житель, как минимум, время каждого полученного обновления и актуальную контрольную точку.

Жителю полезно дать один способ дополнить уже зарегистрированную заявку. Если ответ на уведомление каждый раз создает новую карточку, очередь заполняется дублями и теряет контекст. Система должна распознавать номер обращения или связанный диалог, прикреплять новое фото и поднимать карточку ответственному. Когда сообщение описывает другую проблему, диспетчер отделяет его в новую запись и сообщает новый номер.

Переход из домовых чатов не должен останавливать диспетчерскую

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

Начните с инвентаризации не программ, а входов. Запишите все номера WhatsApp, аккаунты и боты Telegram, домовые группы, телефоны диспетчерской, QR-коды, личные номера председателя, на которые уже пишут жильцы. Для каждого входа укажите владельца, дома, часы контроля и способ переноса в очередь. Канал без назначенного дежурного нельзя оставлять официальным.

Затем проведите переход в четыре этапа:

1. Выберите один дом и одну рабочую смену, подключите их входы к общей очереди и запретите пересылку без создания карточки.
2. В течение недели сверяйте количество входящих сообщений с количеством созданных записей, отдельно разбирая дубли, спам и сообщения без адреса.
3. После каждой смены выбирайте несколько заявок и восстанавливайте путь от исходного сообщения до результата и уведомления жильцу.
4. Подключайте следующий дом только после того, как сотрудники умеют обрабатывать сбой канала, массовый инцидент и передачу между сменами.

На время перехода нужен журнал исключений. В него попадают сообщения, которые не создали карточку автоматически, файлы без привязки, неверно определенные дома, повторные записи и ответы, ушедшие не тому получателю. Это не параллельная вечная таблица заявок. Журнал нужен для исправления процесса и закрывается после переноса каждого элемента в основную очередь.

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

Личные номера председателя и мастеров особенно опасны. Жители будут писать туда еще долго, даже после объявления нового порядка. Сотрудник должен иметь быстрый способ переслать содержание в систему с сохранением контакта и времени, а жителю надо ответить номером карточки и официальным каналом для дальнейшего статуса. Молчаливое игнорирование личного сообщения лишь переносит конфликт.

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

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

Единая очередь должна выдерживать смену людей и домов

Система приема работает только тогда, когда следующая смена может продолжить каждую заявку без устного пересказа. Это проверка сильнее красивого отчета. Если диспетчер обязан позвонить вчерашнему сотруднику, чтобы понять статус, часть реестра по-прежнему живет в голове.

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

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

При смене управляющей организации карточки нельзя сводить к выгрузке заголовков. Нужны вложения, события, текущие владельцы, сроки, связанные акты, переписка с заявителем и сведения о массовых инцидентах. Правила по управлению объектом кондоминиума подробно относятся к передаче финансовой и технической документации при смене управления. Журнал эксплуатационных обращений стоит готовить к передаче с той же аккуратностью, даже если конкретный формат команда определяет своим договором и внутренним регламентом.

Контроль качества начинается с выборки карточек. Руководитель берет закрытую заявку и проверяет исходный сигнал, категорию, назначения, переносы, результат и уведомление. Затем берет старую открытую и спрашивает, какое действие произойдет дальше и кто за него отвечает. Если ответ приходится искать в WhatsApp, единая очередь существует только номинально.

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

Архивирование не означает удаление. Закрытые карточки нужны для повторных неисправностей, планирования ремонта, проверки подрядчика и ответа на спор. Срок хранения определяют применимые требования, договоры и политика документов организации. Нельзя выбирать его по объему памяти телефона или по тому, сколько переписки помещается в мессенджере.

QABAT принимает обращения из приложения, WhatsApp, Telegram, по телефону и QR-коду в общий контур заявок и аварийной диспетчеризации. Для ОСИ и жителей платформа бесплатна, а пилотный запуск дает возможность перенести входы по домам, не заставляя жильцов одновременно менять привычки.

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