То, что абонент Х, во-первых, в рамках своей категории В относится к VIP-клиентам, во-вторых, звонит уже третий раз подряд в течение одного дня и до сих пор не может решить свою проблему, – все это не принимается во внимание.
Мало того, если абонент Х еще и перепутает номер телефона, по которому он должен звонить, и наберет 333-33-33 или 111-11-11 вместо назначенного для него 222-22-22, то система вообще не сможет правильно идентифицировать этого клиента и его вызов поступит на обслуживание совсем не к той группе операторов. Между тем путаница в номерах случается довольно часто. Например, клиенты могут запомнить рекламный номер и пользоваться только им, и тогда вся политика сегментации клиентов потеряет смысл.
Теперь представим, что та же гипотетическая компания имеет средства компьютерно-телефонной интеграции. В этом случае она может даже не заботиться о назначении разных номеров доступа в ЦОВ разным категориям абонентов, поскольку категория будет определяться на основе базы данных. Итак, поступил вызов от абонента Х. Система тут же обращается к базе данных, чтобы определить, что это за абонент и каким образом следует обслужить его вызов.
Предположим, условно говоря, что в клиентской базе данных в поле 1 стоит буква В. Значит, абонент относится к этой категории. В поле 2 стоит символ «VIP». Что ж, и тут все ясно: вызову должен быть присвоен высший приоритет и он должен быть направлен в группу операторов, обслуживающих клиентов категории В. А вот в поле 3 стоит цифра 2. Что это значит? А то, что данный абонент уже звонил дважды в течение дня по одной и той же проблеме, и поскольку звонит в третий раз, то, скорее всего, она так и осталась нерешенной.
Определяем, какие операторы обслуживали клиента при первых двух звонках: Иванов и Рабинович (ну так, для разнообразия). Проверяем, свободны ли они сейчас. Если не занят один из них, к нему и направляем. Если свободны оба, направляем вызов к тому, кто обслуживал вызов последним. Если оба заняты, присваиваем вызову наивысший приоритет и направляем его в очередь напрямую к тому, кто обслуживал вызов последним (Direct Agent Call). И только если ни тот ни другой не могут обслужить вызов (ушли на перерыв, закончили смену и т. д.), клиент Х будет обслужен другими операторами.
Ну как, почувствовали разницу?..
CTI и входные объявления
Как мы уже говорили, CTI отвечает за маршрутизацию вызовов, т. е. за алгоритм их обслуживания. Это относится ко всему процессу в целом, а не только к выбору группы операторов, способных наилучшим образом обслужить данный вызов. Например, с помощью CTI можно выбрать наиболее подходящее для конкретного вызова приветствие или интерактивное меню и таким образом сделать процесс обслуживания еще более гибким.
Без CTI, с помощью одной только системы ACD, выбор входных объявлений определяется в основном набранным номером. Представим, например, некую гипотетическую страховую компанию. Если абонент позвонит по телефону отдела страхования транспорта, то он может услышать меню вызова типа «Если вы звоните по вопросу КАСКО, нажмите 1, ОСАГО – нажмите 2».
Выбор входного приветствия в данном случае, как мы видим, основан только на набранном номере. Теперь давайте представим, что в той же гипотетической страховой компании внедрили CTI. В этом случае, если при поступлении вызова система определит, что звонящий уже оформил договор на добровольное страхование машины, меню вызова воспроизводиться не будет и данный звонок поступит напрямую к группе операторов, занимающихся именно добровольным автострахованием.
Другой пример. Предположим, некий гипотетический банк объявляет новую рекламную кампанию, например предоставление кредита на чрезвычайно выгодных условиях. И хотя, как мы подчеркивали в главе 3, во входные объявления не следует вставлять рекламную информацию, банк настолько агрессивен при проведении своей кампании, что собирается на время пренебречь этим правилом. Ну что ж, по крайней мере он может смягчить последствия такого поведения и не навязывать рекламную информацию хотя бы тем клиентам, которые уже воспользовались рекламируемой услугой (в нашем примере – оформили кредит). В этом случае, если при поступлении вызова система определит, что данному клиенту кредит уже предоставлен, он будет избавлен от прослушивания входного объявления.
«Всплывающие окна» и перевод вызова вместе с данными
После того как система обращается к клиентской базе данных и находит там записи, относящиеся к искомому клиенту, задействуется функция компьютерно-телефонной интеграции, которая по-английски называется Screen Population (чаще – просто Screen Pop), а по-русски – «всплывающее окно». С помощью этой функции одновременно с поступлением звонка на экране компьютера оператора высвечивается информация о вызывающем абоненте, извлеченная из клиентской базы данных (рис. 7.3).
Таким образом, оператор, отвечая на звонок, уже знает, кто именно ему звонит. Преимущества очевидны. Во-первых, оператор не тратит драгоценное время на извлечение из базы данных сведений о клиенте, а во-вторых, во многих случаях благодаря «всплывающему окну» оказывается уже частично осведомленным о вопросе, по которому ему звонит абонент.
Если оператор, ответивший на звонок, по какой-либо причине не в состоянии его полностью обслужить и необходимо перевести вызов на другого оператора (а такое, к сожалению, иногда случается даже при наличии интеллектуальной маршрутизации с помощью CTI), то и при переводе вызова сработает функция «всплывающее окно». Сотрудник, которому поступит переведенный вызов, одновременно со звонком увидит на экране своего компьютера «всплывающее окно», содержащее: 1) сведения о вызывающем абоненте из клиентской базы данных и 2) сведения, внесенные первым оператором. Замечу только, что переводить звонок одновременно с данными можно не на любого сотрудника компании, а лишь на того, кто вошел в систему в качестве оператора.
Во «всплывающем окне» может содержаться любая информация, которая требуется для обслуживания вызовов. Каждая компания определяет для себя, какого рода сведения о клиенте и в каком виде необходимо выдавать на экран оператора. Это может быть всего одно поле одной базы данных или компиляция из нескольких полей нескольких баз данных.
Отнюдь не всегда надо следовать правилу «чем больше информации, тем лучше». Обилие разного рода сведений может только отвлекать оператора, мешать ему. Поэтому, мне кажется, надо выдавать во «всплывающем окне» необходимый минимум информации. Если ее окажется недостаточно, то оператор всегда может дополнить ее, использовав базу данных вручную.
