Comments 50
Очень удобно и придает уверености моментальный обратный ответ (пусть от робота) с присвоением тикета заявке в саппорт. К томуже у хостера есть контакты суперадмина над всем саппортом которому можно жаловаться - такое описание тылов и с номером заявки наперевес чуствуешь себя уверенно и ожидаешь закономерного ответа. Из практики скажу что терпимым периодом я считаю день, желаемым - от часа до четырех.
Полностью согласен.
От себя добавлю, что приятно, когда у хостера есть большой архив вопросов-ответов, пусть стандартных, но в реалиях этого конкретного хостера, разбитый на разделы идентичные тем, что указываешь при обращении в саппорт.
Еще очень приятно, когда есть возможность чата с саппортом — меня несколько раз это спасало у ValueHost в свое время.
От себя добавлю, что приятно, когда у хостера есть большой архив вопросов-ответов, пусть стандартных, но в реалиях этого конкретного хостера, разбитый на разделы идентичные тем, что указываешь при обращении в саппорт.
Еще очень приятно, когда есть возможность чата с саппортом — меня несколько раз это спасало у ValueHost в свое время.
проще говоря, у сервиса должен быть FAQ (ЧаВо) ...
да, полностью согласен ...
но и клиент нынче не всегда использует такие ресурсы.
все-таки несколько изменилось мышление и восприятие - легче позвонить/написать и получить конкретный ответ, чем рыть ФАКи ...
это старое поколение компьютерщиков/интернетчиков и те, кто в теме наличия ФАКа по мере деятельности, привыкли до всего доходить собственными силами ...
нынче смещение в пользовательскую сторону более ощутимо ...
хостинг стал массовой услугой.
чат (live chat) с саппортом штука полезная - я тоже этим пользовался ...
особенно актуально, когда общаешься с западными хостерами, а язык скажем английский ... :)
да, полностью согласен ...
но и клиент нынче не всегда использует такие ресурсы.
все-таки несколько изменилось мышление и восприятие - легче позвонить/написать и получить конкретный ответ, чем рыть ФАКи ...
это старое поколение компьютерщиков/интернетчиков и те, кто в теме наличия ФАКа по мере деятельности, привыкли до всего доходить собственными силами ...
нынче смещение в пользовательскую сторону более ощутимо ...
хостинг стал массовой услугой.
чат (live chat) с саппортом штука полезная - я тоже этим пользовался ...
особенно актуально, когда общаешься с западными хостерами, а язык скажем английский ... :)
FAQ: Я сам, к примеру, всегда сначала пишу в саппорт, и только потом лезу в FAQ, если он, опять же, нормально организован (структурирован). Просто, чтобы запрос ушел раньше, на случай, если решения в FAQ не найдется..
Live-chat: Передо мной, к примеру, не стоит проблемы языка, английский я знаю, а человек, который не знает, вряд ли пойдет к западному хостеру.. :)
Live-chat: Передо мной, к примеру, не стоит проблемы языка, английский я знаю, а человек, который не знает, вряд ли пойдет к западному хостеру.. :)
по поводу робота я сталкивался с мнением клиентов, что это не есть хорошо ...
правда высока вероятность, что клиент был недоволен множественными ответами робота ...
но в любом случае, ответ робота не есть объективная информация о том, что проблемой клиента занимаются ...
имхо, я бы это не использовал
правда высока вероятность, что клиент был недоволен множественными ответами робота ...
но в любом случае, ответ робота не есть объективная информация о том, что проблемой клиента занимаются ...
имхо, я бы это не использовал
про это написал отличную статью Джоэль Спольски
http://www.joelonsoftware.com/articles/c…
http://www.joelonsoftware.com/articles/c…
Я как представитель сервисов, не могу понять что вы хотите узнать. Аудитории разные бывают, и разного уровня проблемы.
я не хочу ничего "узнавать" ... :)
мне важно понимание правильности моего мнения о процессе организации службы поддержки клиента.
про аудитории абсолютно справедливо ...
однако эти группы пользователей и обращаются с разными вопросами - отсюда и дифференцирование тем, по которым может работать саппорт.
Кто поопытнее, сначала сходит в ФАК. Если же он чётко знает, в чём проблема, то вполне резонно обращается к саппортам, а те уже переадресовывают к специалистам.
Кто менее искушен в тонкостях тех же настроек, просто сообщает "у меня не работает" - порой даже не может объяснить, что не работает. И вот это звездный час саппорта ...
В любом случае, иерархия необходима.
мне важно понимание правильности моего мнения о процессе организации службы поддержки клиента.
про аудитории абсолютно справедливо ...
однако эти группы пользователей и обращаются с разными вопросами - отсюда и дифференцирование тем, по которым может работать саппорт.
Кто поопытнее, сначала сходит в ФАК. Если же он чётко знает, в чём проблема, то вполне резонно обращается к саппортам, а те уже переадресовывают к специалистам.
Кто менее искушен в тонкостях тех же настроек, просто сообщает "у меня не работает" - порой даже не может объяснить, что не работает. И вот это звездный час саппорта ...
В любом случае, иерархия необходима.
На самом-то деле, с точки зрения человека, который разбирается в технологиях, предоставляемых хостером, хочется отсутствия "общения" с саппортом, который только и может переправить звонок другому "специалисту".
Откровенно бесит общаться сначала с одной секретаршей, потом со старшей секретаршей и т.д.
Ну а по теме — чем быстрее решат твою проблему, тем лучше, и еще если покажут "динамику" решения проблемы — еще лучше. В смысле присвоение тикета или еще что-то.
Ну и не забывайте про большой FAQ, хоть многие не любят его читать, но мне проще например потратить время на чтение документаци, чем на общение с саппортом.
Откровенно бесит общаться сначала с одной секретаршей, потом со старшей секретаршей и т.д.
Ну а по теме — чем быстрее решат твою проблему, тем лучше, и еще если покажут "динамику" решения проблемы — еще лучше. В смысле присвоение тикета или еще что-то.
Ну и не забывайте про большой FAQ, хоть многие не любят его читать, но мне проще например потратить время на чтение документаци, чем на общение с саппортом.
Ну не реальна такая поддержка на массовом хостинге, по телефону.
реальна ...
возможно, моё мнение идеалистично, но такая техподдержка реальна ...
у меня такая поддержка на канадском хосте.
возможно, моё мнение идеалистично, но такая техподдержка реальна ...
у меня такая поддержка на канадском хосте.
Огласите, пожалуйста, расценки на хостинг/саппорт на этом хостинге
это не массовый хостинг я так понимаю.
не хочу рекламить этого провайдера, т. к. он буржуйский ...
но у меня там дедик стоит.
но у меня там дедик стоит.
Ну отвечать владельцам дедиков это одно, а клиентам которые в год платят 20 у.е. за хостиг это другое совсем.
с одной стороны, справедливое замечание ...
однако клиент (любой) активизируется только тогда, кода появляются грабли - разница только в серьёзности проблемы ...
но это для нас (специалистов) проблема может быть серьёзной и не очень, т. к. мы дифференцируем её по своим понятиям ...
для клиента же любая проблема серьёзна - и тогда уже провайдер услуги становится либо плохим, о чём непременно нужно оповестить весь мир, либо хорошим, о чём можно и умолчать ... ;-)
а вот "плохость" или "хорошесть" по мнению клиента - это в итоге адекватность работы службы поддержки клиента, которая сработает либо на его удовольствие, либо на недовольство ...
однако клиент (любой) активизируется только тогда, кода появляются грабли - разница только в серьёзности проблемы ...
но это для нас (специалистов) проблема может быть серьёзной и не очень, т. к. мы дифференцируем её по своим понятиям ...
для клиента же любая проблема серьёзна - и тогда уже провайдер услуги становится либо плохим, о чём непременно нужно оповестить весь мир, либо хорошим, о чём можно и умолчать ... ;-)
а вот "плохость" или "хорошесть" по мнению клиента - это в итоге адекватность работы службы поддержки клиента, которая сработает либо на его удовольствие, либо на недовольство ...
У РБК поддержка по телефону есть. Правда различные саппорты говорят различные вещи, но одинаково вежливо. Качество страдает, но сам факт организации такой поддержки имеет место быть.
Ничто так сильно не раздражает у некоторых (навязанных) хостеров, как отсутсвие связи в реальном времени. Например, когда есть только форма обратной связи и все. Техподдержка должна обязательно оказываться по телефону или аське круглосуточно. В крайнем случае представитель службы поддержки должен сообщить, через какое время сможет заняться решением проблемы (всякое бывает).
Сразу давать решение или нет, рассказывать о ходе решения - это в зависимости от величины проблемы. Конечно, хорошо бы знать подробности.
Человеческий подход уместен, бывают разные уровни клиентов. Если человека заинтересуют технические подробности, его всегда можно свести со специалистов (но не более одной секретарши посередине )) )
Сразу давать решение или нет, рассказывать о ходе решения - это в зависимости от величины проблемы. Конечно, хорошо бы знать подробности.
Человеческий подход уместен, бывают разные уровни клиентов. Если человека заинтересуют технические подробности, его всегда можно свести со специалистов (но не более одной секретарши посередине )) )
спасибо за хороший комментарий ... :)
я вообще склонен к тому, что соединение клиента с техподдержкой по телефону должно миновать всяческих секретарей ...
конечно не каждый может себе позволить иметь специализированный call-центр, но выделить отдельный телефон можно - не так уж это сегодня дорого ...
сразу дать решение можно, если вопрос ординарный.
но как-раз по таким вопросам и создаются ФАКи.
если же вопрос технически сложный, а клиент пишет саппорту в мыло, то я считаю, саппорт должен ответить сразу (максимум 30 минут, ну час ... ок) - это скажет клиенту о том, что с его проблемой ознакомились и принимают меры ...
я вообще склонен к тому, что соединение клиента с техподдержкой по телефону должно миновать всяческих секретарей ...
конечно не каждый может себе позволить иметь специализированный call-центр, но выделить отдельный телефон можно - не так уж это сегодня дорого ...
сразу дать решение можно, если вопрос ординарный.
но как-раз по таким вопросам и создаются ФАКи.
если же вопрос технически сложный, а клиент пишет саппорту в мыло, то я считаю, саппорт должен ответить сразу (максимум 30 минут, ну час ... ок) - это скажет клиенту о том, что с его проблемой ознакомились и принимают меры ...
UFO just landed and posted this here
Переобщался со множеством хостеров (имеется в виду только аренда дедиков) и для себя решил, что:
1) простые заявки (типа ребут сервера) должны обрабатываться за 10-15 минут
2) заявки должны подаваться через тикет-систему (никаких асек). для оперативного решения вопросов - телефон
3) стиль общения должен быть формальный, это позволяет избежать множества недоразумений
4) конечно же, при длительных операциях необходимо сообщать прогресс работы
Как это ни странно, но даже знаю в России пару хостеров, которые соответствуют таким требованиям.
1) простые заявки (типа ребут сервера) должны обрабатываться за 10-15 минут
2) заявки должны подаваться через тикет-систему (никаких асек). для оперативного решения вопросов - телефон
3) стиль общения должен быть формальный, это позволяет избежать множества недоразумений
4) конечно же, при длительных операциях необходимо сообщать прогресс работы
Как это ни странно, но даже знаю в России пару хостеров, которые соответствуют таким требованиям.
Я работаю в сапорте буржуйской компании. От нас всегда требуются немедленного оповещения клиента о том, что его проблема рассматривается, и информирования клиента о ходе работ по устранению неисправностей. Наименьшее промедление грозит выговором.
Общение по телефону присходит в крайних случаях, все общение идет через тикетную систему.
Для буржуев клиент всегда на первом месте и игнорирование его просьб, даже тупых, недопустимо.
Общение по телефону присходит в крайних случаях, все общение идет через тикетную систему.
Для буржуев клиент всегда на первом месте и игнорирование его просьб, даже тупых, недопустимо.
вооот ...
вот оно тута то, которого я так хотел услышать-то ... :)
правда не всё понятно - про телефон вот, почему только в крайних случаях?
хотя логику проследить могу - телефон, как крайняя мера, используется в том случае, когда идеально работает система тикетов ... ;-)
т. е у клиента даже не возникает желание позвонить ...
тут никаких возражений ...
поздравляю ...
вот оно тута то, которого я так хотел услышать-то ... :)
правда не всё понятно - про телефон вот, почему только в крайних случаях?
хотя логику проследить могу - телефон, как крайняя мера, используется в том случае, когда идеально работает система тикетов ... ;-)
т. е у клиента даже не возникает желание позвонить ...
тут никаких возражений ...
поздравляю ...
Телефон крайний случай потому что
1) не все инженеры саппорта владеют разговорным буржуйским, но отлично могут читать/писать.
2) в случае претензий у вас всегда есть задокументированная в тикетах информация, в отличии от разговора по телефону который нигде никак не фиксируется.
3) тикеты как инструмент контроля за компанией, босс всегда может почитать, что отвечалось клиенту, как провелась та или иная работа.
1) не все инженеры саппорта владеют разговорным буржуйским, но отлично могут читать/писать.
2) в случае претензий у вас всегда есть задокументированная в тикетах информация, в отличии от разговора по телефону который нигде никак не фиксируется.
3) тикеты как инструмент контроля за компанией, босс всегда может почитать, что отвечалось клиенту, как провелась та или иная работа.
Хостер должен отвечать на телефонный звонок быстро, уверенно и бодро. В любое время суток, фазы луны и прилива\отлива. За простой вменяемый человеческий голос на том конце провода в 5 утра 1 января я люблю своего провайдера. :)
Существует класс проблем над которыми работа не требуется, а пользователю просто нужно оказать консультацию, это должно мгновенно решаться в любое время суток.
Общий случай при поступлении заявки (телефонной/асечной или еще какой-нибудь) заявка регистрируется в обязательном порядке в каком-нибудь журнале и пользователю просто необходимо сообщить о том что над проблемой работают и она будет устранена к такому-то приемлимому для пользователя времени (через 15 минут, завтра, через месяц). В любом случае ответ должен быть получен максимально быстро, иначе у пользователя складывается плохое впечатление о support-е компании. Информировать пользователя о ходе работ не вижу особой необходимости, незачем ему знать всю кухню, главно чтоб указанные сроки соблюдались.
Общий случай при поступлении заявки (телефонной/асечной или еще какой-нибудь) заявка регистрируется в обязательном порядке в каком-нибудь журнале и пользователю просто необходимо сообщить о том что над проблемой работают и она будет устранена к такому-то приемлимому для пользователя времени (через 15 минут, завтра, через месяц). В любом случае ответ должен быть получен максимально быстро, иначе у пользователя складывается плохое впечатление о support-е компании. Информировать пользователя о ходе работ не вижу особой необходимости, незачем ему знать всю кухню, главно чтоб указанные сроки соблюдались.
Вообще-то наиболее подробно ответ на Ваш вопрос изложен в ITIL, если конкретно - в книге Incident Management. Очень советую Вам и прочитать книги, и, при возможности, посетить курсы.
По Вашим вопросам:
Сколько времени может ждать клиент до того момента, как представитель службы поддержки ответит ему?
+++ Вообще-то этот на вопрос нельзя ответить, не вводя такое понятие, как SLA (Service Level Agreement) и не оговорив этот параметр в явном виде (в числе прочих, разумеется). Даже если под ответом Вы понимаете снятие трубки и приветствие, это все равно _измеряемый_ параметр, а потому - прописываемый. Очевидно, что клиент может получить _любой_ уровень сервиса, вопрос лишь, готов ли он за это заплатить. Если человек хочет, чтоб его звонок _гарантированно_ принимался в течение 30 секунд, он должен оплатить _достаточное_ количество операторов на саппорте. Не готов платить - пусть слушает длинные гудки. Такова судьба бедноты.
Что должен ответить саппорт?
+++ Задача первой линии саппорта - в установленном порядке зарегистрировать обращение клиента. По возможности - разрешить проблему (допустим, рассказть, где эникей или выдать документированное решение, входящее в рамки компетенций сотрудника саппорта). Далеко не всегда первая линия, т.е. оператор должен и может решить проблему самостоятельно - например, если у человека кончилась дисковая квота, оператор саппорта не должен ее тут же человеку увеличивать, хотя это и решит проблему клиента.
Сразу дать решение проблемы клиента?
+++ Нет, конечно. Это частный случай процесса. Оператор принимает и регистрирует обращение, при возможности - решает, при невозможности решить - отправляет на второй уровень, тем специалистам, которые в теме (или авторизованы)
А если нет, то должен ли он докладывать клиенту о ходе решения его проблемы.
+++ Если это оговорено в SLA - да. Если нет - незачем. Время оператора тоже стоит денег. Если он начнет звонить и информировать клиента, он не сможет в это время принимать другие звонки, что увеличит время ожидания.
Или сначала достаточно дать понять клиенту, что проблема его решается.
+++ Клинету выдается номер тикета и сообщается крайний срок, когда его проблема будет решена в соответствии с его SLA. Зачем сообщать клиенту, что его проблема решается? Это естественный ход событий, Вы же не планируете сообщать клиенту, что Волга, как и вчера, все еще впадает в Каспийское море?
Уместен ли в таких случаях человеческий подход, или достаточно сухого технического языка, а то и формального обращения?
+++ Достаточно просто корректного обращения. Большего от Вас никто не требует.
По Вашим вопросам:
Сколько времени может ждать клиент до того момента, как представитель службы поддержки ответит ему?
+++ Вообще-то этот на вопрос нельзя ответить, не вводя такое понятие, как SLA (Service Level Agreement) и не оговорив этот параметр в явном виде (в числе прочих, разумеется). Даже если под ответом Вы понимаете снятие трубки и приветствие, это все равно _измеряемый_ параметр, а потому - прописываемый. Очевидно, что клиент может получить _любой_ уровень сервиса, вопрос лишь, готов ли он за это заплатить. Если человек хочет, чтоб его звонок _гарантированно_ принимался в течение 30 секунд, он должен оплатить _достаточное_ количество операторов на саппорте. Не готов платить - пусть слушает длинные гудки. Такова судьба бедноты.
Что должен ответить саппорт?
+++ Задача первой линии саппорта - в установленном порядке зарегистрировать обращение клиента. По возможности - разрешить проблему (допустим, рассказть, где эникей или выдать документированное решение, входящее в рамки компетенций сотрудника саппорта). Далеко не всегда первая линия, т.е. оператор должен и может решить проблему самостоятельно - например, если у человека кончилась дисковая квота, оператор саппорта не должен ее тут же человеку увеличивать, хотя это и решит проблему клиента.
Сразу дать решение проблемы клиента?
+++ Нет, конечно. Это частный случай процесса. Оператор принимает и регистрирует обращение, при возможности - решает, при невозможности решить - отправляет на второй уровень, тем специалистам, которые в теме (или авторизованы)
А если нет, то должен ли он докладывать клиенту о ходе решения его проблемы.
+++ Если это оговорено в SLA - да. Если нет - незачем. Время оператора тоже стоит денег. Если он начнет звонить и информировать клиента, он не сможет в это время принимать другие звонки, что увеличит время ожидания.
Или сначала достаточно дать понять клиенту, что проблема его решается.
+++ Клинету выдается номер тикета и сообщается крайний срок, когда его проблема будет решена в соответствии с его SLA. Зачем сообщать клиенту, что его проблема решается? Это естественный ход событий, Вы же не планируете сообщать клиенту, что Волга, как и вчера, все еще впадает в Каспийское море?
Уместен ли в таких случаях человеческий подход, или достаточно сухого технического языка, а то и формального обращения?
+++ Достаточно просто корректного обращения. Большего от Вас никто не требует.
потрясающе ...
но кроме call-центра существует ещё и email.
как в таком случае следует поступать?
с регистрацией обращения и присвоением номера тикета понятно ... а дальше?
но кроме call-центра существует ещё и email.
как в таком случае следует поступать?
с регистрацией обращения и присвоением номера тикета понятно ... а дальше?
и насколько скажем есть смысл нагружать сотрудника техподдержки одновременно и звонками и почтой?
Никакой разницы нет. Хелпдеск должен принимать обращения клиентов всеми ранее оговоренными способами: будь то телефонный звонок, заполненная веб-форма, е-мейл, факс, автоответчик, личное обращение в окно саппорта и все остальное, что еще подскажет фантазия...
В самой любимой программе всех внедренцев хелпдеска HP OpenView Servicedesk просто напросто введено специальное поле: media, куда оператор может ввести, каким путем к нему попала заявка.
Вот, собственно и все - дальше же совершенно неважно, как пришла заявка - ее обязаны отработать в оговоренные в SLA сроки и выдать клиенту решение его проблемы.
Еще различие между телефонным звонком и например почтой - иногда владелец хелпдеска может требовать от операторов, чтобы клиента информировали тем же способом, каким клиент обратился (т.е. прислал клиент факс - ответь факсом, обратился по почте - ответь почтой), но это, скажем так, конкретика реализации.
В принципе же, вся контактная информация о клиенте заранее известна оператору (он же наш клиент, мы о нем вводим все, что знаем, в клиентскую БД), поэтому наиболее разумной политикой будет вернуть клиенту ответ тем же путем, что он направил запрос (на факс - факсом), после чего при необходимости связаться по ранее указанному телефону телефону для уточнения деталей.
В самой любимой программе всех внедренцев хелпдеска HP OpenView Servicedesk просто напросто введено специальное поле: media, куда оператор может ввести, каким путем к нему попала заявка.
Вот, собственно и все - дальше же совершенно неважно, как пришла заявка - ее обязаны отработать в оговоренные в SLA сроки и выдать клиенту решение его проблемы.
Еще различие между телефонным звонком и например почтой - иногда владелец хелпдеска может требовать от операторов, чтобы клиента информировали тем же способом, каким клиент обратился (т.е. прислал клиент факс - ответь факсом, обратился по почте - ответь почтой), но это, скажем так, конкретика реализации.
В принципе же, вся контактная информация о клиенте заранее известна оператору (он же наш клиент, мы о нем вводим все, что знаем, в клиентскую БД), поэтому наиболее разумной политикой будет вернуть клиенту ответ тем же путем, что он направил запрос (на факс - факсом), после чего при необходимости связаться по ранее указанному телефону телефону для уточнения деталей.
Нужно смотреть обобщенно. Главная задача создать у клиента правдивое впечатление, что он ВСЕГДА МОЖЕТ ПОЛУЧИТЬ ПОМОЩЬ, по ЛЮБОМУ ВОПРОСУ. А как этого достичь задача для каждого отдельного случая. Обычно хватает немного подумать головой.
Кстати, никак не пойму товарищей, которые пишут о полезности автоответчика. Автоответчик ничего не подтверждает, кроме того, что КЛИЕНТ ОТПРАВИЛ ПИСЬМО.
Автоответчик немножко соображающих людей должен бесить.
Кстати, никак не пойму товарищей, которые пишут о полезности автоответчика. Автоответчик ничего не подтверждает, кроме того, что КЛИЕНТ ОТПРАВИЛ ПИСЬМО.
Автоответчик немножко соображающих людей должен бесить.
про "впечатление" согласен частично, т. к. в перспективе одним впечатлением не отделаешься ...
про автоответчик могу сказать, что сам факт присвоения номера заявке клиента может его на какое-то время успокоить - создать "впечатление", что всё под контролем ...
а вот дальше уже дело за специалистами - поставленную задачу по любому надо решать ...
про автоответчик могу сказать, что сам факт присвоения номера заявке клиента может его на какое-то время успокоить - создать "впечатление", что всё под контролем ...
а вот дальше уже дело за специалистами - поставленную задачу по любому надо решать ...
Я пишу про ПРАВДИВОЕ ВПЕЧАТЛЕНИЕ. Ок, лучше было сказать создать чувство.
"присвоения номера заявке" извините, но это бессмыссленный непонятный бред. Гораздо лучше, например, когда отправляешь письмо через форму на сайте, а после отправления выводится: "Спасибо, что обратились за помощью. Мы ответим через 4 часа." Это по-человечески.
А вот один знакомый вообще молодец. У них, если клиенту не ответят в течение суток, клиент получает 1 месяц хостинга на халяву. Так что, если и не ответят вовремя, клиенты не парятся, а только радуются.
А вообще, все эти разговоры возникают отчасти из за того, что кто-то работать не умеет, или не хочет. Сидят лентяи, и придумывают, как бы вывернуться. Если бы вовремя отвечали на вопросы, не было бы никаких проблем.
"присвоения номера заявке" извините, но это бессмыссленный непонятный бред. Гораздо лучше, например, когда отправляешь письмо через форму на сайте, а после отправления выводится: "Спасибо, что обратились за помощью. Мы ответим через 4 часа." Это по-человечески.
А вот один знакомый вообще молодец. У них, если клиенту не ответят в течение суток, клиент получает 1 месяц хостинга на халяву. Так что, если и не ответят вовремя, клиенты не парятся, а только радуются.
А вообще, все эти разговоры возникают отчасти из за того, что кто-то работать не умеет, или не хочет. Сидят лентяи, и придумывают, как бы вывернуться. Если бы вовремя отвечали на вопросы, не было бы никаких проблем.
Присвоение номера заявке есть реальность, данная нам в ощущениях. Сомневающихся просим рассказать, как они будут решать следующую ситуацию:
Утром звонит клиент и сообщает о своей проблеме. Оператор хелпдеска не обладает достаточной компетенцией для решения проблемы (ну, например, требуются специфические знания специалиста по оборудованию nortel networks). Означенный специалист в компании есть, но: 1) его рабочий день начнется через час и 2) на первые три часа нам уже есть его чем загрузить.
Забегая вперед, скажем, что после того, как на nortel-овской железке поправят настройки, потребуется работа человека, отвечающего за freebsd-сервер, на котором крутится, ну, предположим, биллинг. Например, надо будет сказать серверу, чтоб учитывал (или, наоборот, перестал учитывать) некий специфический трафик, идущий с клиентского хоста.
Если есть желание, я могу набросать workflow еще на пять-десять специалистов.
Замечу, что они друг друга вправе не знать, работать в разных странах и говорить на разных языках.
Клиент при этом периодически позванивает на хелпдеск и интересуется, а что происходит по его проблеме. Трубку всякий раз берут разные операторы.
Да, чуть не забыл: у этого клиента есть еще четыре других проблемы, по ним он тоже обращался, и тоже хочет знать, что происходит.
И еще: всего клиентов, ну скажем, тысяч пятнадцать. В день приходит не менее 500 сервисных вызовов на, предположим, 24 операторов, работающих посменно.
Внимание, вопрос: как построить процесс работы по заявке, отказавшись от присвоения ей уникального номера?
Как передавать информацию специалистам узкого профиля о том, что уже было сделано по заявке клиента и что требуется именно от этого специалиста?
Как отследить крайний срок выполнения заявки?
Заранее спасибо Вам за ответы. Я уже года два занимаюсь внедрением процессов техподдержки, всякий опыт мне интересен.
Утром звонит клиент и сообщает о своей проблеме. Оператор хелпдеска не обладает достаточной компетенцией для решения проблемы (ну, например, требуются специфические знания специалиста по оборудованию nortel networks). Означенный специалист в компании есть, но: 1) его рабочий день начнется через час и 2) на первые три часа нам уже есть его чем загрузить.
Забегая вперед, скажем, что после того, как на nortel-овской железке поправят настройки, потребуется работа человека, отвечающего за freebsd-сервер, на котором крутится, ну, предположим, биллинг. Например, надо будет сказать серверу, чтоб учитывал (или, наоборот, перестал учитывать) некий специфический трафик, идущий с клиентского хоста.
Если есть желание, я могу набросать workflow еще на пять-десять специалистов.
Замечу, что они друг друга вправе не знать, работать в разных странах и говорить на разных языках.
Клиент при этом периодически позванивает на хелпдеск и интересуется, а что происходит по его проблеме. Трубку всякий раз берут разные операторы.
Да, чуть не забыл: у этого клиента есть еще четыре других проблемы, по ним он тоже обращался, и тоже хочет знать, что происходит.
И еще: всего клиентов, ну скажем, тысяч пятнадцать. В день приходит не менее 500 сервисных вызовов на, предположим, 24 операторов, работающих посменно.
Внимание, вопрос: как построить процесс работы по заявке, отказавшись от присвоения ей уникального номера?
Как передавать информацию специалистам узкого профиля о том, что уже было сделано по заявке клиента и что требуется именно от этого специалиста?
Как отследить крайний срок выполнения заявки?
Заранее спасибо Вам за ответы. Я уже года два занимаюсь внедрением процессов техподдержки, всякий опыт мне интересен.
Еще раз про автоответчик. Представьте, что за вами ходит гном. Когда вы что-то делаете, он говорит "Информирую, что я осведомлен о том, что ты пошел в туалет", "Информирую, что мне известно о том, что ты поставил кипятить чайник".
Нормальный человек вскипятит этого гнома в чайнике, а потом смоет в унитазе.
Нормальный человек вскипятит этого гнома в чайнике, а потом смоет в унитазе.
Стилистика ответа, значит очень много.
По своей практике знаю, что конфликты сходят на нет, при определенном подходе к написанию ответов.
Ужас охватывает меня каждый раз когда я лезу в переписку саппорта и клиентов, ничего более страшного представить нельзя :)
Наверняка какие-то компании пишут четкие должностные инструкции, по поводу того как должен отвечать саппорт, но не знаю как у нас.
И еще есть момент, нагрузка на персонал, вызывает подсознательную желание отвечать так, что бы у клиента не возникало желания болше общаться.
По своей практике знаю, что конфликты сходят на нет, при определенном подходе к написанию ответов.
Ужас охватывает меня каждый раз когда я лезу в переписку саппорта и клиентов, ничего более страшного представить нельзя :)
Наверняка какие-то компании пишут четкие должностные инструкции, по поводу того как должен отвечать саппорт, но не знаю как у нас.
И еще есть момент, нагрузка на персонал, вызывает подсознательную желание отвечать так, что бы у клиента не возникало желания болше общаться.
Sign up to leave a comment.
Поговори со мной,… support…