Для сервисного центра SMS-уведомления о ремонте лучше строить вокруг статусов заказа: техника принята, диагностика завершена, согласование получено, ремонт готов, заказ выдан. CRM или учётная система меняет статус, а SMS-сервис отправляет клиенту короткое сообщение. В статье разберём, какие этапы выбрать, какие данные передавать, как настроить повторную отправку при сбое и как проверить, что уведомление действительно ушло клиенту.
Какие статусы ремонта нужно передавать клиенту?
Сначала составьте список событий, которые влияют на решение клиента. Для небольшой мастерской достаточно пяти или шести статусов. Чем меньше лишних сообщений, тем проще человеку следить за заказом и тем ниже нагрузка на администратора.
- Техника принята. Клиент получает номер заказа и понимает, что устройство зарегистрировали.
- Диагностика завершена. В сообщении можно указать, что мастер подготовил заключение и ждёт согласования.
- Нужна информация или согласование. Например, требуется подтвердить стоимость ремонта или выбрать вариант работ. Ссылку на подробности лучше передавать через личный кабинет, если он есть.
- Запчасть заказана. Такой статус снижает количество вопросов о сроках, когда мастер ждёт поставку.
- Ремонт завершён. Клиент получает уведомление о готовности и часы, когда заказ можно забрать.
- Заказ выдан. Это финальная отметка в истории ремонта.
Не каждое внутреннее действие мастера нужно показывать клиенту. Перемещение устройства между рабочими местами, распечатка акта или изменение ответственного сотрудника обычно не требуют отдельного SMS. В системе оставьте только те статусы, после которых клиенту нужно ждать, согласовать, приехать или забрать технику.
Как связать учётную систему и SMS-сервис?
Связка строится по простой схеме: сотрудник меняет статус заказа, система передаёт событие в SMS-сервис, сервис отправляет сообщение и возвращает технический результат. Для каждого заказа стоит хранить номер телефона, номер ремонта, текущий статус и время последней отправки.
Если в сервисном центре уже есть CRM, сайт с формой заявки или программа учёта, интеграцию подключают через API. Перед началом проверьте, поддерживает ли система исходящие веб-запросы и можно ли получить уведомление о результате доставки. Для самостоятельной проверки пригодится материал о доступности SMS API для сайта.
В событии достаточно передавать такие поля:
- номер телефона клиента;
- номер заказа или заявки;
- новый статус;
- имя клиента, если его используют в шаблоне;
- срок действия сообщения или время отправки;
- признак, отправляли ли SMS по этому статусу раньше.
Последнее поле защищает от дублей. Сотрудник мог дважды сохранить одну и ту же карточку, а интеграция могла повторно обработать запрос. Если система видит, что уведомление по статусу «Ремонт готов» уже отправлялось, второе сообщение создавать не нужно.
Как составить шаблоны SMS о ремонте?
Уведомление должно отвечать на один практический вопрос: что произошло с техникой и что делать дальше. В короткий текст обычно помещаются название мастерской, статус, номер заказа и следующий шаг. Длинное описание диагностики лучше вынести в карточку заказа или сообщить по телефону.
| Событие | Что указать в SMS | Пример текста |
|---|---|---|
| Приём техники | Номер заказа и факт регистрации | «Заявка №4821 принята. Следите за статусом ремонта по SMS.» |
| Готово к согласованию | Результат диагностики и действие клиента | «По заявке №4821 готова диагностика. Свяжитесь с сервисом для согласования ремонта.» |
| Ожидание запчасти | Причина задержки и текущий этап | «По заявке №4821 ожидаем запчасть. Мы сообщим, когда ремонт продолжится.» |
| Ремонт завершён | Номер заказа и способ получения | «Ремонт по заявке №4821 завершён. Технику можно забрать в сервисном центре.» |
| Выдача заказа | Факт завершения обслуживания | «Заявка №4821 закрыта. Спасибо, что обратились в сервисный центр.» |
Название организации лучше ставить в начало сообщения, чтобы клиент сразу понял отправителя. Не включайте в SMS внутренние комментарии мастера, спорные формулировки и неподтверждённые сроки. Если дата готовности зависит от поставки детали, напишите об ожидании запчасти, а точный срок сообщите после подтверждения.
Для каждого статуса создайте отдельный шаблон. Так проще менять текст без вмешательства программиста и видеть, какое событие вызвало отправку. Если SMS содержит код или ссылку на защищённое действие, правила шаблона и защиты будут другими: для таких задач полезен материал о защите SMS-кодов от SIM-swap и перехвата.
Как обработать ошибки и повторную отправку?
Интеграция не заканчивается моментом передачи сообщения провайдеру. Система должна записать результат: запрос принят, SMS доставлено, доставка не подтверждена или произошла техническая ошибка. Для этого используют отчёт о статусе доставки, который часто называют DLR.
Если сервис вернул временную ошибку, сообщение можно поставить в очередь и повторить отправку через небольшой интервал. При постоянной ошибке повторять SMS бесконечно нельзя: это создаёт дубли и расходует баланс. После нескольких неудачных попыток задача должна перейти администратору.
Отдельно обработайте ситуации, когда:
- в карточке нет номера телефона;
- номер записан с ошибкой или в неподдерживаемом формате;
- статус изменился несколько раз подряд;
- SMS-сервис временно недоступен;
- клиент уже получил сообщение по этому событию;
- доставка не подтверждена в ожидаемый срок.
Подробный разбор причин недоставки и работы DLR есть в материале «Почему SMS не доходит до клиента». На практике администратору нужен не технический код ошибки, а понятная отметка: «повторить», «позвонить клиенту» или «проверить номер».
Как контролировать работу уведомлений в сервисном центре?
Раз в неделю проверяйте несколько заказов вручную: совпадает ли статус в учётной системе с текстом SMS, не отправились ли дубли, сохранилось ли время отправки. Тестовые заявки лучше создавать на отдельные номера сотрудников, чтобы не тревожить клиентов при изменении шаблонов.
Полезно разделить права доступа. Мастер меняет технический статус, администратор подтверждает стоимость и готовность к выдаче, а руководитель видит журнал отправок. Такое распределение уменьшает риск, что SMS уйдёт до фактического завершения ремонта.
Для оценки процесса ремонтной мастерской можно связать уведомления с показателями CRM. Подход к такой настройке разобран в статье о KPI в CRM для ремонтной мастерской. Считать имеет смысл конкретные показатели: сколько заказов получили каждый статус, сколько SMS отправлено, сколько доставлено и сколько раз клиенту пришлось напоминать о готовности.
Типичные ошибки при настройке SMS
- Отправка сообщения при каждом сохранении карточки вместо отправки только при смене статуса.
- Отсутствие номера заказа, из-за чего клиент не понимает, к какой технике относится уведомление.
- Обещание точной даты, хотя сервис ждёт запчасть или согласование.
- Использование одного шаблона для диагностики, ремонта и выдачи.
- Отсутствие журнала отправок и невозможность выяснить, почему клиент не получил SMS.
- Бесконечные повторы при ошибке номера или недоступности телефона.
3 шага, которые можно сделать на этой неделе:
- Составьте карту статусов ремонта и уберите из неё внутренние действия сотрудников.
- Подготовьте отдельный шаблон для каждого клиентского события, добавив номер заявки и следующий шаг.
- Настройте журнал отправок, проверку дублей и обработку ошибок доставки до запуска на всех клиентах.
