ПроCall-центр

ПроCall-центр. Доверяй, но проверяй.

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

Каждый из них, один получил, а второй еще получит проблемы со своим техническим специалистом.

Картина 1.

У клиента надо сделать замену старой аналоговой АТС на IP call-центр, завести голос по VoIP (так уже подается) и объединить 7 филиалов. Приходим на экспертизу площадки перед установкой:

1. у клиента два интернета, подающегося с двух разных роутеров – параметры доступа к роутерам, их адреса и параметры соединения клиент не знает.
2. VoIP у клиента заходит в Asterisk, к которому подключены VoIP/FXS шлюзы, со шлюзов подается на офисную АТС LG Nortel Aria Soho,  с которой так же аналоговыми линиями передается на рабочие места – параметры доступа ни к Asterisk, ни к шлюзам, ни к АТС LG не известны.
3. Каким то волшебным образом в приеме факсов на каждом рабочем месте задействовано ПО Fax через встроенный FaxModem в компе – что куда как приходит и по каким электронным адресам потом все раздается не известно

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

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

Результат – дополнительные затраты клиента на «вскрытие замков и изготовление нового комплекта колючей»

Как избежать – обязательно требуйте наличие и поддержку в актуальном состоянии схемы организации связи (и компьютерной и телефонной) со всеми устройствами, адресами, паролями, кратким описанием.

Картина 2.

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

Присутствуют директор и технический специалист с нашей стороны и с нашей стороны технический специалист и руководитель продаж.

Известно, что мы планируем все объединять на основе VoIP и IP АТС, но будет ли это аппаратная станция или ПО на сервере мы для себя еще не решили.

Задаем вопрос:

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

Причем, замечу, речь не идет о промышленном масштабе – сотнях или тысячах сессий. Отвечает нам технический специалист Заказчика:

– Наверное уж, процессор такой то, 4-х ядерный, с 6-ю гигами оперативки, материнка такая то, рейд пять ноль, бла-бла-бла, потянет уж!

Мы в недоумении, наверное он такой сервер собирается покупать под наши задачи или... Ну, в общем, не понятно. Нет чтобы спросить у нас: а что планируется использовать? а что подойдет?  а насколько требовательный должен быть сервер к ресурсам, если мы использовать будем сервер? Ну, то есть не попытаться приобрести «боинг» для перевозки десятка пассажиров, а ограничится добротным микро автобусом.

Мы, конечно, ответили, что подойдет, да, конечно подойдет. Но нам таки надо знать максимальные параметры планируемой нагрузки, чтобы рассчитать все элементы комплекса.

– Максимально не более 15 соединений, – отвечает руководитель.

– Спасибо.

Результат – клиент выкинет лишние средства на приобретение оборудования, которое будет работать на 3-5% своих мощностей и морально устареет за год.

Как избежать – интересуйтесь у поставщика о требованиях к оборудованию, доверяйте мнению профессионалов.