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

Я пишу этот разбор для владельца сервиса по ремонту техники: телефонов, ноутбуков, бытовой техники, инструмента. Мы в ClaudeLab собираем CRM под процессы компании, и первый вопрос, с которого я начинаю разговор с сервисом, всегда один и тот же: где у вас сейчас теряются заказы? Ниже разложен путь заказа по участкам, требования закона, которые программа должна поддержать, и признаки, по которым видно, хватит ли готовой системы.

Что такое CRM для сервисного центра и чем она отличается от обычной?

CRM для сервисного центра - это программа, в которой сервис ведёт каждый заказ на ремонт от первого обращения до выдачи и гарантийного срока. В ней видно, кто клиент, какое устройство, что с ним заявлено, что сделано, какие запчасти ушли и когда клиенту сообщили о готовности.

Карточка заказа - запись в CRM, которая связывает клиента, устройство с серийным номером, заявленную неисправность, смету, запчасти, мастера и статус. Всё остальное в системе строится вокруг неё.

Общее устройство CRM я разбирал в статье что такое CRM-система, а короткое определение есть в словаре. Здесь важна разница с CRM продаж, которую видно в таблице.

Отсюда первое практическое следствие. Если вы берёте универсальную CRM, её придётся переделывать под заказ: добавлять поля устройства, статусы ремонта и склад. Если берёте отраслевую программу, это уже сделано, и вопрос сводится к тому, совпадает ли её логика с вашей.

Что карточка заказа хранит на каждом шаге ремонта?

Путь заказа длиннее, чем видит клиент. Клиент видит два момента: сдал и забрал. Сервис ведёт заказ через заявку, приёмку, смету, ожидание детали, ремонт, выдачу и гарантию, и после каждого шага в карточке должна остаться запись.

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

Что записать при приёмке устройства и зачем нужна квитанция?

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

Что стоит заложить в карточку при приёмке:

1. Клиент: имя и телефон. Больше данных при приёмке обычно не нужно, и собирать лишнее незачем.
2. Устройство: тип, производитель, модель, серийный номер или IMEI.
3. Комплектность: зарядное устройство, чехол, карта памяти, сим-карта. Отдельными отметками, чтобы при выдаче сверить.
4. Внешний вид: царапины, сколы, следы вскрытия. Лучше с фотографиями, прикреплёнными к заказу.
5. Заявленная неисправность со слов клиента. Именно со слов: что найдёт мастер, записывается на следующем шаге.
6. Оценка стоимости устройства, если вы её указываете в квитанции.
7. Ориентир по срокам и порядок согласования сметы.

Отдельно про пароли. Мастеру часто нужен код разблокировки, и его записывают в комментарий к заказу. Этот комментарий видят все, у кого есть доступ к заказам, а иногда он уезжает в печатную квитанцию. Лучше вынести пароль в отдельное поле с ограниченным доступом и очищать его после выдачи. Как вообще держать данные клиентов, чтобы не нарушить закон о персональных данных, я разбирал в статье персональные данные клиентов в нейросети: многие выводы оттуда применимы и к обычной CRM.

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

Какие статусы ремонта нужны и когда писать клиенту?

Статусы нужны для двух вещей. Первая - порядок внутри: по статусу видно, где стоит заказ и кто за него отвечает. Вторая - спокойствие клиента: он узнаёт о движении ремонта раньше, чем начнёт звонить сам.

Статус «ждёт согласования сметы» вырос из тридцать третьей статьи того же закона: о существенном превышении приблизительной сметы исполнитель обязан своевременно предупредить клиента, иначе оплату получит только в её пределах. Разбор нормы - там же. В CRM это значит две вещи: статус останавливает ремонт, пока клиент не ответил, а в карточке остаётся отметка, когда и как клиента спросили.

Уведомления о статусе заказа и рекламные рассылки - разные вещи. Сообщение «ваш ноутбук готов» касается заказа, который клиент сам оформил. Сообщение о скидке на чистку или замену аккумулятора - уже реклама, а по восемнадцатой статье закона о рекламе реклама по сетям электросвязи допускается только с предварительного согласия абонента. Значит, в карточке клиента нужна отдельная отметка о согласии на рекламу, и рассылка акций должна её проверять.

Канал уведомлений выбирайте по клиенту: SMS доходит всем, мессенджер удобнее для переписки и фотографий. Отраслевые программы часто умеют и то и другое: Девайс CRM, например, пишет на своём сайте об уведомлениях клиенту в SMS и Telegram. Если клиенты пишут вам в мессенджер и спрашивают статус сами, этот вопрос может закрывать бот, связанный с CRM: как устроена такая связка, показано на странице чат-бот с интеграцией в CRM.

Как вести запчасти и склад в CRM сервисного центра?

Склад в сервисе устроен иначе, чем в магазине. Деталь редко лежит просто так: чаще её заказывают под конкретное устройство, и она едет к конкретному заказу. Если склад живёт отдельно от заказов, получается знакомая картина: деталь пришла, лежит на полке, а мастер не знает, что его заказ можно продолжать.

Что стоит заложить в систему:

1. Резерв под заказ. Деталь со склада закрепляется за заказом и больше не видна как свободная.
2. Закупка под заказ. Если детали нет, из карточки создаётся заявка поставщику, а заказ получает статус «ждёт запчасть» с ориентиром по сроку.
3. Приход с привязкой. Когда деталь пришла, система сама меняет статус заказа и сообщает мастеру.
4. Списание на заказ. Деталь списывается в момент выдачи или закрытия ремонта, и себестоимость заказа видна целиком.
5. Серийные номера деталей. Для дорогих деталей, например дисплеев и плат, серийный номер детали пишется в заказ. По нему потом разбирают гарантийный случай.
6. Остатки и минимальный запас. Для ходовых деталей задают порог, ниже которого система напоминает о закупке.

У ожидания запчасти есть и юридическая сторона: при гарантийном ремонте товара двадцатая статья закона о защите прав потребителей ограничивает срок устранения недостатков, и отсутствие запчастей его не продлевает. Подробности - там же, в статье про ИИ для сервисного центра. Для CRM нужен счётчик: сколько дней заказ уже провёл в статусе «ждёт запчасть», и сигнал задолго до предельного срока.

Отраслевые программы склад запчастей обычно умеют. FixPilot пишет о складе с автосписанием, Nika CRM и CRM ПроМастер упоминают складской учёт. Вопрос, который я советую задать до покупки: как именно деталь связана с заказом и что происходит со статусом заказа, когда она приходит.

Как CRM помогает с гарантией?

Двадцать девятая статья того же закона задаёт рамку. Требования по недостаткам работы клиент может предъявить в течение гарантийного срока, а если гарантия не установлена, в разумный срок в пределах двух лет со дня принятия работы. От наличия гарантии зависит и то, кто доказывает. На работу с гарантийным сроком исполнитель отвечает за недостатки, если не докажет, что они возникли после того, как клиент принял работу, и из-за того, что клиент нарушил правила пользования результатом работы, из-за действий третьих лиц или непреодолимой силы. Без гарантийного срока доказывать должен уже клиент.

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

1. Дата выдачи - от неё отсчитывается гарантийный срок.
2. Какие работы выполнены и каким мастером.
3. Какие детали поставлены, с серийными номерами, если они есть.
4. Фотографии устройства при приёмке и при выдаче.
5. Гарантийный срок на эту работу и условия, при которых гарантия не действует.

Когда клиент приходит с гарантийным случаем, приёмщик ищет заказ по телефону или серийному номеру устройства, видит прошлый ремонт и открывает новый заказ со ссылкой на старый. Решение о том, гарантия это или нет, принимает мастер после осмотра. Программа здесь не решает, а подаёт всю историю на один экран.

Как работать с повторными обращениями?

Повторного клиента легко принять за нового, если приёмщик не ищет по телефону или серийному номеру. Нужна простая вещь: при вводе телефона или серийного номера карточка сама показывает прошлые заказы.

Что ещё даёт история обращений:

• Видно, какое устройство возвращается чаще других, и с какой поломкой. Это вопрос к качеству ремонта или к поставщику деталей.
• Видно клиентов, которые приносят технику регулярно, например компании с парком ноутбуков. С ними имеет смысл договориться отдельно.
• Можно напомнить о профилактике, например о чистке ноутбука, но только тем, кто согласился получать такие сообщения. Об этом выше, в разделе про статусы.

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

Где вы сейчас

• Заказы в тетради или таблице. Начните с отраслевой программы с бесплатным или пробным периодом и перенесите туда только открытые заказы.
• Программа есть, но склад живёт отдельно. Проверьте, умеет ли ваша система резерв и списание детали на заказ, и включите это до покупки новой.
• Клиенты сами звонят узнать статус. Настройте уведомления на трёх статусах: согласование сметы, ожидание запчасти, готовность.
• Несколько точек, выезды или свой бот, и программа уже мешает. Переходите к разделу о доработке ниже и соберите список того, что не получается.

Какие бывают готовые программы для сервисного центра?

Когда я проверял выдачу Яндекса по запросу «crm для сервисного центра» двадцать восьмого сентября две тысячи двадцать шестого года, в первой десятке стояли шесть страниц программ и четыре подборки. Ниже названия из этой выдачи и из подборок в ней, а также то, что вендоры сами пишут о себе. Это примеры классов, а не рейтинг.

Отраслевые программы уже знают, что такое квитанция, статус «ждёт запчасть» и серийный номер. Универсальные CRM сильнее в заявках из разных каналов и переписке, но под сервис их приходится настраивать. Похожая развилка есть у автосервисов, и я разбирал её отдельно в статье CRM для автосервиса: у СТО своя специфика с автомобилем, нормо-часами и записью на подъёмник, но логика выбора та же.

Когда хватает готовой программы, а когда нужна доработка?

Признаки, что готовой программы хватит:

• Одна или две точки приёма с общим складом.
• Ремонт в мастерской, без выездов к клиенту.
• Гарантия одна на все виды работ или различается по простому правилу.
• Клиенты приходят по телефону и с улицы, заявки из других каналов единичны.
• Нет своего бота, сайта с личным кабинетом или программы лояльности, которые надо связать с заказами.

Признаки, что пора дорабатывать или собирать свою систему:

• Несколько точек приёма и один центральный склад, и детали перемещаются между ними.
• Выездной ремонт: мастеру нужен маршрут, заказ на телефоне и отметка о выполнении на месте.
• Корпоративные клиенты с договорами, парком техники и своими сроками.
• Свой бот или сайт, откуда клиент хочет видеть статус заказа без звонка.
• Приёмщики ведут параллельную таблицу, потому что в программе чего-то нет.
• Данные из CRM нужно связать с бухгалтерией или складской системой, а готовой интеграции нет.

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

Если готовая программа уже не держит ваш путь заказа (несколько точек, выезды, свой склад или свой бот), посмотрите, как устроена разработка CRM в ClaudeLab. Мы разбираем ваш путь от приёмки до гарантийного обращения, собираем рабочий прототип до договора, и вы проводите через него настоящий заказ. После этого вы решаете, продолжать ли проект.

Что спросить у вендора до переноса базы?

1. Как переносятся данные? Какой формат импорта клиентов, устройств и открытых заказов, кто делает перенос и переносится ли история ремонтов.
2. Как деталь связана с заказом? Можно ли зарезервировать деталь, заказать её у поставщика из карточки и что происходит со статусом заказа, когда она приходит.
3. Можно ли менять статусы? Добавить свои, запретить переход дальше без согласия клиента, привязать уведомление к статусу.
4. Какие каналы уведомлений есть? SMS, мессенджеры, почта, кто платит за отправку и можно ли отключить рекламные сообщения тем, кто не давал согласия.
5. Кто видит какие данные? Можно ли ограничить доступ к паролям устройств и телефонам клиентов по ролям.
6. Как уйти из системы? В каком виде выгружается вся база, если вы решите сменить программу.

Перед переносом проверьте результат на десяти знакомых заказах: совпали ли клиенты, устройства, суммы и статусы. Старую базу не удаляйте, пока не сверили перенос.

Какие ошибки делают при внедрении CRM в сервисе?

Самые частые ошибки, которые я вижу:

1. Выбор по списку функций. Функций у всех много. Проверять надо свой путь заказа: провести в пробной версии три-четыре настоящих заказа, включая отказ клиента и ожидание детали.
2. Статусы без хозяина. Если не договориться, кто ставит «готов к выдаче», статус будет ставиться через раз, и уведомления потеряют смысл.
3. Склад отдельно от заказов. Детали ведут в одной программе, заказы в другой, и себестоимость ремонта никто не видит.
4. Перенос всего архива в первый день. Сначала переносят открытые заказы и клиентов за последний год, архив потом.
5. Пароли и лишние данные в открытом доступе. Код разблокировки в общем комментарии и паспортные данные там, где хватает телефона.
6. Реклама без согласия. Рассылка акций всей базе, включая тех, кто оставлял телефон только для уведомления о готовности.

Чек-лист

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