Как организовать обработку входящих обращений в Битрикс24: от письма и звонка до результата

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

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

Минимальный процесс выглядит так: поступило обращение → определили клиента и тип заявки → назначили ответственного → обработали самостоятельно или поставили задачу коллеге → ответили клиенту → зафиксировали результат.

Начинать стоит с проверки данных и этой последовательности на реальных обращениях, а не с добавления новых роботов и сложных бизнес-процессов.

Какие данные нужно привести в порядок до автоматизации

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

Для начала согласуйте минимальный набор сведений:

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

Источник обращения: почта и телефония требуют отдельной проверки

В Битрикс24 есть поле «Источник» и поле «Дополнительно об источнике». Но не стоит считать, что значения заполняются одинаково для всех подключений.

Например, при некоторых сценариях SIP-телефонии дополнительная информация может обозначать подключение, а не конкретный номер, на который позвонил клиент. Поэтому требуемый номер нужно искать и проверять в фактических данных своей интеграции, а не предполагать, что он уже записан в нужном поле. Подробности зависят от настройки телефонного канала. См. справку Битрикс24 по SIP и коллтрекингу.

Отправьте контрольное письмо на каждый используемый ящик и позвоните на каждый согласованный входящий номер. Затем откройте созданные записи в CRM: совпадают ли фактические значения источников с правилами распределения?

Для известного и нового клиента обработка может различаться. Это тоже стоит включить в проверку, прежде чем считать правило универсальным.

Контакт, компания и объект: не путать роли

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

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

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

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

«Тип заявки»: категории на основе реальных обращений

Поле «Тип заявки» полезно сразу для двух задач: текущего учёта и будущего анализа повторяющихся вопросов.

Посмотрите выборку недавних писем, выделите повторяющиеся темы и согласуйте названия с сотрудниками. Например, могут получиться категории «Документы», «Оплата», «Технический вопрос», «Статус исполнения». Это условный набор, а не готовый справочник для любой компании.

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

Лиды или сделки: где обрабатывать обращения

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

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

Лид - отдельная запись CRM, которую в некоторых процессах используют для предварительной обработки входящего запроса. Если в лидах уже настроены нужные проверки и бизнес-процессы, удалять их ради новой воронки не требуется.

Возможны два сценария:

• Без промежуточного технического лида.
  Подключённый канал и настройки CRM позволяют создавать или связывать нужную рабочую запись непосредственно со сделкой. Конкретное поведение нужно проверить.

• С технической обработкой в лидах.
  Сначала выполняются необходимые действия и проверки, затем на основании лида создаётся сделка для повседневной работы сотрудника. Ненужные старые автоматизации можно отключить, сохранив настройки на случай проверки или возврата.

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

Возможность конвертации и её настройки зависят в том числе от режима CRM, прав, обязательных полей и доступных роботов. См. инструкцию Битрикс24 по конвертации лидов.

Для сотрудников процесс при этом может оставаться одним: они работают в согласованной воронке обращений и не отвлекаются на технический контур.

Отдельно проверьте права доступа. Убрать пункт «Лиды» из меню или скрыть лишнюю воронку недостаточно для ограничения доступа к данным: навигацию и права CRM настраивают и проверяют отдельно.

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

Как организовать распределение обращений

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

Минимальная схема распределения:
Почтовый ящик или телефонный источник → ответственный отдел → конкретный сотрудник → резервное действие, если назначить некому.

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

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

1. Распределение на уровне канала. Например, своя очередь в телефонии или открытой линии.
2. Ответственный за CRM-запись. Человек, который ведёт сделку с клиентом до результата.
3. Исполнитель внутренней задачи. Коллега, который выполняет отдельную часть работы и не обязательно отвечает перед клиентом.

Штатный робот Битрикс24 «Изменить ответственного» поддерживает, в частности, последовательный выбор сотрудников и отдельные настройки учёта отсутствий и завершённого рабочего дня. Если все сотрудники в очереди завершили рабочий день, робот может не изменить ответственного.

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

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

Подробный выбор между штатной очередью и распределением по нагрузке разобран в статье «Распределение сделок в Битрикс24».

Какой должна быть воронка «Входящее обращение»

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

Ниже один из возможных вариантов для сервисных обращений:

1. Необработанная. Обращение поступило, сотрудник ещё не начал разбор.
2. Ответственный назначен. Понятно, кто должен выполнить следующий шаг.
3. В работе. Запрос изучают, отвечают или организуют исполнение.
4. Передана клиенту, ожидаем обратную связь. Вопрос или предварительный результат направлен клиенту; нужен его ответ.
5. Передана в исполнение. Для решения требуется действие другого сотрудника или подразделения.
6. Клиенту ответили. Ответ направлен; нужно проверить, закрыт ли вопрос полностью.
7. Успешно завершена. Результат зафиксирован, необходимая работа выполнена, дальнейших действий по обращению не требуется.

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

Простая логика:
Необработанная → Ответственный назначен → В работе → ответ / ожидание клиента / внутренняя задача → Клиенту ответили → Успешно завершена.

Если организация использует другие формулировки или ей достаточно меньшего числа стадий, не нужно копировать этот список механически.

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

Как сотрудник обрабатывает обращение и передаёт задачи коллегам

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

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

Когда нужен другой отдел, начните с простого способа передачи поручения. Отдельный бизнес-процесс требуется не для каждого такого случая.

Условный пример. Клиент спрашивает, выполнена ли ранее согласованная работа. Менеджеру нужна проверка технического специалиста.

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

В такой схеме у работы два разных уровня ответственности:

• Сделка: кто отвечает за общение с клиентом и закрытие обращения.
• Связанная задача: кто выполняет конкретное внутреннее поручение.

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

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

Как проверить, что процесс действительно работает

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

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

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

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

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

Возникшие в реальной работе вопросы - повод скорректировать поля, стадии, права или порядок действий, а не сразу добавлять новый уровень автоматизации.

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

Отдельно о вариантах обучения сотрудников есть статья «Как обучить сотрудников работе в Битрикс24».

Как обращения становятся основой базы знаний и ИИ

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

Но здесь есть принципиальное различие: накопление истории обращений ещё не равно накоплению проверенных знаний.

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

Рабочая последовательность может выглядеть так:

История обращения → кандидат на повторно используемое решение → проверка специалистом → утверждённое и поддерживаемое знание → возможная помощь ИИ.

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

На проверенных материалах впоследствии можно проектировать поиск похожих решений, классификацию заявок или черновики ответов. Это отдельная задача: нужно определить источники, доступы и роль человека в проверке ответа. Закрытие сделки само по себе не обучает ИИ.

Как организовать уже саму базу знаний с AI и передачу нерешённых вопросов специалистам, отдельно разобрали в статье «База знаний в Битрикс24 с AI».

С чего начать в своей компании

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

1. Выписать действующие источники и согласовать, какой отдел отвечает за каждый из них.
2. Определить небольшой набор необходимых данных, проверить связи контактов и компаний, согласовать типы заявок.
3. Выбрать рабочий объект и понятные стадии; сохранить нужные технические настройки, убрать лишь мешающее и проверить права сотрудников.
4. Установить правила ответа клиенту, передачи связанных задач и завершения обращения.
5. Провести контрольные обращения и попросить сотрудников самостоятельно пройти полный цикл.
6. После накопления проверенных решений отдельно решить, какие из них достойны базы знаний и где может быть полезен ИИ.

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

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