Как мы изобретали колл-центр

Перенесено со старого сайта. Автор — Дмитрий Инцин.

Предисловие:

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

Эта история одновременно — годовой отчет, акт эксгибиционизма и басня для энтузиастов собственных разработок. Хотя рассказывается в ней больше о делах предыдущих лет, слишком «интимные» детали опущены, а «мораль» вырезана. Мы надеемся, что некоторым из тех, кто считает нас конкурентами, она позволит увидеть в нас партнеров. И всем даст представление о том, чего от нас ожидать в новом 2011 году.

Часть 1. НАЧАЛО

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

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

Требования, которые предъявлялись к будущему ПО, выглядели так:

  1. Пригодность не только для обслуживания информационных линий, но и для проведения массовых опросов (т.е. обязательное наличие предиктивного дайлера или подобного инструмента, устойчивость под нагрузками и проч.).
  2. Возможность объединения нескольких географически удаленных операторских центров в одну производственную единицу (т.е. только IP-телефония, архитектура — клиент-сервер, Интернет — в качестве среды передачи данных между клиентским приложением и сервером, повышенные требования к безопасности).
  3. Возможность параллельного использования множеством компаний (т.е. кроссплатформенность, опять же клиент-сервер, особые требования к базе данных: раздельное хранение информации, разграничение доступа). Конечно, в 2006 году было немного рановато для SaaS, но мы же смотрим в будущее.
  4. Полноценное управление пользователями самостоятельно, без привлечения технического персонала (т.е. графический интерфейс, дающий доступ к максимуму настроек). Это позволило бы нам избежать слабого места всех существовавших на тот момент колл-центров да и многих нынешних.
  5. Оперативное управление расходами на связь (т.е. наличие роутинга и биллинга, потребность в которых вообще-то — «родимое пятно» всех IP-телефонистов).
  6. Минимальные расходы на лицензирование (т.е. свободные средства программирования и опять же кроссплатформенность).

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

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

Времени на разработку отвели 6 месяцев и еще 2 — на тестирование. План-график утвердили и — вперед. А параллельно строили операторский центр. Как и планировалось, удаленный: в 120 км от Киева в городе Канев. И не спрашивайте, зачем нам это нужно было — выносить колл-центр подальше — вспомните ситуацию на рынке труда четыре года назад.

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

  1. ПО перешло в разряд устаревшего, едва закончилось бета-тестирование: в его основу была положена работа с телефонными номерами, а к тому времени уже нужно было оперировать контактами. CRM стал реальностью.
  2. Предиктивный дайлер на базе Астериска с первых дней работал плохо и оставался таким до последних своих времен. Да и вообще Астериск в качестве коммуникационной платформы для нашей весьма сложной системы оказался не подходящим решением: «as is» ведет себя нестабильно, нужно изрядно «прикладывать руки», а для этого слишком мало информации в сети и авторы слишком далеко.
  3. Java оказалась не лучшей средой для разработки клиентских приложений ввиду сложности архитектуры, трудностей работы с Native API и DB Interface, удаленной отладкой и т.д..
  4. JBoss оказался сложен вдвойне: очень много специфики и всяких «to do» в описании необходимых функций. В результате: ограничения в разработке.
  5. Hydra — библиотека, которую мы выбрали для real-time messaging, — проявила много странностей в работе при малом количестве документации.
  6. Инсталляции и обновления клиентского приложения создавали много неожиданностей, с которыми пользователь часто не мог справиться самостоятельно. Какой уж тут SaaS!

Все это не позволило нам создать программное обеспечение, достаточно стабильное для коммерческого использования. И если Астериск предположительно можно было «побороть», то недостатки Java и JBoss оказались несовместимыми с жизнью. Ведь мы планировали дальнейшее развитие ПО (вернее, оно само запланировалось благодаря обстоятельству из п. 1), и это означало бы постоянные неудобства, ограничения и сложности при разработках.

Вместо 6 мы потратили на разработку около 10 месяцев, а тестирование растянулось на 4 месяца вместо 2-х. При этом стоимость разработок стремительно уходила в небо и не обещала останавливаться.

Итог: похоже на первый самолет братьев Райт (летает, но недалеко, недолго, немного не туда и сделан немного не так ). Первый самолет у братьев забрала стихия, мы решили не дожидаться судьбы, и свой первый колл-центр отправили «в топку» самостоятельно.

В эксплуатации ПО Оки-Токи первой генерации находилось менее 2-х лет.

Часть 2. ВТОРАЯ ПОПЫТКА

Во время кризиса поменялось многое. В нашем окружении одни люди закрыли или заморозили свои колл-центры, другие переключились на работу на Запад, третьи сократились до необходимого минимума (в том числе и мы).

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

  1. Потенциальные заказчики начали считать деньги, вместо того, чтобы любоваться бренднеймами. И это коснулось не только стоимости внедрения, но и дальнейшего обслуживания;
  2. Слова «контакт-центр», «колл-центр» окончательно перестали быть пустым звуком для представителей малого и среднего бизнеса (в 2006 году разговор с потенциальным клиентом нам часто приходилось начинать с объяснений, что такое «колл-центр», или что 4 барышни с сидиэмэйками вряд ли можно назвать этим словом).
  3. SaaS как бизнес-модель набирал популярность.
  4. Т.е. рынок будущего продукта стал обретать реальные очертания. А мы получали возможность воплотить модель, наиболее прогрессивную и заманчивую с нашей точки зрения для развития продукта и сопровождения клиентов.

  5. Наши партнеры дополнили Лиру — коммуникационное ядро (softswitch), — с которой мы раньше успешно работали, функциями, необходимыми колл-центру.
  6. Технологии развились, и появилась возможность реализовать через браузер то, для чего раньше требовалось клиентское приложение.
  7. Т.е. мы получали возможность избавиться, наконец, от Астериска в пользу более стабильного и устойчивого коммуникационного ядра и от толстого клиента — в пользу браузера, который есть на любой машине. Это нам давало возможность обслуживать действительно большие количества заказчиков и звонков, оперативно разбираться с багами и фичами. Ну, а о преимуществах браузера перед инсталлируемыми приложениями для внедрения и обслуживания и говорить излишне.

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

Новый подход был выработан. И сочетался он, как ни странно, со «старыми» инструментами: старым добрым PHP вместо Java, Python-ом вместо JBoss и Lira вместо Asterisk. Только Postgresql-ю мы не изменяли. По понятным причинам: альтернатива — MS SQL — не соответствует нашим требованиям по лицензированию. Таким образом, мы вернулись к использованию средств создания приложений, хорошо знакомым нам по прежним разработкам.

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

Затем мы построили роутинг, снабдив его, кроме учета трафика и LCR (least cost routing, роутинг звонков по наименьшей цене), возможностью обмена трафиком между клиентами (инновация). Следом пошел ACD — собственно колл-центр со всякими мелочами для удобства клиента и оператора. Он получил чат для операторов, индикацию активных звонков, телефонную книгу, сценарии разговора, учет рабочего времени и многое другое, что очень хотелось, было нужно или виделось полезным.

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

Затем новые модули стали появляться еще быстрее: предиктивный дайлер, конструктор IVR (голосового меню), мини-АТС, модуль работы с SMS.

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

Годовой итог работы над Оки-Токи2®:

  • Система может выдерживать довольно серьезный напор звонков. Мы пробовали 500 звонков в минуту, и это не оказало существенного влияния на быстродействие и стабильность. Серверы, Лира и кластеризованный Postgresql имеют хороший запас прочности.
  • Мы можем вести разработки, внедрять новые модули и вносить обновления, не останавливая системы, т.е. никак не влияя на жизнь наших клиентов. С декабря 2009 года мы ни разу не перезагружали серверы для обслуживания и не останавливали сервис по другим причинам.
  • Мы можем подключать новых клиентов просто и очень быстро — как и положено коммерческому сервису.
  • Наши клиенты могут объединяться для работы над крупными проектами или просто арендовать операторов друг у друга (инновация).
  • Все работы по настройке очередей, IVR-а, роутинга, предиктивного дайлера, по распределению прав, созданию сценариев, и т.д. и т.п. производятся клиентами самостоятельно при помощи веб-интерфейса, без участия технического персонала.
  • SaaS стал основным направлением нашего бизнеса.

Но, как всегда, чем ближе был конец работ над Оки-Токи2, тем отчетливее мы видели дальнейшее развитие.

Часть 3. КАКИМ БУДЕТ ОКИ-ТОКИ3?

За время годовой работы Оки-Токи2 у клиентов и в нашем контакт-центре, мы осознали необходимость хранения полной истории коммуникаций в одной системе, в то время как Оки-Токи2 обрабатывает только звонки и SMS. И в первую очередь это касается почты. Мы решили, что лучше не хранить сообщения в почтовых ящиках сотрудников, а присоединять к контактам в базе Оки-Токи3.

В Оки-Токи3 можно будет использовать любые средства коммуникаций. Как минимум, мы будем стараться поддерживать все популярные средства.

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

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

Изобретение колл-центра продолжается.

Дмитрий Инцин и все-все-все. Первый в Украине SaaS-колл-центр «Оки-Токи» © 2011

  • О колл-центрах, статьи со старого сайта