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


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

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

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

Выделенный сервер в Европе

Понедельник, 03 Апреля 2017 г. 15:43 (ссылка)

server12.200x0 (200x148, 16Kb)
Если вам необходим качественный ресурс для работы в интернете или для мощных приложений (в особенности для игр), тогда подробнее тут , вы сможете познакомиться с условиями аренды выделенного сервиса от компании DCXV. Здесь на очень выходных условиях вы можете получить такой ресурс при гарантированном стабильном питании, высокой производительности, расположенном в Европе, при простом управлении и технической поддержке (даже в случае перегрузки основной системы), в в течении суток.
Сотрудники компании DCXV также предложат вашему вниманию различные конфигурации с полной базой технических данных. Это позволит вам получить выделенный сервис, согласно индивидуальным требованиям, по приемлемым ценам. Комфортабельный и просторный ресурс позволит работать более эффективно, при любых обстоятельствах.

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

Опыт DataLine: как мы готовим дежурных инженеров для своих дата-центров

Вторник, 07 Марта 2017 г. 10:11 (ссылка)

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




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

  • это наша “кузница кадров”. Некоторые ребята потом вырастают до ведущих инженеров профильных технических групп и даже до руководителей отделов.



Но обо всем по порядку.





Чем занимаются дежурные инженеры



У дежурных инженеров много задач. Они работают:




  • с клиентами: сопровождают их по дата-центру, помогают клиентам оформить внос/вынос оборудования, следят за соблюдением правил поведения в дата-центре.

  • с ИТ-оборудованием: маркируют и регистрируют вновь в системе учета, готовят стойки под монтаж, монтируют и демонтируют, перезагружают его, прокладывают кроссировки.

  • с инженерной инфраструктурой: два раза в день визуально осматривают все инфраструктурные помещения дата-центра.

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



В дневной смене в зависимости от дата-центра вахту несут 6-8 дежурных инженеров и один старший инженер. В ночной – на два человека меньше.

Инженеры работают по двум графикам на выбор: 5 дней в неделю по 8 часов или сутки через трое.



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





Посты дежурных инженеров некоторых наших дата-центров. Всего на площадке OST работает 19 дежурных, NORD – 27 человек.



Кто может стать дежурным инженером



Мы отдаем предпочтение выпускникам и студентам последних курсов технических университетов. Многие приходят из расположенного по соседству с площадкой OST МТУСИ, МГТУ им. Баумана, МЭИ.

Единственное ограничение на этом этапе – это возраст: кандидату должно быть не более 24 лет. Причина возрастной “дискриминации” в том, что дежурный инженер – позиция стартовая. По нашему опыту, после года работы инженер получает все возможные знания на этой должности, и в “дежурке” ему становится скучно. В то же время к этому моменту он понимает, куда двигаться дальше.














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


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




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




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




  • перейти в бизнес-направления — дирекции продаж и управления сервисом, отдел развития продуктов.





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























Кирилл Шадский, руководитель отдела по работе с внешними дата-центрами
В 2010 году Кирилл закончил МТУСИ и пришел в DataLine на должность дежурного инженера.
В начале 2011 возглавил службу поддержки, в 2012-м – отдел эксплуатации дата-центров. На этой должности занимался управлением инженерными системами дата-центра, реорганизовал процессы эксплуатации, мониторинга, ремонта и модернизации систем. За это время количество дата-центров DataLine выросло с 2 до 6.
В 2014-м Кирилл со своей командой успешно прошел аудит дата-центров NORD-1 и NORD-2 по стандарту Uptime Institute Management & Operations и получил рекордные 92 из 100 баллов. В 2015 году участвовал в сертификации дата-центра NORD-4 по стандартам Uptime Institute Tier III: Design и Uptime Institute Tier III: Facility.
Со второй половины 2015-го возглавляет отдел по управлению внешними ЦОД, проводит обучающие семинары по инженерной инфраструктуре дата-центров.






















Григорий Атрепьев, руководитель отдела по управлению проектами
Григорий закончил МТУСИ и пришел в компанию в 2009 году в качестве дежурного сетевого инженера. Принимал участие в модернизации и развитии ядра сетевой инфраструктуры дата-центров, внедрял системы телефонии и контакт-центра.
В 2011-м возглавил сетевой отдел, завершил строительство оптоволоконных линий связи между сетевыми точками присутствия, провел модернизацию сетевого оборудования DataLine на ММТС-9 и ММТС-10.
C 2012–2014 годах занимал должность директора по производству: отвечал за работу технических отделов, эксплуатацию ЦОД, работу технической поддержки.
С 2014 года руководит отделом по управлению проектами. Его команда разрабатывает архитектуру для нестандартных комплексных проектов на базе виртуальных и физических мощностей DataLine, решает задачи по миграции из внешних дата-центров и сторонних сервисов, организовывает поддержку инфраструктуры клиентских информационных систем, проводит аудиты.






















Алексей Багаев, руководитель сетевого отдела
В 2009-м году Алексей пришел на позицию дежурного инженера.
В 2010-м перешел в сетевой отдел, где занимался администрированием VoIP сервисов, организацией резервирования клиентских подключений.
В 2011-м занял должность старшего сетевого инженера.
С 2012 возглавляет сетевой отдел. За это время его команда провела полную модернизацию сети передачи данных DataLine, внедрила новые сервисы, построила Meet-Me-Room и порядка 250 км. оптических трасс по г. Москве. В 2015-м заработала собственная точка обмена трафиком DataLine-IX.






















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


Как проходят отбор и стажировка



С момента отправки резюме до записи в трудовую проходит от 1 до 3 в зависимости стартовых знаний и умений. За это время и мы, и сам кандидат поймем, подходим ли мы друг другу.

Путь кандидата к званию “дежурный инженер” выглядит следующим образом:



отборочный тур – 1 день;

вводное обучение и экзамен – 3 дня;

оплачиваемая стажировка – 1-3 месяца;

зачисление в штат.



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



Вам пишет письмо сервис-менеджер с просьбой подключить для клиента дополнительную стойку. Официального непосредственного подтверждения от вашего руководства нет. Сегодня пятница 19:00, ваша смена заканчивается в 9 часов утра в субботу, а работа должна быть сдана в 12 часов утра в субботу. Ваши действия?



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



Вместе с приглашением на отборочный тур ребята получают инструкции по самым простым и частым операциям в дата-центре: обжать витую пару, настроить IP KVM, снять логи с PDU и т.д. Разобраться в них и понять, что к чему, – своего рода домашнее задание. На собеседовании нужно проделать все самостоятельно, по возможности без инструкций и подсказок. Здесь мы тоже проверяем не столько техническую подкованность, сколько ответственность и обучаемость кандидата. Вот на фото ниже кто-то делом занимается, а кто-то курит бамбук, потому что дома не подготовился.





Базовые технические знания проверяются в ходе отдельного теста. Если у кандидата нет понимания, что такое TCP\IP, для чего нужен DNS-сервер, каковы параметры бытового тока, то на позиции дежурного инженера ему будет сложно.

Баллы подсчитываются сразу, результаты разбираются совместно. Все баллы заносятся в “личное дело”, где фиксируют все результаты последующих экзаменов и стажировки.



Вводное обучение. Если кандидат набрал не менее 21 балла (70% от возможного), то он продолжает свой путь и его приглашают на трехдневное вводное обучение.



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



В конце первого дня – первая обзорная экскурсия по дата-центру, где рассказывают про основных функции инженерных систем.



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

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






































ТОП-10 самых частых инцидентов в зоне ответственности дежурного инженера
Работа с оборудованием (замена аппаратных узлов, установка ОС)
Подключение и/или настройка КВМ для клиента
Перезагрузка оборудования
Коммутация оборудования
Монтаж/демонтаж оборудования
Работы по СКС
Маркировка оборудования
Визуальный мониторинг (проверка работы оборудования по запросу)
Представление информации по запросу клиентов


Третий день полностью посвящен инженерной инфраструктуре дата-центра. Старший инженер площадки во всех деталях рассказывает про основные системы дата-центра – энергоснабжение, холодоснабжение. На примере одной из площадок кандидатов знакомят с оборудованием и системами, рассказывают про их роль в работе дата-центра. Будущие инженеры узнают принципы работы промышленных ДГУ, ИБП, кондиционеров, чиллеров. В этот же день они разбирают типы стоек и первый раз пробуют установить и подключить оборудование в стойку.

Также ребятам рассказывают про устройство сетевой инфраструктуры.



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



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



Все эти три дня к ребятам присматриваются их будущие руководители. Они оценивают их умение работать в команде.

По итогам экзамена (нужно набрать не менее 70% от возможного количества баллов) мы принимаем решение, приглашать кандидата на стажировку или нет.



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

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



Вот такой интересный и насыщенный путь проходит желающий стать дежурным инженером в нашем дата-центре.



Если хотите попробовать свои силы и получить возможность поработать в самом крупном коммерческом дата-центре России, присылайте свои резюме на job@dtln.ru.


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

https://habrahabr.ru/post/323136/

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

Успеть за 30 минут и другие рекорды Social Media Support

Среда, 01 Марта 2017 г. 06:17 (ссылка)





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







Мир меняется, а вместе с ним развиваются различные сферы нашей жизни. Службы технической поддержки не исключение. В век социальных сетей помогать клиентам и отвечать на вопросы не выходя из Facebook вещь довольно обыденная. Добавились горячие номера, куда клиенты могут звонить 24/7 и задавать любые вопросы. Появились чаты, в командах становится все больше и больше инженеров, говорящих не только на английском, но и на других языках. Несмотря на то что, английский остается приоритетным во многих службах, довольно приятной и неожиданной фичей является возможность поговорить с инженером техподдержки на родном языке.







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

Что в первую очередь приходит вам на ум, когда вы слышите сочетание слов Social Media Support (SMS)? Наверно, это социальные сети и подобные им каналы, в которых вам могут оказать помощь, ответив на вопросы, инженеры, продажники или другие сотрудники компании. Все так, но есть в SMS своя специфика, о которой и пойдет речь ниже.







Стиль общения



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



Привычные фразы и темплиты, которые ежедневно и ежечасно использовались в переписке с пользователями трансформируются в короткие «please check this out », «give this a shot» и «thanks for sharing!», а спустя какое-то время даже эти фразы умудряются уменьшиться до «plz», «thx», «ICYMI» — in case you missed it и даже w/ вместо привычного with.







Конечно, сокращения используются только тогда, когда они действительно нужны. Например, для того, чтобы уместить свой ответ в 140 символов твита. В отличие от твиттера, форумы и фэйсбук позволяют нам писать слова целиком, однако, сам стиль общения заметно меняется. К слову, «Hey» или «Hi there» заменяет привычное «Hello. Thank you for contacting Customer Support». А так же можно добавить «I mean..» для рассшифровки своих же слов в посте, или обратиться к пользователю с просьбой “We’d need more details on this” для того, чтобы получить дополнительную информацию о проблеме. Просто переспросить клиента о том была ли решена проблема – на форуме тоже гораздо легче: «Does it work OK now?» или что-то очень похожее инженеры спрашивают у пользователей, да и сами пользователи не бояться уточнить лишний раз помогли ли обходные пути.











Такой стиль в первую очередь задают сами пользователи и никуда от этого не денешься. Отвечать на живой, приправленный смайлами вопрос «Thank you for contacting us. Please try these steps as a potential solution and let us know how it goes. …… Also, verify these settings and provide us with the steps to reproduce the issue if it doesn’t help» становится не только неуместно, но и затратно по времени.



End of life license или конец фильма



Еще одно отличие SMS от обычного саппорта заключается в ответах и помощи клиентам с истекшей лицензией или с вопросами о других приложениях. Если в обычных тикетах можно объяснить, что мы больше не поддерживаем эти версии или проблема связана в другим приложением, и после этого закрыть тикет (возможно, предоставив клиенту пару ссылок на статьи о починке приложения или возможность обновиться без лишних временных затрат), то в социальных сетях помимо фразы «это проблема вот того, левого приложения», мы обычно стараемся предложить решение, которое наверняка поможет нашему кастомеру. Более того, отвечать на форуме человеку с версией end-of life, что мы не можем ему помочь, потому что это официально больше не обновляется не чинится и не поддерживается просто некрасиво, неправильно и неграмотно с точки зрения принципов нашей работы. Это такой официальный канал, который помимо официального делает еще очень много неофициального. Поэтому при работе с таким вопросом, стоит постараться не только описать фичи новой версии, но и сделать все возможное, чтобы помочь клиенту решить его вопрос.







Как помочь мистеру «не работает» или третье отличие



SMS отличается еще и тем, что инженеры предлагают клиенту множество возможных решений, в ответ на его вопросы. Зачастую пользователи не описывают симптомы так подробно как в тикете, потому что, возможно, у них нет анкеты, которую нужно полностью заполнить, тем самым ответив на интересующие саппорт вопросы. Обычно все пишут в Facebook, форум или твиттер простое: "Все козлы! Все сломалось.! Или просто: "- Алее! Чейта не работает?"



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



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







Сроки



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



Конечно, время ответа зависит не только от показателей, которые нужно выполнить, но и от сложности вопроса, компетентности инженера, подробного описания проблемы пользователем и многих других факторов. В среднем на один ответ на фэйсбуке уходит 24 часа, на твиттере – около 11 часов. Есть и другие показатели, говорящие о том, что кастомер получает ответ на твиттере в течение 20 минут и в течение 30-40 минут ему могут ответить на фэйсбуке.



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



Но не стоит забывать и о том, что решение вопроса с одного реплая в классическом и СМ саппорте ценится очень высоко.







Сложность – пятое отличие



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



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



Сама я на практике встречала достаточное количество вопросов от системных администраторов.

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



Вместо заключения.

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




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

https://habrahabr.ru/post/322860/

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

Качество сервиса на три буквы

Среда, 22 Февраля 2017 г. 12:39 (ссылка)





«В старом мире, мы тратили 30% нашего времени на создание хорошего сервиса и 70% времени на то, чтобы рассказать о нём. В современном мире всё наоборот» — Джефф Безос, CEO, Amazon



Это самый ужасный сервис на свете! Верните мне мои деньги немедленно!” — каждый инженер техподдержки хотя бы раз, но слышал такое от пользователя. Да что и говорить, чаще всего высказываются самые недовольные: “Я 27 минут висел на телефоне", “Мою проблему не могут решить уже четвертый день!”. Те, кто никогда не работал в саппорте судят о качестве предоставляемого сервиса по своему личному опыту. А как о нем судим мы, те, кто отвечает на звонки и решает проблемы? Как определить, хороший ли сервис вы предоставляете своим пользователям?



На самом деле тут не нужно изобретать велосипед — всё уже давно придумали до нас. Достаточно обратиться к ключевым показателям эффективности (КПЭ/kpi) и цифрам. Цифры - язык, понятный всем, будь то новый инженер, которому ставят цели или топ-менеджер, которого нужно убедить о необходимости расширения штата.







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



Начну с самого начала. Когда я пришла работать в Parallels, у нас уже было порядка 5 млн пользователей Parallels Desktop for Mac по всему миру. В активе значились первая линия поддержки на аутсорсе, вторая линия в Москве и посменный график 24/7. Команд было много, работы тоже. Я пришла как раз во время очередного мажорного релиза. Так получилось, что все тренеры были в Индии на обучении наших саппортеров. Мне дали почитать правила работы и инструкции по продуктам и «десантом» выбросили сразу в ночные смены. 







Первым делом, как прилежная ученица я изучила все метрики (а тогда их было больше 20!), вроде бы разобралась и благополучно забыла до тех пор, пока следом за мной не пришел новый инженер, которого мне поручили учить. В голове была абсолютная путаница — какая метрика за что отвечает? Как что считается? А самое главное — как я могу на что повлиять? Конечно, в итоге я во всем разобралась, но, став тимлидом, первым делом я убрала из целей половину метрик, оставив только самые главные.



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



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



Incoming volume или количество обращений



Как измерять? Считать количество созданных заявок за заданный промежуток времени.

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



Помню, когда я только пришла в поддержку, на релизах нас «заваливало», в буквальном смысле этого слова. А если кто-то из опытных вдруг еще и заболевал, то приходилось работать по 6 смен подряд, чтобы хоть как-то раскидать заявки. Бывало так, что задержка в ответе доходила до двух недель. Мы звонили пользователям, а они говорили: «Знаете, я уже просто всё заново поставил, слишком уж долго вы отвечали».



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



За 2016 год мы зафиксировали минимальное количество обращений в день — 1 заявка (9 октября) и максимальное количество — 52 заявки (16 марта). Что удивительно, даже в январские праздники нам прилетает в среднем по 8-12 заявок в день и не было ни одного дня без обращений.



IRT — initial response time или время обработки новых заявок



Как измерять? Берем суммарное время реакции на новые заявки и делим на количество созданных заявок за определенный промежуток времени.



Почему это важно для нас? Никто не любит, когда ответа от техподдержки приходится ждать долго. В среднем, пользователь ждет ответа в social media ресурсах в течение часа, а на свой email запрос в течение 24 часов. И здесь не берутся в расчет автоответы: “ваша заявка создана”, только нормальный адекватный ответ с информацией по проблеме. 



Я как-то даже проводила эксперимент: завела заявку в 5 разных компаний и ждала ответа. Два письма прилетело сразу же с автоответом, что со мной свяжутся в течение 24 часов; через полчаса мне ответили из компании #3 и предоставили решение, #4 отвечали в среднем порядка 7 часов, а последнее письмо так и осталось без ответа. Удивительно то, что после обещания связаться со мной, компании #1 и #2 потерялись надолго: один ответ пришел спустя пару дней, а другой через неделю.



Когда мы только начали предоставлять поддержку корпоративным клиентам, мы понятия не имели, как быстро мы отвечаем. Какие на самом деле должны быть SLA, чтобы мы их выполняли? Мы отслеживали динамику IRT в течение 3 месяцев, учли всевозможные составляющие, в том числе “человеческий фактор” и релизы, и теперь точно знаем свои сроки и стремимся их перевыполнить.







FCR — first contact resolution или число заявок, решенных одним ответом



Как измерять? В Parallels всегда было принято отслеживать количество интеракций в рамках одной заявки и считать заявки, решенные в первом же ответе. Хотя, судя по последним течениям и обсуждениям, это не совсем верно, ведь пользователь может вернуться и в новую заявку, но с уточняющим вопросом? Многие компании «следят» за пользователем в течение 7 дней с момента обращения в саппорт. Если пользователь пришел один раз и больше не звонил после полученного решения — отлично, это FCR.



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



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



TTR — time to resolution или время решения заявки



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



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

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



И опять пример из жизни (не про техподдержку, но про сервис и очень показательный). На прошлой неделе я ходила на почту за марками и простояла в очереди добрых 27 минут, а когда подошла к окошку, оказалось, что марки именно в этом окне закончились и мне нужно в другое, во второе. Во втором окне никого не было и пришлось молча ждать снова. Еще 9 минут, я уже опаздываю на работу и тут появляется Светлана. За 2 минуты Светлана рассказала мне всё, что мне нужно знать о марках, объяснила, чем отличаются марки за 37 и 35 и предложила взять открытки сразу же к себе в окошко, потому что из ящика сегодняшнюю почту на отправку уже вытащили. Я не пожалела, что ждала Светлану. То, как быстро она решила мой запрос перечеркнуло томительное время ожидания и я осталась очень довольна сервисом.







QA — quality assurance или качество выполнения заявки



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



Почему это важно для нас? Потому что с количеством и быстрыми ответами мы не хотим терять качество.



Оценивать работу других — сложно, тем более, если заявок много, а в каждой заявке много инфы. Плюс еще оценка может быть субъективной, ведь каждый думает по-разному. Для того, чтобы была некая объективность, мы разработали специальную форму, содержащую несколько основных блоков, по которым оценивается заявка. QA менеджер (кстати, обязательно – инженер в прошлом) только выставляет «да/нет», а финальный балл считается автоматически. 



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



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



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









Конечно, у нас есть и второстепенные метрики. Есть цифры, которые мы достаём раз в год для каких-то особых случаев. Но есть и ситуации, в которых мы стараемся уходить от метрик. Они могут показать, в каком направлении смотреть, но они не расскажут всю историю. За цифрами всегда стоят люди, а люди совершают ошибки, думают по-разному, да и вообще иногда воспринимают KPI как демотиватор. Вводите ли вы, выбрасываете ли или просто следуете метрикам — всегда обязательно проговаривайте всё с командой и начальством. 







Так, в итоге, какими же должны быть КПЭ и как определить, нужны они вам или нет? Я считаю, что метрики — это хороший и проверенный инструмент. Но для него нужна четкая и подробная инструкция. Ещё Питер Друкер, один из самых влиятельных теоретиков менеджмента XX века, говорил, что управлять можно только тем, что можно измерить. Не жалейте времени, разберитесь сами и объясните каждому в своей команде, зачем, для чего и как.



Руководствуйтесь базовыми принципами:




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

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

  • ваша команда должна иметь влияние на метрики. Как пример, даже на количество входящих заявок вы можете так или иначе повлиять. Из самого простого — если видите, что все пользователи приходят к вам с одним и тем же вопросом, то напишите об этом статью в вашу базу знаний КБ. Банально? Тогда заведите задачу FR програм-менеджеруPMу, чтобы сделать продукт более удобным

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



Ну и последнее, цифры говорят правду. Да-да, даже когда это больно. Совсем больно. Будьте готовы и к этому.







З.Ы. Тема КПЭ оказалась настолько интересной, что мы обсудили ее на недавнем митапе для руководителей и специалистов техподдержки SupNet. По ссылке доклады со встречи. Кстати, если хотите принять участие в очередном митапе лайкайте нашу страничку в Facebook и следите за новостями. 
Original source: habrahabr.ru.

https://habrahabr.ru/post/322374/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

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

FirstVDS или как «профессионально» сменить тарифный план

Пятница, 17 Февраля 2017 г. 22:04 (ссылка)

Здравствуйте. Я являюсь веб-разработчиком и администратором web-сервера одного небольшого игрового сообщества, которое имеет простенький сайт и пару игровых серверов. В своё время, когда стоял выбор хостера было решено воспользоваться услугами FirstVDS, как одного из наиболее дешевых хостинг-провайдеров. Посмотрев на тарифную сетку, а также прикинув все требования нашего проекта мы остановились на двух VDS с тарифом VDS-Разгон, но с разной виртуализацией. Для игрового сервера мы взяли KVM (позже взяли еще один KVM), а для сайта OpenVZ, так как нам требовалась гибкая настройка, в том числе и дискового пространства. Казалось, что все будет хорошо, потому что сервера были быстро установлены, аптайм был более чем приемлемый для наших целей и пинг был стабильный и небольшой, что было очень важно для игровых серверов.



Первое наше разочарование возникло месяца через 2, а то и 3. Все дело было в ддос. Тогда сообщение хостера гласило, что наш сервер отключен на 24 часа так как его ддосят уже 10 минут. При этом нам не двусмысленно показали, что нам неплохо было бы выбрать себе тариф с защитой. Да, прекрасно, тариф, который на тот момент стоил 4,5 тыс. руб./месяц для сайта с посещаемостью в 100 чел./день — это конечно они круто завернули. Мы являемся некоммерческим сообществом и все организуем на чистом энтузиазме, денег у нас таких не было, поэтому мы смиренно ждали. Но что больше всего тогда разочаровало — это то, как они предлагали новые тарифы или дополнительные IP-адреса, что как бы наводило на некоторые мысли.







Безусловно я понимаю, что ддос на наш сервер негативно влиял на работу других серверов и естественно его надо было выключать, но у меня возник другой вопрос, а где гарантия, что сервер вообще атакуют и где гарантия что атака идет именно на наш сервер? Проверить это я не мог, потому что доступ к серверу был заблокирован, а чтобы достучаться до него они предлагали купить еще один IP-адрес, который стоил еще 90 руб./мес.



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



И если первое разочарование особо не влияло на мое отношение к хостеру, то разочарование №2, которое возникло вчера в корне это отношение изменило. Я не следил за обновлением тарифной сетки хостера, но вчера мне на игровых серверах понадобилось увеличить количество памяти, в связи с чем я полез в тарифные планы, чтобы подобрать новый тариф. Каким же было мое удивление, когда я увидел, что за те же деньги сейчас дают в два раза больше памяти, что мне как раз и нужно. Спрашиваю у консультанта, являются ли эти тарифы временной акцией и оказывается, что это актуальные тарифы, введенные еще в сентябре. Отлично, лезу в панель управления и тут меня ждёт сюрприз. Оказывается я не могу перейти на новый тариф, а могу сменить лишь на тариф из старой сетки:







Забавно, спрашиваю об этом консультанта и он мне сообщает, что для перехода на новый тариф мне нужно либо купить у них новый сервер и самому все перенести туда, либо купить у них Пакет Администрирования и технические специалисты мне сменят тариф на одном VDS за одно обращение (5 обращений стоят 450 руб./мес.). Ладно, всем хочется кушать и один раз я согласен заплатить 450 рублей, чтобы сменить тариф на новый на всех арендуемых VDS, хотя в моих представлениях это чистейший лохотрон.



Покупаю обращения, пишу запрос в ТП на смену тарифа на одном VDS-KVM, в общей сложности мы потратили час на урегулирование мелких проблем, типа установки их SSH-ключа для ТП. После чего технический специалист менее чем за 3 минуты сделал все остальное и на KVM уже было не 1 Gb памяти, а 2. Здорово, переходим к следующей KVM и здесь операция занимает буквально 20 минут, потому что все необходимые данные я предоставил сразу.



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







Отлично, вся операция заняла около 30 минут и в целом я доволен, но СТОП. Сайт недоступен, хм… По ssh подключения нет. Пинг? Отсутствует. Что такое? Перед этим я выполнил обновление системы, может ли быть такое, что что-то встало криво и теперь Debian отказывается грузиться? Забыл уточнить, что для этого сервера мы покупали дополнительное дисковое пространство в размере 40 Гб, так как на сайтах нам требовалось в первую очередь много дискового пространства, чтобы хранить игровые мувики. Пишем в то же обращение, что связь потеряна и начинается веселуха.







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







Отлично, во-первых, оператор не знает, что после тарифа Разгон идет тариф Отрыв, а вовсе не Улет. Во-вторых, он предлагает мне перейти на тариф, который стоит в два раза больше при том, что мне вовсе не нужно увеличение ресурсов CPU и Памяти. В-третьих, переходим по ссылке которую сбросил оператор, переходим на вкладку «Чем различаются виртуализации OpenVZ и KVM» и видим:







Параметры сервера и тарифный план можно менять через панель управления. Может они забыли тут обновить с сентября информацию и стоит посмотреть в тарифной сетке? Опа, а тут тоже самое:







Ну как же так? Пишем ответ в техническую поддержку и оказывается что нам уже ответили, поэтому чуть-чуть подправляем ответ и отправляем тоже самое, но уже другому специалисту:







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

— Напрочь убитый вечер

— Убитое настроение

— Срыв всех планов

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



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

Original source: habrahabr.ru.

https://habrahabr.ru/post/322118/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

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

FirstVDS или как «профессионально» сменить тарифный план

Пятница, 17 Февраля 2017 г. 22:04 (ссылка)

Здравствуйте. Я являюсь веб-разработчиком и администратором web-сервера одного небольшого игрового сообщества, которое имеет простенький сайт и пару игровых серверов. В своё время, когда стоял выбор хостера было решено воспользоваться услугами FirstVDS, как одного из наиболее дешевых хостинг-провайдеров. Посмотрев на тарифную сетку, а также прикинув все требования нашего проекта мы остановились на двух VDS с тарифом VDS-Разгон, но с разной виртуализацией. Для игрового сервера мы взяли KVM (позже взяли еще один KVM), а для сайта OpenVZ, так как нам требовалась гибкая настройка, в том числе и дискового пространства. Казалось, что все будет хорошо, потому что сервера были быстро установлены, аптайм был более чем приемлемый для наших целей и пинг был стабильный и небольшой, что было очень важно для игровых серверов.



Первое наше разочарование возникло месяца через 2, а то и 3. Все дело было в ддос. Тогда сообщение хостера гласило, что наш сервер отключен на 24 часа так как его ддосят уже 10 минут. При этом нам не двусмысленно показали, что нам неплохо было бы выбрать себе тариф с защитой. Да, прекрасно, тариф, который на тот момент стоил 4,5 тыс. руб./месяц для сайта с посещаемостью в 100 чел./день — это конечно они круто завернули. Мы являемся некоммерческим сообществом и все организуем на чистом энтузиазме, денег у нас таких не было, поэтому мы смиренно ждали. Но что больше всего тогда разочаровало — это то, как они предлагали новые тарифы или дополнительные IP-адреса, что как бы наводило на некоторые мысли.







Безусловно я понимаю, что ддос на наш сервер негативно влиял на работу других серверов и естественно его надо было выключать, но у меня возник другой вопрос, а где гарантия, что сервер вообще атакуют и где гарантия что атака идет именно на наш сервер? Проверить это я не мог, потому что доступ к серверу был заблокирован, а чтобы достучаться до него они предлагали купить еще один IP-адрес, который стоил еще 90 руб./мес.



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



И если первое разочарование особо не влияло на мое отношение к хостеру, то разочарование №2, которое возникло вчера в корне это отношение изменило. Я не следил за обновлением тарифной сетки хостера, но вчера мне на игровых серверах понадобилось увеличить количество памяти, в связи с чем я полез в тарифные планы, чтобы подобрать новый тариф. Каким же было мое удивление, когда я увидел, что за те же деньги сейчас дают в два раза больше памяти, что мне как раз и нужно. Спрашиваю у консультанта, являются ли эти тарифы временной акцией и оказывается, что это актуальные тарифы, введенные еще в сентябре. Отлично, лезу в панель управления и тут меня ждёт сюрприз. Оказывается я не могу перейти на новый тариф, а могу сменить лишь на тариф из старой сетки:







Забавно, спрашиваю об этом консультанта и он мне сообщает, что для перехода на новый тариф мне нужно либо купить у них новый сервер и самому все перенести туда, либо купить у них Пакет Администрирования и технические специалисты мне сменят тариф на одном VDS за одно обращение (5 обращений стоят 450 руб./мес.). Ладно, всем хочется кушать и один раз я согласен заплатить 450 рублей, чтобы сменить тариф на новый на всех арендуемых VDS, хотя в моих представлениях это чистейший лохотрон.



Покупаю обращения, пишу запрос в ТП на смену тарифа на одном VDS-KVM, в общей сложности мы потратили час на урегулирование мелких проблем, типа установки их SSH-ключа для ТП. После чего технический специалист менее чем за 3 минуты сделал все остальное и на KVM уже было не 1 Gb памяти, а 2. Здорово, переходим к следующей KVM и здесь операция занимает буквально 20 минут, потому что все необходимые данные я предоставил сразу.



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







Отлично, вся операция заняла около 30 минут и в целом я доволен, но СТОП. Сайт недоступен, хм… По ssh подключения нет. Пинг? Отсутствует. Что такое? Перед этим я выполнил обновление системы, может ли быть такое, что что-то встало криво и теперь Debian отказывается грузиться? Забыл уточнить, что для этого сервера мы покупали дополнительное дисковое пространство в размере 40 Гб, так как на сайтах нам требовалось в первую очередь много дискового пространства, чтобы хранить игровые мувики. Пишем в то же обращение, что связь потеряна и начинается веселуха.







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







Отлично, во-первых, оператор не знает, что после тарифа Разгон идет тариф Отрыв, а вовсе не Улет. Во-вторых, он предлагает мне перейти на тариф, который стоит в два раза больше при том, что мне вовсе не нужно увеличение ресурсов CPU и Памяти. В-третьих, переходим по ссылке которую сбросил оператор, переходим на вкладку «Чем различаются виртуализации OpenVZ и KVM» и видим:







Параметры сервера и тарифный план можно менять через панель управления. Может они забыли тут обновить с сентября информацию и стоит посмотреть в тарифной сетке? Опа, а тут тоже самое:







Ну как же так? Пишем ответ в техническую поддержку и оказывается что нам уже ответили, поэтому чуть-чуть подправляем ответ и отправляем тоже самое, но уже другому специалисту:







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

— Напрочь убитый вечер

— Убитое настроение

— Срыв всех планов

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



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

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

https://habrahabr.ru/post/322118/

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

Как выгодно организовать и управлять бизнесом удаленно

Среда, 15 Февраля 2017 г. 19:29 (ссылка)

43i5484ade534ed9.200x0 (200x199, 12Kb)
Каждый предприниматель в нашей стране (к их числу отношусь и я), всегда ищут пути, как выгодно и эффективно продвинуть свой бизнес. Специалисты советуют эту работу проводить через интернет, а именно арендовать выделенный сервер и использовать соответственно выделенный хостинг.
Выделенный сервер имеет ряд преимуществ, главные из которых что вы являетесь единственным пользователем такого сервера с возможностью выбора типа операционной системы, базы данных, иными словами, можете управлять конфигурацией сервера, что дает вам возможность решать различные задачи. И конечно же стоит упомянуть, что выделенный сервер обеспечивает бесперебойный доступ ко всем ресурсам, и все это вы сможете делать легко и просто, даже в Европейском пространстве. А значит, что у вас повышается шанс найти надежных клиентов за рубежом.
Если вы заинтересовались таким методом продвижения бизнеса в интернете, советую зайти на сайт https://dcxv.com/ru/dedicated.html и внимательно изучить условия аренды, технические возможности от компания DCXV. Со своей стороны хочу добавить, что я пользуюсь услугой этого выделенного хостинга успешно (благодаря технической поддержке) и довольно успешно.

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

Ваш звонок очень важен для нас? Или как работает система приоритезации заявок в сервисных подразделениях

Понедельник, 23 Января 2017 г. 14:47 (ссылка)

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



Итак, представим ситуацию, что обратился ты в организацию X за некой услугой/продуктом. Возможно, еще на этапе покупки у тебя возникали сомнения относительно разумности выбора компании, но по каким-то причинам услугу/продукт ты все-таки приобрел. Как оказалось впоследствии – очень зря. Качество услуги/продукта не соответствует ожиданиям, возврат не предусмотрен, но заставить сие изделие работать все равно нужно. Выход – служба поддержки. Но вот незадача. Служба поддержки как будто не замечает твоих просьб о помощи, по телефону с ними не связаться, электронные сообщения будто сразу отправляются в спам. Знакомо?



С чем могут быть связаны подобные проблемы и имеет ли это отношение к нерациональному распределению ресурсов в сервисных подразделениях и неправильной приоритезации обращений заказчиков? На эти вопросы я и постараюсь пролить свет на примере системы приоритезации обращений АО «Инфовотч».



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



Расстановка приоритетов обращений в сервисных подразделениях при работе с очередями часто вызывает вопросы. Организация должна дорасти до определенного уровня зрелости, чтобы начать придавать этому аспекту оказания услуг нужное внимание. Конечно, объем запросов должен достичь того уровня, чтобы и критерии расстановки приоритетов «созрели», и количество ошибок из-за «человеческого фактора» возросло до неприемлемых величин (что легко заметить по растущему количеству «крикливых» заказчиков и эскалаций от руководства), и экономический эффект от автоматизации процесса стал осязаемым.



Вы когда-нибудь анализировали, сколько времени затрачивается сотрудниками на рутинное администрирование бизнес-процессов в вашем подразделении? Думаю, что даже если и приходилось этим заниматься, то не слишком часто. Между тем, рутина может отнимать значительное количество рабочего времени сотрудника. Нельзя сказать, что она не важна, ведь она обеспечивает функционирование всего механизма, но, вместе с тем, такая работа не приносит и измеряемого результата, который руководство желает видеть в KPI. К примеру, в службе технической поддержки вряд ли кому-то интересно, сколько сотрудник потратил времени на администрирование заявок (то есть проставление приоритетов, заполнение служебных полей и прочее сопутствующее подкручивание винтиков большого механизма заявки в CRM-системе). На контроле, как правило, только количество обработанных и решенных заявок, результаты по проверке качества и CSAT (Customer Satisfaction). Между тем, практика показывает, что заниматься этим вопросом нужно:



Одна-две минуты на заявку * количество заявок =?

А сколько это в неделю? А в месяц? А в год?

А если умножить это количество часов на средний ФОТ сервисной службы?



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



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



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



Задачи:




  • Упрощение и унифицирование определения приоритета обращений для инженера технической поддержки;

  • Обеспечение правильной очередности обработки заявок.



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



Способы решения:




  • Контроль рабочего времени сотрудников (в данной статье рассматриваться не будет);

  • Повышение квалификации и производительности сотрудников (тоже как-нибудь в другой раз);

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



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



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



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



image



Как видим, за базис приоритета обращения были приняты существующая система SLA и особые источники поступления заявок. В нашей компании имеется три типа контрактов технической поддержки, которые предлагают заказчикам различные SLA. Каждый из таких контрактов получил свое базовое число. Это же касается и источников поступления заявки. При этом система автоматически проставляет более высокий приоритет при выборе из двух базовых. А дальше началось самое интересное. Базовые значения никак не учитывают все возможные нюансы в работе технической поддержки.



Приведу пример:



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



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

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



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



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









То есть конечная формула выглядит так:



Базовый показатель + плавающий показатель = Итоговое значение приоритета.

Попробую для наглядности провести расчет по приведенным ранее примерам.



Для примера №1 расчет выглядит так:



Premium SLA + Предпродажная эскалация + Постпродажная эскалация + Вес организации*количество пользователей более 10000 + Серьезность проблемы * пожелания по функциональности + продолжительность работы = 0.07+0+0+0.03*0.38+0.56*0.02-0 = 0.07+0.0114+0.0112 = 0.09 Как видите, итоговый показатель приоритета достаточно низкий, несмотря на приличные вводные данные (Premium поддержка, крупный клиент).



Для примера №2 расчет выглядит так:



Extended SLA + Предпродажная эскалация + Постпродажная эскалация + Вес организации*количество пользователей 100 + Серьезность проблемы * Критическая проблема + продолжительность работы = 0.04+0+0+0.03*0.03+0.56*0.42=0.04+0.0009+ 0.24=0.28 Здесь ситуация обратная. Несмотря на то, что организация совсем не крупная и имеет более скромный контракт на техническую поддержку, из-за высокого уровня важности проблемы значение приоритета заявки превышает заявку из примера №1.



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



image



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



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



Новая система внедрена в нашей CRM и функционирует с начала декабря 2016 (51 неделя). За время ее пилотной эксплуатации мы уже заметили снижение количества эскалаций:







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



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



За сим у меня все, буду рад пообщаться в комментариях.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/320226/

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

Ваш звонок очень важен для нас? Или как работает система приоритезации заявок в сервисных подразделениях

Понедельник, 23 Января 2017 г. 12:59 (ссылка)

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



Итак, представим ситуацию, что обратился ты в организацию X за некой услугой/продуктом. Возможно, еще на этапе покупки у тебя возникали сомнения относительно разумности выбора компании, но по каким-то причинам услугу/продукт ты все-таки приобрел. Как оказалось впоследствии – очень зря. Качество услуги/продукта не соответствует ожиданиям, возврат не предусмотрен, но заставить сие изделие работать все равно нужно. Выход – служба поддержки. Но вот незадача. Служба поддержки как будто не замечает твоих просьб о помощи, по телефону с ними не связаться, электронные сообщения будто сразу отправляются в спам. Знакомо?

С чем могут быть связаны подобные проблемы и имеет ли это отношение к нерациональному распределению ресурсов в сервисных подразделениях и неправильной приоритезации обращений заказчиков? На эти вопросы я и постараюсь пролить свет на примере системы приоритезации обращений АО «Инфовотч».



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

Расстановка приоритетов обращений в сервисных подразделениях при работе с очередями часто вызывает вопросы. Организация должна дорасти до определенного уровня зрелости, чтобы начать придавать этому аспекту оказания услуг нужное внимание. Конечно, объем запросов должен достичь того уровня, чтобы и критерии расстановки приоритетов «созрели», и количество ошибок из-за «человеческого фактора» возросло до неприемлемых величин (что легко заметить по растущему количеству «крикливых» заказчиков и эскалаций от руководства), и экономический эффект от автоматизации процесса стал осязаемым.



Вы когда-нибудь анализировали, сколько времени затрачивается сотрудниками на рутинное администрирование бизнес-процессов в вашем подразделении? Думаю, что даже если и приходилось этим заниматься, то не слишком часто. Между тем, рутина может отнимать значительное количество рабочего времени сотрудника. Нельзя сказать, что она не важна, ведь она обеспечивает функционирование всего механизма, но, вместе с тем, такая работа не приносит и измеряемого результата, который руководство желает видеть в KPI. К примеру, в службе технической поддержки вряд ли кому-то интересно, сколько сотрудник потратил времени на администрирование заявок (то есть проставление приоритетов, заполнение служебных полей и прочее сопутствующее подкручивание винтиков большого механизма заявки в CRM-системе). На контроле, как правило, только количество обработанных и решенных заявок, результаты по проверке качества и CSAT (Customer Satisfaction). Между тем, практика показывает, что заниматься этим вопросом нужно:



Одна-две минуты на заявку * количество заявок =?

А сколько это в неделю? А в месяц? А в год?

А если умножить это количество часов на средний ФОТ сервисной службы?



У менеджеров всегда есть более важные задачи, не терпящие отлагательств, и инвестировать время в то, чтобы автоматизировать часть рутины, да еще получить согласие и поддержку смежных подразделений, чьи интересы эта автоматизация затрагивает, не всегда представляется возможным. К (не)счастью, в современной экономической модели случаются кризисы, которые стимулируют компании работать в режиме экономии и обратить свой взор к оптимизации монструозных процессов, накрученных в тучные годы. Ранее несрочные задачи по оптимизации и автоматизации процессов выходят на первый план. Так случилось и в нашей организации. Экономическая ситуация в стране не способствует найму сотрудников под каждую новую задачу, а кризис роста в условиях экономии создает уникальную ситуацию, в которой у руководителей подразделений не остается иного выхода, кроме как заняться ревизией процессов, чтобы и сервис не пострадал, и ФОТ не разрастался.



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

Задачи:


  • Упрощение и унифицирование определения приоритета обращений для инженера технической поддержки;

  • Обеспечение правильной очередности обработки заявок.



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

Способы решения:


  • Контроль рабочего времени сотрудников (в данной статье рассматриваться не будет);

  • Повышение квалификации и производительности сотрудников (тоже как-нибудь в другой раз);

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





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



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

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



image



Как видим, за базис приоритета обращения были приняты существующая система SLA и особые источники поступления заявок. В нашей компании имеется три типа контрактов технической поддержки, которые предлагают заказчикам различные SLA. Каждый из таких контрактов получил свое базовое число. Это же касается и источников поступления заявки. При этом система автоматически проставляет более высокий приоритет при выборе из двух базовых. А дальше началось самое интересное. Базовые значения никак не учитывают все возможные нюансы в работе технической поддержки.



Приведу пример:

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



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

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



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

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









То есть конечная формула выглядит так:

Базовый показатель + плавающий показатель = Итоговое значение приоритета.

Попробую для наглядности провести расчет по приведенным ранее примерам.



Для примера №1 расчет выглядит так:

Premium SLA + Предпродажная эскалация + Постпродажная эскалация + Вес организации*количество пользователей более 10000 + Серьезность проблемы * пожелания по функциональности + продолжительность работы = 0.07+0+0+0.03*0.38+0.56*0.02-0 = 0.07+0.0114+0.0112 = 0.09 Как видите, итоговый показатель приоритета достаточно низкий, несмотря на приличные вводные данные (Premium поддержка, крупный клиент)



Для примера №2 расчет выглядит так:

Extended SLA + Предпродажная эскалация + Постпродажная эскалация + Вес организации*количество пользователей 100 + Серьезность проблемы * Критическая проблема + продолжительность работы = 0.04+0+0+0.03*0.03+0.56*0.42=0.04+0.0009+ 0.24=0.28 Здесь ситуация обратная. Несмотря на то, что организация совсем не крупная и имеет более скромный контракт на техническую поддержку, из-за высокого уровня важности проблемы значение приоритета заявки превышает заявку из примера №1.



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



image



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



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



Новая система внедрена в нашей CRM и функционирует с начала декабря 2016 (51 неделя). За время ее пилотной эксплуатации мы уже заметили снижение количества эскалаций:







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

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

За сим у меня все, буду рад пообщаться в комментариях.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/320208/

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

Что такое Блогун, миф или реальная возможность для дополнительного заработка.

Суббота, 26 Ноября 2016 г. 11:33 (ссылка)

Я достаточно долгое время общаюсь онлайн и читаю интересные дневники всем известного нам сообщества Лиру. По моим наблюдениям многие из вас стали блогерами на очень известном сервисе, Блогун, где действительно можно получать денежные вознаграждения за написанные рекламные посты.
Оказывается, сервис Блогун, в своем арсенале имеет достаточно большое количество рекламодателей, которые готовы (за определенную сумму и требования к посту), оплатить вашу работу. Конечно, просто так денег никто не платит, необходимо проявить фантазию, использовать свои навыки в написании уникальных статей. Кстати, опытные блогеры советуют постоянно держать высокий уровень своего блога (это показатель ТИЦ), или выражаясь профессиональным языком, площадки. Ведь именно от этого показателя в будущем, будет зависеть сумма вашего вознаграждения. Кстати, работать на этом сервисе можно в любое удобное для вас время, в уютной домашней обстановке. Сервис в свою очередь гарантирует своевременную оплату, техническую поддержку, надежных партнеров, что в совокупности дает нам возможность неплохо заработать.
Я тоже заинтересовалась этим сервисом, зашла на его сайт, внимательно изучила все требования ресурса и решила, что в моих силах заняться такой работой. Для тех, кто заинтересовался таким видом заработка, советую пройти по ссылке http://u.to/LKNQ, где изложена вся интересная и полезная информация о работе этого сервиса. Надеюсь , что у меня все получится, а вы, мои постоянные читатели, будете поддерживать мои посты своими оригинальными комментариями.
blogruneta (507x600, 49Kb)

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

Случай из практики...Смеюсь!

Суббота, 05 Ноября 2016 г. 11:11 (ссылка)


Реальный случай из практики службы технической поддержки, восхитительный диалог!



компьютер1 (600x400, 60Kb)




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



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



— У меня проблема с текстовым редактором..



— А что именно?



— Я печатал текст, и вдруг все, что я набрал, куда-то делось с экрана.



— Куда-то делось?



— Просто исчезло.



— Хм… А что на вашем экране теперь?



— Ничего. Он пустой. Никак не реагирует, когда я что-нибудь печатаю на клавиатуре.



— Вы все еще в редакторе или вышли из него?



— Откуда я знаю?



— Вы видите открытое окно программы на экране?



— Что еще за окно?



— Ничего, ничего… Скажите, можете ли вы перемещать курсор?



 


— Да нет никакого курсора… Я же вам говорю — ничего не происходит, когда я нажимаю на клавиши.



— У вашего монитора горит индикатор питания?



— У монитора? Что это?



— ???!!!Это такая штука у вас на столе, с экраном, похожая на телевизор. На ней есть небольшая лампочка, которая показывает, что он включен. Горит она?



— Я не знаю…



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



— Вроде да.



— Отлично. Проследите за шнуром до розетки и скажите мне, включена ли вилка в сеть?



— Да, включена.



— Когда вы смотрели за монитор, заметили что там включено два шнура, а не один?



— Нет.



— Должно быть два. Пожалуйста, загляните за монитор снова и найдите второй кабель. — Ага, нашел.



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



— Я не могу его достать, компьютер стоит на полу.



— О, господи… Ну вы хотя бы можете посмотреть, включен ли этот шнур в компьютер? — Нет, не могу.



— Даже если вам придется сесть на пол и заглянуть за компьютер?



— Это не потому, что я не могу сесть на пол! Просто тут слишком темно!



— Темно?!!



— Да, света из окна недостаточно.



—Ну так включите свет в комнате!



—Не могу. У нас сегодня был сбой с энергией, и света нет во всем здании.



— Во всем здании?! Ммм… Хорошо, похоже, я знаю, что делать. У вас сохранились коробки и книги к вашему компьютеру?



— Да, все лежит в шкафу.



— Здорово! Достаньте коробки, отключите компьютер, упакуйте все как было и отвезите обратно в магазин, где вы его купили.



— Серьезно? Неужели дело настолько плохо?



— Боюсь, что да.



— Хорошо, я так и сделаю. А что мне сказать в магазине?



— СКАЖИТЕ ИМ, ЧТО ТАКОМУ ИДИОТУ, КАК ВЫ, НЕЛЬЗЯ ИМЕТЬ КОМПЬЮТЕР!!!



источник



 

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

Как четырехчасовая поддержка превращается в недельную, и некоторые особенности платного сервиса HP, IBM, Dell

Вторник, 30 Августа 2016 г. 15:47 (ссылка)



Разбираемся в хитросплетениях платной поддержки на серверное оборудование и соотносим стоимость “овчинки” к ее выделке. Речь пойдет о сервисной поддержке от IBM, HP и Dell – компании очень активно продвигают собственные услуги в этой сфере.



Платная поддержка на серверы “большой тройки” называется по-разному:




  • Support Service (Care Pack) у HP;

  • ProSupport в исполнении Dell;

  • ServicePac в каталогах IBM.



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



Памятка – основная информация о сервисных контрактах, их нюансах и особенностях

Базовая информация о платной поддержке HP, IBM и Dell



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



Обычно в него входят:




  • Сертифицированная установка оборудования (может быть обязательным);

  • Удаленный мониторинг, обновление прошивок (может быть обязательным);

  • Прием заявок на ремонт и обслуживание с заранее оговоренным временем реакции;

  • Работы по устранению неполадок с заранее согласованным сроком и массой нюансов;

  • Выезд сервисного инженера в ваш офис, отправка запчастей курьерской службой.



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



В этой статье мы подробнее остановимся на сервисных контрактах для серверов начального и среднего уровней (HP Proliant ML\DL1xx\3xx, IBM System X 3xxx, Dell PowerEdge R\T), как наиболее востребованных.



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



В качестве источников информации использованы следующие ресурсы:





Базовая платная поддержка



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



Сроки начала работ зависят от расстояния между вашим офисом и сервисным центром, хотя не все вендоры четко оговаривают километраж. Например, у HP 6 часов CTR актуальны, если до ближайшего сервисного центра не более 80 км. В противном случае, скорость восстановления может затянуться на несколько дней и повлечь дополнительные расходы на поездку инженера.







































Пакет Реакция Начало работ

по восстановлению
Время доступности Cтоимость поддержки к стоимости оборудования
HP Foundation Care следующий рабочий день следующий рабочий день 5 дней в неделю по 9 часов 0,044
HP Foundation Care 24x7 N\A 24/7 0,372
HP Foundation Care — Call to Repair (CTR) 2 часа 4 часа 24/7 0,671
Dell ProSupport следующий рабочий день следующий рабочий день 5 дней в неделю по 10 часов 0,047


На скорость реакции может влиять и время обращения. Например, в описании поддержки Dell NBD оговорено, что если позвонить после 17:00, то на обработку заявки может потребоваться дополнительный рабочий день.



Вы заметили, что в этой таблице нет IBM? Дело в том, что компания предоставляет только проактивный сервис Committed Service.



Поддержка с проактивным сервисом



Пакеты с проактивной удаленной поддержкой включают дополнительный набор услуг и обычно дороже предыдущей категории в 1,3 – 6 раз. В таблице ниже вы можете видеть основные отличия этой категории от базовой:





























Опция Поддержка с удаленной диагностикой Базовая поддержка
Выделенные менеджеры + -
Обновления прошивок и ПО, аудит и прогноз работоспособности (несколько раз в год) + -
Удаленная техническая поддержка + +
Быстрая реакция на критические сбои + +


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



Сервисные пакеты IBM аналогичны по возможностям HP Call to Repair и Dell Mission Critical, то есть оговаривается время от удаленной диагностики проблемы до начала восстановления.










































































Пакет Реакция Начало работ

по восстановлению
Время доступности Cтоимость поддержки к стоимости оборудования
HP Proactive Care Next Business Day следующий рабочий день следующий рабочий день 5 дней в неделю по 9 часов 0,287
HP Proactive Care 24x7 4 часа N\A 24/7 0,616
HP Proactive Care — Call to Repair (CTR) 2 часа 4 часа 24/7 0,915
Dell ProSupport Plus NBD 0,5 — 2 часа (доп. услуга) следующий рабочий день 5 дней в неделю по 10 часов 0,115
Dell ProSupport Plus Mission Critical 4 Hours 0,5 – 2 часа (доп. услуга) 4 часа 24x7 0,306
IBM ServicePac 0 – 4 часа следующий рабочий день 5 дней в неделю по 9 часов 0,283
IBM ServicePac — NBD 0 – 4 часа 48 часов (следующий рабочий день) 5 дней в неделю по 9 часов 0,283
IBM ServicePac — 24x7 8 часов 0 – 4 часа 8 часов 24x7 0,964
IBM ServicePac — 24x7 24 часа 0 – 4 часа 24 часа 24x7 0,444


У Dell за время ответа отвечает отдельная услуга Support Service, которая делится на 3 категории:




  1. Standard;

  2. 24x7;

  3. Premier.



Все они позволяют общаться с Dell по телефону или e-mail, получать обновления и читать документацию (Knowledge Base и другие онлайн-ресурсы), а отличаются по времени реакции на ваш инцидент. Например, с категорией Premier на критичный сбой среагируют за полчаса, против часа у других категорий.



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



Помните, что пакет проактивной поддержки обычно продается вместе с услугой сертифицированной установки ($100 – 300).



Время реакции != Скорость восстановления





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




  • Например, пакет HP Foundation Care 24x7 ($1 389) позволяет круглосуточно обращаться в поддержку и получать реакцию в течение 4 часов. Но работы могут начаться и значительно позже;

  • Аналогично с более дорогим пакетом HP Proactive Care 24x7 ($2 296). Правда, туда входит дополнительный сервис по онлайн-диагностике и обновлениям, но они на скорость восстановления не особенно влияют;

  • У IBM есть сервис Committed Service 24x7, который предполагает реакцию в течение 4 часов, но работы могут начаться как через 8 часов ($2 799), так и через сутки ($1 291).



На практике, время реакции выглядит приблизительно так:



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

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



Но и здесь не все так гладко, ведь в действие вступают следующие факторы:




  • Есть ли нужный компонент на складе ближайшего сервисного центра (СЦ)?

  • Насколько далеко от вас находится СЦ? У некоторых производителей оговорены определенные гарантированные расстояния, у других – нет. Но если ваш офис в сотнях километров от регионального СЦ, то время восстановления будет измеряться уже днями. Плюс, может потребоваться оплата поездки инженера;

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



«Мы сами регулярно общаемся с поддержкой вендоров, поэтому есть определенный практический опыт в этом плане. Например, быстрее всего работают HP и Dell – запчасти нам привозили обычно на следующий день. Из недочетов HP можно отметить только довольно запутанную систему регистрации заявки, с несколькими этапами подтверждения»

Кроме всего перечисленного, стоит помнить и о дополнительных требованиях к расширенным пакетам вроде HP Proactive Care или Dell ProSupport Plus. Условия поддержки по ним включают требования к сертифицированной установке ($100 — 300 за сервер) и удаленному доступу. Конечно, это не так страшно, если только у вас не государственное или режимное учреждение.



Сервисную поддержку оказывают партнеры, а не производитель





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



«Первая крамольная мысль: раз приедет специалист из той же компании, где приобретается сервер, то стоит ли заказывать дополнительную поддержку именно от производителя? Очень интересный вопрос, и мы совсем скоро на него ответим»

Вообще, как внутренние, так и внешние инженеры по ремонту и обслуживанию располагают похожей базой знаний и одинаковым набором сертификатов от вендора. К примеру, для ремонта серверных систем IBM System X или HP ProLiant нужны, как минимум, следующие квалификации:




  • HP Accredited Platform Specialist for HP Proliant Server;

  • IBM Certified Specialist — System x Server Family Technical Support V1.



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



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



Интереснее дела обстоят с сервисом от продавца. Например, при покупке восстановленного сервера вам могут предложить собственную гарантию с выездом на площадку и удаленной помощью. Как же убедиться в качестве поддержки, если вендор ею не управляет?



Можно пойти двумя путями:




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

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



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



Нельзя однозначно сказать “покупайте у N и пользуйтесь их гарантией” или “заказывайте серверы с фирменной поддержкой”, ведь в каждом конкретном предложении баланс плюсов и минусов будет разный. Чтобы немного облегчить вам выбор, мы изучили массу спецификаций HP, IBM, Dell и подготовили по их пакетам сводную таблицу (см. спойлер в начале статьи).



Расстояние имеет значение





Мы живем в очень большой стране, где из одного ее края в другой можно ехать неделю. Конечно же, это не могло никак не сказаться на сроках оказания технической поддержки, даже за деньги. У всех производителей “большой тройки” есть лимит на расстояние между вашим офисом и их сервисным центром, от которого напрямую зависит соблюдение оговоренной скорости восстановления. Но не все публикуют такую информацию в явном виде.



Например, у HP 6 часов CTR (из большой таблицы во врезке) актуальны только при расстоянии до сервис-партнера не более 80 км. Если же вы попадаете в промежуток 80-160 км, то задержка увеличивается на 2 часа. При б_о_льших расстояниях речь пойдет уже о днях и потребуется отдельное обсуждение этого нюанса при покупке.



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

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



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



Ответственность за сервис перед законом несет продавец





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



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



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

Вы ведь помните, что сервисный партнер и продавец – как правило, одна и та же компания?»

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



Возможны 2 варианта:




  • Если приобретен сервис от производителя, то ваш запрос перебрасывается другому сервисному центру и вы получаете все необходимые услуги;

  • В случае с сервисом от продавца вы не получаете ничего и вынуждены обращаться в суд за компенсацией. Вероятность успеха тут каждый оценивает сам, но времени уйдет явно больше оговоренных 4\6\24 часов.



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



Для восстановленного оборудования тоже доступна расширенная поддержка





В силу специфики бизнеса, не можем пройти мимо вопроса поддержки восстановленного оборудования (не путайте с бывшим в употреблении). Дело в том, что в вопросах поддержки вендор рассматривает официально восстановленное оборудование как “практически новое” и позволяет приобрести официальный сервисный контракт в дополнение к стандартному году гарантии.



Тем не менее, покупка восстановленного оборудования обычно означает желание сэкономить, в том числе и на поддержке. Так почему бы продавцу не предложить собственную гарантию? Заодно, можно сделать восстановление более оперативным и добавить пару “козырей”, которых нет в дорогой поддержке от производителя.



Например, нам удалось добиться следующих условий бесплатной гарантии на продаваемое Администратором Сети оборудование:




























Тип сервера Реакция Начало работ

по восстановлению
Время доступности Удаленная диагностика и ремонт Срок гарантии
Новый до 1 часа

(обычно 5-10мин)
24 часа при наличие запчастей, 48 – при их отсутствии 5 дней + 5 лет (3 года от производителя + 2 года собственной)
Восстановленный (refurbished) до 1 часа (обычно 5-10мин) 24 часа при наличие запчастей, 48 – при их отсутствии 5 дней + 3 года собственной


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



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

А так, каждая «железка» проверяется очень внимательно, во избежание»

Все это возможно благодаря:




  1. Отдельному подразделению поддержки, которое не отвлекается на продажи и проектные работы;

  2. Работе только с крупнейшими курьерскими службами, которые могут обеспечить доставку товара в любую точки РФ за 1-3 дня;

  3. Особым условиям заказа комплектующих. Спасибо партнерским отношениям с региональными дистрибьюторами HP, IBM и Dell;

  4. Акценту на качестве поставляемого оборудования и его сервисной поддержке.



Подведем итоги



Базовый набор сервисных контрактов у IBM, HP и Dell в целом совпадает и может включать дополнительные услуги, вроде удаленного проактивного мониторинга.



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



Мы же оформим свои рекомендации и мысли в виде небольшого резюме:




  • При выборе сервисного контракта обращайте самое пристальное внимание на цифры времени реакции и срока восстановления. Первая в большинстве случаев не гарантирует ничего;

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

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

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


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

https://habrahabr.ru/post/308830/

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

Когда разработчику вредно совмещать программирование и техническую поддержку ПО

Четверг, 21 Июля 2016 г. 12:53 (ссылка)



Изображение сайта easywebstudio.ru



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



Так или иначе, перспектива совмещения техподдержки и разработки программного обеспечения радует далеко не всех программистов. Работа специалиста технической поддержки зачастую оказывается серьезным испытанием для нервов разработчика. Более того, такое совмещение часто сказывается на его результативности. Головному мозгу требуется время для переключения с одной деятельности на другую. Для многих программистов это означает несколько потерянных часов, которые тратятся на то, чтобы вернуться из мира людей в мир алгоритмов и кодирования. А неудачное общение с разгневанным пользователем и вовсе может выбить некоторых разработчиков из колеи на весь день.



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



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





Изображение сайта stihi.ru



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



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



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



Руководство допускает такие ситуации, в том числе, потому, что не относится к технической поддержке достаточно серьезно. На территории СНГ распространены две крайности – в поддержке работают люди, которые умеют общаться, но не обладают знаниями в предметной области; в поддержке работают квалифицированные специалисты, которые не умеют правильно выстроить общение с разгневанными пользователями.



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





Изображение сайта alexandrgilenko.com



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



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

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



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



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





Изображение сайта videoforme.ru



Если в качестве инструментов применяются e-mail, специализированные helpdesk системы, чаты и социальные сети, то большинству программисту будет намного легче освоиться. Более того, если и пользователь, и разработчик умеют связно излагать свои мысли в письменном виде, они быстро найдут решение проблемы. Ведь в письменно зафиксированном запросе будут на виду детали, которые могут пригодиться для решение проблемы.



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



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





Изображение сайта journal.ib-bank.ru



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



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



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



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



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



А в каких-то случаях, к технической поддержке лучше привлечь менеджера проектов. Особенно, когда поддержка не «слишком техническая» – такая, где более важны общение и достижение каких-то договоренностей.



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



P.S.



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



А в среднем по больнице, с большим трудом можно найти жалобы (если они вообще есть) на принуждение сотрудников саппорта к программированию.





Изображение сайта joyreactor.cc



P.S.S.



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

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

https://habrahabr.ru/post/306120/

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

VPS сервер

Среда, 29 Июня 2016 г. 12:26 (ссылка)


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



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



       Узнать подробнее о VPS сервере, а также о цене на него можно по ссылке https://dcxv.com/ru/vps.html. Арендовать такой виртуальный сервер можно также и в Европе. Покупайте лучшее за доступную стоимость.

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

Пришел ответ!

Понедельник, 23 Мая 2016 г. 20:02 (ссылка)


 



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

 Добрый день.

 В течение нескольких дней наш сайт подвергался массированной атаке хакеров

 с примерно 20 тысяч адресов. В частности, из-за этой исключительно мощной

 DDoS-атаки, не были доступны дневники на отдельных доменах, а также

 появлялись другие проблемы с доступом. Подробности можно прочитать в

 сообщении руководителя сервиса и комментариях под ним:

 http://www.valez.ru/post391165825/



Ну вот как-то так...

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

Оригинальные шаблоны для ваших сайтов.

Среда, 24 Февраля 2016 г. 20:33 (ссылка)

Иметь свой продвинутый сайт в интернете, значит сказать, что вы имеете хороший бизнес, большое количество постоянных клиентов, которое необходимо увеличивать.
Чтобы сайт сделать привлекательным, достаточно купить landing page шаблоны по доступной цене, с полной технической поддержкой. Стоит один раз попробовать и вы станете постоянным клиентом интернет-магазина шаблонов, для которых оформляется хорошая скидка. Оплата за товар производится полностью (Visa или Mastercard,Yandex.Деньги),
а сам шаблон приходит в виде ссылки на файл, который необходимо скачать. Если у вас возникли вопросы, пишите их в онлайн, в форме обратной связи.
В итоге, вы получаете эффективный инструмент для продвижения бизнеса в сети, за приемлемые цены, и с полной технической поддержкой.

1.
3b9ce85f341aff36501ff99944e6e6d9 (356x276, 140Kb)

2.
7662581544542421f617e23657c693ac (356x276, 104Kb)
bd1ee962f1640d0e3c0ba7e6c7ca5853 (356x276, 131Kb)

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

Интересные находки в интернете на сегодня.

Воскресенье, 31 Января 2016 г. 14:09 (ссылка)

lend-img-ap (700x401, 222Kb)
Пролистав много страниц интернета, я нашла сайт superkopilka.com, на котором можно выгодно преумножить свои сбережения. Здесь работает уникальная система накоплений, благодаря которой вы получаете 50% от системы к своим деньгам, независимо от внешних факторов экономики. Необходимо пройти простую регистрацию и заставить свои деньги работать на мечту. Техническая поддержка гарантирована в любое время суток.

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

timthumb (191x117, 4Kb)

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

Доступный кардшаринг сервер.

Суббота, 23 Января 2016 г. 14:31 (ссылка)

В последнее время я заметила, что наши кабельное телевидение, практически не вещают российских каналов. Это неправильно! Ведь на них можно смотреть уже давно полюбившиеся передачи, концерты, фильмы с популярными актерами. Поэтому я решила подключить кардшаринг от Русское ТВ, который дает возможность смотреть закрытые спутниковые каналы в высоком качестве, по приемлемым ценам. Для его подключения необходимо иметь специальный спутниковый ресивер, доступ в интернет, и антенну, настроенную на нужный спутник. Кстати, чтобы убедиться в эффективности этого сервера, можно пройти бесплатный тест, результатами которого, я удовлетворена на все сто. Техническая поддержка (в любое время суток) и качественное телевидение вам обеспечено.


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

Создание и разработка сайтов.

Пятница, 15 Января 2016 г. 13:25 (ссылка)

Бизнес в интернете растет и развивается, но для того, что бы достичь успешных результатов, необходимо иметь свой продвинутый и интересный сайт. Cоздание сайтов дело рук специалистов студии Design Orbita, которые составляют специальное техническое задание, на основании которого, будут решаться все проблемы сайта ( структура, содержание, интерактивные возможности). Здесь вам гарантирована техническая поддержка и хостинг, в любое время суток.
img-item-1-6 (292x200, 16Kb)

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

Использование Telegram в техподдержке (Или помоги Админу)

Воскресенье, 10 Января 2016 г. 18:51 (ссылка)


Хочу поделиться опытом внедрения Telegram в нашу компанию. Чем занимается компания: мы оказываем услуги технической поддержки высоконагруженных серверов. Всё общение с клиентами ведётся в чатах, для каждого клиента создаётся свой чат и в него добавляются ответственные системные администраторы. Так же есть общий чат для всех системных администраторов и руководителей, в котором обсуждаются текущие задачи и ставятся новые, после чего руководитель создает соответствующие задачи на внутреннем портале.



Без внесения смуты: мы работаем так, кто-то по другому, я лишь делюсь опытом. Раньше использовали Skype, но по разным причинам отказались от него.



Итак, мы склонировали Telegram Desktop версии 0.8.33. Были внесены следующие изменения:


  • Перестали «прыгать» чаты

  • Изменился внешний вид списка диалогов (поместилось на экран больше чатов)

  • Отображается количество непрочитанных чатов, а не количество непрочитанных сообщений

  • Появилась возможность закрепить чат или контакт в верху списка

  • Добавлена кнопка: «Прочитать всё»

  • Добавлена кнопка: «Группировка чатов технической поддержки»

  • Отправленные и полученные сообщения отображаются слева

  • Сообщения от одного пользователя объединились в один блок (как в Skype)





В итоге наш Telegram стал выглядеть так:





Изменения претерпел и поиск: результаты поиска мы группируем по чатам и сортируем по времени (самые ранние сверху):





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





Была добавлена индикация персонального сообщения в чате (символ @ в начале сообщения), которая отображается при условии наличия персонального сообщения среди непрочитанных сообщений. Полезная функция, на мой взгляд, если количество сообщений в чате переваливает за 100500 и не хочется пропустить чего-то важного. Символ рупора — сигнал тревоги в чате (Alarm!) — загорается у всех участников чата, что-то вроде: «Смотреть всем сюда — важно!»

Звёздочка — пометить диалог (аналог избранного). спорная фича, но админы настояли: им нужно и удобно.



Добавлено контекстное меню:


  • Pin\Unpin запинить\ распинеть диалог

  • Mute\Unmute отключить\включить уведомления диалога

  • Alarm! выставить\снять статус диалога «обратить внимание»

  • It’s OK (Dont care) Убрать выделение диалога

  • Mark\Unmark пометить\ снять пометку с диалога





Реализованы две интересны опции в настройках:




  • Не показывать статус набора сообщений

  • Отключить показ превью URL.





К примеру:

Стандартный телеграмм:



Наш телеграмм:





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



Для руководителей были добавлены две функции:



Add All Admin — Добавить в чат администратора.





Add Admin to Chats — Добавить администратора во все чаты технической поддержки





Оба списка отображают всех администраторов (не обязательно, что бы они были в списке контактов), и позволяют добавлять в один или несколько чатов (Add Admin to Chats) ответственных администраторов.



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



Одним из важных нововведений это интеграция с корпоративным порталом, теперь после обсуждения появилась возможность создать задачу (Notes), выделив нужные сообщений в диалоге и щёлкнув на соответствующую кнопку или пункт контекстного меню (Create Note).



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



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



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



На момент написания статьи наш Telegram соответствовал Telegram Desktop 0.9.13.

Читать дальше →

http://habrahabr.ru/post/274777/

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

Следующие 30  »

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

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

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