Автоуведомления о готовности ремонта снимают главную боль сервисного центра: клиент сам не звонит каждые полчаса, мастер не отвлекается на звонки и не теряет нить заказа. SMS или сообщение в мессенджер уходит автоматически, когда статус заказа меняется — «диагностика завершена», «нужна согласование стоимости», «можно забирать». В статье разберём, как связать типы ремонта с шаблонами уведомлений, какие статусы выносить в триггеры и где спрятаны типичные ошибки.
Почему одного шаблона «ремонт готов» мало
Клиент реагирует на конкретику. Сообщение «Ваш телефон готов» вызывает вопросы: что именно сделали, сколько стоит итоговый ремонт, что делать дальше. Сервисный центр теряет дни на переписку, хотя мог отправить готовый шаблон с нужными полями. Для каждого типа ремонта нужен свой набор триггеров и свой набор полей в сообщении.
Проще всего поделить всю работу на категории по срокам и логике согласования:
- быстрый ремонт без согласования стоимости — замена экрана, чистка ноутбука, установка ПО;
- ремонт с обязательным согласованием — замена аккумулятора, восстановление после залития, сложная диагностика;
- длительный ремонт с промежуточными статусами — BGA-пайка, восстановление платы, ожидание запчастей со склада;
- сервисное обслуживание по регламенту — ТО оборудования, плановая замена расходников.
Какие статусы в CRM отдавать в триггеры уведомлений
Не отправляйте клиенту сообщение на каждое движение заказа. Достаточно четырёх-пяти ключевых переходов, которые реально меняют его действия: нести деньги, приехать забрать, ждать звонка мастера или просто знать, что всё идёт по плану.
Рабочий набор триггеров для большинства сервисных центров выглядит так:
- «Приняли в работу» — подтверждение, что заказ зарегистрирован и мастер взял в руки.
- «Диагностика завершена» — и сразу либо «согласуйте стоимость», либо «можем приступить, стоимость такая-то».
- «Согласовано, ремонт начат» — для заказов, где клиент подтверждал смету.
- «Ремонт завершён, готов к выдаче» — итоговая стоимость, время работы, что нужно для получения.
- «Ожидание запчасти» — отдельный статус, чтобы клиент понимал паузу и не ждал звонка сегодня.
Для каждого типа ремонта список урезается. Быстрый ремонт без согласования обходится тремя статусами. Длительный ремонт с ожиданием запчастей требует всех пяти, плюс промежуточное сообщение «запчасть пришла, приступаем».
Как собрать шаблоны под разные типы ремонта
Шаблон — это текст с переменными, которые CRM подставит автоматически: имя клиента, номер заказа, тип устройства, итоговая сумма, адрес выдачи. Без переменных шаблон превращается в спам, который клиент пролистывает.
| Тип ремонта | Какие переменные нужны | Когда уходит сообщение |
|---|---|---|
| Замена экрана за 1 час | Имя, модель, сумма, время выдачи | Статус «готов к выдаче» — сразу |
| Ремонт со согласованием сметы | Имя, модель, сумма, ссылка на подтверждение | Статус «диагностика завершена» — с просьбой подтвердить стоимость |
| Ожидание запчасти 5–14 дней | Имя, модель, ориентировочная дата | Статусы «ожидание запчасти», «запчасть пришла» |
| Плановое ТО оборудования | Имя, объект, перечень работ, следующая дата ТО | Статусы «приняли», «ТО завершено», «следующее ТО через 6 мес.» |
Для каждой категории держите отдельный шаблон. Смешивать их в одном длинном сообщении с условиями «если-то» — путь к ошибкам: мастер меняет статус, CRM подставляет не те поля, клиент получает текст с пустым местом вместо суммы.
SMS, мессенджер или оба канала сразу
SMS работает всегда и читается сразу, но стоит дороже и не даёт кнопок. Мессенджер дешевле и позволяет прикрепить фото, квитанцию, ссылку на карту с адресом. Опрашивать клиента в момент приёмки, какой канал ему удобнее, — нормальная практика, а не каприз. Один и тот же человек может попросить SMS для коротких статусов и Telegram для финального сообщения с документами.
Если хотите автоматизировать выбор канала без опроса, ориентируйтесь на тип ремонта. Быстрый ремонт за час — SMS, уведомление короткое и срочное. Длительный ремонт со сметой — мессенджер, там влезет и сумма, и ссылка на подтверждение. Сервисное обслуживание оборудования по регламенту — мессенджер, потому что удобно прикрепить акт и напоминание о следующем ТО.
Для SMS-уведомлений удобно подключить отдельный сервис рассылок, чтобы не зависнуть на встроенных лимитах CRM. Для мессенджеров проверьте, что CRM умеет отправлять через нужный канал сам, без копирования текста в личный аккаунт менеджера.
Типичные ошибки при настройке автоуведомлений
- Отправлять уведомление на каждый статус. Клиент получает пять сообщений за день и начинает их игнорировать, а потом пропускает главное — «можно забирать».
- Один шаблон на все типы ремонта. Сообщение про замену экрана приходит клиенту, у которого сложная пайка и согласование сметы, и вызывает путаницу.
- Забыть согласование стоимости. Мастер завершил диагностику, CRM сразу шлёт «ремонт готов», а клиент ещё не знает итоговую сумму и не давал добро.
- Не тестировать шаблоны на реальных номерах. Переменная не подставилась, в тексте осталось «Уважаемый , ваш готов» — клиент звонит разбираться.
- Смешивать SMS и мессенджер в одном триггере. Клиент просил только Telegram, а ему пришло и SMS, и сообщение в мессенджер — двойное уведомление раздражает.
- Не сохранять лог отправки. Если клиент говорит «я ничего не получал», нечем доказать обратное и разобрать, на каком этапе сломалось.
Как проверить, что связка CRM и уведомлений работает
После настройки прогоните пять контрольных сценариев: быстрый ремонт без согласования, ремонт с согласованием сметы, ремонт с ожиданием запчасти, сервисное ТО и отказ от ремонта после диагностики. Для каждого сценария проверьте три вещи: пришло ли сообщение вовремя, подставились ли переменные и нет ли дублей.
Заведите отдельный тестовый заказ с реальным номером и наблюдайте за сообщениями со стороны клиента неделю. Это покажет, как часто приходят уведомления, не теряются ли SMS у оператора и читаются ли сообщения в мессенджере без открытия. Полезно посмотреть, как уведомления выглядят на разных телефонах и в разных приложениях: длинный текст в Telegram режется, короткая SMS не вмещает адрес с улицей.
Что учесть при выборе CRM и сервиса уведомлений
Перед подключением проверьте три технических момента. CRM должна отдавать событие по смене статуса в внешний сервис — webhook или API, иначе уведомления придётся дублировать вручную. Сервис уведомлений должен принимать переменные из CRM, а не только фиксированный текст. У обоих должен быть лог отправки с временем и статусом доставки, иначе разбор споров превратится в переписку «я не получал» — «вы не отправляли».
3 шага, которые можно сделать на этой неделе:
- Выписать все типы ремонта, которые ведёт сервис, и отметить, где нужно согласование сметы, а где нет.
- Собрать 3–4 шаблона сообщений с переменными под каждый тип ремонта и согласовать их с мастерами.
- Прогнать связку CRM и сервиса уведомлений на пяти тестовых заказах и посмотреть на сообщения глазами клиента.
