Что учитывать при переносе контакт-центра на российскую платформу
Автор:
Дмитрий Томилов
Дмитрий Томилов
Менеджер проектов, «Авантелеком»
Зарубежное ПО для телефонии и контакт-центров — Cisco, Avaya и другие решения — становится источником операционных рисков: сложнее поддерживать инфраструктуру, получать обновления и развивать систему. Но контакт-центр нельзя заменить одним «переключением рубильника», тем более зрелый. Это критичная для бизнеса система и перенос контакт-центра на российскую платформу затрагивает сразу несколько взаимосвязанных компонентов.
Нужно перенести не только само программное обеспечение, но и всю существующую логику работы: номера и маршруты, IVR, очереди, записи разговоров, интеграции с CRM и другими системами, рабочие места операторов и инструменты контроля. И чем сложнее инфраструктура, тем выше риск, что отдельные зависимости всплывут уже после начала миграции.
В «Авантелеком» мы участвуем в проектах переноса контакт-центров на российские платформы и видим: проблемы чаще всего возникают не из-за самойа миграции, а из-за неучтенных интеграций и нехватки проработанной поэтапности перехода. А такой проект — это именно поэтапная перестройка всей экосистемы контакт-центра.
В этой статье разберем, опираясь на экспертизу «Авантелеком», что нужно учесть при переносе контакт-центра на отечественную платформу: от аудита текущей инфраструктуры и выбора решения до сохранения истории обращений, записей разговоров, интеграций и рабочих мест операторов.
В «Авантелеком» мы участвуем в проектах переноса контакт-центров на российские платформы и видим: проблемы чаще всего возникают не из-за самойа миграции, а из-за неучтенных интеграций и нехватки проработанной поэтапности перехода. А такой проект — это именно поэтапная перестройка всей экосистемы контакт-центра.
В этой статье разберем, опираясь на экспертизу «Авантелеком», что нужно учесть при переносе контакт-центра на отечественную платформу: от аудита текущей инфраструктуры и выбора решения до сохранения истории обращений, записей разговоров, интеграций и рабочих мест операторов.
Краткий ответ: что учитывать при переносе контакт-центра на российскую платформу
Перед миграцией контакт-центра на российскую платформу стоит трезво оценить задачи и нагрузку, которые несет система, — от этого зависит выбор платформы. Поскольку «Авантелеком» ведет такие проекты под ключ, от аудита до постпродакшн-поддержки, то опираясь на свой опыт внедрений, расскажем что происходит дальше в успешных проектах.
После аудита смотрят на каналы связи и логику маршрутизации, совместимость с имеющимся оборудованием и то, как на переходный период организовать сосуществование с Cisco или Avaya, пока старая система не отключена полностью.
Отдельно стоит проговорить сохранность данных. История обращений, записи разговоров, интеграции с CRM — всё это должно переехать на новую систему без потерь. Например, если у оператора связи хранится три года записей звонков для разбора спорных ситуаций с клиентами, а после миграции доступна только последняя неделя — это уже не мелкая недоработка, а серьёзная проблема для бизнеса.
Если для заказчика принципиально работать с отечественным ПО — скажем, это компания с госучастием или подпадает под требования по импортозамещению — стоит заранее свериться, есть ли решение в реестре российского ПО. Выяснять это постфактум, когда закупка уже согласована, гораздо дороже.
И ещё один момент, который часто недооценивают: не стоит переключать всех операторов на новую систему одним днём. Лучше сначала прогнать пилот в параллельном контуре — например, перевести один отдел или 10−15% линий на новое решение на пару недель, пока остальные продолжают работать по-старому. Так всплывают вещи, которые на бумаге не видны: где-то не так работает переадресация, где-то интеграция с CRM подтягивает не все поля. Гораздо лучше поймать это на пилоте, чем в разгар рабочего дня, когда клиенты уже висят на линии.
После запуска систему нельзя оставлять без сопровождения — первые недели обычно показывают, что упустили на этапе аудита.
После аудита смотрят на каналы связи и логику маршрутизации, совместимость с имеющимся оборудованием и то, как на переходный период организовать сосуществование с Cisco или Avaya, пока старая система не отключена полностью.
Отдельно стоит проговорить сохранность данных. История обращений, записи разговоров, интеграции с CRM — всё это должно переехать на новую систему без потерь. Например, если у оператора связи хранится три года записей звонков для разбора спорных ситуаций с клиентами, а после миграции доступна только последняя неделя — это уже не мелкая недоработка, а серьёзная проблема для бизнеса.
Если для заказчика принципиально работать с отечественным ПО — скажем, это компания с госучастием или подпадает под требования по импортозамещению — стоит заранее свериться, есть ли решение в реестре российского ПО. Выяснять это постфактум, когда закупка уже согласована, гораздо дороже.
И ещё один момент, который часто недооценивают: не стоит переключать всех операторов на новую систему одним днём. Лучше сначала прогнать пилот в параллельном контуре — например, перевести один отдел или 10−15% линий на новое решение на пару недель, пока остальные продолжают работать по-старому. Так всплывают вещи, которые на бумаге не видны: где-то не так работает переадресация, где-то интеграция с CRM подтягивает не все поля. Гораздо лучше поймать это на пилоте, чем в разгар рабочего дня, когда клиенты уже висят на линии.
После запуска систему нельзя оставлять без сопровождения — первые недели обычно показывают, что упустили на этапе аудита.
Почему бизнес переносит контакт-центр на российскую платформу
Переход на российскую платформу — это не просто замена зарубежного софта на отечественный аналог. Контакт-центр — связанная система, где телефония, каналы обращений, CRM, аналитика и рабочие места операторов должны работать согласованно. Поэтому при миграции важно сохранить не только функции платформы, но и действующую логику обслуживания клиентов.
Что связано с переносом контакт-центра, кроме самого ПО
Контакт-центр — это целая экосистема: IP-АТС, CRM, каналы обращений (звонки, чаты, почта, мессенджеры), запись разговоров, отчётность и рабочие места операторов. Все эти элементы связаны между собой, и изменение любого из них отражается на остальных. Новая платформа должна не просто «уметь принимать звонки» — она обязана корректно передавать данные в CRM и сохранять привычные сценарии маршрутизации, к которым уже адаптировались операторы и клиенты.
Поэтому миграция — это не «поставили новый софт и заработало». Нужно проверить оборудование, телефонные маршруты, настройки IVR, права доступа, все интеграции и историю обращений. Отдельного внимания заслуживают записи разговоров: например, если отдел контроля качества привык прослушивать звонки за последние полгода для оценки работы операторов, а после переезда доступен только свежий архив — это не техническая мелочь, а удар по всему процессу обучения и контроля.
Ошибка на этапе планирования обходится дорого: потерянные маршруты, разорванные интеграции с CRM, сбои в отчётности — всё это всплывает не сразу, а в тот момент, когда на это меньше всего рассчитывают. Например, отчёт за квартал, который вдруг не сходится с реальными данными, потому что часть звонков после миграции не долетела до CRM.
Поэтому прежде чем переходить на новую платформу, стоит описать текущую архитектуру и то, как её компоненты зависят друг от друга, а затем сверить это с возможностями новой системы. Именно так «Авантелеком» и подходит к контакт-центру — не как к набору отдельных модулей, а как к экосистеме, где эффективность определяется слаженностью работы всех частей, а не силой одной из них.
Поэтому миграция — это не «поставили новый софт и заработало». Нужно проверить оборудование, телефонные маршруты, настройки IVR, права доступа, все интеграции и историю обращений. Отдельного внимания заслуживают записи разговоров: например, если отдел контроля качества привык прослушивать звонки за последние полгода для оценки работы операторов, а после переезда доступен только свежий архив — это не техническая мелочь, а удар по всему процессу обучения и контроля.
Ошибка на этапе планирования обходится дорого: потерянные маршруты, разорванные интеграции с CRM, сбои в отчётности — всё это всплывает не сразу, а в тот момент, когда на это меньше всего рассчитывают. Например, отчёт за квартал, который вдруг не сходится с реальными данными, потому что часть звонков после миграции не долетела до CRM.
Поэтому прежде чем переходить на новую платформу, стоит описать текущую архитектуру и то, как её компоненты зависят друг от друга, а затем сверить это с возможностями новой системы. Именно так «Авантелеком» и подходит к контакт-центру — не как к набору отдельных модулей, а как к экосистеме, где эффективность определяется слаженностью работы всех частей, а не силой одной из них.
Кто обычно инициирует перенос контакт-центра на отечественную платформу
Чаще всего повод — ограничения в развитии действующей системы: заканчивается поддержка или обновления зарубежного ПО связи, а зависимость от поставщика превращается в риск для эксплуатации и дальнейшего развития.
Вторая причина — требования к использованию российского ПО. Они зависят от отрасли, статуса организации и конкретных нормативных актов, поэтому перед стартом проекта стоит отдельно выяснить, распространяются ли такие обязательства на компанию и какие именно компоненты инфраструктуры они затрагивают.
Иногда перенос — часть долгосрочной стратегии: компания хочет меньше зависеть от зарубежных вендоров, самостоятельно контролировать развитие контакт-центра и подстроить его под свои процессы. В этом случае миграция — не вынужденная замена, а повод пересмотреть архитектуру и автоматизировать то, что раньше упиралось в возможности старой платформы.
Инициатором миграции может выступать сама компания, привлечённый консультант или интегратор — и от этого выбора многое зависит.
Если компания идёт своим путём, всю нагрузку — аудит, проектирование, выбор решения, само переключение — берёт на себя ИТ-департамент, а подрядчиков зовут точечно, под конкретные задачи. Например, для настройки интеграции с нестандартной CRM или для работ, которые своими силами делать невыгодно.
Консультант обычно закрывает часть пути: обследование, разработку архитектуры или отдельные этапы проекта. Но в этой схеме ответственность за итоговый результат размыта между несколькими сторонами — и если что-то пойдёт не так на стыке, скажем, между рекомендациями консультанта и тем, как их реализовал интегратор, разбираться, кто виноват, придётся отдельно.
Интегратор под ключ — это другая логика. Один подрядчик отвечает за всё: проектирование, внедрение, интеграции, саму миграцию и дальнейшее сопровождение. Для сложного контакт-центра, где завязаны десятки процессов и систем, это часто оправданная модель — есть один ответственный за результат, а не набор смежных зон, за каждую из которых отвечает кто-то свой.
В проектах «Авантелеком» такой подход сочетается с индивидуальным сопровождением — от оценки задач и подготовки технического задания до внедрения и эксплуатации. Компания также берет на себя интеграции с CRM и другими системами автоматизации бизнес-процессов.
Вторая причина — требования к использованию российского ПО. Они зависят от отрасли, статуса организации и конкретных нормативных актов, поэтому перед стартом проекта стоит отдельно выяснить, распространяются ли такие обязательства на компанию и какие именно компоненты инфраструктуры они затрагивают.
Иногда перенос — часть долгосрочной стратегии: компания хочет меньше зависеть от зарубежных вендоров, самостоятельно контролировать развитие контакт-центра и подстроить его под свои процессы. В этом случае миграция — не вынужденная замена, а повод пересмотреть архитектуру и автоматизировать то, что раньше упиралось в возможности старой платформы.
Инициатором миграции может выступать сама компания, привлечённый консультант или интегратор — и от этого выбора многое зависит.
Если компания идёт своим путём, всю нагрузку — аудит, проектирование, выбор решения, само переключение — берёт на себя ИТ-департамент, а подрядчиков зовут точечно, под конкретные задачи. Например, для настройки интеграции с нестандартной CRM или для работ, которые своими силами делать невыгодно.
Консультант обычно закрывает часть пути: обследование, разработку архитектуры или отдельные этапы проекта. Но в этой схеме ответственность за итоговый результат размыта между несколькими сторонами — и если что-то пойдёт не так на стыке, скажем, между рекомендациями консультанта и тем, как их реализовал интегратор, разбираться, кто виноват, придётся отдельно.
Интегратор под ключ — это другая логика. Один подрядчик отвечает за всё: проектирование, внедрение, интеграции, саму миграцию и дальнейшее сопровождение. Для сложного контакт-центра, где завязаны десятки процессов и систем, это часто оправданная модель — есть один ответственный за результат, а не набор смежных зон, за каждую из которых отвечает кто-то свой.
В проектах «Авантелеком» такой подход сочетается с индивидуальным сопровождением — от оценки задач и подготовки технического задания до внедрения и эксплуатации. Компания также берет на себя интеграции с CRM и другими системами автоматизации бизнес-процессов.
Кто поставляет решения связи для импортозамещения контакт-центра
Рынок импортозамещения связи — это не только вендоры, которые пишут отечественное ПО. На практике в проекте участвует целая цепочка поставщиков: кто-то отвечает за саму платформу, кто-то — за внедрение и интеграции, кто-то предоставляет номера и каналы связи. Плюс отдельная категория — узкие игроки, которые закрывают конкретную задачу: речевую аналитику, голосовых роботов, омниканальность.
Для среднего и крупного бизнеса это создаёт риск, если зоны ответственности не развести на берегу. Представим ситуацию: перестала работать переадресация звонков из мессенджера в CRM. Кто чинит — провайдер номеров, интегратор платформы или разработчик омниканального модуля? Если это не прописано заранее, компания рискует получить не решение проблемы, а хождение по кругу, пока три подрядчика выясняют, на чьей стороне баг.
Для среднего и крупного бизнеса это создаёт риск, если зоны ответственности не развести на берегу. Представим ситуацию: перестала работать переадресация звонков из мессенджера в CRM. Кто чинит — провайдер номеров, интегратор платформы или разработчик омниканального модуля? Если это не прописано заранее, компания рискует получить не решение проблемы, а хождение по кругу, пока три подрядчика выясняют, на чьей стороне баг.
Какие роли есть на рынке импортозамещения связи
Разработчики программных IP-АТС и платформ создают базовое ПО, на котором строится телефония и работа операторов. Платформа определяет возможности маршрутизации, очередей, IVR, записи разговоров, управления операторами, отчетности и интеграции с другими системами.
Интеграторы берут платформу и адаптируют ее под инфраструктуру и процессы конкретной компании. В их зоне ответственности — обследование текущей системы, проектирование архитектуры, настройка маршрутов и IVR, миграция, интеграции с CRM, подключение оборудования, пилот и сопровождение. По сути, в сложном проекте именно интегратор отвечает за то, чтобы отдельные компоненты сложились в работающий контакт-центр.
Операторы связи предоставляют номера и каналы подключения. Они обеспечивают саму услугу связи, но, как правило, не отвечают ни за архитектуру контакт-центра и его бизнес-логику, ни за CRM-интеграции или организацию рабочих мест операторов.
Поставщики смежных решений закрывают отдельные функции контакт-центра: речевую аналитику, голосовых роботов, омниканальные платформы, базы знаний, инструменты автоматизации. Такие компоненты подключаются к основной платформе через интеграции и расширяют ее возможности. В «Авантелеком», например, контакт-центр рассматривают как экосистему — с IP-телефонией, омниканальным окном оператора, голосовыми роботами, речевой аналитикой и интеграциями с CRM.
Поэтому при выборе поставщика важно смотреть не только на список функций платформы, но и на то, кто проектирует архитектуру, кто выполняет интеграции, кто отвечает за миграцию и кто будет сопровождать систему после запуска. Если эти задачи распределены между разными компаниями, зоны ответственности нужно закрепить заранее. Если проект ведет интегратор под ключ, у заказчика сразу появляется единая точка ответственности за результат.
Для оценки зрелости поставщика стоит также проверить опыт внедрений, возможности кастомизации и интеграции с существующими системами, наличие технической поддержки и резервирования. Для крупных проектов особенно важен опыт построения распределенных контакт-центров и работы с высокой нагрузкой: например, для наших клиентов один из важных критериев выбора нас — опыт работы над такими же задачами с компаниями похожих масштабов.
Интеграторы берут платформу и адаптируют ее под инфраструктуру и процессы конкретной компании. В их зоне ответственности — обследование текущей системы, проектирование архитектуры, настройка маршрутов и IVR, миграция, интеграции с CRM, подключение оборудования, пилот и сопровождение. По сути, в сложном проекте именно интегратор отвечает за то, чтобы отдельные компоненты сложились в работающий контакт-центр.
Операторы связи предоставляют номера и каналы подключения. Они обеспечивают саму услугу связи, но, как правило, не отвечают ни за архитектуру контакт-центра и его бизнес-логику, ни за CRM-интеграции или организацию рабочих мест операторов.
Поставщики смежных решений закрывают отдельные функции контакт-центра: речевую аналитику, голосовых роботов, омниканальные платформы, базы знаний, инструменты автоматизации. Такие компоненты подключаются к основной платформе через интеграции и расширяют ее возможности. В «Авантелеком», например, контакт-центр рассматривают как экосистему — с IP-телефонией, омниканальным окном оператора, голосовыми роботами, речевой аналитикой и интеграциями с CRM.
Поэтому при выборе поставщика важно смотреть не только на список функций платформы, но и на то, кто проектирует архитектуру, кто выполняет интеграции, кто отвечает за миграцию и кто будет сопровождать систему после запуска. Если эти задачи распределены между разными компаниями, зоны ответственности нужно закрепить заранее. Если проект ведет интегратор под ключ, у заказчика сразу появляется единая точка ответственности за результат.
Для оценки зрелости поставщика стоит также проверить опыт внедрений, возможности кастомизации и интеграции с существующими системами, наличие технической поддержки и резервирования. Для крупных проектов особенно важен опыт построения распределенных контакт-центров и работы с высокой нагрузкой: например, для наших клиентов один из важных критериев выбора нас — опыт работы над такими же задачами с компаниями похожих масштабов.
По каким критериям оценивать российскую платформу для колл-центра
На примере опыта «Авантелеком» — лучше выбирать подрядчика, который оценивает все приведенные в таблице ниже критерии совместно с клиентом на этапе аудита. Плохой знак — если вам предлагают единственное готовое решение без анализа задач бизнеса.
Замена Cisco и Avaya на отечественную платформу: что важно понимать
Переход с Cisco или Avaya на российскую IP-АТС — это не обязательно «выключили одно, включили другое». На переходный период новую платформу можно подключить к текущей системе и какое-то время держать оба контура параллельно. Пользователей, номера и функции переносите постепенно, а телефония и контакт-центр всё это время продолжают работать как обычно.
Но интеграция — не самоцель, и гнаться за ней не стоит. Перед миграцией лучше сначала разобраться, что вообще происходит в текущей инфраструктуре: какие номера, маршруты, очереди, IVR, записи разговоров и интеграции реально используются, а что давно превратилось в балласт. Что-то стоит сохранить как есть, что-то — перенести на новую платформу уже в более вменяемом виде. Тогда на выходе получается не копия старой системы со всеми её наслоениями, а архитектура, в которой реально можно разобраться.
Но интеграция — не самоцель, и гнаться за ней не стоит. Перед миграцией лучше сначала разобраться, что вообще происходит в текущей инфраструктуре: какие номера, маршруты, очереди, IVR, записи разговоров и интеграции реально используются, а что давно превратилось в балласт. Что-то стоит сохранить как есть, что-то — перенести на новую платформу уже в более вменяемом виде. Тогда на выходе получается не копия старой системы со всеми её наслоениями, а архитектура, в которой реально можно разобраться.
Можно ли интегрировать Cisco или Avaya с российской АТС из реестра ПО
На переходный период российскую АТС вполне реально подружить с существующей инфраструктурой Cisco или Avaya через обычные протоколы — SIP или E1. Две системы связываются на уровне телефонной логики: вызовы ходят туда-сюда, а пользователей и функции переводите на новую платформу постепенно, без спешки.
По сути, получается параллельный контур. Часть сотрудников как работала в Cisco или Avaya, так и работает, а новые или уже переведённые люди сидят на российской IP-АТС. Подразделения переезжают по готовности — никто не выключает всей компании разом.
И тут важно не пытаться утащить в интеграцию вообще всё, что было в старой системе. После аудита что-то можно на время оставить как есть, а что-то — сразу перенести на новую платформу. Сложную логику IVR, например, чаще выгоднее перенести на российскую АТС, чем годами тянуть зависимость от старой системы. А насколько глубоко копать интеграцию — зависит от того, как устроена Cisco или Avaya, какие номера, маршруты и оборудование в ходу, и как вообще работает компания.
У «Авантелеком» есть проекты, где новая IP-АТС на первом этапе работает бок о бок с Cisco или Avaya — пользователей переключают поэтапно, а контакт-центр при этом не встаёт ни на минуту. Так риски миграции снижаются, и новую платформу успевают обкатать на реальной нагрузке ещё до того, как зарубежную систему отключат окончательно.
По сути, получается параллельный контур. Часть сотрудников как работала в Cisco или Avaya, так и работает, а новые или уже переведённые люди сидят на российской IP-АТС. Подразделения переезжают по готовности — никто не выключает всей компании разом.
И тут важно не пытаться утащить в интеграцию вообще всё, что было в старой системе. После аудита что-то можно на время оставить как есть, а что-то — сразу перенести на новую платформу. Сложную логику IVR, например, чаще выгоднее перенести на российскую АТС, чем годами тянуть зависимость от старой системы. А насколько глубоко копать интеграцию — зависит от того, как устроена Cisco или Avaya, какие номера, маршруты и оборудование в ходу, и как вообще работает компания.
У «Авантелеком» есть проекты, где новая IP-АТС на первом этапе работает бок о бок с Cisco или Avaya — пользователей переключают поэтапно, а контакт-центр при этом не встаёт ни на минуту. Так риски миграции снижаются, и новую платформу успевают обкатать на реальной нагрузке ещё до того, как зарубежную систему отключат окончательно.
Что учесть при полной замене Cisco/Avaya
Полная замена Cisco или Avaya оправдана, когда зарубежная система уже не получает нормальной поддержки, оборудование доживает свой век или сама архитектура становится риском — и для безопасности, и для дальнейшего развития. В этом случае мало просто поменять АТС: важно заранее продумать, как на новой платформе заработают все связанные процессы — маршрутизация вызовов, IVR, очереди, запись разговоров, отчёты, интеграции с CRM. Контакт-центр — это экосистема из множества связанных частей, и сбой в одной легко тянет за собой остальные.
Перед миграцией имеет смысл составить подробную карту действующей телефонии: какие номера и маршруты используются, какие сценарии IVR настроены, как вызовы распределяются по очередям и сотрудникам, какие данные уходят в CRM и какие отчёты формируются на выходе. Отдельное внимание — нестандартным бизнес-процессам и кастомным интеграциям: типовые решения не всегда учитывают специфику конкретной компании, а вот индивидуальная интеграция позволяет сохранить именно те связи между системами, которые реально нужны.
Менять сразу всё оборудование не обязательно. SIP-совместимые IP-телефоны и часть шлюзов вполне можно оставить, если новая платформа поддерживает их протоколы и функции. Аналоговые устройства и линии тоже продолжат работать — через шлюзы с портами FXS (для аналоговых телефонов) и FXO (для аналоговых линий). Так что решение здесь принимается по результатам аудита и проверки совместимости конкретного оборудования, а не по принципу «раз не наше — значит под замену».
Главный риск полной замены — это миграция без предварительного проектирования. Тогда легко потерять действующие маршруты и сценарии обработки вызовов, нарушить обмен данными с CRM или в итоге получить неполную отчётность. Надежнее двигаться иначе: сначала аудит и фиксация действующей схемы со всеми зависимостями, затем — развертывание новой платформы и проверка ключевых сценариев, и только потом — поэтапное переключение пользователей. Такой порядок сохраняет не только связь между системами, но и привычные бизнес-процессы контакт-центра.
Перед миграцией имеет смысл составить подробную карту действующей телефонии: какие номера и маршруты используются, какие сценарии IVR настроены, как вызовы распределяются по очередям и сотрудникам, какие данные уходят в CRM и какие отчёты формируются на выходе. Отдельное внимание — нестандартным бизнес-процессам и кастомным интеграциям: типовые решения не всегда учитывают специфику конкретной компании, а вот индивидуальная интеграция позволяет сохранить именно те связи между системами, которые реально нужны.
Менять сразу всё оборудование не обязательно. SIP-совместимые IP-телефоны и часть шлюзов вполне можно оставить, если новая платформа поддерживает их протоколы и функции. Аналоговые устройства и линии тоже продолжат работать — через шлюзы с портами FXS (для аналоговых телефонов) и FXO (для аналоговых линий). Так что решение здесь принимается по результатам аудита и проверки совместимости конкретного оборудования, а не по принципу «раз не наше — значит под замену».
Главный риск полной замены — это миграция без предварительного проектирования. Тогда легко потерять действующие маршруты и сценарии обработки вызовов, нарушить обмен данными с CRM или в итоге получить неполную отчётность. Надежнее двигаться иначе: сначала аудит и фиксация действующей схемы со всеми зависимостями, затем — развертывание новой платформы и проверка ключевых сценариев, и только потом — поэтапное переключение пользователей. Такой порядок сохраняет не только связь между системами, но и привычные бизнес-процессы контакт-центра.
Что учитывать при переносе контакт-центра на российскую платформу: пошаговый план
Наш выверенный за более чем 15 лет работы план поможет избежать типичных проблем миграции особенно зрелых контакт-центров крупных компаний. Учитывая, что «Авантелеком» берет на себя сопровождение контакт-центра после переноса, включая мониторинг качества связи и донастройку маршрутизации, можно сказать что мы его отшлифовали.
1. Провести аудит текущего контакт-центра
Начните с инвентаризации: какими каналами пользуются клиенты — звонки, чаты, почта, мессенджеры, — как устроены маршруты обращений, какие IVR и очереди настроены, с какими CRM и другими системами связан контакт-центр. Отдельно зафиксируйте объём и формат истории обращений и записей разговоров: сколько это гигабайт, за какой период, в каком формате хранится.
Здесь важно понять, какие данные и настройки критичны для бизнеса и не могут потеряться при миграции. Например, для одной компании принципиален архив звонков за три года — на нём строится вся система контроля качества, а для другой актуальна только последняя неделя, и остальное можно смело архивировать.
На выходе должна получиться понятная схема текущей системы и список того, что нужно сохранить, перенести, заменить или просто отправить в архив.
Здесь важно понять, какие данные и настройки критичны для бизнеса и не могут потеряться при миграции. Например, для одной компании принципиален архив звонков за три года — на нём строится вся система контроля качества, а для другой актуальна только последняя неделя, и остальное можно смело архивировать.
На выходе должна получиться понятная схема текущей системы и список того, что нужно сохранить, перенести, заменить или просто отправить в архив.
2. Выбрать целевую платформу по критериям бизнеса, а не по рейтингам
Платформу стоит выбирать исходя из реальных потребностей контакт-центра: функциональности, масштабируемости, интеграций, совместимости с текущей инфраструктурой, статуса ПО в реестре и качества поддержки. Важен не только набор функций сам по себе, а то, насколько решение вообще можно адаптировать под конкретные бизнес-процессы.
Публичный рейтинг — неплохая отправная точка, но не замена технической проверке, особенно если контакт-центру нужны нестандартные интеграции или собственная логика маршрутизации. В «Авантелеком» отдельно отмечают ценность кастомизированного подхода: он даёт учитывать особенности бизнеса, связывать несколько систем и перестраивать решение по мере изменения процессов.
Публичный рейтинг — неплохая отправная точка, но не замена технической проверке, особенно если контакт-центру нужны нестандартные интеграции или собственная логика маршрутизации. В «Авантелеком» отдельно отмечают ценность кастомизированного подхода: он даёт учитывать особенности бизнеса, связывать несколько систем и перестраивать решение по мере изменения процессов.
3. Спроектировать архитектуру миграции и параллельный контур
Прежде чем переключаться, стоит определить, что переносится сразу, что временно поработает в параллельном контуре, а какие данные и системы достаточно просто заархивировать. Отдельно продумайте план интеграции с CRM, BI и другими корпоративными системами.
Параллельный контур позволяет обкатать новую платформу на реальных сценариях, не трогая работающий контакт-центр. Само переключение тоже нужно спланировать заранее — порядок, темп, этапность.
Параллельный контур позволяет обкатать новую платформу на реальных сценариях, не трогая работающий контакт-центр. Само переключение тоже нужно спланировать заранее — порядок, темп, этапность.
4. Подготовить данные, оборудование и интеграции
Заранее подготовьте экспорт истории обращений и записей разговоров — лучше сделать это до старта работ, а не в последнюю минуту, когда уже поджимают сроки. Проверьте, совместимы ли пользовательские устройства, телефонные шлюзы и линии связи с новой платформой.
Отдельно стоит сказать про аналоговые телефоны и линии, которые часто остаются в инфраструктуре — например, на удалённых точках продаж или у сотрудников, для которых IP-телефония избыточна. Их не обязательно менять целиком: такие устройства можно подключить к IP-АТС через соответствующие шлюзы, и парк оборудования обновлять сразу не придётся.
Интеграции с CRM лучше протестировать ещё до пилота. Это особенно важно для нестандартных процессов: контакт-центр может не просто передавать данные в CRM, а запускать действия по итогам разговора — менять статус клиента, переводить его на другой этап воронки, ставить автообзвон.
Отдельно стоит сказать про аналоговые телефоны и линии, которые часто остаются в инфраструктуре — например, на удалённых точках продаж или у сотрудников, для которых IP-телефония избыточна. Их не обязательно менять целиком: такие устройства можно подключить к IP-АТС через соответствующие шлюзы, и парк оборудования обновлять сразу не придётся.
Интеграции с CRM лучше протестировать ещё до пилота. Это особенно важно для нестандартных процессов: контакт-центр может не просто передавать данные в CRM, а запускать действия по итогам разговора — менять статус клиента, переводить его на другой этап воронки, ставить автообзвон.
5. Провести пилот на ограниченной группе пользователей
Не стоит переносить весь контакт-центр сразу. Возьмите ограниченную группу операторов, один отдел или конкретный сценарий и проверьте на нём основные процессы: маршрутизацию, качество связи, работу интеграций, сохранность истории, поведение системы под нагрузкой.
Пилот помогает поймать ошибки до массового переключения и подправить настройки без риска остановить весь контакт-центр. Этой же логике следует и «Авантелеком»: перед полноценным запуском — пилотный проект, после которого систему и людей уже готовят к боевой эксплуатации.5. Провести пилот на ограниченной группе пользователей.
Пилот помогает поймать ошибки до массового переключения и подправить настройки без риска остановить весь контакт-центр. Этой же логике следует и «Авантелеком»: перед полноценным запуском — пилотный проект, после которого систему и людей уже готовят к боевой эксплуатации.5. Провести пилот на ограниченной группе пользователей.
6. Переключить пользователей поэтапно
После удачного пилота можно переходить к поэтапной миграции. Пользователей переключают по отделам, филиалам или группам — не всю компанию одним махом. Так проще держать нагрузку под контролем и быстро находить проблемы, если они возникают.
План отката стоит подготовить заранее. Переключение при действующей телефонии лучше проводить в согласованное время, а на случай сбоя — иметь возможность быстро вернуться к прежней схеме.
План отката стоит подготовить заранее. Переключение при действующей телефонии лучше проводить в согласованное время, а на случай сбоя — иметь возможность быстро вернуться к прежней схеме.
7. Обеспечить контроль качества и сопровождение после запуска
После миграции важно продолжать следить за ключевыми показателями контакт-центра: дозвоном, временем ответа, долей потерянных обращений, средним временем обработки, решением вопроса с первого обращения. Это позволяет сравнить работу системы «до» и «после» и вовремя заметить, если что-то пошло не так. В «Авантелеком» среди признаков неэффективности контакт-центра тоже называют отрицательную динамику этих показателей и высокую долю ручной постобработки.
Не менее важно заранее договориться о модели сопровождения: кто принимает обращения, кто отвечает за обновления, устранение инцидентов и дальнейшее развитие системы. После запуска нагрузка на поддержку обычно растёт, так что проблемы лучше отслеживать проактивно, а не ждать, пока о них сообщат пользователи.
Не менее важно заранее договориться о модели сопровождения: кто принимает обращения, кто отвечает за обновления, устранение инцидентов и дальнейшее развитие системы. После запуска нагрузка на поддержку обычно растёт, так что проблемы лучше отслеживать проактивно, а не ждать, пока о них сообщат пользователи.
Как не потерять звонки, историю обращений и интеграции при переносе
Главный риск миграции контакт-центра — не сам факт перехода на новую платформу, а ошибки в подготовке. Звонки и обращения теряются, как правило, из-за некорректной маршрутизации, непротестированных сценариев или отсутствия резервного маршрута на случай сбоя. Поэтому до переключения стоит подробно описать текущую схему работы: входящие и исходящие маршруты, IVR, очереди, переводы между сотрудниками, запись разговоров, интеграции с CRM и другими системами. Интеграция с CRM при этом должна давать доступ к истории взаимодействий с клиентом и не терять данные при переходе.
Переносить контакт-центр безопаснее не одним рывком, а поэтапно. Сначала — аудит и проектирование новой схемы, затем — параллельный контур и тестовые звонки по основным сценариям. Отдельно проверяют резервные маршруты: что произойдёт, если оператор не ответит, откажет основной маршрут или станет недоступен один из компонентов системы. После успешных тестов запускают пилот на ограниченной группе пользователей, и только потом переводят остальные очереди и номера. А мониторинг после запуска помогает быстро заметить пропущенные вызовы, ошибки маршрутизации и сбои в интеграциях.
Историю обращений и записи разговоров тоже не обязательно переносить по одному шаблону. В зависимости от задач проекта данные можно перенести целиком, частично, а старые записи оставить в архиве с сохранением доступа. То же самое с историей в CRM: заранее решают, что должно быть под рукой у оператора в новой системе, а что достаточно держать в архиве. И решение это принимают на этапе проектирования — до миграции, а не после того, как старую платформу уже отключили.
Минимальный набор мер перед переключением:
При таком подходе миграция перестаёт быть одномоментным риском и становится контролируемым процессом: старая система продолжает подстраховывать бизнес на этапе перехода, а новая проверяется на реальных сценариях ещё до того, как прежнюю инфраструктуру отключат окончательно.
Переносить контакт-центр безопаснее не одним рывком, а поэтапно. Сначала — аудит и проектирование новой схемы, затем — параллельный контур и тестовые звонки по основным сценариям. Отдельно проверяют резервные маршруты: что произойдёт, если оператор не ответит, откажет основной маршрут или станет недоступен один из компонентов системы. После успешных тестов запускают пилот на ограниченной группе пользователей, и только потом переводят остальные очереди и номера. А мониторинг после запуска помогает быстро заметить пропущенные вызовы, ошибки маршрутизации и сбои в интеграциях.
Историю обращений и записи разговоров тоже не обязательно переносить по одному шаблону. В зависимости от задач проекта данные можно перенести целиком, частично, а старые записи оставить в архиве с сохранением доступа. То же самое с историей в CRM: заранее решают, что должно быть под рукой у оператора в новой системе, а что достаточно держать в архиве. И решение это принимают на этапе проектирования — до миграции, а не после того, как старую платформу уже отключили.
Минимальный набор мер перед переключением:
- аудит маршрутов, IVR, очередей, записей и интеграций;
- параллельный контур новой системы;
- тестовые звонки по всем ключевым сценариям;
- резервные маршруты на случай недоступности основного контура;
- пилотный запуск;
- мониторинг после переключения;
- заранее определённый порядок переноса или архивирования истории и записей.
При таком подходе миграция перестаёт быть одномоментным риском и становится контролируемым процессом: старая система продолжает подстраховывать бизнес на этапе перехода, а новая проверяется на реальных сценариях ещё до того, как прежнюю инфраструктуру отключат окончательно.
Перенос контакт-центра на российскую платформу на примере подхода «Авантелеком»
Как выглядит на практике переноса контакт-центра на российскую платформу — показываем на реальном примере.
ДВГУПС — один из крупнейших вузов Дальнего Востока, свыше 20 тыс. студентов, несколько кампусов и филиалов в Хабаровске. Телефония была построена на разрозненной инфраструктуре: часть на проприетарном оборудовании Cisco, часть — на АТС Iskratel Si3000. Оборудование Cisco требовало замещения, при этом новую АТС нужно было связать сразу с пятью корпусами, распределёнными по городу, а собственного персонала для внедрения новой системы у заказчика не было.
Что было сделано. Задачу решали поэтапно. Сначала спроектировали переход на локальную программную IP-АТС «Авантелеком» из Реестра отечественного ПО с интеграцией в существующую инфраструктуру на Cisco и Iskratel Si3000. Часть телефонных аппаратов Cisco заменили на IP-телефоны Yealink, для остального проприетарного оборудования Cisco (которое работает только с собственным ПО) предусмотрели отдельный этап реинжиниринга — чтобы встроить его в общую систему уже после первого этапа проекта. Дополнительно настроили 15 модулей под конкретные задачи вуза: автообработку пропущенных вызовов, автоинформирование, запись разговоров, оценку качества операторов и другие.
«Авантелеком» выступил интегратором полного цикла: спроектировал архитектуру миграции, внедрил локальную АТС и связал пять филиалов в единую систему и развернул колл-центр на пять операторов и супервизора. Отдельно взял на себя дальнейший план работ — реинжиниринг оставшегося оборудования Cisco для его встраивания в новую систему, опираясь на опыт похожих проектов.
Результат для бизнеса. Университет получил единую централизованную телефонную систему для всех филиалов вместо разрозненной инфраструктуры. Система построена на российском ПО и устойчива к пиковым нагрузкам — что особенно важно во время приёмных кампаний и сессий. Настройка внутренней связи между пятью филиалами позволила существенно сократить регулярные затраты на связь.
ДВГУПС — один из крупнейших вузов Дальнего Востока, свыше 20 тыс. студентов, несколько кампусов и филиалов в Хабаровске. Телефония была построена на разрозненной инфраструктуре: часть на проприетарном оборудовании Cisco, часть — на АТС Iskratel Si3000. Оборудование Cisco требовало замещения, при этом новую АТС нужно было связать сразу с пятью корпусами, распределёнными по городу, а собственного персонала для внедрения новой системы у заказчика не было.
Что было сделано. Задачу решали поэтапно. Сначала спроектировали переход на локальную программную IP-АТС «Авантелеком» из Реестра отечественного ПО с интеграцией в существующую инфраструктуру на Cisco и Iskratel Si3000. Часть телефонных аппаратов Cisco заменили на IP-телефоны Yealink, для остального проприетарного оборудования Cisco (которое работает только с собственным ПО) предусмотрели отдельный этап реинжиниринга — чтобы встроить его в общую систему уже после первого этапа проекта. Дополнительно настроили 15 модулей под конкретные задачи вуза: автообработку пропущенных вызовов, автоинформирование, запись разговоров, оценку качества операторов и другие.
«Авантелеком» выступил интегратором полного цикла: спроектировал архитектуру миграции, внедрил локальную АТС и связал пять филиалов в единую систему и развернул колл-центр на пять операторов и супервизора. Отдельно взял на себя дальнейший план работ — реинжиниринг оставшегося оборудования Cisco для его встраивания в новую систему, опираясь на опыт похожих проектов.
Результат для бизнеса. Университет получил единую централизованную телефонную систему для всех филиалов вместо разрозненной инфраструктуры. Система построена на российском ПО и устойчива к пиковым нагрузкам — что особенно важно во время приёмных кампаний и сессий. Настройка внутренней связи между пятью филиалами позволила существенно сократить регулярные затраты на связь.
ДВГУПС — один из крупнейших вузов Дальнего Востока, свыше 20 тыс. студентов, несколько кампусов и филиалов в Хабаровске. Телефония была построена на разрозненной инфраструктуре: часть на проприетарном оборудовании Cisco, часть — на АТС Iskratel Si3000. Оборудование Cisco требовало замещения, при этом новую АТС нужно было связать сразу с пятью корпусами, распределёнными по городу, а собственного персонала для внедрения новой системы у заказчика не было.
Что было сделано. Задачу решали поэтапно. Сначала спроектировали переход на локальную программную IP-АТС «Авантелеком» из Реестра отечественного ПО с интеграцией в существующую инфраструктуру на Cisco и Iskratel Si3000. Часть телефонных аппаратов Cisco заменили на IP-телефоны Yealink, для остального проприетарного оборудования Cisco (которое работает только с собственным ПО) предусмотрели отдельный этап реинжиниринга — чтобы встроить его в общую систему уже после первого этапа проекта. Дополнительно настроили 15 модулей под конкретные задачи вуза: автообработку пропущенных вызовов, автоинформирование, запись разговоров, оценку качества операторов и другие.
«Авантелеком» выступил интегратором полного цикла: спроектировал архитектуру миграции, внедрил локальную АТС и связал пять филиалов в единую систему и развернул колл-центр на пять операторов и супервизора. Отдельно взял на себя дальнейший план работ — реинжиниринг оставшегося оборудования Cisco для его встраивания в новую систему, опираясь на опыт похожих проектов.
Результат для бизнеса. Университет получил единую централизованную телефонную систему для всех филиалов вместо разрозненной инфраструктуры. Система построена на российском ПО и устойчива к пиковым нагрузкам — что особенно важно во время приёмных кампаний и сессий. Настройка внутренней связи между пятью филиалами позволила существенно сократить регулярные затраты на связь.
«Авантелеком» выступил интегратором полного цикла: спроектировал архитектуру миграции, внедрил локальную АТС и связал пять филиалов в единую систему и развернул колл-центр на пять операторов и супервизора. Отдельно взял на себя дальнейший план работ — реинжиниринг оставшегося оборудования Cisco для его встраивания в новую систему, опираясь на опыт похожих проектов.
Результат для бизнеса. Университет получил единую централизованную телефонную систему для всех филиалов вместо разрозненной инфраструктуры. Система построена на российском ПО и устойчива к пиковым нагрузкам — что особенно важно во время приёмных кампаний и сессий. Настройка внутренней связи между пятью филиалами позволила существенно сократить регулярные затраты на связь.
FAQ — частые вопросы
о переносе контакт-центра на российскую платформу
о переносе контакт-центра на российскую платформу
- Что нужно учитывать при переносе контакт-центра на российскую платформу?Перед переносом стоит провести аудит текущей системы: зафиксировать маршрутизацию звонков, IVR, очереди, интеграции с CRM и другие используемые сценарии. Важно заранее продумать резервирование и возможность поэтапного переключения, чтобы новая система заработала без остановки связи. И российская платформа должна закрывать не только телефонию как таковую, но и задачи контакт-центра целиком: омниканальность, аналитику, автоматизацию, работу с историей обращений.
- Кто делает миграцию на отечественные системы связи — своими силами или с подрядчиком?Небольшую и несложную систему вполне можно перенести силами собственной ИТ-команды — если у специалистов уже есть опыт с телефонией, сетевой инфраструктурой и интеграциями. А вот для крупного или распределенного контакт-центра безопаснее привлечь подрядчика: он берёт на себя аудит, проектирование, настройку, интеграции, тестирование и само переключение. Так обычно работает «Авантелеком» — выполняет внедрение и сопровождает систему после запуска.
- Кто поставляет решения связи для импортозамещения контакт-центра?Решения поставляют российские разработчики и интеграторы: многие не просто предоставляют платформу, а сами же её и внедряют в существующую инфраструктуру — как"Авантелеком" разрабатывает собственное решение и одновременно занимается его внедрением, включая индивидуальные интеграции с бизнес-системами.
- Как выбрать лучшую платформу для автоматизации колл-центра под задачи бизнеса?Универсально лучшей платформы просто не существует: выбор зависит от каналов связи, числа операторов, логики маршрутизации, CRM, требований к безопасности и задач автоматизации. Оценивать стоит не только базовую телефонию, но и омниканальность, интеграции, речевую аналитику, голосовых роботов, инструменты супервизора и возможности кастомизации. Для нестандартных процессов особенно важна глубина интеграции с уже работающими системами.
- Можно ли интегрировать Cisco или Avaya с российской АТС из реестра ПО?Да, миграция не обязательно означает одномоментный отказ от всей существующей инфраструктуры. Старую телефонию можно оставить в работе на переходном этапе, а новую российскую платформу подключить параллельно и постепенно переводить на нее пользователей и сервисы. Так система модернизируется поэтапно — без потери работающих телефонов, номеров и линий.
- Что нужно для замены Cisco / Avaya на отечественную платформу?Начинать нужно с описания текущей архитектуры: абоненты, номера, маршруты, IVR, очереди, интеграции и другие сценарии, которые должны сохраниться после перехода — по сути, снимок того, как всё работает сейчас, до любых изменений.
Дальше — выбор платформы, проектирование новой инфраструктуры, настройка интеграций и резервирования, пилот — и только после того, как пилот подтвердил, что всё работает штатно, систему переводят в промышленную эксплуатацию.
Полную замену необязательно делать одним рывком. Например, можно сначала перевести на новую платформу один отдел или часть номеров, оставив старую телефонию в работе, а остальных операторов переключать по мере готовности нового контура — так у бизнеса всегда есть путь назад, если что-то пойдёт не по плану. - Как «Авантелеком» помогает перенести контакт-центр на российскую платформу без потери звонков и истории?«Авантелеком» ведет проект под ключ: от анализа текущей инфраструктуры и настройки новой системы до интеграции с CRM и подключения оборудования. Переход организуют поэтапно и с резервированием, существующие номера сохраняются, а интеграции с бизнес-системами при необходимости настраиваются под конкретные сценарии заказчика. В итоге переносится не только сама телефония, но и все связанные с ней процессы контакт-центра.
- В каких случаях стоит обратиться в «Авантелеком», а не переносить контакт-центр самостоятельно?Подрядчик особенно нужен, если контакт-центр распределен между несколькими площадками, использует сложную маршрутизацию, CRM-интеграции или требует высокой доступности. Самостоятельный перенос заметно нагружает внутреннюю ИТ-команду и требует компетенций сразу в нескольких областях — от телефонии до интеграций и резервирования. «Авантелеком» совмещает разработку собственной платформы с её внедрением, поэтому может адаптировать решение под конкретные бизнес-процессы и сопровождать его после запуска.