В банк звонит клиент — срочно нужно узнать, почему не прошёл перевод. Оператор открывает три вкладки: в одной — тарифы, в другой — регламент по блокировкам, в третьей — FAQ с кодами ошибок. Пока он сверяет пункты, клиент ждёт. Секунды складываются в минуты, минуты — в раздражение. Получается, знания у сотрудника контакт-центра есть, но они разрознены. Вместо помощи клиенту приходится тратить время на поиски.
Решение — база знаний, которая не просто хранит документы, а становится рабочим инструментом. Здесь собраны продуктовая матрица, регламенты, глоссарий и, главное, готовые сценарии диалога.
Разберём, из чего строится такая система, как сделать скрипты полезными, а не формальными. Покажем на реальном примере, как это работает — в том числе на платформе Teamly, где сценарии собираются прямо в базе знаний.
Что хранит база знаний
Эффективная база знаний — это не «склад» документов, а продуманная структура, где каждый блок решает конкретную задачу оператора.
Продуктовая матрица. Это фундамент для любой консультации. Оператору важно быстро сравнить условия. Например, клиенту нужно выбрать вклад. За пару кликов специалист смотрит ставки, сроки, возможность пополнения и снятия, а также комиссии. На практике это выглядит так: оператор открывает карточку продукта и сразу получает не только цифры, но и подсказки, какие аргументы лучше использовать в разговоре. После внедрения единой платформы (вроде Teamly) операторы перестают «гулять» по разным файлам: вся продуктовая линейка собрана в одном месте, с фильтрами и возможностью быстрого сравнения.
Процессы и регламенты. Здесь хранятся пошаговые алгоритмы: от открытия счёта до блокировки карты и оформления заявки. Сюда же входят внутренние политики, требования регуляторов и комплаенс-ограничения. В банковской сфере правила меняются регулярно, и критически важно, чтобы у оператора был один «источник правды». Если в регламент внесли правки, они автоматически подтягиваются во все связанные сценарии — и риск работать по устаревшей инструкции сводится к минимуму. Для этого, например, можно использовать инструмент «синхронизированный блок».
Типовые клиентские сценарии и FAQ. Это готовые ответы на частые вопросы и решения типовых проблем. Например, клиент спрашивает: «Почему у меня списалась комиссия?» — оператор не придумывает формулировку на ходу, а берёт проверенный ответ и при необходимости дополняет его деталями. Такие заготовки экономят время и делают качество обслуживания стабильным: неважно, кто принял звонок — клиент получит корректную информацию.
Единый глоссарий. Словарь терминов с контекстными подсказками помогает говорить с клиентом на одном языке. В современных системах достаточно навести курсор на термин в тексте статьи — и сразу появится короткое определение. Это особенно полезно для новичков: они быстрее осваивают профессиональную лексику, а опытные операторы не тратят время на уточнение формулировок.
Скрипты диалога: когда база знаний становится живым инструментом
База знаний ценна не сама по себе, а тем, как она помогает оператору в реальном разговоре. Скрипт здесь — не шпаргалка, а навигатор: он ведёт сотрудника от первого «здравствуйте» до финального «до свидания», подсказывая, что сказать, что проверить и куда направить клиента.
Хороший пример — разговор про ошибку перевода. Вместо того чтобы держать в голове десятки возможных причин, оператор идёт по шагам: сначала приветствует и идентифицирует клиента, затем проверяет базовые гипотезы (лимиты, баланс, блокировку, корректность реквизитов) и только при необходимости передаёт обращение дальше. Каждый шаг в таком сценарии — это готовая статья базы знаний с инструкциями, скриншотами и ссылками на регламенты.
Принципы разработки эффективного скрипта
Чтобы скрипт действительно помогал, а не мешал, в его основе должны лежать три принципа.
Персонализация. Скрипт даёт готовые фразы, но не делает из оператора робота. Например, шаблон приветствия может выглядеть так: «Здравствуйте, [Имя Отчество], это [банк], меня зовут [Имя], я помогу вам с вопросом по переводу». Дальше оператор адаптирует формулировки под интонацию и ситуацию. Практика показывает: даже небольшая персонализация заметно снижает напряжённость в разговоре и повышает доверие клиента.
Единый тон. Банк — это единый бренд, и клиент должен получать одинаковый уровень сервиса независимо от того, к какому оператору он попал. Тон может быть дружелюбным и заботливым, но при этом профессиональным: без излишней формальности и без панибратства. В базе знаний закрепляются стандарты: какие фразы уместны, а какие — нет, как мягко сообщать об ограничениях и как завершать разговор.
Динамичность. Сценарий должен быть гибким. Оператор следует логике скрипта, но может отклоняться, если клиент сообщает новую информацию. Например, в середине разговора клиент вспоминает, что уже пробовал повторить перевод — и оператор сразу переходит к проверке гипотез, минуя лишние вопросы. В визуальном конструкторе (как в Teamly) это реализуется через ветвления: из каждого шага выходят 2–3 варианта («идентификация успешна», «идентификация не пройдена», «требуется дополнительная проверка»), и оператор мгновенно понимает, куда двигаться дальше.
Эти принципы работают вместе: персонализация и единый тон создают правильный эмоциональный фон, а динамичность даёт свободу в рамках стандарта.
Пошаговая методология создания скрипта
На современных платформах сценарий диалога строится как блок-схема, где каждый шаг — это полноценная статья базы знаний. Технически процесс выглядит так:
Сценарий создаётся в визуальном конструкторе без программирования: достаточно перетаскивать блоки и соединять их стрелками.
Каждый блок имеет порядковый номер, название, текст инструкции для оператора и обязательные действия.
Из каждого блока выходят 2–3 понятных варианта ветвления — например, «лимит не превышен», «лимит превышен», «требуется эскалация».
Каждый шаг — самостоятельная статья: в неё можно добавить скриншоты, видеоинструкции, ссылки на регламенты, чек-листы и примеры типовых ошибок.
Шаги могут быть общими для нескольких сценариев. Если обновили инструкцию по идентификации, она меняется сразу во всех скриптах, где используется этот шаг.
Такой подход даёт сразу несколько преимуществ:
Стандартизация. Все операторы работают по одинаковым шагам, что снижает количество ошибок.
Упрощённое обучение. Новые сотрудники осваивают не многостраничные регламенты, а конкретные сценарии, которые можно отрабатывать на тренажёрах.
Быстрые правки. Если изменился тариф или появился новый продукт, достаточно обновить один шаг — и он автоматически применяется во всех связанных сценариях.
Пример скрипта: «Клиент сообщает об ошибке при попытке перевода» (телефонный канал)
Шаг 1. Приветствие и идентификация
Оператор: «Здравствуйте, [Имя Отчество], это [банк], меня зовут [Имя]. Помогу вам разобраться с проблемой перевода. Для безопасности подтвердите, пожалуйста, личность: назовите серию и номер паспорта либо кодовое слово».
Важно: до завершения идентификации оператор не проверяет в АБС никакие данные клиента и не озвучивает персональную информацию.
Ветвления:
Идентификация успешна → Шаг 2.
Идентификация не пройдена → Шаг 1а: предложить альтернативный способ подтверждения (контрольный вопрос, СМС‑код). Если и это не сработало → Шаг 1б: вежливо сообщить, что без подтверждения личности продолжить консультацию нельзя, и предложить варианты решения (например, обратиться в отделение или повторить звонок с подтверждённого номера).
Шаг 2. Автоматическая проверка статусов (по данным АБС)
Оператор проверяет в системе три ключевых параметра:
статус счёта/карты (активен ли счёт, нет ли блокировки по комплаенс‑основаниям);
наличие средств с учётом комиссии;
лимиты (суточные/месячные) на переводы.
Результат проверки сразу определяет дальнейший маршрут.
Ветвления:
Блокировка по комплаенс‑основаниям (в т. ч. 115‑ФЗ) → Шаг 2а: оператор не предлагает «разблокировать по телефону» и не даёт ложных надежд. Готовая формулировка: «Вижу, что по счёту действуют ограничения в соответствии с внутренними правилами банка. Чтобы разобраться в ситуации, нужно предоставить пояснения и документы. Сейчас передам ваше обращение профильным специалистам — они свяжутся с вами и расскажут, какие шаги предпринять». Переход к Шагу 5 (эскалация).
Недостаточно средств → Шаг 2б: сервисная формулировка: «На счёте недостаточно средств с учётом комиссии за перевод. Вы можете пополнить счёт или, если удобно, выполнить перевод на меньшую сумму. Подскажу, как это быстро сделать в приложении». Завершить диалог либо помочь с пополнением, если это предусмотрено скриптом.
Превышен лимит → Шаг 2в: формулировка: «Сумма перевода превышает текущий лимит. Я могу рассказать, как его увеличить в приложении или через поддержку, либо подобрать альтернативный способ отправки денег. Что удобнее?» В зависимости от выбора клиента — дать краткую инструкцию или завершить консультацию.
Всё в порядке → Шаг 3.
Шаг 3. Сбор анамнеза (только то, что нельзя проверить автоматически)
Оператор задаёт короткие, чёткие вопросы, ответы на которые фиксируются в карточке обращения:
«Расскажите, пожалуйста, какой тип перевода вы пробовали: по номеру карты, по телефону, по реквизитам, межбанковский?»
«Какая сумма и валюта перевода?»
«Какой текст ошибки вы видели (можно процитировать или назвать код ошибки)?»
«Где пытались сделать перевод: в мобильном приложении, веб‑версии, банкомате?»
«Эта ошибка возникает только с этим получателем или при любых переводах?»
Цель шага — собрать именно те детали, которые не видны в АБС и без которых невозможно точно определить причину.
Шаг 4. Проверка гипотез (только уникальные причины)
На этом шаге оператор работает с причинами, которые не покрываются автоматической проверкой из Шага 2. Каждая гипотеза — это отдельная статья с инструкцией.
Гипотеза 1 — ошибка в реквизитах. Оператор предлагает: «Давайте сверим реквизиты получателя. Если у вас есть шаблон или история успешных переводов, можно скопировать данные оттуда — так меньше риск опечатки». При необходимости даёт короткую инструкцию по копированию реквизитов.
Гипотеза 2 — технический сбой на стороне банка/платёжной системы. Оператор проверяет внутренний дашборд инцидентов: статус систем, наличие известных сбоев, ETA восстановления. Если инцидент подтверждён: «Сейчас есть временный сбой в работе сервиса. Рекомендую повторить перевод через 30 минут. Мы уже работаем над устранением проблемы». В карточке обращения фиксируется ID инцидента и ETA.
Гипотеза 3 — специфическая ошибка ДБО (нестандартный код, проблема с шаблоном). Оператор сверяется с базой известных ошибок: если есть готовое решение — даёт клиенту пошаговую инструкцию со скриншотами (если интерфейс позволяет) или описывает действия словами. Если решения нет — переход к Шагу 5.
Если одна из гипотез подтверждается и проблему удаётся решить — оператор кратко резюмирует решение и уточняет, всё ли понятно. Если ни одна гипотеза не сработала — переход к Шагу 5.
Шаг 5. Эскалация на вторую линию
Оператор заполняет стандартную форму эскалации, где обязательно указывает:
тип перевода, сумма, валюта;
реквизиты получателя (минимум — номер карты/счёта или телефон);
текст/код ошибки, способ совершения, повторяемость;
результаты проверок из Шага 2 (баланс, лимиты, статус счёта);
ID инцидента (если был технический сбой);
логи/ID сессии (если доступно в АБС).
Готовая формулировка для клиента: «Я зафиксировал(а) вашу ситуацию и передал(а) обращение профильным специалистам. Ожидайте обратную связь в течение [согласно SLA]. Мы будем держать вас в курсе». Обращение закрывается с пометкой «Эскалировано».
Единая платформа: когда скрипты собираются прямо в базе знаний
Ключевое преимущество современных решений — использование сценариев непосредственно в базе знаний. На платформе Teamly это реализовано так, что контент-менеджеры могут обновлять сценарии без программистов: достаточно зайти в визуальный конструктор, перетащить блок, добавить ссылку или вставить скриншот.
Практические удобства такого подхода:
Визуальный конструктор. Создание блок-схем без кода, с понятными подписями на выходах и ссылками на статьи.
Каждый шаг — полноценная статья. В один клик оператор получает всё необходимое: видеоинструкцию, скриншот, чек‑лист, ссылки на внутренние регламенты.
Интеграция с CRM и АБС. Проверка данных клиента происходит прямо из интерфейса скрипта — без переключения между окнами.
Умный поиск. Система находит нужную статью даже при опечатках, неверной раскладке и разных словоформах — как в привычном интернет‑поиске.
Гибкая навигация. В любой момент можно вернуться к предыдущему ветвлению (если клиент вспомнил новую деталь), начать сценарий заново или посмотреть подсказки по шагу без потери контекста.
Единое хранилище. В одной системе собраны все сценарии, инструкции, глоссарий и регламенты — так оператор всегда работает с актуальной версией документов и может моментально найти нужную информацию.
***
База знаний со скриптами — это не архив регламентов, а живой рабочий контур поддержки. Пока инструкции лежат в разных файлах, качество обслуживания неизбежно «плавает»: один оператор помнит актуальный порядок действий, другой опирается на старую версию, третий тратит время на поиск. В банковской среде такая несогласованность — прямой риск: и для клиента, и для соблюдения регуляторных норм.
Сценарный подход снимает эту проблему: вместо разрозненных документов оператор получает понятный алгоритм с готовыми ветвлениями, подсказками и интеграцией в рабочие системы. Качество перестаёт зависеть от личной памяти сотрудника и становится воспроизводимым стандартом — даже в пиковую нагрузку и при высокой текучке кадров.
Разумная точка входа — не глобальная автоматизация, а точечный пилот на самых массовых типах обращений. Достаточно собрать 2–3 сценария (например, по ошибкам переводов, блокировкам карт и вопросам комиссий) и оценить эффект по двум метрикам: сколько времени экономится на каждом обращении и как меняется удовлетворённость клиентов. Такие цифры — самый убедительный аргумент для масштабирования: они показывают не абстрактную пользу, а конкретный вклад в операционную устойчивость банка.
