Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 447 сообщений
Cообщения с меткой

техподдержка - Самое интересное в блогах

Следующие 30  »
gedichte

Адаптация сайта под мобильные устройства

Суббота, 23 Апреля 2016 г. 19:59 (ссылка)


Поисковики меняют политику. Гугл уже давно стал пессимизировать в своих индексах и поисковой выдаче сайты, не адаптированные для мобильных пользователей. Примерно два месяца назад об этом же объявил и Яндекс. У студий вебдизайна появилась уникальная возможность заработать на тотальной адаптации сайтов. За адаптацию просят почти столько же, как за новый сайт.



Вот, к примеру, какой ответ я получил в одной из служб техподдержки:



"Уменьшить размеры блоков вы можете в редакторе карты дизайна, но это не поможет работе на мобильных устройствах. В данном случае, необходимо подключать технологии bootstrap, которые будут изменять размеры сайта под каждую модель телефона или планшета, ведь их огромное количество.



Так же, само меню можно не просто убрать, а сделать его универсальным. На мобильных устройствах появится специальная кнопка, при нажатие на которую будет вызываться меню сайта. Для реализации всего этого, необходим специалист по адаптивной верстки, наша компания предоставляет такие услуги." 



Ужас! Все настолько усложняется, что скоро мы попадем в полную зависимость от компьютерщиков, вебдизайнеров и иже с ними. А я привык, по возможности, делать все сам. Ю.Н.



Жизнь программиста/3241858_ (700x542, 117Kb)



 
Комментарии (11)КомментироватьВ цитатник или сообщество
Энергосбыт

Задайте вопросы специалистам!

Вторник, 29 Марта 2016 г. 13:18 (ссылка)

Задавайте вопросы нашим специалистам. Они всегда готовы оказать Вам быструю и компетентную поддержку. Система позволяет не только описать проблему, но и прикрепить файлы с различными расширениями – это удобно, если Вам нужно задать вопрос, касающийся счетов или других документов. Переходите по ссылке https://nn.tns-e.ru/population/memo-individuals/#form. Там же Вы сможете найти ответы на часто задаваемые вопросы.


система вопрос-ответ (700x593, 230Kb)

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
kiev2376393

Apple открыла аккаунт техподдержки в Twitter

Четверг, 24 Марта 2016 г. 04:32 (ссылка)

Apple запустила в Twitter официальный аккаунт техподдержки – @AppleSupport. Этот шаг удивил многих, поскольку компания известна своим настороженным отношением к социальным сетям.


Welcome to... pic.twitter.com/EZA8eRycDs

— Apple

Читать далее...
Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
lj_kommari

Питерским

Четверг, 10 Марта 2016 г. 11:42 (ссылка)

Люди, кто знает в Питере надежного зубного врача, ставящего импланты?

В сетевые клиники не советуют обращаться.

Если кому в голову чего придет - напишите в комменты - я скрыл их.

Спасибо.

http://kommari.livejournal.com/2875676.html

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Сетевой мониторинг: как мы следим за тем, чтобы у крупных компаний работали все узлы

Пятница, 27 Ноября 2015 г. 11:49 (ссылка)




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



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



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



Расскажу про то, как это организовано и пару историй с выездов. Читать дальше →

http://habrahabr.ru/post/271823/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
SKELET-info

СБУ обыскивает техподдержку телеканала боевиков в Киеве

Вторник, 24 Ноября 2015 г. 17:41 (ссылка)


Сотрудники службы безопасности Украины проводят обыски в службе техподдержки телеканала сепаратистов «Новороссия ТВ», который расположен в Киеве. Об этом пишет в Facebook пресс-секретарь СБУ Елена Гитлянская.

 

ЧИТАТЬ ДАЛЕЕ

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
ru_prnews

Сбербанк признан лауреатом премии CNews AWARDS 2015 в номинации «Проект по организации технической поддержки корпоративных клиентов»

Четверг, 12 Ноября 2015 г. 17:07 (ссылка)


Сбербанк одержал победу в ежегодном конкурсе CNews AWARDS в номинации за организацию технической поддержки корпоративных клиентов.


В результате развития проекта (c 2009 года) общий охват корпоративных клиентов, пользующихся технической поддержкой Сбербанка дистанционно, превысил 1 млн. Развитие проекта также предполагает переход на круглосуточное обслуживание и подключение сервиса по онлайн-консультированию через корпоративный интернет-банк «Сбербанк Бизнес Онлайн».




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



Особенность награды CNews состоит в том, что в качестве жюри выступают непосредственно участники CNews FORUM, в рамках которого проходит награждение лучших российских IT-проектов.



Сбербанк



Александр Базиян



Пресс-служба



тел. +7(495) 957 5721



media@sberbank.ru



https://twitter.com/SberbankMedia





ПАО Сбербанк — крупнейший банк в России и один из ведущих глобальных финансовых институтов. На долю Сбербанка приходится около трети активов всего российского банковского сектора. Сбербанк является ключевым кредитором для национальной экономики и занимает крупнейшую долю на рынке вкладов. Учредителем и основным акционером ПАО Сбербанк является Центральный банк Российской Федерации, владеющий 50 % уставного капитала плюс одна голосующая акция. Другими 50 % акций Банка владеют российские и международные инвесторы. Услугами Сбербанка пользуются более 135 млн физических лиц и более 1 млн предприятий в 22 странах мира. Банк располагает самой обширной филиальной сетью в России: около 17 тысяч отделений и внутренних структурных подразделений. Зарубежная сеть Банка состоит из дочерних банков, филиалов и представительств в Великобритании, США, СНГ, Центральной и Восточной Европе, Турции и других странах.



Генеральная лицензия Банка России на осуществление банковских операций 1481.



Официальные сайты Банка — www.sberbank.com (сайт Группы Сбербанк), www.sberbank.ru


Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Как мы открыли IT-школу на базе отдела техподдержки: держи кабель и дуй в поля

Пятница, 30 Октября 2015 г. 10:49 (ссылка)





Так получилось, что мы — чертовски большая компания. Более 2000 сотрудников, тысячи масштабных проектов. И везде нужны люди. Много квалифицированных специалистов. Одна из основных точек входа — наш отдел техподдержки.



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



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



Но я не про это. Я про практику IT.



Как устроено



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



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



ПМ Илья:
Учился я в Бауманке по компьютерным системам и сетям. Пришел на обучение как раз по этим сетям. Нас учили каждый день: половина тем была про инженерию, а другая часть — про менеджмент и управление проектами. Процентов 40 из этого я знал, а остальные 60% — нет. По технической части так глубоко не дают в универе, здесь была практика. Помню, я тогда чётко определился, что вести проекты интереснее. Сам бы, наверное, очень долго учился — просто не знал, куда идти, что смотреть, как делать. Курсы у производителей тоже мало бы помогли — системные целостные знания есть на рынке, по сути, только у интегратора. После обучения хотел подать на аналитика в Райфайзен, но всё же решил, что здесь будет интереснее. Помню, рассказывали, как составлять карту ответственных — кто за что отвечает. Иногда — когда кто-то в отпуске или на новогодних праздниках — чтобы знать, у кого это ещё в ответственности.


Инженер Никита:
Тут люди учили крутые. Очень много нового. Это же первая работа, делаешь всё руками. К нам приходили люди из разных отделов: менеджеры и ВКС’ники, и цискари — рассказывали про свою работу, плюсы и минусы. Всё как есть. Знал я тогда мало — захотелось ещё. Оборудование ещё дало пинок — в институте оно было, но весьма посредственное. А тут реальная лаборатория — и с парнями пилишь что-то, мозговой штурм вместе проходишь. На первый выезд ехал, погоняв железо в лаборатории — командочки понятные, а всё вместе не складывается. Стрёмно было поначалу — непонятно куда едешь, незнакомые люди что-то хотят… Потом уже на одном языке разговариваешь. Поначалу ездил с другими инженерами. Потом одного отправили. Первый боевой выезд был — менять узел Авайи. Поехал с мануалом. Приехал, нашел где, сделал. Никаких сюрпризов. Уехал. Выдохнул. Помню обучение второго года — были телефоны, у которых полетели прошивки, и они все стали с одинаковым маком. Я их разбирал и настраивал, а мой наставник Илья их перепрошивал. Два дня сидели — 14 часов в общей сложности заняло. Ещё одна из первых задач — прикрепили меня на занятиях к Гарри. Говорят: «вот он инженер, ходите за ним». Он заходит в машзал, показывает стойку. Провода криво лежат. Сделайте, чтобы было ровно. И мы пилили СКС, наверное, минут 25.


Инженер Эмма:
Обучение кончилось год назад, впечатления очень положительные. Училась на инженера систем телекоммуникаций, в группе было 5 девушек и 15 парней. Здесь на инженерном обучении только две девушки на человек 20 парней. Но не мешало вообще, было круто. Необычно было всё. Здание, люди. Больше всего запомнилась телефония — я решила сразу туда — уж больно интересно, как всё строится. Когда знания начала получать вглубь по этой теме, поняла, что это не совсем то, куда хотелось бы дальше, выбрала другое инженерное направление. Что запомнилось? Вот, например, надо было плату менять на сервере авайевском — я думала, приду, открою серверную, начну разбираться… А по сути как в офисе примерно прикинули проблему — так сразу и стало понятно, что надо выключить, вытащить плату и поставить обратно. А с другой стороны, приятно: приходишь, чувствуешь, сейчас всю телефонию поднимешь, людям поможешь.


Почему именно практика



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



Итого, схема у нас такая:


  1. Телекоммуникационная IT-школа. Это, как правило, теория и возможность на практике попробовать проектную работу, решая несложные задачи. Расширяем кругозор студента, используем его для рутинных операций, где сложно ошибиться. Вот, например, как выше Никита рассказывал — он раскручивал телефоны, а инженер перепрошивал.

  2. Если всё понравилось — берём студента стажёром. Это уже оплачиваемая работа, но обучение продолжается. Расширенный курс, больше практики. Преподаватели приходят, учат, кто понравился — к тому в отдел можно попроситься. Обычно закрепляем стажёра не за самим преподавателем, а за инженером. Например, с 10 до 16 студент работает с цисководом, с которым стажируется (то есть делает задачи по нашему отделу), а остальной рабочий день (иногда — до ночи, если выезд) проводит с экспертом, которого выбрал наставником. Перенимает опыт из первых рук. Понятное дело, экспертов у нас мало, поэтому они достаются не всем. Драки за них нет, но более успевающий студент или стажёр всегда имеет приоритет.

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





Собственно, знания



В какой-то момент мы поняли по потоку студентов, что учиться жизни в IT многие хотят именно у интегратора. Можно пощупать весь парк железа, реальные проекты, если шевелиться — хороший карьерный рост. Большие задачи, большие возможности, одни из лучших практиков страны. Редкое железо, которое иногда в России в единичном экземпляре. В общем, Клондайк. И экспертам нравится — старая советская система наставника и ученика отлично работает.



Смысл в том, что теперь мы решили сделать несколько важных вещей:


  1. Во-первых, начать потихонечку собирать, систематизировать и расшаривать теорию, которая идёт на практических занятиях. Пока в виде вебинаров, вот, например.

  2. Во-вторых, сделать не только летнюю IT-школу для молодых специалистов, но и зимнюю. Это всё самое сладкое из обучения — и новый живой эксперт (иногда в свитере из 90-х и только с выезда) каждое занятие, и полный обзор технологий с плюсами-минусами, и рассказы про особенности работы каждого отдела и по каждой специальности. Просто и без прикрас. Чтобы можно было ориентироваться в целом в ситуации, знать, куда копать, и хотя бы понимать, какие мануалы и для чего брать. И какие технологии для чего используются, где в чём проблемы. Зимняя школа платная, и желающих уже довольно много. Практика в реальной команде в школе не предусмотрена (это не всем интересно) но после занятий можно договориться с интересующими преподавателями без особых проблем.

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





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



Original source: habrahabr.ru (comments, light).

http://habrahabr.ru/post/269805/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
Donnarossa

Жалоба на мужа в техподдержку - укатайка!

Вторник, 27 Октября 2015 г. 22:38 (ссылка)

Это цитата сообщения Ангарск Оригинальное сообщение


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




Читать далее...
Метки:   Комментарии (3)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Анализируй это: как извлечь дополнительную пользу из клиентских логов

Вторник, 27 Октября 2015 г. 12:54 (ссылка)

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



В этой статье я расскажу об одном из способов, которым мы пользуемся в компании Parallels.



Итак, для этого рецепта нам понадобятся:


  • хранилище пользовательских данных (наверняка есть у каждой большой компании: сервер, куда складываются логи и данные о клиентских компьютерах);

  • парсер вышеупомянутых пользовательских данных (тоже наверняка имеется: кто же откажется от лишней статистики по операционным системам, конфигурациям, моделям и версиям);

  • парочка программистов: один со стороны продукта и еще один со стороны отдела внутренней разработки (главный по хранилищу и парсерам);

  • аналитик (приятно познакомиться).





Пункт первый: реестр сообщений.

Участники: продуктовый программист, аналитик.



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



Внимание: сообщения с вопросами вроде «Действительно ли вы хотите отформатировать диск С? Да/Нет» в этом рецепте не участвуют!



В коде и логах эти сообщения могут быть организованы либо при помощи цифровых кодов (APP_ERR_1 и далее), либо при помощи имен (APP_ERR_KABOOM), либо при помощи комбинаций того и другого. В принципе, способ организации для нашей затеи неважен. Выгружаем все сообщения, которые видит пользователь, в файл и скармливаем аналитику, который в содружестве с продуктовым программистом добавляет к каждому из них комментарии: когда, кому и зачем это сообщение может показываться и какие механизмы в этом задействованы. Например: APP_ERR_KABOOM – показывается компонентом таким-то в случае, если он вот-вот взорвется. Возможные причины: 1) кончилось место на диске, 2) кончились права на запись на диск, 3) что-то недоброе с самим диском. Создается этот реестр для того, чтобы не дергать продуктового программиста лишний раз в процессе последующей работы с сообщениями. Дальше сообщения можно сортировать по компонентам или любым другим любезным вам признакам.



Пункт второй: розыскные мероприятия.

Участники: оба программиста, аналитик.



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



Пункт третий: выемка и осмысление результатов парсинга.

Участники: программист отдела внутренней разработки, аналитик.



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



Пункт четвертый: выводы.

Участники: аналитик.



Ошибки. Зачем, спрашивается, таким странным и сложным способом анализировать сообщения об ошибках, если пользователь сам побежит с ошибкой в техподдержку? И тут-то я достану из кармана свой любимый пример о таймаутах. Таймауты есть у каждого, и время ожидания зачастую задается из сложных соображений, не вполне сообразующихся с реальностью пользователя – скажем, на глаз. Отсюда распространеннейший тип проблем: время от времени какой-то тяжелый процесс грустно сообщает о таймауте. Но не всегда, а в зависимости от загрузки компьютера или сети. Воспроизведение у пользователя отнюдь не стопроцентное, повторение операции зачастую проходит удачно, а техподдержка далеко, и как ты объяснишь, что происходит, если сообщение машинально закрыл, например. Посему, если таймаут не выскакивает каждый или хотя бы каждый второй раз, мы можем не узнать об этом довольно долго. При этом, не блокируя работу полностью, эти сообщения создают крайне негативное впечатление от программы. То же касается и многих других ситуаций с непостоянным воспроизведением.



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



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



Таким образом, ценой небольшой автоматизации компания получает изобильную дополнительную статистику, не беспокоя притом пользователя. Данные эти по мере накопления можно анализировать самыми разнообразными способами – сравнивать версии, получая немедленное подтверждение (или нет) своим решениям, отслеживать проблемы, типичные для новых операционных систем, и так далее. Но лишними в работе они определенно не будут.



Original source: habrahabr.ru (comments, light).

http://habrahabr.ru/post/269615/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Как организовать платную поддержку сложного продукта: Опыт «Гидры»

Вторник, 20 Октября 2015 г. 16:46 (ссылка)





Мы в «Латере» занимаемся разработкой биллинга для операторов связи (провайдеры проводного и беспроводного интернета, ТВ и телефонии, магистральные и спутниковые провайдеры) уже 8 лет, и за это время поучаствовали более чем в 80 проектах внедрения.



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



Бизнес на поддержке



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



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



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



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



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



За что платят и за что не платят клиенты



Существует два типа логируемого времени службы поддержки — оплачиваемое по договору (настройка системы, консультации), и неоплачиваемое. К последнему может относиться, например, исправление багов, возникших на этапе разработки или внедрения. Если причиной ошибки в работе системы стала неверная настройка, то за исправление проблемы клиент платить не должен.



Также к неоплачиваемому времени относится время, потраченное сотрудниками на собственное обучение (или передачу знаний коллегам). Также плата с клиента не берется, например, за время, потраченное на передачу заявки между сотрудниками отдела поддержки.



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




  • DEVBUG — работы по дефекту разработчиков системы. Например: «Устранение проблемы совместно с разработчиками. DEVBUG».

  • SUPBUG — работы по дефекту внедрения и техподдержки. Например: «Добавление недостающих сервисов в автозагрузку. SUPBUG».

  • STUDY — получение помощи (в свою сторону). Например: «Консультация коллег, чтение документации. STUDY».

  • HELP — оказание помощи (в сторону коллег). Например: «Консультация для проработки решения. HELP».

  • ORG — решение организационных вопросов с менеджером и перенимание знаний по ранее выполненным работам. Например: «Получение информации у менеджера. ORG».



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



Используемые инструменты



Изначально для задач отдела внедрения и техподдержки использовалась система Jira. Однако со временем стало очевидно, что приспособить этот инструмент для разработчиков к задачам отдела внедрения и поддержки не так-то просто. В результате мы начали искать альтернативные средства.



Одним из рассматриваемых вариантов был сервис Zendesk, однако препятствием к его использованию стал неудобный одностраничный интерфейс, в котором и только в котором, по задумке авторов, должны работать сотрудники отдела поддержки. Кроме того, скорость работы Zendesk оставляла желать лучшего. С этими проблемами мы столкнулись в 2013 году, возможно сейчас проект сделал шаг вперед, однако мы уже нашли ему альтернативу.



Ей стал сервис Freshdesk — он похож на Zendesk, но обладает более дружелюбным интерфейсом и довольно активно развивается. Разработчики оперативно реагируют на запросы, в их системе реализован и API-интерфейс (надо признать, он уступает API Zendesk).



Для управления проектами внедрения мы используем ирландский PM-сервис Teamwork, также для некоторых задач до сих пор используется Jira (ведение задач, которые не подходят по назначению ни в одну из других систем управления).



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



Как все устроено



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



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



Информация из хранилища используется для построения графиков загрузки сотрудников (заявки, их состояние, прогресс выполнения задачи). Повышенное внимание мы уделяем анализу того, как изменяются основные показатели.







Контроль



Для платной услуги корректное логирование затраченного времени очень важно.



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







Для сбора обратной связи об удовлетворенности после каждого обращения клиенту предлагается оценить свой опыт взаимодействия со службой поддержки.



Оценками служат смайлики — зеленый, желтый и красный. Клиент выбирает подходящий смайлик одним кликом мышки. Из-за простоты этой системы оценок поступает много, обратная связь надежная. Существует «внутренний SLA», согласно которому из 100 последних оценок как минимум 96 должно приходиться на зеленые смайлы. Информация по удовлетворенности пользователей «Гидры» открыта и доступна на специальной странице, а сотрудникам техподдержки она видна постоянно на специальном настенном экране.



По каждой негативной оценке проводится разбирательство с получившим ее сотрудником.



Бонусная программа



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



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



Вот за что сотрудник может получить пойнты:




  • За зеленый смайл, оставленный клиентом (за желтый или красный — штраф).

  • За каждый оплачиваемый (залогированный) час работы по поддержке.

  • За быстрое решение срочной заявки.

  • Решение проблемы дежурным сотрудником не в основное рабочее время.

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



Регламенты и работа с клиентами



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



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



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



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



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



Взаимодействие с разработчиками



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



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



Заключение



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



К примеру, среднее время реакции на заявку клиента снизилось с 7,5 рабочих часов до 5, а ответы на комментарии клиента по заявки поступают, в среднем, за 6 рабочих часов — раньше за 11. Время реагирования на критические запросы стабильно держится на уровне 10 минут.



Более чем в два раза сократилось число взаимодействий с клиентом по одной заявке — со среднего показателя в 10,5 взаимодействий до 4,5. Удовлетворенность клиентов выросла с 87% и наличия 4% красных смайлов до 97%. Кроме того доля оплачиваемого времени поддержки выросла в 1,5 раза за счёт более эффективного расхода рабочего времени сотрудниками.



Original source: habrahabr.ru (comments, light).

http://habrahabr.ru/post/269181/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<техподдержка - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda