Если вы делаете service desk

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

– если у нас есть e-mail, на который пользователь может послать сообщение о проблеме, чтобы завести тикет, то вроде бы хорошая практика настроить робота, чтобы он сразу же отвтил о заведенной проблеме под номером N. К сожалению, примерно 2-3 раза в год находится клиент, который уходя в отпуск делает автоответ в MS Outlook и не ставит галку “одному получателю – 1 раз”. В результате при хороших мощностях утром можно обнаружить несколько сотен тысяч кейсов типа “меня нет!”, “ок, мы звели по этой проблеме инцидент”, “вы писали мне о том, что завели инцидент, а меня нет”, “вы пишите что-то, а меня нет!” и т.д. Если настроить робота на сканирование почтового ящика не по мощности, а раз в 10 минут, то сотни тысяч сводятся в обозримым цифрам.

– у большинства CRM’ов есть четкое правило: “1 человек в лице 1 адреса == 1 проблема”. Некоторые системы, например HEAT или Request Tracker, позволяют при общении по почте делать сс тем, кто был в сс при заведении инцидента. Например, клиент хочет поставить кого-то еще (получил визитку Главного Директора на Цебите) в копию своей проблемы, чтобы она решалась быстрее, а система обрабатывает это корректно. Выпилите эту фичу: вас всегда самих будут ставить в сс по любому поводу, а все обращения будут адресовать Главному Директору лично и жаловаться на общие вещи, вместо того, чтобы писать прямо в поддержку о конкретной проблеме.

– нельзя сравнивать Лидера Рынка и Перспективный Стартап: если у поставщика нет еще 100500 клиентов вашего размера и объема, что бы вам не обещали, будет плохо. Риск, что Перспективный Стартапер не справится неприемлемо высокий.

– если вам купили Очень Дорогую и Неимоверно Функциональную систему, которую для вас выбрал кто-то из Big Four, а настраивает Господь Бог, то будьте морально готовы, что основной функционал заработает сразу, а который не очень (то есть тот, без которого вам просто очень неудобно, но бизнес не встает) заработает не скоро, не сразу и не совсем так как хотелось. И это очень-очень круто, потому что если вместо Монстров будет Вася Пупкин, который выберет Динамично Развивающееся Решение, то будет плохо и бизнес встанет.

– уже через 2 месяца никто не вспомнит как и что настраивалось.

– закладывайте на сроки внедрений опоздание в 1.5 раза как удачный вариант

– опенсорсные решения работают как минимум не хуже.

Кстати, о Request Tracker я могу дать только исключительно положительный отзыв: система с Февраля 2009 по Ноябрь 2011 проработала без единого сбоя в режиме 24х7 при кристально ясном recovery plan на случай если все сломается. А вот Frontrange Gold Mine не захотел прозрачно интегрироваться с Frontrange Heat Service Desk по совершенно объективным причнам, хотя стоил очень дорого и у меня был собственный программист, разобравшийся в системах до уровня внутреннего представления данных (хотя именно эта интеграция была решающей в выборе, так бы я поставил SugarCRM или RT).