Учёт заявок сервисной компании: CRM вместо чатов

2026-07-14

Типовой сценарий внедрения: как сервисная компания уходит от учёта заявок в чатах и Excel к управляемому контуру на Bitrix24 или amoCRM.

Контекст

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

Симптомы типовые: клиент звонит уточнить статус, и диспетчер при нём спрашивает инженера «ты был у них?»; две бригады выезжают на один адрес из-за дублирования заявки; таблица «актуальна на прошлую пятницу»; отметка «взял» в чате инженеров означает «прочитал», а не «выполняю».

Задача

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

Решение

1. Провели диагностику: прошли путь 20-30 реальных заявок за месяц — когда пришла, сколько ждала назначения, сколько раз переносился выезд, когда выставлен акт и когда пришли деньги.
2. Перенастроили воронку под фактический путь заявки: приём, назначение, диагностика, согласование, ожидание запчасти или клиента, выезд, выполнение, акт, оплата — вместо трёх коробочных стадий.
3. Завели все точки входа (WhatsApp, Telegram, сайт, телефония) в систему автоматически, с фиксацией источника и времени обращения — ручной перенос из чата исключили как основную точку потерь.
4. Закрепили обязательного ответственного и срок на каждом этапе: заявка не может находиться в системе без владельца.
5. Настроили уведомления и эскалации: инженер получает назначение с адресом и историей в привычном мессенджере, диспетчер — сигнал о заявке без назначения дольше норматива, руководитель — только эскалации по просрочкам и зависаниям.
6. Ввели закрывающий шаг: заявка не считается закрытой без акта и оплаты, невыставленные акты видны отдельным списком.

Стек

Результаты

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

Выводы и тиражируемость

Логика переносится на любую компанию с потоком коротких заявок — от клининга до техобслуживания — где заявка живёт дни, а не месяцы. Если у вас длинные объекты с этапами работ и отчётами заказчику, а не короткие заявки, механика другая — она разобрана в кейсе учёта объектов монтажной компании.

Подробный разбор пути заявки и типовых потерь — в статье Учёт заявок в сервисной компании.

Связанные материалы