Итак, на сегодняшний день Маркетплейс.1С-Битрикс изобилует множеством готовых типовых решений и модулей. Иногда для закрытия конкретной проблемы и тематики нам предлагается аж несколько десятков вариантов решений. С одной стороны, это хорошо – всегда приятно, когда есть выбор. Это как-то греет душу. С другой – при множестве вариантов выбора есть вероятность впасть в некий ступор, когда появляется опасение: как бы выбрать лучший вариант и не прогадать?
Даже мы, специалисты в профессиональной разработке решений для Маркетплейс, тоже иногда впадаем в подобный ступор, когда необходимо для клиента подобрать наиболее оптимальный вариант решения той или иной задачи. Какой готовый интернет-магазин выбрать? Какой модуль накопительных баллов лучше? Чем отличаются друг от друга модули выгрузки на торговые площадки? Вопросов, к сожалению, может быть много, а вот ответов – мало.
Поэтому мы за 5 лет работы на рынке Маркетплейс выработали для себя некий чеклист, который помогает нам с большой долей вероятности не ошибаться и выбирать наиболее оптимальные программные решения в Маркете.
Ранее этот чеклист мы использовали только для собственных нужд. Теперь мы готовы им поделиться с Вами, дорогие клиенты Маркетплейс, чтобы свести к минимуму Ваши риски по выбору готовых сайтов и модулей.
Итак, давайте договоримся сразу, что сейчас мы не будем рассматривать сам программный продукт. Думаю, ни для кого не будет секретом, что программный продукт – это по умолчанию один из наиболее важных аспектов при выборе того или иного решения. Для каждого проекта и каждой задачи – свои требования к ПО. Поэтому этот пункт мы полностью оставляем на откуп Вам, дорогие клиенты Маркетплейс.1С-Битрикс. То есть мы изначально предполагаем, что Вы самостоятельно либо с помощью своих технических специалистов формируете пул программных решений, которые подходят под Ваши требования и могут решить необходимые задачи.
А далее после подбора несколько потенциально подходящих программных продуктов вступает в силу наш чеклист, который состоит из 9 последовательных шагов:
- Демо-режим
- Техподдержка
- Отзывы
- Развитие и обновления
- Разработчик
- Информационная поддержка
- Кейсы
- Стоимость
- Аккаунт-менеджер
Демо-режим – это возможность протестировать полнофункциональную версию решения в течение определенного периода времени совершенно бесплатно.
Согласитесь, очень крутая вещь?! Не нужно покупать «кота в мешке». Решение о покупке вы принимаете только после внедрения программного продукта на Вашем проекте. Риски практически равны нулю.
Но что же разработчики Маркетплейс предлагают нам с Вами в этом плане? К сожалению, почти ничего. Всего лишь 10-15% всех решений на площадке Маркета имеют демо-режим. И если с модулями немного проще – разработчики модулей более охотно дают бесплатно протестировать свои решения. То с разработчиками готовых интернет-магазинов и сайтов немного сложнее – можно пересчитать по пальцам тех, кто предоставляет демо-режим.
Откуда же такое нежелание разработчиков предоставлять функционал бесплатного тестирования свои решений в течение определенного периода? Все просто. Основные причины две:
- Технологическая. Необходимо продумать систему защиты, дописать дополнительный код, что немного усложняет разработку и сопровождение программного продукта. Не все готовы на это идти.
- Пиратство. Разработчики боятся, и небезосновательно, что их ПО будет попросту взломано и украдено. Да, такое может произойти. Но не стоит забывать, что ПО – это в любом случае риск нелегального использования. Отсутствие демо-режима точно от этого не спасет.
А теперь давайте определимся, какой же оптимальный срок для предоставления демо-периода? По нашим выверенным оценкам: 2-3 недели. Этого времени хватает, чтобы установить, настроить и протестировать практически любое решение. Срок в 1 неделю – слишком короткий, можно просто физически не успеть проверить работоспособность ПО. Срок в 1 месяц – наоборот, может оказаться в большинстве случаев большим, что может расслабить клиента и демотивировать разработчика.
Что касается нас, то мы на все наши решения предоставляем демо-режим в течение 14 дней. Как правило, этого срока хватает, чтобы успеть всё установить и протестировать. Иногда, конечно, возникают случаи, когда клиент установил и поздно приступил к настройке модуля. Либо клиент просто давно устанавливал модуль, а теперь опять решил его «пощупать». Во всех этих ситуациях мы просто «сбрасываем» демо-режим и он начинает работать «с нуля».
Хочется также предупредить клиентов о так называемых псевдо-демо-режимах. Что это такое? Это когда разработчик устанавливает демку сроком на 1-2 дня. За это время просто нереально что-то протестировать. Тогда зачем они это делают? Все просто. Если зайти в каталог Маркетплейс и поставить фильтр по наличию демо-режима, то модули с таким коротким демо-периодом тоже будут в списке. Небольшая хитрость. Формально демка есть, а вот фактически – ее нет.
Итак, думаю, приведенной выше информации нам с Вами будет достаточно, чтобы сделать вывод – при наличии демо-режима остальные пункты нашего чеклиста можно даже не рассматривать. Согласитесь, какая разница, сколько у разработчика отзывов или какая документация, если решение уже удачно внедрено на Вашем проекте? Вы его еще даже не купили, а оно уже приносит деньги! Прямо фантастика!
А нам с Вами, дорогие пользователи 1С-Битрикс, остается только надеяться, что разработчики Маркетплейс будут больше доверять свои клиентам и внедрять в своих решениях полноценные демо-режимы. Разработчиков готовых интернет-магазинов и корп. сайтов это касается в первую очередь.
И мы считаем, если в ближайшее время на рынке появится готовый интернет-магазин с демо-режимом, то это будет серьезным прорывом на рынке шаблонов Маркетплейс.1С-Битрикс. Такой магазин сразу же завоюет симпатии пользователей, которые за предоставленное им доверие готовы отплатить сторицей. Кроме того, такое нововведение может задать всеобщий тренд на демо-режимы среди готовых сайтов. А клиенты будут только рады таким приятным изменениям.
Что касается нас, то мы даже не рассматриваем решения, на которых не установлен демо-режим. Исключение может быть в том случае, если заказчик настаивает.
2. Техподдержка
Техническая поддержка (ТП) – важнейший аспект программного обеспечения. Программный продукт без грамотного технического сопровождения может быть бесполезен. Именно поэтому разработчик продает не только сам продукт, но и его техническую поддержку.
Итак, давайте определимся, что же мы вкладываем в понятие «бесплатная техническая поддержка». Как правило, это:
- Установка
- Первичная настройка
- Консультационная помощь
Теперь давайте разберемся, как же понять, что бесплатная техподдержка действительно хорошая? Все очень просто – методом «тыка». Наверное, один из немногих работающих методов вселенной. Просто надо «щупать» ТП, активно взаимодействовать с ней.
Если ПО имеет демо-режим, то тут намного проще. Просто пишите разработчику, чтобы он самостоятельно установил и настроил решение. И уже при взаимодействии с ТП разработчика оцениваете качество обслуживания и вообще целесообразность дальнейшей работы с этим программным решением.
Так, а если демо-режима нет? Что тогда? Как проверить работу ТП? Тут мы видим два варианта проверки:
- Консультация. Вы просто связываетесь с разработчиком и обсуждаете: подходит ли его продукт под Ваши требования. Главное, не забудьте сами понять, что Вам нужно и составить требования в письменном виде. Так и Вам, и разработчику будет намного лучше.
- Тестирование на сервере разработчика. Раз уж нет демо-режима, то прямо требуйте от разработчика, чтобы развернул Вам решение на своем сервере и предоставил Вам все доступы. А Вы уже самостоятельно хотя бы в таком режиме протестируете ПО: подходит ли оно под Ваши требования?
И еще несколько моментов, на которые я бы порекомендовал Вам обратить внимание при работе с ТП:
- Способы коммуникации
- Режим работы и скорость ответа
Необходимо обратить внимание, как разработчик предлагает взаимодействовать с Вами. Если в качестве общения предлагается переписка по имейлу, то это первый признак того, что к данному разработчику нужно отнестись с большой осторожностью. И давайте разберемся: почему?
Во-первых, это первый признак того, что разработчик не подошел к разработке программных продуктов как к системе. Это, скорее всего, его хобби либо дополнительная сфера деятельности. И с Вами, в таком случае, с большой долей вероятности, будут общаться не сотрудники ТП, а сами программисты. И выделяться на Вас время будет только тогда, когда разработчик слегка освободится от своей основной работы. Кроме того, учтите, что программисты - очень специфичный народ. Общение с ними в письменной форме редко приносит удовольствие.
Во-вторых, переписка по имейлу может затеряться, письма могут быть пропущены. Да и вообще, сложно потом уследить за всей логикой общения. Вывод – взаимодействие с ТП разработчика может затянуться.
Итак, какие же средства связи должен предоставить разработчик, чтобы Вам было комфортно и вопросы решались с максимальной эффективностью? Делимся:
- Платформа для работы с клиентами (Битрикс, Битрикс24, ZenDesk и прочее). Это минимум, который разработчик должен Вам предложить. Вы должны общаться через полноценную систему обращений. Лишь в таком случае Ваши вопросы могут быть оперативно решены.
- Открытые линии. Это когда Вы можете связаться с ТП прямо из соц сетей или мессенджеров. Согласитесь, очень удобно?! Актуально в том случае, когда у Вас есть очень простой вопрос, на который Вы хотите получить быстрый ответ.
- Телефон. К сожалению, единицы разработчиков позволяют звонить и общаться с техническими специалистами по телефону. А как удобно иногда не писать, а просто позвонить и словами объяснить, что же ты хочешь от ТП. Особенно актуально для тех клиентов, которым проще наговорить, нежели писать.
Итак, как говорилось выше, наличие платформы для работы с клиентами – это тот минимум, который должен предоставить для Вас разработчик. Остальных источников связи может и не быть.
Ну а наличие дополнительно открытых линий и телефона будет просто огромным преимуществом разработчика перед конкурентами.
Режим работы и время ответа
Прежде чем связаться с ТП, обязательно ознакомьтесь с режимом работы техподдержки разработчика, а также со средним временем ответа. Как правило, эта информация описана в карточке решения на Маркетплейс во вкладке «Поддержка».
В первую очередь, выясните режим работы технической поддержки. Возможно, разработчик находится далеко в Сибири, а Вы в Москве и у Вас существенная разница во времени. В таком случае могут возникнуть определенные трудности при взаимодействии с такой компанией.
Далее необходимо найти информацию о регламенте ответа, то есть как быстро разработчик обещает отвечать на Ваши запросы. Если эта цифра более 2-х суток, то это не есть хорошо. Такими темпами Вы будете внедрять решение очень долго. Оптимальная же скорость ответа 4-10 часов. Но, как правило, ответственные разработчики стараются отвечать еще быстрее.
Но это еще не все. Еще останется самолично проверить все эти режимы работы и регламенты. Если они отличаются в худшую сторону от заявленных, то бить тревогу и писать плохие отзывы сразу же необязательно. Нужно просто поинтересоваться у разработчика: по каким причинам заявлены одни сроки, а по факту они совсем иные? Возможно, у разработчика период отпусков либо какая-либо другая адекватная причина.
Если же нарушение регламентов происходит регулярно и системно, то в принципе, уже можно сделать определенные выводы о ТП данного разработчика. И эти выводы далеко неутешительные.
3. Отзывы
Очень интересный пункт. И мы в любим его особенно.
Ведь отзывы – это фактически первое впечатление о программном решении и разработчике. По отзывам уже можно сделать определенные выводы.
Отзывы Вы можете найти в карточке модуля Маркетплейс во кладке «Отзывы».
Теперь давайте разберемся, на что в первую очередь обращать внимание при анализе отзывов:
- Контент
- Количество отзывов
- Дата последнего отзыва
- Ответы разработчика
Надо ознакомиться с сутью отзывов, то есть с их текстом. Ведь по тексту отзыва уже можно сделать выводы как о текущем состоянии ПО, так и о качестве работы ТП.
Иногда, читая отзывы, понимаешь, что смысла обращаться в техподдержку разработчика просто нет, не говоря уже о приобретении программного продукта.
Количество отзывов
По количеству отзывов можно судить о популярности программного решения.
Если отзывов менее 5 или они отсутствуют – тогда решение помещается в разряд сомнительных. А если среди такого малого количества отзывов есть и негативные, то сомнений становится еще больше.
Далее, если отзывов достаточно, то есть более пяти, тогда можно перейти к рассмотрению следующего пункта.
Единственным оправданием малого количества отзывов может быть лишь то, что ПО лишь относительно недавно, в течение полугода, вышло на рынок.
Необходимо иметь ввиду, что количество отзывов стоит анализировать только для популярных категорий ПО. К примеру, для типовых интернет-магазинов, сайтов и SEO модулей. Для узкопрофильных и специализированных программных продуктов этот пункт никак не подходит. Ведь рынок подобных программных решений значительно уже, соответственно, и отзывов будет на порядок меньше. Но это никак не мешает данному программному обеспечению закрывать все задачи своей аудитории.
Так что в случае со сложным программным продуктом приоритетнее обращать внимание на кейсы, которые описаны в пункте №7 данного чеклиста, нежели на отзывы.
Дата последнего отзыва
В первую очередь необходимо обратить внимание на свежие отзывы, которые были опубликованы в течение последнего полугодия. Почему так? Да потому что – это и есть пульс ПО. Это лакмусовая бумажка того, как развивается решение и сам разработчик.
Отсутствие же свежих отзывов – знак того, что о программном обеспечении забыли не только пользователи, но и сами разработчики. Данное ПО уже утратило былую популярность, если таковая, конечно, вообще была.
Очень часто в Маркете происходит такая ситуация, когда к решению отзывов много, а вот свежие – отсутствуют. В таком случае со старыми отзывами стоит ознакамливаться только для общей информации. Никакие выводы на их основании делать нельзя.
А вообще, качественное ПО может похвастаться не только свежими отзывами, но и регулярными. Это, наверное, даже важнее. Поэтому, если в карточке решения Маркетплейс стабильно и ежемесячно появляется более 1 отзыва, то это признак класса как разработчика, так и самого программного обеспечения.
Со сложными и узкопрофильными программными продуктами дело обстоит аналогично предыдущему пункту. Из-за малой аудитории отзывов тоже, соответственно, немного. Поэтому в таком случае лучше, в первую очередь, рассматривать кейсы, которые более подробно расписаны в пункте №7 нашего с Вами чеклиста.
Ответы разработчика.
Наш любимый компонент анализа отзывов. Ответы разработчика несут в себе очень много информации. Даже плохой отзыв разработчик может занести себе в актив, если грамотно на него ответит.
Стоит отметить, что ответы разработчика стоит анализировать именно на негативные отзывы. Ведь на положительные – нет смысла даже отвечать.
Итак, с чего же начать анализ ответов разработчика?! Во-первых, с того – есть ли вообще эти ответы?! Если разработчик не дает ответ на негативный отзыв – значит, он своим молчанием соглашается с недовольным клиентом, значит, он своим молчанием подписывается под его словами. Молчунов мы рекомендуем обходить стороной.
С другой стороны, иногда разработчик ответит так, что сделает себе и своему решению еще хуже. И тогда точно невольно подумаешь: «Уж лучше бы молчал».
Так каким образом должен ответить разработчик, чтобы нивелировать воздействие отрицательного отзыва и все же склонить клиента на свою сторону?! Все просто. Вот краткий список того, как должно быть:
- Отсутствие эмоций. Если разработчик отвечает под стать клиенту – эмоционально, то он сам загоняет себя в угол. Ответ должен быть четким и хладнокровным.
- Структурированный анализ претензии. Каждая претензия должна быть разобрана внутри компании разработчика, должен быть произведен полный анализ ситуации. Лишь после этого разработчик должен четко и по делу донести свою позицию до клиента. Просто очень часто в ответах разработчиков одна эмоциональная каша, анализом и структурой даже не пахнет.
- Осознание своей ответственности. Разработчик должен осознавать, что за сложившуюся ситуацию он несет полную ответственность. Да, клиент может быть проблемный, да, клиент может быть и сам виноват, но ситуацию не смогли диагностировать на ранней стадии – значит, вина разработчика. Если же разработчик в каждом свое слове винит клиента, который приносит ему деньги, – это не есть хорошо. А со стороны вообще смотрится как-то смешно и нелепо.
- Подведение итогов. Разработчик обязательно должен в конце своего ответа подвести некий итог: кто виноват, кто будет наказан, получит ли что-то клиент в качестве компенсации за сложившуюся ситуацию? То есть в отзыве мы должны не просто увидеть словоблудство, но и конкретные шаги, которые предпримет разработчик или не предпримет, но об этом он нам обязан сообщить.
Кроме отзывов, существуют еще и комментарии. Они находятся во вкладке «Обсуждения».
Анализ комментариев происходит аналогично отзывам. Механизм тот же.
Почему же пользователи оставляют комментарии, а не отзывы? Ведь в большинстве случаев комментариев значительно больше, чем отзывов. В чем же причина?
Во-первых, комментарий оставить намного проще. В отличие от отзывов нет необходимости оставлять ключ лицензии и прочие данные.
Во-вторых, пользователи очень часто пишут свои отзывы именно в комментарии. Связано это с тем, что не все пользователи могут оставлять отзывы во вкладке «Отзывы». Такой привилегии заслужили только те, кто приобретал ПО непосредственно через площадку Маркетплейс. Если же Вы приобретали решение напрямую через разработчика, то знайте: отзыв Вы оставить не сможете – только комментарий.
4. Развитие и обновление
E-commerce, да и весь рынок веб-разработки в целом, активно развивается и видоизменяется. Тренды, стандарты и технологии меняются ежедневно. Разработчики должны держать руку на пульсе и активно реагировать на все изменения рынка, как, к примеру, это делает 1С-Битрикс.
Именно поэтому одним из ключевых аспектов при выборе ПО в Маркетплейс является понимание: какими темпами развивается решение и каковы перспективы его развития в будущем?
Чтобы проанализировать обновляемость программного решения, необходимо в карточке ПО перейти во вкладку «Что нового». И там мы можем наблюдать полный список обновлений ПО, начиная с самого его запуска.
На что следует обратить особое внимание:
- Периодичность. Хороший признак – решение систематически и с определенной регулярностью (минимально: 1 раз в 3 месяца, идеально: 1-2 раза в месяц) обновляется. Плохой признак – редкие обновления или полное их отсутствие. Если обновления до текущего момента были эпизодическими, то сомнительно, что в будущем что-то изменится.
- Полное описание. Обновления должны быть полно и конкретно описаны. Если разработчик пишет «Исправление багов», «Незначительные изменения и доработки» и все в этом духе – это значит, что он или сам не совсем понимает, какие обновления делает, или просто ленится более подробно описать доработки для своей аудитории. Скажите, кому-то нужны незнающие или ленивые?
- Стиль написания. Список доработок должен быть представлен в виде списка. Иногда разработчики публикуют все одной строкой. Тогда это просто невозможно читать.
5. Разработчик
А теперь давайте искать скелеты в шкафу разработчика, то есть подробно разбирать саму организацию (юридическое лицо), которое является правообладателем на ПО.
Всегда обращайте внимание на два аспекта разработчика:
- Специализация
- Рейтинг
На первый взгляд может показаться, что тут такого? К чему этот пункт? Все просто.
Если разработчик специализируется на контекстном или SEO продвижении, если он делает на потоке сайты «с нуля», если он позиционирует себя кем угодно и как угодно, но только не разработчиком ПО, то могут возникнуть определенные трудности. И сейчас объясним: почему?
Разработка софта – это определенная компетенция. Она включает в себя следующие составляющие:
- планирование разработки софта
- непрерывное развертывание ПО
- автоматизация процессов сборки, тестирования и внедрения новых версий продукта
- создание отдела технической поддержки
- документальное сопровождение ПО и прочее
И чем данная ситуация может грозить простому пользователю? А тем, что такой разработчик в лучшем случае будет предоставлять плохой сервис и медленно развивать свой продукт, а в худшем – вообще прикроет этот модуль.
И чтобы не быть голословными, приведу реальный пример из нашей практики. В январе 2016 года мы первыми запустили модуль «» – самое популярное наше решение на данный момент. Изначально он умел работать только с уникальными метатегами. И вот буквально через месяц никому неизвестная украинская компания выпустила аналог нашего модуля. И он был намного круче нашего.
В результате их модуль стал очень популярным. Он был в ТОПах по продаваемости, а нашему решению такое и не снилось.
Но проблема заключалась в том, что компания, разработавшая этот модуль, была обычной digital. Они занимались контекстом и SEO. Их модуль явился результатом всех их многолетних наработок и доработок. И они все это вместе взяли и соединили в свое решение.
Но по мере того, как популярность модуля росла, как активными темпами увеличивалось количество пользователей, разработчики стали проседать по многим направлениям: обновления, техподдержка, документация. Судя по их карточке решения, они перестали выпускать обновления и вообще отвечать своим клиентам. И их клиенты медленно, но верно, начали переходить к нам.
А через определенное время модуль-аналог просто исчез с Маркетплейс. Видимо, разработчики решили, что дешевле закрыть модуль, нежели продолжать его обслуживать.
А мы все это время планомерно работали не только над модулем «», но и над всей структурой, над всеми процессами по разработке ПО. В результате мы могли похвастаться не только системным развитием нашего программного решения, но и хорошим сервисом вкупе с оперативной и грамотной техподдержкой. Именно поэтому наш модуль до сих пор на рынке, а тех ребят уже никто и не вспомнит. Но стоит сказать им спасибо. Они дали нам импульс к развитию.
Так что вот Вам реальным пример того, как узкая специализация побеждает желание заниматься сразу всем.Рейтинг
Честно говоря, мы долго думали, стоит ли включать этот пункт в наш чеклист. Но все же пришли к выводу, что стоит. Но много времени ему уделять не будем.
Итак, речь у нас пойдет именно о рейтинге разработчиков в Маркетплейс, с которым Вы можете ознакомиться по адресу:
Соответственно, чем выше рейтинг, тем успешней компания. Рейтинг строится на основании продаж ПО разработчиков непосредственно через Маркетплейс.
Какое внимание уделять рейтингу разработчика? Скажем так, если вы рассматриваете: покупать у разработчика №1 или №5 в списке, то разницы особой нет и рейтинг можно пропустить. А вот если перед выбором стоит разработчик №3 и, условно говоря, разработчик №21, то тут уже внимание стоит обратить.
Рейтинг также дает понять: не сольется ли данный разработчик в процессе работы, не исчезнет ли он? Согласитесь, навряд ли разработчик из ТОП-10 может прекратить свое существование, а вот из последней 30-ки – вполне может.
6. Информационная поддержка
Важный пункт разработки ПО. Для Маркетплейс.1С-Битрикс он включает в себя следующие составляющие:
- Упаковка
- Документация
- Видеоматериалы
Упаковка
Под упаковкой будем понимать все то, что доносит нам правильные смыслы о ПО. Стоит выделить следующие варианты упаковки:
- Карточка решения в Маркетплейс
- Лендинги
- PDF презентации
- Рассылки
Так как же упаковка может повлиять на выбор программного решения? Опять-таки, все просто. Если разработчик сделает упаковку правильно, то вы сразу поймете, о чем идет речь. Правильная упаковка – это совокупность структуры, смыслов, стиля и хорошего вкуса. Если упаковка оставляет понятное и приятное впечатление, значит, разработчик попал в точку, значит, он точно знает, что нужно клиенту. Значит, и Вы быстро поймете, что Вам нужно именно это ПО.
Если же после прочтения упаковки Вы ничего не поняли, к тому же стилевое оформление вызвало у Вас чувства отвращения, то это плохая упаковка. Плохая упаковка – первый признак того, что разработчик, по сути, сам не понимает, что нужно рынку, что нужно пользователю. А как можно хорошо делать то, чего не понимаешь?
Документация
Наличие документации является большим плюсом как для ПО, так и для самого разработчика. Она может снизить порог вхождения пользователя в программное решение, а также облегчить работу техподдержки. Ведь в таком случае клиент может просто «покурить» мануалы и уже самостоятельно начать работу с программным обеспечением.
Важным аспектом документации является ее актуальность. Поэтому всегда убеждайтесь, что она действительно рабочая. А то может случится так, что документация, вроде, и есть, но для ПО годичной давности.
Видеоматериалы
Тренд современного мира – это видео. Людям куда приятнее смотреть, чем читать. К тому же намного проще воспринимать информацию, когда ее прямо показывают на пальцах.
В каком же случае видео может стать реальным конкурентным преимуществом? Лишь в том случае, если Вы на выходе видите качественную картинку, хороший звук и свет, а контент видоса не оставляет каких-либо глобальных вопросов – все четко и по делу.
Хочется также отметить, что записать действительно качественное видео куда сложнее, нежели черкануть пару страниц документации. Уж Вы нам поверьте. Это мы знаем на собственном опыте. Одного профессионального оборудования для съемок будет недостаточно. Добавьте ко всему этому хорошую графику и профессионального монтажера. Плюс о сценаристе не забудьте. Вот в таком случае может получиться крутое видео.
Плохое же видео, как правило, вызывает желание быстрее его закрыть и конкурентным преимуществом никак быть не может. Радует тот факт, что плохое видео можно распознать в течение первых секунд: отвратительный звук, плохой свет и еще худшая картинка. Про контент в таком случае и говорить не стоит.
Так что, дорогие пользователи, если разработчик предоставляет для Вас видеоматериалы, то пользуйтесь ими с удовольствием. И будьте уверены: если разработчик заморочился и подготовил для Вас профессиональный видеокурс, то, значит, ко всем другим аспектам своей деятельности он будет подходить с такой же ответственностью.
А теперь, смеха ради, на своих примерах продемонстрируем Вам разницу между плохим и хорошим видосом.
Вот с подобных видео мы начинали. Январь 2016 года по модулю «» (да простите нас): . Обратите внимание на дизлайки и негативные комментарии к видео. Да, именно так мы учились делать видеоконтент.
А вот уже наше свежее видео совершенно иного формата:
7. Кейсы
Кто-то может сказать: «Товарищи, Вы что-то попутали! Как может такой важный пункт, как кейсы, стоять аж под 7 номером?!». Давайте успокоимся и вместе разберемся, почему мы приняли именно такое решение.
Во-первых, кейсом для готовых сайтов и интернет-магазинов уже никого не удивишь. Любой мало-мальский шаблон имеет хоть какой-либо кейс. Это не проблема. Но сам кейс не дает нам никакого понятия о бэкграунде проекта. Навряд ли разработчик Вам сообщит о своих факапах, неоптимизированном коде или плохой коммуникации с клиентом. Но зато Вы увидите красивые картинки и как все круто работает.
Кстати, не поленитесь не просто прочитать кейс, но и самолично зайти на проект, разработанный на шаблоне разработчика. Вот тут уже все по-настоящему. Тут Вы можете самостоятельно все тестировать. Вас уже не обманешь.
Именно из-за всех подводных камней, связанных с кейсами, мы рекомендуем всё же большее внимание уделять отзывам. Никто не говорит, что кейсы смотреть не надо. Надо для справки, но в любом случае проверяйте их самолично. И это касается в первую очередь готовых сайтов и популярных категорий модулей.
Если же мы имеем дело с узкоспециализированным и технологически сложным продуктом, то тут кейсы придутся очень кстати. В таком случае их можно будет поставить даже на первое место в нашем с Вами чеклисте. Внедрение сложного ПО – само по себе занятие трудоемкое, требующее привлечения высококвалифицированных специалистов. Да и кейс к таком программному решению составить куда сложнее, нежели к готовому интернет-магазину.
8. Стоимость
Вот мы добрались и до стоимости ПО. Казалось бы, она должна быть в самом начале. Ведь очень часто все мы грешим тем, что принимаем свои решения о приобретении чего-либо только на основании более дешевой цены. Возможно, для других вещей это может прокатить, но только не для ПО. И давайте разберемся, почему?
Ведь ориентируясь только на цену, Вы рискуете упустить ряд важных моментов:
- Техподдержка. Купил и забыл – это точно не про ПО. Его еще надо внедрять и сопровождать. А если разработчик не предусмотрел или слишком занизил свои трудозатраты на техподдержку в стоимости ПО, то Вы рискуете остаться один на один со своим программным продуктом. В таком случае Вам придется потратить дополнительные денежные средства на поддержку продукта.
- Статус разработчика. Вы можете в спешке не проверить разработчика: специализацию, компетенции и рейтинг. В итоге по дешевке приобретете ПО у сомнительного разработчика-одиночки, который завтра сольется и прекратит поддерживать свои разработки.
- Развитие ПО. Есть вероятность того, что вы приобретете программное решение, которое более не будет развиваться. Поэтому рекомендуем Вам ознакомиться с периодичностью обновлений модуля или готового решения.
Что касается самих разработчиков Маркетплейс, то они в большинстве случаев ставят цены только по своим ощущениям (в принципе, мы тоже не безгрешны, ранее тоже так делали). Они не понимают и не считают трудозатраты на разработку ПО, трудозатраты на маркетинговую кампанию, планируемые трудозатраты на ТП и прочее. Именно поэтому очень часто разработчики выходят на рынок Маркета, устанавливают мизерные цены, а потом разочаровываются в площадке Маркетплейс и в результате сливаются.
Надо понимать: площадка Маркетплейс – это не PlayMarket и не AppleStore. Здесь нельзя установить 300 рублей на ПО и стать миллионером. Аудитория и рынок здесь совсем иные. И это надо учитывать.
Так вот, вернемся непосредственно к ценам. В каком случае стоит обращать на цену внимание? Скажем так, если Вы рассматриваете готовый шаблон, то разница в 10 000 – не критическая. С большой долей вероятности Вы потратите на порядок больше денег, если неправильно подберете готовое решение и разработчика соответственно.
Если же мы рассматриваем модули, то разница в 7 тыс. тоже не особо существенна. Аналогично готовым решениям можно сэкономить на модуле, а потом потратить в несколько раз больше ДС на его внедрение.
Итак, подытожим. Цена может оказать влияние на выбор ПО, но не критическое. На цену стоит обращать внимание только когда, когда другие показатели, описанные выше в данной статье, приблизительно равны.
Если же Вы при выборе готового решения обращаете внимание только на цену, то заранее подготовьтесь к дополнительным вложениям по его доработке и допилу.
9. Аккаунт-менеджер
Этот пункт нашего чеклиста мы специально оставили напоследок для истинных ценителей хорошего сервиса. Это как вишенка на торте.
Итак, для тех, кто еще, возможно, не знаком с таким понятием, как «аккаунт-менеджер», представим краткое его определение:
«Аккаунт-менеджер (account-менеджер) – специалист, обеспечивающий поддержание постоянного контакта с существующими клиентами, координирующий работу всех подразделений агентства над конкретными заказами клиента».
Исходя из этого определения можно сделать вывод, что аккаунт-менеджер (далее по тексту будем называть сокращенно: аккаунт) – это, в первую очередь, друг клиента, который помогает ему взаимодействовать со всеми отделами компании-разработчика.
Стоит с грустью признать тот факт, что разработчики Маркетплейс редко балуют своих клиентов аккаунтами. И причин тому несколько.
Первая причина. Отсутствие компетенций. Разработчики – люди технические. Все, что связано с сервисом и продажами для них может быть чуждо. К тому же куда приятнее уделять время тому, что ты понимаешь, нежели тому, в чем ты совсем не разбираешься.
Причина вторая. Вытекающая из первой. Разработчики просто не осознают необходимость внедрения аккаунтов. Ведь ПО – это сложный продукт. А аккаунты делают его проще: объясняют, поясняют, при необходимости связывают с техническими специалистами. Но люди с техническим складом ума считают, что и так все понятно и ничего объяснять не надо.
Причина третья. Высокие затраты. Затраты не только финансовые, но и временные. Руководству приходится уделять больше внимания на сервис и продажи, нежели на продукт. К тому же обучение аккаунтов продукту занимает немало времени и денег.
Так стоит ли внедрять аккаунт-менеджеров компаниями-разработчикам?
Мы ответим на этот вопрос простым примером из собственного опыта.
Итак, аккаунты у нас появились всего лишь год назад (сентябрь 2017 года). И этот шаг дался нам с большим трудом. Почему? А причины те же, что мы описали выше. И главная – отсутствие нужных компетенций. Мы могли сделать хороший продукт, но вот как организовать целый отдел аккаунтов, который будет плотно работать с клиентами – это оказалось для нас настоящей проблемой.
И как же мы решали данную проблему? Всё просто: привлечение консультантов, книги, тренинги и прочее. Все это принесло нам свои плоды. За один год мы смогли сколотить мощный отдел аккаунтов. Теперь мы жалеем лишь об одном, что не внедрили его еще раньше.
А теперь давайте рассмотрим наши результаты. Какие же показатели мы смогли увеличить благодаря аккаунтам:
- Сервис. Приятно слышать, когда клиенты хвалят наш сервис. А вдвойне приятнее, когда нас хвалят наши коллеги, которые тоже периодически работают с нашими аккаунтами. И все это благодаря аккаунтам. Людям нравится, когда их «вылизывают».
- Техподдержка. Аккаунты – это адвокаты клиента. Эти адвокаты постоянно терроризируют отдел техподдержки и напрягают его, чтобы тикеты обрабатывались как можно оперативнее и клиенты были довольны. Из-за этого отдел ТП втайне ненавидит аккаунтов.
- Отзывы. Клиенты стали с большим желанием оставлять положительные отзывы о нас и нашем сервисе. Сами интересуются, как это можно сделать?
- Конверсия. Всё вышесказанное сконвертировалось в увеличение числа клиентов. Соответственно и конверсия выросла.
10. Резюме
Итак, теперь в наших руках есть чеклист, который в 9 шагов позволит нам с минимальными рисками выбрать программное решение и разработчика в Маркетплейс.1С-Битрикс. Но наличие чеклиста как такового ничего не дает, если его не применять. Думаю, желания к применению у Вас прибавится, когда Вы узнаете, что по законодательству РФ программное обеспечение возврату и обмену не подлежит. Так что не поленитесь потратить некоторое время на изучение ПО, прежде чем его приобретать. Это сэкономит Ваши деньги и нервы.
А теперь освежим память и продублируем чеклист:
- Демо-режим
- Техподдержка
- Отзывы
- Развитие и обновления
- Разработчик
- Информационная поддержка
- Кейсы
- Стоимость
- Аккаунт-менеджер
Техподдержка продемонстрирует нам, как оперативно и слаженно команда разработчика работает с вопросами и обращениями пользователей. Если техподдержка плохая, то смысла рассматривать остальные пункты нет. Вы всё равно будете утыкаться в некомпетентность ТП разработчика.
Отзывы расскажут нам о мнении других пользователей как о самом продукте, так и о техподдержке разработчика. Если это мнение в больше степени негативное, то продолжать работу с данным разработчиком не рекомендуем.
Развитие и обновления докажут нам, что ПО регулярно и системно обновляется. Кроме того, необходимо убедиться, что вектор развития программного решения совпадает с Вашими требованиями. Если все хорошо по данному пункту, то двигаемся дальше.
Разработчик должен зарекомендовать себя с лучшей стороны. Он должен специализироваться именно на разработке софта, а не на смежных специальностях (SEO, контекст, сайты на потоке и прочее). Кроме того, не забудьте ознакомиться с рейтингом разработчика. Возможно, это тоже поможет Вам при выборе.
Информационная поддержка должна обеспечивать нас с Вами всеми материалами для быстрого внедрения продукта на проект. Документация, видеокурсы, упаковка, PDF презентации – всё это понижает порог вхождения в ПО. Если у разработчика этот аспект развит слабо, то у Вас будут большие проблемы с освоением продукта.
Кейсы помогут Вам убедиться в том, что ПО действительно помогает клиентам. И в том, что его действительно можно внедрить и на Вашем проекте.
Стоимость дает нам дополнительные аргументы в пользу выбора того или иного программного продукта. Но только на основании цены нельзя делать какие-то выводы о продукте. Цену рассматриваем именно в дополнение к сравнению. Так как неверно подобранное программное решение может привести к дополнительным затратам денежных средств, связанных с привлечение третьих лиц для доработки и сопровождения ПО.
Аккаунт-менеджер сможет создать такой сервис, когда программный продукт приобретается с довольствием и с осознанием того, что получил ты намного больше, нежели вложил.
И вот, пройдя по всем пунктам нашего с Вами чеклиста, можно с высокой долей вероятности выбрать действительно достойное программное решение, которое будет помогать Вам и Вашему бизнесу.
Оригинал статьи вы можете найти на нашем .
Получить консультацию можно любым удобным для вас способом:
с помощью соц. сетей, мессенджеров либо онлайн-чата на нашем сайте
