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

Для претензии не определён самостоятельный путь

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

Жалоба не создаёт новую продажу. Она меняет работу по уже состоявшейся покупке.

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

Ошибку приняли за новую сделку

Когда жалобу записывают как обычную коммерческую карточку, отдел начинает измерять её стадиями продажи, поэтому ожидание заключения специалиста может выглядеть как подготовка предложения, а закрытие претензии — как ещё одна успешная покупка в общей очереди менеджера. Предмет работы у претензии другой. В Битрикс24 смарт-процесс позволяет настроить собственный сценарий CRM — отдельный вид карточки под задачу компании. Сотрудник сопровождения получает свою очередь и сохраняет результат рядом с покупкой. Менеджер продолжает видеть прежний коммерческий результат, а руководитель находит оставшееся обязательство.

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

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

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

Причина записана до выяснения обстоятельств

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

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

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

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

Ответственный пропал после передачи специалисту

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

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

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

Для ожидания действия подходит универсальное дело Битрикс24, в котором можно задать описание и крайний срок. Оно помогает сотруднику вернуться к вопросу. Срок выбирают по содержанию обязательства и реальной возможности ответить; в описании указывают, какое действие требуется по этой претензии.

Стадия описывает настроение вместо работы

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

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

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

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

Карточку закрыли после отправки письма

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

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

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

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

Похожие обращения потерялись в свободном тексте

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

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

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

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

Найдите обещание, которое ещё не исполнено

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

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

Для организации обработки претензий в Битрикс24 передайте интегратору этот путь и критерии завершения. Специалист предложит карточки, связи и уведомления, а руководитель оценит результат по судьбе ответа и обещания клиенту.