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

С чего начинается путаница на масштабе

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

Первое — смены. Утренний оператор принял обращение, к вечеру его нет, а клиент вернулся с уточнением. Если контекст не передан, вечерняя смена начинает диалог с нуля, и клиент это чувствует.

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

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

Дальше — по шагам, как это закрывается.

Шаг 1. Снять с людей рутину — пусть первую линию держит бот

Большая часть обращений на сети — повторяющиеся: часы работы, адрес филиала, статус записи, цены, «как проехать». Если это разбирают живые операторы, они выгорают на однотипных вопросах, а действительно сложные диалоги ждут в очереди.

Первую линию в BOTIX держит ассистент. Все каналы — Telegram, WhatsApp, ВКонтакте, виджет на сайте и остальные — сходятся в один движок: сценарий и ассистент работают одинаково, независимо от того, откуда пришёл клиент. Оператор не сидит в пяти разных мессенджерах — рутину отсекает бот, а людям остаётся то, где нужен человек.

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

Шаг 2. Передавать диалог оператору вместе с контекстом

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

BOTIX передаёт диалог в ту систему, где ваша команда операторов уже работает. Есть готовые интеграции:

• RetailCRM — сообщения между клиентом и оператором идут в обе стороны через Chat API. Клиент пишет в своём мессенджере, оператор отвечает из RetailCRM, переписка не рвётся.
• ПланФикс — каждое обращение из бота становится задачей, а комментарии оператора в этой задаче пересылаются клиенту обратно в его канал.

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

Шаг 3. Сохранить контекст между сменами

Передача между сменами — место, где чаще всего теряется нить. Что помогает удержать её:

• Единая база знаний на сеть. Ответы, регламенты и тон общения ведутся централизованно — любая смена отвечает одинаково, а не «как привык этот оператор». Обновили правило один раз — его знают все.
• Карточка клиента с историей. Обращения и записи копятся в карточке контакта. Вечерняя смена открывает её и видит, что было утром, а не полагается на устный пересказ.
• Локальное — у каждого филиала. Адрес, расписание, локальные цены привязаны к своей точке, поэтому оператор не путает данные соседнего филиала.

Контекст живёт не в голове конкретного сотрудника, а в системе — и переживает пересменку.

Шаг 4. Назначить, кто за что отвечает

Последний шаг — границы. В BOTIX ровно три роли, и один человек — одна роль на проект:

• Владелец — видит всё: все точки, финансы, настройки, управляет командой.
• Администратор — ведёт операционку: записи, клиентов, контент бота, но без долгосрочных финансов и без банковских реквизитов.
• Сотрудник — работает со своей операционкой: своими клиентами и записями. Телефоны и email клиентов ему показываются маскированно, чужое он не видит.

Для сотрудника данные фильтруются автоматически — он видит только то, что закреплено за ним, а не всю сеть. Это снимает и лишний доступ, и вопрос «а моё ли это»: зона каждого очерчена ролью.

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

Отдельная тонкость сети: филиалы не смешиваются

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

Что в итоге меняется

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