Когда продукто много, саппорта становится слишком много, он может пожрать все ваше свободное время и энергию. Ваша цель, сокращать время на саппорт и как странно это бы не звучало, не быть легко доступным для саппорта, и способов здесь много:
1. Обширный хелп. 100% покрытие вашего продукта должно быть не тестами (0депты TDD — идите в сад) а документацией, нормальной документацией написанной людями для людей. И никто лучше вас ее не напишет. Написание документации – один из способов тестирования. Когда вы пишете документацию, вы проходите весь функционал с точки зрения пользователя, отлавливая все мелкие (и не очень) баги, работает совсем другая часть мозга нежели при проектировании и написании кода, что позволяет найти то, что упускается пока вы в IDE. Также онлайн хелп – это хорошо с точки зрения SEO.
2. FAQ – должно покрывать все то, что не покрыто хелпом, а иногда и частично дублировать его, периодически обновляйте фак когда отвечаете на письма пользователей.
3. Желательно заставить пользователя почитать хелп и фак до того как он добереться до кнопки “Написать в поддержку”, сложно, но возможно, не пренебрегайте этим.
4. Не будьте доступны для саппорта 24 часа в сутки и даже 16. Выделите определенное время, раз в сутки, когда вы читаете и отвечаете на почту/тикеты. Пользователь должен получать ответ раз в сутки, это хороший способ отсеять скучающих гов***едов и троллей, дайте пользователю время самому разрулить проблему, конечно если у вас хороший фак и хелп.
5. Регулярно анализируйте вопросы пользователей на предмет того что вы можете улучшить, упростить. переделать, а то и вовсе выкинуть из продукта для того чтобы снизить количество обращений в саппорт.
6. В продукте должна быть хорошая система диагностики, все что вы спращивате у пользователя, должна готовить программа и по нажатию кнопки отправлять вам, создавая тикет/письмо/etc В идеале цепочка должна выглядет так [Первичное обращение с диагностикой] => [ваш ответ] => [спасибо проблема решена]. Избегайте длинных цепочек, аля, посмотрите туда, пришлите то, пришлите лог, пришлите настройки, пришлите скриншот. Автоматизируйте.
Автоматизация – первый друг шароварщика, автоматизировано должно быть все что поддается автоматизиции. Релиз должен проходить по нажатию одной педальки. Это один из ключей к способности вести несколько продуктов одному.
7. Готовые ответы – создавайте базу готовых ответов на часто задаваемые вопросы пользователей, наиболее универсальная, содержательная и годная для публики часть этой базы должна периодически переезжать фак, остальная для внутреннего использования регулярно пополняться. Годятся даже небольшие предложения, типа “спасибо за ваше предолжение, но эту фичу мы делать не станем”, всегда быстрее вставить это, чем печатать снова и снова, конечно если эта база у вас доступна по горячей клавише и не нужно десять раз кликать чтобы до нее добраться.
8. Баньте не задумываясь дол***овъ, гов***довъ и троллей, а также пользователей с неразрешимыми проблемами которые возникают только у них и очень hardware/configuration specific. Не тратьте время на то, что не принесет вам денег. Не каждый тикет/письмо должны быть отвечены. Как говаривал один умный камрад – нормальный человек писать в саппорт не станет. Не бойтесь делать рефанды, если проблема не решается и она не проявляется у других пользователей, не тратьте свое время и силы, делайте рефанд, нет человека, нет проблемы.
Здравствуйте, шароварный желудь, Вы писали:
ШЖ>Когда продукто много, саппорта становится слишком много, он может пожрать все ваше свободное время и энергию. Ваша цель, сокращать время на саппорт и как странно это бы не звучало, не быть легко доступным для саппорта, и способов здесь много:
Много для одиночки — это сколько? 5-7-10?
Так может проще отказаться от мелочевки, а заниматься только самыми крупными (и самыми прибыльными) максимум 2-3 проекта?
Здравствуйте, Submitter, Вы писали:
S>Здравствуйте, шароварный желудь, Вы писали:
ШЖ>>Когда продукто много, саппорта становится слишком много, он может пожрать все ваше свободное время и энергию. Ваша цель, сокращать время на саппорт и как странно это бы не звучало, не быть легко доступным для саппорта, и способов здесь много:
S>Много для одиночки — это сколько? 5-7-10?
Мне кажется тут больше зависит от размера пользовательской базы, возраста и сложности продукта.
S>Так может проще отказаться от мелочевки, а заниматься только самыми крупными (и самыми прибыльными) максимум 2-3 проекта?
Здравствуйте, шароварный желудь, Вы писали:
ШЖ>Когда продукто много, саппорта становится слишком много, он может пожрать все ваше свободное время и энергию. Ваша цель, сокращать время на саппорт и как странно это бы не звучало, не быть легко доступным для саппорта, и способов здесь много:
Отличные способы зарекомендовать себя неадекватным мудаком, я считаю.
Здравствуйте, шароварный желудь, Вы писали:
ШЖ>Когда продукто много, саппорта становится слишком много, он может пожрать все ваше свободное время и энергию. Ваша цель, сокращать время на саппорт и как странно это бы не звучало, не быть легко доступным для саппорта, и способов здесь много:
Я так понимаю, основная проблема это говноеды и тролли? У нас таких процентов 2-5.
Хелп есть, годный, но никто не читает.
Система диагностики и база готовых ответов это правильно.
Ну и надо отметить, что подходы к саппорту на триале немного другие.
p.s. пару раз слышал от кастомеров "мы отказались от ваших конкурентов потому что там дерьмовый саппорт". Что они имели в виду догадайтесь сами
Здравствуйте, sr_dev, Вы писали:
_>Я так понимаю, основная проблема это говноеды и тролли? У нас таких процентов 2-5.
Так это зависит от того кого имм считает ТС. Спрашивает пользователь: "А под линуксом это можно как-то запустить?" И сразу идет в бан как тролль-говноед.
_>Хелп есть, годный, но никто не читает.
Покеж, плз? Хоть раз в жизни на годный хелп посмотрю.
Здравствуйте, pestis, Вы писали:
_>>Хелп есть, годный, но никто не читает. P>Покеж, плз? Хоть раз в жизни на годный хелп посмотрю.
Вообще-то хороший хелп встречается даже у бесплатных программ. Вот, например: AutoIt
Но всё равно ответы на некоторые вопросы приходится искать на форумах.
Здравствуйте, pestis, Вы писали:
ШЖ>>Когда продукто много, саппорта становится слишком много, он может пожрать все ваше свободное время и энергию. Ваша цель, сокращать время на саппорт и как странно это бы не звучало, не быть легко доступным для саппорта, и способов здесь много:
P>Отличные способы зарекомендовать себя неадекватным мудаком, я считаю.
Капитализм и свободный рынок, я бы сказал. Конкуренты всего в одном клике. Не нравится — иди конкуренту мозг выноси.
Здравствуйте, шароварный желудь, Вы писали:
ШЖ>Удачи и длинных чеков
Я бы добавил наличие форума или tag на SO чтобы пользователи сами отвечали на свои вопросы.
А я люблю сапорт.
И с самого начала давал хороший сапорт.
Потом нашел сапортера, который давал хороший сапорт, и т.д.
Ключевое слово здесь "одиночка".
Да, если планируешь до пенсии быть одиноким шароварным волком, то все правильно расписано.
У меня относительно продукта другие цели.
Хочу чтобы у него был и сапортер и разработчики и QA и маркетолог и тех. писатель и продавец.
Процентов на 50% это уже осуществил.
Сапорт люблю за то, что люди генерят фичи и указывают на баги.
Сразу видишь, какие фичи востребованы, а какие умерли.
Какие баги людей напрягают, а какие можно отложить в долгий ящик.
По факту у меня SDD — Support Driven Development.
Стараюсь решать все сапорт-проблемы и имплементить все заявленные фичи, если они не противоречат концепции продукта и не уводят его в сторону.
Хочу вынести сапорт строго на форум.
Таким образом, я буду иметь контент, который генерят сами пользователи.
Да, есть "тупые" клиенты.
Но чем тупее у тебя клиенты, тем их больше.
Именно поэтому, крупные корпорации целятся в b2c — массовый сегмент.
И каждый такой клиент помогает мне продвинуться в том, как сделать в итоге софт, чтобы его могла юзать любая домохозяйка.
В общем, без саппорта я уже не могу) пару дней бес сапорта, и перестаю понимать как развивать продукт дальше.
FAQ нет. Однако есть уже сотня тем на форуме и я помню где и что подобное спрашивали. Даю ссылки прямо туда.
Юзеры делают поиск. Даю ссылки на онлайн документацию. Удивительно, но ее тоже читают.
Если вы параноик — это еще не значит, что за вами никто не следит
C>Сапорт люблю за то, что люди генерят фичи и указывают на баги. C>Сразу видишь, какие фичи востребованы, а какие умерли. C>Какие баги людей напрягают, а какие можно отложить в долгий ящик.
А сколько лет продукту? Через 10 лет особо уже не остается ни фич, ни багов. Кроме того, имплементить все фичи не всегда хорошо — иногда оказывается, что это переводит продукт в другую ценовую категорию.
S>А сколько лет продукту? Через 10 лет особо уже не остается ни фич, ни багов. Кроме того, имплементить все фичи не всегда хорошо — иногда оказывается, что это переводит продукт в другую ценовую категорию.
Около 10.
Фич и багов еще на 10 лет вперед.
что это переводит продукт в другую ценовую категорию
Не сказал бы что переводит, скорее расширяет покрытие.
И чем ниже ценовая категория и чем выше ее охват, тем лучше.
В разы лучше продать 1000 по 100 чем один за $100.000.
Главное чтобы фичи не выходили за логическое ядро.
Например, делаешь ты софт для квадрокоптеров, а тебе предлагают вставить туда CD ejector.
Если вы параноик — это еще не значит, что за вами никто не следит
S>Кроме того, имплементить все фичи не всегда хорошо
Да, еще фича должна более менее нормально ложиться на архитектуру.
Если она превращается в один большой костыль, то это повод задуматься.
Если костыль небольшой и раззбираемый, то позже можно отрефакторить.
Такие фичи имплеменчу только за большие деньги и в обычно в тупиковый branch.
Они, как правило, не приживаются в продакшене, но дают деньги + xp разработчикам.
Если вы параноик — это еще не значит, что за вами никто не следит
Здравствуйте, turbocode, Вы писали:
>>Здравствуйте, шароварный желудь, Вы писали:
T>Если продукты приносят деньги то зачем заниматься саппортом самому?
Потому что большинство вопросов либо имеют ответы в Doc/Faq, либо это баг, и исправить его может только программист (вы сам).
Если продукт расчитан не на обычных юзеров ("программа планирования свадьбы"), а на нишевых (программеры или ещё кто), то техподдержкой заниматься можно только самому, либо платить зп специалиста данной ниши (для небольших проектов дорого). Попробуйте нанять кого-то саппортить проект либы на ГитХабе. А теперь то же самое, но не выдавая кода.
Тут нанимать человека возможно стоит только по финансовым вопросам (refund, subscription cancellation, wrong product, give me a discount pleeeease).
Здравствуйте, Sharowarsheg, Вы писали:
S>Здравствуйте, Kernan, Вы писали:
ШЖ>>>Удачи и длинных чеков K>>Я бы добавил наличие форума или tag на SO чтобы пользователи сами отвечали на свои вопросы.
S>У меня не очень работал форум, до такой степени не очень, что я выкинул его.
Самое смешное, что похоже, все шароварщики выбросили свои форумы. И я тоже.
Ну, не отвечают люди на свои вопросы. Сейчас всё через хелпдеск. Но задумываюсь разворачивать дешевых клиентов на StackOverflow
Здравствуйте, Sharowarsheg, Вы писали:
S>А сколько лет продукту? Через 10 лет особо уже не остается ни фич, ни багов. Кроме того, имплементить все фичи не всегда хорошо — иногда оказывается, что это переводит продукт в другую ценовую категорию.
Тонкий момент — разработчик часто думает, что уже ничего не сделать лучшше (особенно, если отталкиваться от существующего продукта, а от нуля), но если хорошенько подумать со стороны пользователя... оказывается, что работы просто непочатый край. Просто иногда она не укладывается в правило 80/20, часто вследствии перекраивания всех архитектуры с учетом ошибок, и разработчик просто фильтрует эту идею как андроиды Westworld'а запрещенные слова. Это нужно преломить в себе, сгенерить идеи, а потом обдумать целесообразность.
T>>Если продукты приносят деньги то зачем заниматься саппортом самому? S>Потому что большинство вопросов либо имеют ответы в Doc/Faq, либо это баг, и исправить его может только программист (вы сам). S>Если продукт расчитан не на обычных юзеров ("программа планирования свадьбы"), а на нишевых (программеры или ещё кто), то техподдержкой заниматься можно только самому, либо платить зп специалиста данной ниши (для небольших проектов дорого). Попробуйте нанять кого-то саппортить проект либы на ГитХабе. А теперь то же самое, но не выдавая кода.
Хорошо, занимайтесь саппортом но нанимайте тогда программистов.
