Учёт заявок в сервисной компании: как уйти от чатов и таблиц

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

**Коротко:** чаты и таблицы не фиксируют ответственного, срок и статус как обязательные поля — они хранят переписку. После 5 сотрудников этого перестаёт хватать. Решение — не «купить CRM», а собрать контур под реальный путь заявки: точки входа, этапы, роли, уведомления и экран руководителя.

Почему заявки в чатах и таблицах перестают работать после 5 сотрудников

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

Эта схема ломается предсказуемо, и ломается она в трёх местах:

• **Объём.** Тридцать-пятьдесят заявок в день уже не помещаются в голове. Диспетчер начинает пропускать — не потому что стал хуже работать, а потому что у схемы есть физический предел.
• **Передача смены.** Второй диспетчер, выходные, отпуск. Картина из головы одного человека не передаётся другому. Появляются заявки, о которых «никто не знал».
• **Несколько точек входа.** Клиенты пишут в WhatsApp, звонят, оставляют заявки на сайте, кто-то пишет напрямую инженеру. Каждый канал — своя лента, и заявка из одного канала легко дублируется или теряется в другом.

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

<Callout>

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

</Callout>

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

Путь заявки от обращения до закрытия: где теряются деньги и время

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

Приём обращения

Клиент написал в WhatsApp в субботу вечером. Диспетчер увидел сообщение в понедельник, среди сорока других. Заявка ещё не потеряна — но клиент уже двое суток думает, что его игнорируют, и параллельно позвонил конкуренту. Потеря здесь измеряется не временем инженера, а заявками, которые ушли до того, как их вообще приняли. Чем больше каналов входа, тем больше таких «мёртвых зон».

Назначение исполнителя

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

Выполнение и статус «в работе»

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

Закрытие и оплата

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

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

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

Руководителю сервисной компании для управления заявками нужно на удивление немного. Не сорок отчётов, а один экран, который отвечает на три вопроса.

**Первый: что сейчас в работе и в каких статусах.** Сколько заявок принято, назначено, в работе, ждёт запчасть или клиента, выполнено, закрыто по оплате. Не список из двухсот строк, а счётчики по этапам. Аномалия видна за секунды: например, тридцать заявок скопились на этапе «назначение» — значит, затык в диспетчеризации, а не у инженеров.

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

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

Отдельно стоит сказать, чего на экране руководителя быть не должно: переписки. Если руководитель вынужден читать чаты, чтобы понять состояние дел, — контур не собран. Переписка остаётся в карточке заявки для разбора конкретной ситуации, а управляют по статусам и срокам. Когда базовый контур работает, поверх него можно строить и [аналитику по направлениям и клиентам](/services/analytics-bi) — но начинать с дашбордов, когда не работает учёт, бессмысленно.

Если Bitrix24 или amoCRM уже внедрены: почему контроль всё равно ручной

Частая ситуация: CRM в компании формально есть — купили Bitrix24 или amoCRM год-два назад, кто-то что-то настроил. А контроль всё равно ручной: руководитель по-прежнему звонит и спрашивает «что по заявке». Причин обычно три, и ни одна из них не «CRM плохая».

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

**Часть процесса живёт вне системы.** Заявки принимают в WhatsApp, а в CRM заносят «потом» — то есть иногда. Согласование с клиентом идёт по личному телефону инженера. Наряды печатают из Excel. В итоге CRM показывает не то, что происходит, а то, что в неё донесли. Люди это быстро понимают и перестают на неё смотреть — зачем смотреть туда, где заведомо неполная картина.

**У полей нет обязательности, а у этапов — правил.** Заявку можно создать без срока и без ответственного. Можно перевести в «выполнено» без акта. Система не сопротивляется неполным данным — значит, данные будут неполными. Это вопрос времени, а не дисциплины.

<Callout>

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

</Callout>

Хорошая новость: в этой ситуации почти никогда не нужно менять систему. Bitrix24 и amoCRM закрывают задачу учёта сервисных заявок, если [настроить их под реальный процесс](/services/crm-automation): этапы — под фактический путь заявки, точки входа — внутрь системы, обязательные поля и автоматические уведомления — вместо памяти диспетчера. Это дешевле и быстрее миграции, а сопротивление команды ниже — интерфейс людям уже знаком.

Из чего состоит CRM-контур для сервисных заявок: этапы, роли, уведомления

Слово «контур» здесь не случайно. Это не «внедрение CRM» как установка программы, а замкнутый цикл: заявка входит в систему одним из известных путей, проходит понятные этапы с ответственными и выходит закрытой — с актом и оплатой. Из чего он состоит.

**Точки входа.** Все каналы — WhatsApp, Telegram, телефония, сайт, почта — заводят обращение в систему автоматически, с источником и временем. Ручной перенос из чата в CRM — первое, что нужно убрать: именно на нём заявки теряются и дублируются. Из практики: для отдела продаж на amoCRM с телефонией UIS я собирал [ИИ-агента квалификации входящих чатов](/blog/ii-agent-kvalifikacii-zayavok) — он принимает обращение, задаёт уточняющие вопросы и заполняет карточку до передачи менеджеру. Для сервисных заявок логика та же: типовые вопросы («адрес, что случилось, когда удобно») [снимает автоматика](/services/ai-automation), диспетчер подключается к уже заполненной заявке.

**Этапы под реальный процесс.** Не три коробочных, а фактический путь: новая, назначена, диагностика, согласование, ожидание (запчасть/клиент), выезд, выполнена, акт выставлен, оплачена. Важная деталь — этапы ожидания выделены отдельно: заявка, которая ждёт запчасть, и заявка, по которой идёт работа, — это разные ситуации, и смешивать их в одном «в работе» нельзя.

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

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

**Закрывающий шаг.** Заявка не считается закрытой, пока нет акта и оплаты. Выполненные, но не закрытые по деньгам работы висят отдельным списком перед глазами того, кто отвечает за выставление счетов, — и перестают забываться.

Такой контур не требует «большого внедрения на год». По устройству это та же задача, что и учёт в производстве: на [швейном производстве](/blog/where-sewing-production-loses-money) с объёмом порядка 100 тысяч изделий в месяц путь пачки по цеху разваливается на те же элементы — этапы, ответственные, фиксация передачи. И собирается так же: сначала один работающий участок, потом расширение. Похожая логика была в задаче [анализа тендеров для производственной компании](/blog/avtomatizaciya-analiza-tenderov-dlya-proizvodstvennyh-kompanij): сначала один поток документов в один структурированный реестр, потом обвязка.

Оговорка про смежный случай. Если у вас не поток коротких заявок, а длинные объекты с этапами работ, актами и отчётами заказчику — механика другая, её я разобрал отдельно в статье про [учёт объектов монтажной компании](/blog/uchet-obektov-montazhnoy-kompanii). Граница простая: заявка живёт дни, объект — месяцы.

С чего начать: диагностика процесса и первый работающий контур

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

**Шаг 1. Диагностика.** Берём 20–30 реальных заявок за последний месяц и проходим путь каждой: когда пришла, сколько ждала назначения, сколько раз переносилась, когда выставлен акт, когда пришли деньги. Плюс короткие разговоры с диспетчером и парой инженеров — не «как должно быть по регламенту», а как происходит на самом деле. На выходе — карта процесса с конкретными местами потерь и план первого контура. У меня такая диагностика стоит от 50 000 ₽ и полностью зачитывается в стоимость проекта, если идём дальше. Даже если дальше вы делаете всё своими силами, карта потерь остаётся у вас.

**Шаг 2. Первый контур, а не «вся система».** Из карты потерь выбирается самый болезненный участок — чаще всего это приём и назначение либо закрытие и оплата — и собирается работающий кусок: точки входа, этапы, обязательные поля, уведомления, экран руководителя. Первый контур — от 150 000 ₽, по срокам 2–8 недель в зависимости от числа каналов и интеграций (телефония, мессенджеры, 1С). Критерий готовности простой: диспетчер и инженеры реально работают в системе, а руководитель перестал выяснять статусы звонками.

**Шаг 3. Расширение по факту.** Когда первый контур прижился, к нему добавляются следующие участки: склад запчастей, гарантийные обращения, ИИ-квалификация входящих, аналитика по клиентам и направлениям. Добавлять их до того, как заработала база, — способ потратить бюджет на систему, в которую никто не смотрит.

Если хотите понять, где теряются заявки именно у вас, опишите ситуацию тремя строками: сколько человек принимает и выполняет заявки, где ведёте учёт сейчас и что чаще всего приходится выяснять вручную. Я посмотрю вводные и честно скажу, нужен ли вам отдельный контур или хватит донастройки того, что уже есть. Напишите на [MrBoroAI@yandex.ru](mailto:MrBoroAI@yandex.ru) или [оставьте три строки в брифе](/brief?utm=blog_uchet_zayavok_servisnoy_kompanii).

<CTA/>