Отдел продаж, у которого сломалась автоматизация, теряет лиды. Сервисный отдел в той же ситуации теряет клиента, который уже заплатил, у которого сломалась купленная у вас техника и который пишет второй раз, потому что на первое сообщение никто не ответил. Поэтому техподдержка Битрикс24 для сервисного отдела устроена иначе, чем поддержка продаж: здесь важнее всего, чтобы ни одна заявка не пропала, гарантийный случай сразу определялся как гарантийный, а повторное обращение было видно до того, как клиент сам напомнит о нём на повышенных тонах.
Почему сервисному отделу мало один раз настроить портал
Внедрение обычно заканчивается в момент, когда процесс работает на тестовых заявках. Воронка собрана, роботы ставят задачи мастерам, форма на сайте создаёт карточки. Дальше начинается обычная жизнь компании, и портал начинает понемногу расходиться с реальностью.
Приходит новый мастер, и ему нужны права. Компания начинает продавать новую линейку оборудования с другим сроком гарантии. Маркетинг подключает ещё один номер WhatsApp. Руководитель сервиса просит разделить заявки на платные и гарантийные. Кто-то из сотрудников переименовывает стадию, потому что старое название ему не нравилось. Каждое такое изменение затрагивает поля, стадии и роботов, а связи между ними знает только тот, кто всё настраивал.
Через полгода-год выясняется, что часть автоматизации работает на честном слове. Интегратор давно закрыл проект, штатного администратора нет, а сотрудники сервиса просто обходят сломанные места вручную. Регулярная техническая поддержка Битрикс24 нужна как раз для того, чтобы такие расхождения ловить до того, как они превратятся в жалобы.
Где теряются сервисные заявки уже после внедрения
Самая неприятная поломка в сервисе выглядит тихо. Ошибки на экране нет, просто заявок в какой-то день стало меньше. Руководитель думает, что техника стала реже ломаться, а на деле обращения уходят в пустоту. Ниже частые причины, которые мы видим на порталах сервисных компаний.
| Что видит сервисный отдел | Что обычно сломалось | Что проверяет поддержка |
|---|---|---|
| Из одного канала перестали приходить заявки | Переподключили номер мессенджера, обновили сайт или форму, сменили пароль у интеграции | Отправляет тестовую заявку через каждый канал и смотрит, появилась ли карточка |
| Мастер не получил задачу по новой заявке | Стадию переименовали, удалили или создали заново, роботы на ней не настроены | Сверяет список роботов по каждой стадии воронки с описанием процесса |
| Заявки висят без движения | Ответственный уволился или ушёл в отпуск, распределение продолжает назначать его | Ищет карточки, где ответственный неактивен или долго не открывал элемент |
| В карточке нет модели и серийного номера | Заявка пришла из чата, где эти данные не запрашиваются | Настраивает обязательные поля на нужной стадии и шаблон первого ответа клиенту |
| Клиенту дважды позвонили разные сотрудники | Одна и та же заявка создала два контакта | Проверяет дубли и настройки поиска контакта при создании обращения |
Общий принцип простой: у каждого канала приёма заявок должна быть регулярная проверка живым обращением. Раз в неделю кто-то отправляет тестовое сообщение в WhatsApp, заполняет форму на сайте и звонит на линию, а затем смотрит, что карточка создалась, ответственный назначен и задача мастеру ушла. Это десять минут работы, которые избавляют от ситуации, когда форма молчит две недели подряд.
Второй полезный сигнал даёт сравнение количества новых заявок по каналам с обычным уровнем. Если в понедельник из WhatsApp всегда приходит двадцать обращений, а сегодня пришло два, радоваться затишью рано: сначала стоит проверить подключение.
Учёт гарантийных заявок: где хранить гарантию, чтобы не спорить с клиентом
Спор о гарантии почти всегда начинается с того, что у сервиса нет быстрой справки: когда куплена техника, какой у неё срок гарантии, что с ней уже делали. Приёмщик ищет старый акт, клиент ищет чек, и оба теряют время. Учёт гарантийных заявок в CRM решает эту проблему, если продумать, к чему именно привязан срок гарантии.
Вариант 1. Поле с датой окончания гарантии в сделке
Самый быстрый путь: в карточку сделки продажи добавляют поле «Дата окончания гарантии». Для небольшого сервиса этого часто хватает. Минус проявляется позже. Гарантия привязана к продаже, а поломка приходит через год новым обращением. Приёмщику приходится открывать клиента, листать его старые сделки и искать нужную. Если клиент покупал несколько единиц техники, путаница почти гарантирована.
Вариант 2. Отдельная карточка на каждую единицу оборудования
Более надёжная схема строится на смарт-процессах. Это отдельные элементы CRM со своим набором полей, стадиями, воронками, роботами и связями с другими элементами. Создаются они в разделе CRM → Смарт-процессы → Список смарт-процессов. Сервис заводит смарт-процесс условно «Оборудование клиента», где каждая карточка описывает одну единицу техники: модель, серийный номер, дату продажи, срок гарантии, адрес установки.
Карточка оборудования привязывается к контакту или компании, а каждая новая сервисная заявка привязывается к этой карточке. В настройках смарт-процесса есть опции привязки к другим элементам CRM и вывода списка связанных элементов прямо в карточку. В итоге приёмщик открывает аппарат и сразу видит всю историю: когда продан, какие были ремонты, что меняли.
У этой схемы есть цена. Старые продажи придётся перенести в новые карточки хотя бы по активной гарантии, а менеджеров по продажам приучить заводить оборудование при закрытии сделки. Без этого через месяц половина карточек окажется пустой.
Как отделить гарантийный ремонт от платного
Гарантийные и платные заявки удобно вести в разных воронках, потому что у них разные стадии. Платному ремонту нужно согласование стоимости и оплата, гарантийному нужны проверка условий гарантии и, возможно, взаимодействие с поставщиком. Перевод между воронками делают роботом с условием. В роботах Битрикс24 доступны условия «Заполнено», «Не заполнено», «Равно», «Больше», «Меньше», «Между» и объединение условий через И и ИЛИ. Например, если поле «Тип ремонта» равно «Гарантийный», заявка уходит в гарантийную воронку.
Решение о том, гарантийный случай или нет, на старте лучше оставить человеку: приёмщик сверяет дату окончания гарантии и выбирает тип ремонта. Если компания хочет, чтобы система сама сравнивала срок гарантии с сегодняшней датой и проставляла тип, такую логику собирают отдельно, через бизнес-процесс или доработку. Её стоит обсуждать с поддержкой под конкретный портал, потому что универсальной кнопки на этот случай нет.
У гарантийного ремонта часто есть второй участник: поставщик или производитель, который компенсирует запчасти или сам принимает решение по случаю. В гарантийной воронке стоит предусмотреть стадию ожидания ответа поставщика и поле с датой отправки запроса. Иначе заявки, которые неделями ждут решения поставщика, смешиваются с теми, что застряли по вине самого сервиса, и отчёт по срокам ремонта перестаёт что-либо показывать.
Что ломается в гарантийном учёте со временем
Из нашей практики, чаще всего три вещи. Первая: поле гарантии добавили не с первого дня, и у старых карточек оно пустое, поэтому отчёт по гарантийным заявкам показывает меньше, чем есть на самом деле. Вторая: кто-то переименовал или удалил значение в списке «Тип ремонта», и условие робота, которое ждёт старое значение, перестало срабатывать. Третья: к полю, на которое завязан бизнес-процесс, внесли изменения, и процесс начал останавливаться на середине. Все три случая заметны только тогда, когда кто-то целенаправленно проверяет автоматизацию после каждой правки полей.
Повторные обращения: как Битрикс24 их отмечает и почему отметка иногда пропадает
В Битрикс24 есть механизм повторных лидов и сделок. Повторный лид создаётся, когда обращение связано с уже существующим контактом или компанией. Сделка считается повторной, если у клиента уже была хотя бы одна успешная сделка. В карточках и фильтрах такие элементы видны по полям «Повторный лид», «Повторная сделка» и «Повторное обращение».
Включается и выключается механизм в настройках CRM: CRM → Ещё → Настройки → Настройки CRM, раздел «Другое», пункт «Прочие настройки», блок «Настройка лидов». Там находится опция «Включить автоматическую регистрацию повторных продаж», по умолчанию она включена. Если CRM работает в режиме без лидов, повторные обращения не создаются, а новая сделка получает отметку повторной, когда у клиента уже есть успешная сделка.
Почему повторное обращение может остаться незамеченным
Механизм опирается на связь с существующим контактом. Если клиент написал с другого номера, если приёмщик в спешке создал новый контакт вместо того, чтобы найти старый, или если номер телефона записан в другом формате и система не распознала совпадение, обращение будет выглядеть как первое. Для сервиса это особенно болезненно: клиент уверен, что вы знаете о его проблеме, а сотрудник видит новую карточку без истории. Поэтому регулярная чистка дублей входит в поддержку сервисного портала наравне с проверкой роботов. Как это сделать аккуратно, мы описывали в статье как объединить дублирующиеся контакты в Битрикс24.
Практическое правило для приёмщика: перед созданием новой карточки искать клиента по номеру телефона и по серийному номеру техники. Серийный номер надёжнее, потому что клиент может сменить телефон, а аппарат остаётся прежним.
Повторная продажа и повторная поломка: разные вещи
Отметка «Повторная сделка» говорит только о том, что клиент к вам уже обращался. Она не знает, что это та же самая стиральная машина с той же неисправностью через две недели после ремонта. Для сервиса же именно такой случай самый важный: повторная поломка после ремонта означает, что мастер что-то не доделал, а гарантийная заявка на ремонт гарантийного ремонта обходится компании дважды.
Поэтому в сервисной заявке полезно завести собственное поле, например «Связано с предыдущей заявкой», и привязывать новое обращение к прошлому ремонту того же аппарата. Если оборудование ведётся отдельными карточками, как описано выше, связь получается почти сама собой. По такому полю руководитель сервиса видит долю повторных ремонтов по каждому мастеру и по каждой модели техники. Штатные роботы при этом тоже пригодятся: по данным справки Битрикс24, с их помощью повторные сделки можно переводить на другие стадии и в другие воронки и запускать бизнес-процессы.
Что входит в техподдержку Битрикс24 для сервисного отдела
Состав работ зависит от размера портала, но у сервисных компаний он повторяется. В нашу регулярную поддержку обычно входят:
- проверка всех каналов приёма заявок тестовыми обращениями и контроль, что карточки создаются и назначаются;
- правки воронок, стадий и роботов, когда меняется процесс, с проверкой, что соседняя автоматизация не сломалась;
- права доступа для новых мастеров и приёмщиков, отключение уволенных сотрудников и перераспределение их заявок;
- настройка полей и отчётов по гарантийным заявкам, срокам ремонта и повторным обращениям;
- поиск и объединение дублей контактов;
- разбор остановившихся бизнес-процессов и роботов, которые не сработали;
- короткое обучение новых сотрудников работе с карточкой заявки.
Раз в месяц руководитель сервиса получает от нас короткую сводку: какие были сбои и сколько они длились, что изменили на портале, сколько дублей объединили, на каких стадиях копятся заявки. По такой сводке видно, где процесс начинает буксовать, ещё до того, как это заметят клиенты.
Отдельно про время реакции. Сервис часто работает по вечерам и в выходные, а поломка приёма заявок в субботу означает потерянные выходные и пачку недовольных клиентов в понедельник. Поэтому мы держим поддержку 24/7: критичные сбои, когда заявки не создаются или не назначаются, разбираем в любое время суток, не дожидаясь утра рабочего дня. Если вашему сервисному отделу нужна техподдержка Битрикс24 24/7 с людьми, которые знают устройство вашего портала, оставьте заявку на странице услуги.
Если портал ещё только собирается и процесс сервиса пока не описан, начинать лучше с настройки. Про воронку сервисной заявки, выезды и напоминания о ТО есть отдельный материал: Битрикс24 для сервисной компании.
Как сервисному отделу обращаться в поддержку, чтобы задачу решили с первого раза
Половина времени на обращение уходит на уточнения. «Робот не работает» может означать десять разных проблем, и специалист начинает с вопросов вместо решения. Сэкономить это время помогает простой шаблон обращения:
- ссылка на конкретную карточку, где проявилась проблема, а лучше две-три;
- что должно было произойти и что произошло на самом деле;
- когда это заметили и с какого момента, по ощущениям, всё сломалось;
- что меняли на портале в последние дни, если известно;
- скриншот, если ошибка видна на экране.
Внутри компании стоит назначить одного владельца портала. Это не обязательно технический специалист, чаще это старший приёмщик или руководитель сервиса. Он собирает жалобы сотрудников, отсеивает ошибки в работе от ошибок настройки и передаёт в поддержку уже понятные задачи. Когда в поддержку пишут шесть человек с разными формулировками одной и той же проблемы, решение затягивается.
Полезно также договориться о приоритетах. Критично: заявки не создаются, не назначаются или пропадают. Важно: автоматизация сработала не на всех карточках, отчёт показывает неверные цифры. Планово: новое поле, новый отчёт, изменение стадий. Критичные задачи решаются сразу, плановые собираются и выкатываются пакетом, чтобы не трогать рабочий процесс несколько раз в неделю.
Условный пример: сервис бытовой техники с гарантийным отделом
Пример собирательный, цифры условные, но ситуации взяты из типовых обращений. Компания продаёт и ремонтирует бытовую технику. В сервисе три приёмщика и шесть мастеров, заявки приходят с сайта, в WhatsApp и по телефону. Портал настроили восемь месяцев назад, после этого правки вносили сами сотрудники.
Поводом обратиться в поддержку стала жалоба клиента: он дважды писал о поломке холодильника, находящегося на гарантии, и получил ответ только на третий день. Проверка портала показала несколько проблем сразу.
Форма на сайте после обновления темы перестала передавать заявки в CRM, и одиннадцать дней все обращения с сайта уходили на почту, которую никто не читал. Роботы на стадии «Диагностика» были настроены на старую воронку, а заявки после реорганизации шли в новую, поэтому мастера узнавали о них из чата. У заметной части клиентов было по два-три контакта, и повторные обращения система не отмечала. В карточках продаж, закрытых до появления поля гарантии, срок гарантии не был заполнен, и приёмщики определяли его по памяти.
Исправление заняло около двух недель. Форму переподключили и настроили еженедельную тестовую заявку. Роботов перенесли на актуальную воронку и сверили с описанием процесса. Дубли объединили, а приёмщиков научили искать клиента по номеру перед созданием нового контакта. Для техники на действующей гарантии завели карточки оборудования и перенесли туда данные из старых продаж. В заявку добавили поле «Связано с предыдущей заявкой», и через месяц руководитель сервиса впервые увидел, у какой модели и какого мастера больше всего повторных ремонтов.
Ни одна из этих проблем не была сложной технически. Все они накопились, потому что за порталом никто не следил, а каждый сотрудник исправлял то, что мешало лично ему.
Частые вопросы
Чем техподдержка Битрикс24 от партнёра отличается от поддержки самого Битрикс24?
Поддержка вендора отвечает на вопросы о работе платформы: как устроена функция, почему сервис недоступен. Партнёрская поддержка работает с вашими настройками: воронками, роботами, полями, правами и процессом сервисного отдела, и вносит изменения на портале.
Можно ли вести учёт гарантийных заявок без смарт-процессов?
Можно. Для небольшого сервиса хватает поля с датой окончания гарантии в сделке и отдельной воронки для гарантийного ремонта. Смарт-процесс с карточками оборудования нужен, когда у клиентов много техники и важна история ремонтов по каждому аппарату.
Как отключить автоматическое создание повторных лидов и сделок?
В разделе CRM → Ещё → Настройки → Настройки CRM откройте «Другое», затем «Прочие настройки» и блок «Настройка лидов». Там есть опция «Включить автоматическую регистрацию повторных продаж». Перед отключением стоит проверить, не завязаны ли на повторные сделки роботы и отчёты.
Вы поддерживаете и облачный, и коробочный Битрикс24?
Да, мы работаем с обеими версиями. Для сервисного отдела подход одинаковый: проверка каналов, автоматизации, гарантийного учёта и повторных обращений, различаются только технические детали доступа к порталу.
Как быстро поддержка реагирует на сбой приёма заявок?
Мы на связи 24/7. Сбои, из-за которых заявки не создаются или не назначаются, берём в работу сразу в любое время суток, плановые доработки согласуем и выполняем в оговорённые сроки.