Техподдержка : Другие вопросы

Что значит "отстоишь"???? я чего в суде что ли? Было - убрали, я должен теперь по каждой маленькой фишке которая есть в СМ_+ писать поощрительные письма в С+ чтобы там знали, что мы этим пользуемся? А бизнес анализ произвел вау-эффект? Это к техподдержке отношения не имеет. И пример про расчет себестоимость я написал лишь в тон твоему сообщению о грандиозности сравнения Microsoft и C+.
А 7-ка закрылась по-моему из-за фишечек XP в 8-ке что-то координально нового я не увидел, может конечно плохо смотрел.
Всё, прекращаю и так уже в оффтоп ушли..

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

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

В корне не согласен. Если у меня была кнопка в акте переоценки и она меня устраивала, то я как клиент ОПЛАТИЛ её присутствие именно в этом документе, и убирать в следующих версиях С+ ДОЛЖЕН её только моего согласия. У меня как у клиента никто согласия не спрашивал.
В версии 1024,5 я мог спокойно в офисе завести пользовательскую операцию по умолчанию для всех мест хранения, потом просто тупо разослать её всем, то в версии 1026,3 я должен ходить ножками или терминалам по всем клиентским машинам во всех магазинах и проставлять эту операцию ДЛЯ КАЖДОГО ДОКУМЕНТА РУЧКАМИ..Нет, ну я понимаю что кто то мог захотеть такого изврата, наверное он даже обоснован кем - то, но МЕНЯ КАК КЛИЕНТА устраивает первый вариант, а Я КАК КЛИЕНТ ЕГО ОПЛАТИЛ. Однако опять же без согласия клиента в последующей версии СМ+ данный функционал убирается, заметь, не ДОБАВЛЯЕТСЯ НОВЫЙ ФУНКЦИОНАЛ, а старый ЗАМЕНЯЕТСЯ новым.
Я еще раз подчеркиваю версия 1024,5 у меня по крайней мере устраивала всех и всем. И переходил я на 1026,3 только из-за заявленной ТЕХПОДДЕРЖКОЙ стабильности работы с Oracle 10g x 64, поддержку получил, а вот остальным функционалом остался жутко недоволен. И в том кто виноват пусть расудит нас Бог, а я не судья, ты тоже.
По поводу работы с менеджером я уже написал реакцию на наше желание изменить расчет себестоимости. Желания дальше убивать время пустыми разговорами нет.

Предлагаю дальше только по техподдержке...

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

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

Сразу поясню, что эти советы/правила больше относятся к саппорту через HelpDesk или e-mails, у телефонной поддержки есть некоторые свои особенности.

1. Быстрая реакция и ответы.

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

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

В этом случае нам поможет одна интересная штука.

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

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

К примеру, клиент А известил нас о проблеме. Инженер Ц приступил к её решению, через 20 часов проблема была решена. Инженер известил клиента об этом. То есть время от репорта проблемы до её решения — 20 часов.

Вторая ситуация: клиент Б известил нас о проблеме. Ему тут же приходит нотификация, что его запрос получен и примерное время реакции — N часов.
Инженер Ц приступил к решению проблемы и написал, что, скорее всего, проблема вызвана вот этим вот и ближайшие результаты будут через два-три часа. Через три часа инженер пишет, что нашел точную причину, но решение займет время и будет готово завтра. Завтра, через 20 часов от исходного репорта, проблема решена.

И в первом и во втором случаях проблема была решена одинаково быстро — за 20 часов. Но во втором случае у клиента останется впечатление, что мы отреагировали и решили проблему быстро.

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

2. Ясное объяснение.

На мой взгляд, ответ/отчет саппортера о решенной проблеме должен отвечать на следующие вопросы:

• чем вызвана проблема?
• что было сделано для решения проблемы? что еще надо сделать?
• решена ли проблема полностью сейчас или нет?
• может ли возникнуть проблема в будущем? если да, как этого избежать? [опционально]

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

Пример.
Клиент пишет: "Мой сайт не работает, ПОМОГИТЕ!"
Инженер отвечает: "Мы решили данную проблему, проверьте пожалуйста ваш сайт."

Это плохой, негодный ответ, несмотря на наличие слова «пожалуйста». Хорошо, что сайт работает, но что же все таки было?

Хороший ответ выглядит примерно так:

«Мы проверили ваш сайт. В файле site/file.php была синтаксическая ошибка, из-за которой всё не работало.
Мы отредактировали этот файл и исправили данную ошибку, в настоящий момент все работает правильно, проверьте пожалуйста: [ example.com ]
Мы не знаем, кем был изменен файл. Дата изменения — ДДММ. Я проверил последние ваши последние запросы, никто из наших инженеров не работал с вашим магазином. Я сохранил файл до моего изменения. Оригинальный и измененный файлы присоединены к моему сообщению. Пожалуйста свяжитесь с Вашим хостингом и проверьте FTP логи, чтобы выяснить, кем было сделано некорректное изменение.»

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

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

3. Никогда не спорьте с клиентом.

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

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

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

Пример из жизни:
Клиент захотел переместиться из одного хостинга в другой. В процессе перемещения сайта, клиент без предупреждения слишком рано изменил DNS сервера своего домена. Как результат — сайт недоступен. Он пишет: "Ах, вы, олухи, у вас отвратительный сервис, у меня всё не работает. Вы все сломали! А-а-а, панике!!".

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

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

4. Давайте решение.

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

Например, сайт не работает из-за ограничений хостинга. Какие могут быть решения?

• можно изменить сайт, приспособив его под ограничения хостинга
• можно сменить хостинг
• можно обратиться к хостингу и попросить убрать ограничения

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

5. Клиент не дурак.

Не считайте клиента идиотом. Одна из проблем IT-индустрии и саппорта в том, что клиента считают существом низшего сорта, потому что он не знает, что такое Perl и PHP, считает, что компьютер это такой телевизор на столе, и зависает на одноклассниках.ру. Да, клиент не разбирается в технических штуках.
Да, он «блондинка», ничего не умеет и бывает, всё ломает. Так радуйтесь же этому!

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

А если считать клиента идиотом, то это всё прекрасно чувствуется. А кому хочется общаться с людьми, которые считают тебя идиотом?

Вы скажете: а как же вредные, странные, неадекватные клиенты, как общаться с ними? Ребята, таких клиентов не бывает. И чем раньше вы в это поверите, тем быстрее ваш саппорт будет клёвым и офигительным.

Cчитайте их просто такими взрослыми детьми. Дети могут не понимать каких-то вещей, капризничать, топать ногами, обижаться. Вы же не обижаетесь всерьёз на детей, ведь так? Так и тут, пожалейте их, успокойте, объясните простыми словами, что желаете им добра. Это действует.
Когда клиент не понимает, что мы хотим сказать, объясняйте как себе, как своей собственной маленькой сестре, которая этого технического языка не понимает, объясняйте образами.

Ну и самое главное: клиентов нужно любить. Они это чувствуют и отвечают тем же: -)

[ ➜ ]

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

Дим, они читают форум :)
И иногда даже отвечают в топиках.

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

Добавил опрос. Опрос скрытый. Те, кто написал менее 20 сообщений голосовать не может.

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

Мне кажется что не хватает оценки
"удовлетворительно"
плохо - это 2
хорошо - 4