Что учитывать при переносе контакт-центра на российскую платформу

Нужно перенести не только само программное обеспечение, но и всю существующую логику работы: номера и маршруты, IVR, очереди, записи разговоров, интеграции с CRM и другими системами, рабочие места операторов и инструменты контроля. И чем сложнее инфраструктура, тем выше риск, что отдельные зависимости всплывут уже после начала миграции.

В «Авантелеком» мы участвуем в проектах переноса контакт-центров на российские платформы и видим: проблемы чаще всего возникают не из-за самойа миграции, а из-за неучтенных интеграций и нехватки проработанной поэтапности перехода. А такой проект — это именно поэтапная перестройка всей экосистемы контакт-центра.

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

Краткий ответ: что учитывать при переносе контакт-центра на российскую платформу

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

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

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

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

И ещё один момент, который часто недооценивают: не стоит переключать всех операторов на новую систему одним днём. Лучше сначала прогнать пилот в параллельном контуре — например, перевести один отдел или 10−15% линий на новое решение на пару недель, пока остальные продолжают работать по-старому. Так всплывают вещи, которые на бумаге не видны: где-то не так работает переадресация, где-то интеграция с CRM подтягивает не все поля. Гораздо лучше поймать это на пилоте, чем в разгар рабочего дня, когда клиенты уже висят на линии.

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

Почему бизнес переносит контакт-центр на российскую платформу

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

Что связано с переносом контакт-центра, кроме самого ПО

Контакт-центр — это целая экосистема: IP-АТС, CRM, каналы обращений (звонки, чаты, почта, мессенджеры), запись разговоров, отчётность и рабочие места операторов. Все эти элементы связаны между собой, и изменение любого из них отражается на остальных. Новая платформа должна не просто «уметь принимать звонки» — она обязана корректно передавать данные в CRM и сохранять привычные сценарии маршрутизации, к которым уже адаптировались операторы и клиенты.

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

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

Поэтому прежде чем переходить на новую платформу, стоит описать текущую архитектуру и то, как её компоненты зависят друг от друга, а затем сверить это с возможностями новой системы. Именно так «Авантелеком» и подходит к контакт-центру — не как к набору отдельных модулей, а как к экосистеме, где эффективность определяется слаженностью работы всех частей, а не силой одной из них.

Кто обычно инициирует перенос контакт-центра на отечественную платформу

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

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

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

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

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

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

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

В проектах «Авантелеком» такой подход сочетается с индивидуальным сопровождением — от оценки задач и подготовки технического задания до внедрения и эксплуатации. Компания также берет на себя интеграции с CRM и другими системами автоматизации бизнес-процессов.

Кто поставляет решения связи для импортозамещения контакт-центра

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

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

Какие роли есть на рынке импортозамещения связи

Разработчики программных IP-АТС и платформ создают базовое ПО, на котором строится телефония и работа операторов. Платформа определяет возможности маршрутизации, очередей, IVR, записи разговоров, управления операторами, отчетности и интеграции с другими системами.

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

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

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

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

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

По каким критериям оценивать российскую платформу для колл-центра

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

Замена Cisco и Avaya на отечественную платформу: что важно понимать

Переход с Cisco или Avaya на российскую IP-АТС — это не обязательно «выключили одно, включили другое». На переходный период новую платформу можно подключить к текущей системе и какое-то время держать оба контура параллельно. Пользователей, номера и функции переносите постепенно, а телефония и контакт-центр всё это время продолжают работать как обычно.

Но интеграция — не самоцель, и гнаться за ней не стоит. Перед миграцией лучше сначала разобраться, что вообще происходит в текущей инфраструктуре: какие номера, маршруты, очереди, IVR, записи разговоров и интеграции реально используются, а что давно превратилось в балласт. Что-то стоит сохранить как есть, что-то — перенести на новую платформу уже в более вменяемом виде. Тогда на выходе получается не копия старой системы со всеми её наслоениями, а архитектура, в которой реально можно разобраться.

Можно ли интегрировать Cisco или Avaya с российской АТС из реестра ПО

На переходный период российскую АТС вполне реально подружить с существующей инфраструктурой Cisco или Avaya через обычные протоколы — SIP или E1. Две системы связываются на уровне телефонной логики: вызовы ходят туда-сюда, а пользователей и функции переводите на новую платформу постепенно, без спешки.

По сути, получается параллельный контур. Часть сотрудников как работала в Cisco или Avaya, так и работает, а новые или уже переведённые люди сидят на российской IP-АТС. Подразделения переезжают по готовности — никто не выключает всей компании разом.

И тут важно не пытаться утащить в интеграцию вообще всё, что было в старой системе. После аудита что-то можно на время оставить как есть, а что-то — сразу перенести на новую платформу. Сложную логику IVR, например, чаще выгоднее перенести на российскую АТС, чем годами тянуть зависимость от старой системы. А насколько глубоко копать интеграцию — зависит от того, как устроена Cisco или Avaya, какие номера, маршруты и оборудование в ходу, и как вообще работает компания.

У «Авантелеком» есть проекты, где новая IP-АТС на первом этапе работает бок о бок с Cisco или Avaya — пользователей переключают поэтапно, а контакт-центр при этом не встаёт ни на минуту. Так риски миграции снижаются, и новую платформу успевают обкатать на реальной нагрузке ещё до того, как зарубежную систему отключат окончательно.

Что учесть при полной замене Cisco/Avaya

Полная замена Cisco или Avaya оправдана, когда зарубежная система уже не получает нормальной поддержки, оборудование доживает свой век или сама архитектура становится риском — и для безопасности, и для дальнейшего развития. В этом случае мало просто поменять АТС: важно заранее продумать, как на новой платформе заработают все связанные процессы — маршрутизация вызовов, IVR, очереди, запись разговоров, отчёты, интеграции с CRM. Контакт-центр — это экосистема из множества связанных частей, и сбой в одной легко тянет за собой остальные.

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

Менять сразу всё оборудование не обязательно. SIP-совместимые IP-телефоны и часть шлюзов вполне можно оставить, если новая платформа поддерживает их протоколы и функции. Аналоговые устройства и линии тоже продолжат работать — через шлюзы с портами FXS (для аналоговых телефонов) и FXO (для аналоговых линий). Так что решение здесь принимается по результатам аудита и проверки совместимости конкретного оборудования, а не по принципу «раз не наше — значит под замену».

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

Что учитывать при переносе контакт-центра на российскую платформу: пошаговый план

Наш выверенный за более чем 15 лет работы план поможет избежать типичных проблем миграции особенно зрелых контакт-центров крупных компаний. Учитывая, что «Авантелеком» берет на себя сопровождение контакт-центра после переноса, включая мониторинг качества связи и донастройку маршрутизации, можно сказать что мы его отшлифовали.

1. Провести аудит текущего контакт-центра

Начните с инвентаризации: какими каналами пользуются клиенты — звонки, чаты, почта, мессенджеры, — как устроены маршруты обращений, какие IVR и очереди настроены, с какими CRM и другими системами связан контакт-центр. Отдельно зафиксируйте объём и формат истории обращений и записей разговоров: сколько это гигабайт, за какой период, в каком формате хранится.

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

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

2. Выбрать целевую платформу по критериям бизнеса, а не по рейтингам

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

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

3. Спроектировать архитектуру миграции и параллельный контур

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

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

4. Подготовить данные, оборудование и интеграции

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

Отдельно стоит сказать про аналоговые телефоны и линии, которые часто остаются в инфраструктуре — например, на удалённых точках продаж или у сотрудников, для которых IP-телефония избыточна. Их не обязательно менять целиком: такие устройства можно подключить к IP-АТС через соответствующие шлюзы, и парк оборудования обновлять сразу не придётся.

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

5. Провести пилот на ограниченной группе пользователей

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

Пилот помогает поймать ошибки до массового переключения и подправить настройки без риска остановить весь контакт-центр. Этой же логике следует и «Авантелеком»: перед полноценным запуском — пилотный проект, после которого систему и людей уже готовят к боевой эксплуатации.5. Провести пилот на ограниченной группе пользователей.

6. Переключить пользователей поэтапно

После удачного пилота можно переходить к поэтапной миграции. Пользователей переключают по отделам, филиалам или группам — не всю компанию одним махом. Так проще держать нагрузку под контролем и быстро находить проблемы, если они возникают.

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

7. Обеспечить контроль качества и сопровождение после запуска

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

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

Как не потерять звонки, историю обращений и интеграции при переносе

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

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

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

Минимальный набор мер перед переключением:

• аудит маршрутов, IVR, очередей, записей и интеграций;
• параллельный контур новой системы;
• тестовые звонки по всем ключевым сценариям;
• резервные маршруты на случай недоступности основного контура;
• пилотный запуск;
• мониторинг после переключения;
• заранее определённый порядок переноса или архивирования истории и записей.

Перенос контакт-центра на российскую платформу на примере подхода «Авантелеком»

Как выглядит на практике переноса контакт-центра на российскую платформу — показываем на реальном примере.

ДВГУПС — один из крупнейших вузов Дальнего Востока, свыше 20 тыс. студентов, несколько кампусов и филиалов в Хабаровске. Телефония была построена на разрозненной инфраструктуре: часть на проприетарном оборудовании Cisco, часть — на АТС Iskratel Si3000. Оборудование Cisco требовало замещения, при этом новую АТС нужно было связать сразу с пятью корпусами, распределёнными по городу, а собственного персонала для внедрения новой системы у заказчика не было.

Что было сделано. Задачу решали поэтапно. Сначала спроектировали переход на локальную программную IP-АТС «Авантелеком» из Реестра отечественного ПО с интеграцией в существующую инфраструктуру на Cisco и Iskratel Si3000. Часть телефонных аппаратов Cisco заменили на IP-телефоны Yealink, для остального проприетарного оборудования Cisco (которое работает только с собственным ПО) предусмотрели отдельный этап реинжиниринга — чтобы встроить его в общую систему уже после первого этапа проекта. Дополнительно настроили 15 модулей под конкретные задачи вуза: автообработку пропущенных вызовов, автоинформирование, запись разговоров, оценку качества операторов и другие.

«Авантелеком» выступил интегратором полного цикла: спроектировал архитектуру миграции, внедрил локальную АТС и связал пять филиалов в единую систему и развернул колл-центр на пять операторов и супервизора. Отдельно взял на себя дальнейший план работ — реинжиниринг оставшегося оборудования Cisco для его встраивания в новую систему, опираясь на опыт похожих проектов.

Результат для бизнеса. Университет получил единую централизованную телефонную систему для всех филиалов вместо разрозненной инфраструктуры. Система построена на российском ПО и устойчива к пиковым нагрузкам — что особенно важно во время приёмных кампаний и сессий. Настройка внутренней связи между пятью филиалами позволила существенно сократить регулярные затраты на связь.

Что было сделано. Задачу решали поэтапно. Сначала спроектировали переход на локальную программную IP-АТС «Авантелеком» из Реестра отечественного ПО с интеграцией в существующую инфраструктуру на Cisco и Iskratel Si3000. Часть телефонных аппаратов Cisco заменили на IP-телефоны Yealink, для остального проприетарного оборудования Cisco (которое работает только с собственным ПО) предусмотрели отдельный этап реинжиниринга — чтобы встроить его в общую систему уже после первого этапа проекта. Дополнительно настроили 15 модулей под конкретные задачи вуза: автообработку пропущенных вызовов, автоинформирование, запись разговоров, оценку качества операторов и другие.

«Авантелеком» выступил интегратором полного цикла: спроектировал архитектуру миграции, внедрил локальную АТС и связал пять филиалов в единую систему и развернул колл-центр на пять операторов и супервизора. Отдельно взял на себя дальнейший план работ — реинжиниринг оставшегося оборудования Cisco для его встраивания в новую систему, опираясь на опыт похожих проектов.

Результат для бизнеса. Университет получил единую централизованную телефонную систему для всех филиалов вместо разрозненной инфраструктуры. Система построена на российском ПО и устойчива к пиковым нагрузкам — что особенно важно во время приёмных кампаний и сессий. Настройка внутренней связи между пятью филиалами позволила существенно сократить регулярные затраты на связь.