Pull to refresh
23
0
Вадим Кысса @cissav

Управленец, саппортер, дизайнер и маркетер

Send message
Кстати, посмотрите наш виджет с поиском: http://blog.omnidesk.ru/post/139845201824. Поиск появляется не при наведении, но всё остальное так, как вам нужно (результаты в самом виджете + оттуда можно сразу обращение отправить).
Use case с подсказкой довольно специфичный. За всё время никто о подобном не просил, хотя у нас зафиксировано около 500 «хотелок» клиентов :)

Когда речь идёт о подобной настройке под себя, обычно клиенты используют нашу базу знаний, но прикручивают её к своему сайту через API. В итоге можно всё максимально гибко настроить, но не потерять в остальном: личный кабинет клиента с обращениями, добавление статей через аккаунт сотрудника, полноценная работа виджета (с поиском по базе), те же боты и т.д.

Своё решение, конечно, хорошо, но допиливать его постоянно — плохая идея. В долгосрочной перспективе от этого больше головной боли, чем пользы :)
У нас скоро появится возможность прикрутить к своему боту (или создать новый) базу знаний от Омнидеска. То есть пользователь сможет осуществлять поиск по базе, просто просматривать базу знаний или напрямую связаться через бота со службой поддержки (живым человеком). Последнее особенно удобно, если у клиента есть вопрос, на который бот не в состоянии ответить :)
Наконец-то, у нас клиенты давно ждали поддержки сообщений для канала «ВКонтакте» :)
1) Это не «бот», пусть даже в скобках :) Речь о полноценном сотруднике, который заточен под общение с определёнными клиентами. С опытом он станет отвечать клиентам значительно лучше, чем это делали до него, так как будет лучше понимать потребности клиентов и их манеру общения.

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

3) Соглашусь, что автор немного сгустил краски в плане «бесполезности» такого сотрудника, но это было сделано нарочно. Более того, Jason Lemkin отлично разбирается в продажах, инвестициях и управлении, но поддержка — не его сильная сторона. Соответственно, этот аспект нужно додумывать своими силами :)

4) Описанные вами проблемы не связаны с «ботами». Это общее плачевное состояние поддержки в Рунете, с которым, кстати, мы боремся путем обучения наших клиентов. Проблема на несколько уровней выше: руководители не понимают, почему поддержку нужно оказывать всей командой, и почему именно поддержка является одной из ключевых точек контакта. Однако улучшения есть, и компаний, которые серьёзно относятся к поддержке, становится больше. «Совок» нельзя перерасти так быстро :)
Спасибо за комикс :)
У американцев пиццы существенно больше наших, поэтому очень сомневаюсь, что вы осилите :)
Конечно, к людям нужно относиться как к людям, но это не решит проблем, описанных в статье. Связей меньше не станет (сложная и менее эффективная структура), а самонадеянность и стресс, скорее всего, никуда не денутся.
Едва ли эти вещи связаны напрямую, но количество действительно совпадает :)
Теперь хоть понятно, почему вы так активно изучали Омнидеск :)
Дело не только в том, что вы развиваете одновременно несколько проектов. Просто этот факт как стоп-индикатор, означающий, что дальше смотреть не нужно. То есть они остановились на этом шаге и не стали дальше изучать ваш сервис. Возможно, при более детальном ознакомлении появились бы и другие моменты :)
Согласен с вами. Поэтому мы и пишем подобные статьи, чтобы постепенно изменить отношение многих компаний к поддержке и общению с клиентами :)
Рад, что вы нашли пользу в комментарии :) Сама статья именно с этой целью и была переведена: не переубедить, а подтолкнуть переосмыслить определённые вещи.
Верно, но это уже не слежка, а точечное изучение. И заниматься этим чаще будут продажники и маркетологи, а не руководитель компании, который из-за появившейся «манечки» и неправильного расположения звёзд может срочно изменить приоритеты и начать делать то, чего «нет у нас, но уже есть у них».

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

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

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

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

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

Совсем не изучать конкурентов едва ли возможно. При этом важно не превращать это в слежку. Особенно это актуально для руководителей. У них должно быть четкое видение развития своего проекта, а не маниакальное желание ни в чём не отставать. Задача «создать уникальный продукт» в разы лучше задачи «продукт не хуже, чем Х».
У нас тоже не было и не будет, хотя в начале пару клиентов спрашивали о них. Когда же крупных клиентов стало больше, мы убедились в том, что сделали правильно. Если бы «повелись», ограничили бы себе потолок дохода :)
Это мнение автора статьи. Оно основано на личном опыте. Указанные суммы представляют своего рода минимум, ниже которого опускаться опасно, так как денег в принципе не будет достаточно для развития любого проекта.

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

К слову, в Омнидеске мы почувствовали облегчение, преодолев именно эти показатели. Последующие увеличения сумм только прибавили комфорта. Поэтому мы и решили перевести статью :)
У нас это решается другим образом. Для одного сотрудника сервис совершенно бесплатен, поэтому можно зарегистрироваться и знакомиться с сервисом без ограничений по времени. Триал активируется только тогда, когда добавляется второй и последующие сотрудники. Поэтому и крупным клиентам хватает 14 дней.
По триалу мы остановились на 14 днях.

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

Конечно, всё это индивидуально и зависит от предоставляемых услуг. Тот же Basecamp без проблем предлагает 60 дней, подсаживая клиентов на свой сервис. В некоторых же случаях такая щедрость сделает только хуже.
Неплохая статья вышла. Мы как-то тоже писали о первых рекламных затратах, но это было ещё на едином Хабре :)

Отдельное спасибо за информацию о новом формате рекламы у Лебедева. Не знал.

Information

Rating
Does not participate
Date of birth
Registered
Activity