Comments 18
Мне кажется, вы изобретаете велосипед :)
Всем ожиданиям полностью удовлетворит Kayako — при грамотной настройке, буквально за пару дней, позволяет все то, что описано и даже гораздо больше. К каяке легко прикрутить тот же твиттер.
Очень рекомендую попробовать, это тот инструмент, который даст клиенту почувствовать индивидуальный подход даже в масштабе нескольких сотен клиентов.
С точки зрения разбития на 3 левела — на сколько это оправдано? Как определяете переходы сотрудников из уровня в уровень, не возникает проблем? Я со временем пришел к выводу, что лучше минимизировать такие разбивки до 2-х уровней — собственно хелпдеск и люди, решающие вопросы. Так проще построить структуру и знаешь, что от кого ожидать.
А что для gotomeeting используете? Нативное решение от cisco, или нашли что-то более удобное?
Всем ожиданиям полностью удовлетворит Kayako — при грамотной настройке, буквально за пару дней, позволяет все то, что описано и даже гораздо больше. К каяке легко прикрутить тот же твиттер.
Очень рекомендую попробовать, это тот инструмент, который даст клиенту почувствовать индивидуальный подход даже в масштабе нескольких сотен клиентов.
С точки зрения разбития на 3 левела — на сколько это оправдано? Как определяете переходы сотрудников из уровня в уровень, не возникает проблем? Я со временем пришел к выводу, что лучше минимизировать такие разбивки до 2-х уровней — собственно хелпдеск и люди, решающие вопросы. Так проще построить структуру и знаешь, что от кого ожидать.
А что для gotomeeting используете? Нативное решение от cisco, или нашли что-то более удобное?
Я как раз недавно триалил Kayako — не понравилось, что клиент не может переслать файл через чат ( для тех. саппорта нам это важно), а при отправке логов в виде текстового сообщения теряет line breaks.
Буду признателен, если кто посоветут чат, в котором это можно делать нормально.
К тому же мы eat our own dogfood — используем то, что сами производим ( для саппорта у нас есть отдельная часть приложения, не самая мощная на мой взгляд). Это помогает нам сделать продукт лучше.
Что до левелов — мы как раз тоже не разбиваем. Т.е. стараемся использовать savvy support, но некоторые проблемы требуют привлечения девелоперов ( например, неизведанный ранее баг).
Используем тул который так и называется «GoToMeeting». Есть вопросы по скорости, думаем перейти на TeamViewer.
Буду признателен, если кто посоветут чат, в котором это можно делать нормально.
К тому же мы eat our own dogfood — используем то, что сами производим ( для саппорта у нас есть отдельная часть приложения, не самая мощная на мой взгляд). Это помогает нам сделать продукт лучше.
Что до левелов — мы как раз тоже не разбиваем. Т.е. стараемся использовать savvy support, но некоторые проблемы требуют привлечения девелоперов ( например, неизведанный ранее баг).
Используем тул который так и называется «GoToMeeting». Есть вопросы по скорости, думаем перейти на TeamViewer.
Основная идея как раз в том, что общение через чат лучше минимизировать по многим причинам:
1. В чате требуется ответ как можно быстрее, в тикете есть возможность подумать и построить структурированный ответ.
2. Если вам присылают файл или логи, то их необходимо анализировать, это опять же занимает время. Лучше попросить клиента прислать на емейл.
3. Когда клиент пишет в тикетную, я сразу вижу, какие у клиента могут быть вопросы, исходя из примечаний.
В общем, в идеале — приучать клиентов писать на емейл. Другой вопрос — как это делать. У меня накопилось достаточное количество аргументов и всяких шаблонных фраз для этой цели, когда-нибудь напишу статью.
Лайв-чат имеет смысл, но он имеет смысл для первого уровня поддержки и сейлсов.
1. В чате требуется ответ как можно быстрее, в тикете есть возможность подумать и построить структурированный ответ.
2. Если вам присылают файл или логи, то их необходимо анализировать, это опять же занимает время. Лучше попросить клиента прислать на емейл.
3. Когда клиент пишет в тикетную, я сразу вижу, какие у клиента могут быть вопросы, исходя из примечаний.
В общем, в идеале — приучать клиентов писать на емейл. Другой вопрос — как это делать. У меня накопилось достаточное количество аргументов и всяких шаблонных фраз для этой цели, когда-нибудь напишу статью.
Лайв-чат имеет смысл, но он имеет смысл для первого уровня поддержки и сейлсов.
Мне кажется, что общаться через емэйл – комфортней вашей команде. Для клиента гораздо удобней общаться через лайф чат или голосом через gotomeeting. Людям не нужен структурированный ответ, им нужно, что бы им как можно быстрее решили их проблему.
Какая у вас кстати средняя скорость реакции на емэйл?
Ну и ждём статьи конечно :) На хабре про тех. поддержку очень мало историй.
Какая у вас кстати средняя скорость реакции на емэйл?
Ну и ждём статьи конечно :) На хабре про тех. поддержку очень мало историй.
Я просто слабо представляю, с чем обращаются к вам клиенты. Насколько я понимаю, есть две категории обращений, первая: обращения уровня «у меня не работает такая-то фича, надо доработать» — тогда и команде и клиенту удобнее по емейл. Вторая — вопрос по функционалу, уровня «как сделать то-то» — то да, через лайв-чат или голосом.
Средняя скорость ответа на емейл очень относительна <шутка про температуру в больнице>. Есть экстренные запросы, когда ничего не работает, на такие письма реакция через несколько минут, но чаще всего, в таких случаях звонят по телефону.
Если запрос не срочный, то в течении часа отвечаем клиенту, что мы им занимаемся и нам требуется примерно столько-то времени.
Средняя скорость ответа на емейл очень относительна <шутка про температуру в больнице>. Есть экстренные запросы, когда ничего не работает, на такие письма реакция через несколько минут, но чаще всего, в таких случаях звонят по телефону.
Если запрос не срочный, то в течении часа отвечаем клиенту, что мы им занимаемся и нам требуется примерно столько-то времени.
По доработке продукта вообще много вариантов, например, можно создать отдельную категорию для всяких юзкейсов, в которую будут попадать заявки после обработки сапортом, это упростит работу PO.
Согласен, про доработку продукта — вообще отдельная тема. Сами много чего используем и влияем на продукт путем решения клиентских проблем. Но к клиентским «хотелкам» относимся как к «идеям» — т.е. благодарим, но ничего не обещаем.
Какой примерно у вас процент от таких обращений уходит в юзкейсы и передается разработке?
довольно небольшой. Т.е. большинство из них хорошие идеи, которые неплохо бы реализовать, но реализовать и закинуть в бэклог — это не совем одно и то же.
Был у нас период, когда делали в основном то, что просили кастомеры, но поняли, что лучший тул так не сделать. У нас своих идей больше, чес успеваем сделать.
Был у нас период, когда делали в основном то, что просили кастомеры, но поняли, что лучший тул так не сделать. У нас своих идей больше, чес успеваем сделать.
Вот есть у вашей компании небелорусская черта. Вы умеете рассказывать о себе интересно и понятно. :) Молодцы!
Спасибо вам за инструмент. Уже все перетащили к вам, правда так и не решили проблему с клиентами — на каждого покупать аккаунт не круто, графики они смотреть хотят, а у нас заказная разработка по agile — то есть много новых клиентов в месяц, и они должны наблюдать за процессом.
Много раз просил о бесплатном реад-онли доступу для клиентов — как появиться, будет очень круто. Ну а пока, будем думать, как через API вытягивать данные =)
Много раз просил о бесплатном реад-онли доступу для клиентов — как появиться, будет очень круто. Ну а пока, будем думать, как через API вытягивать данные =)
Иво, спасибо вам за отзыв, нас очень многие просят создать бесплатный read-only access для случаев как ваш. Вы же знаете, кстати, про кривенький workarround. Создать одного юзера с read-only, но дать его login/password всем вашим клиентам :)
В ТП3 будет такая фича — рид онли доступ в строго ограниченную область. Для такого доступа не нужна будет лицензия. Но. Кастомизировать вид этого доступа можно будет только машапами. По дефолту там будет почти то же самое, что есть сейчас в хелп деске. Но будет несложно сделать машап с бурндауном, к примеру. Ограничение доступа будет сделано через привязку компании к проекту (как и сейчас в хелп деске). Но это будет не раньше ноября.
"Практика показала, что, так как люди из техподдержки больше всего общаются с клиентами, и писать документацию у нас это и получается лучше всего."
Как-то не совсем по-русски. Я даже до конца не понял что имеется ввиду.
ПС: Прошу прощения за некропостинг.
Sign up to leave a comment.
Наши процессы. Опыт формирования support-команды и немного про SMM