Как организовать обработку заявки жителя: от звонка до приёмки
Важен весь маршрут обращения: кто принял, кому передал, какие работы назначили и кто подтвердил результат. Если эти переходы остаются только в звонках и чатах, руководителю приходится собирать картину вручную.
Свяжите звонок и обращение
Диспетчер уточняет адрес, место проблемы и описание, проверяет существующие обращения и создаёт запись. Связь с телефонией помогает вернуться к контексту разговора. В нашем проекте диспетчерской использована Asterisk; конкретные функции зависят от согласованной конфигурации телефонии.
- Звонок не всегда означает новую заявку: житель может уточнять старую.
- Одно обращение может потребовать нескольких работ.
- Номер телефона помогает найти историю, но сам по себе не доказывает личность.
Разделите обращение и рабочие задачи
Обращение описывает проблему жителя. Задачи описывают действия команды. Например, сообщение о протечке может потребовать осмотра, ремонта и проверки результата. Если всё хранится одним статусом, трудно понять, какая именно работа задерживается.
Закрепите ответственность за переходы
Ниже маршрут, реализованный в нашем проекте. Это пример организации процесса, который адаптируется под роли конкретной компании.
| Участник | Действие | Что должно остаться в системе |
|---|---|---|
| Диспетчер | Регистрирует обращение и назначает мастера | Адрес, описание, источник и ответственный |
| Мастер | Определяет работы и распределяет исполнителей | Задачи, сроки и назначенная бригада |
| Исполнитель | Выполняет работу и передаёт отчёт | Комментарий, результат и фотографии |
| Мастер | Принимает результат или возвращает на доработку | Решение и причина возврата |
| Система | Проверяет завершение связанных работ | Согласованный итоговый статус обращения |
Проверьте процесс на примере
Учебный сценарий: житель сообщает о протечке в подъезде. Диспетчер связывает звонок с адресом и назначает мастера. Мастер создаёт задачу осмотра, затем ремонт. Исполнитель прикладывает отчёт; мастер проверяет его. Если результат недостаточен, задача возвращается на доработку с причиной. Завершение осмотра ещё не означает завершение ремонта.
Сделайте причины задержки видимыми
Вместо бесконечного общего статуса «В работе» договоритесь, как отмечать ожидание доступа, материалов или решения ответственного. Список причин должен соответствовать реальной работе. Для срочных ситуаций нужен отдельный согласованный порядок: интерфейс CRM не заменяет правила аварийного реагирования.
Дайте каждому сотруднику свой рабочий список
Диспетчеру нужны новые и требующие уточнения обращения. Мастеру — назначенные заявки и работы на приёмку. Исполнителю — его задачи с адресом и описанием. Руководителю — просрочки, нагрузка и причины возвратов. Права на изменение и просмотр задаются отдельно от внешнего вида списков.
Как принимать такую CRM
Проверяйте цепочку под реальными ролями, а не только под администратором. Подготовьте обычное обращение, повторный звонок, несколько работ по одной проблеме и возврат результата.
- Из обращения понятно, кто отвечает за следующий шаг.
- Исполнитель видит нужную информацию и не меняет чужие назначения.
- Возврат на доработку сохраняет историю и причину.
- Обращение не закрывается при незавершённой обязательной работе.
- Звонок и отчёт можно найти из связанной записи.
Что обсудить перед разработкой
Нужны роли сотрудников, каналы обращений, текущая телефония, справочник объектов и примеры рабочих ситуаций. Начать можно с одного маршрута обращения. Подключение остальных служб и отчётов планируется после проверки первой версии.