9737
СОГЛАСЕН С ОБРАБОТКОЙ ЛИЧНЫХ ДАННЫХ

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

Обсуждения-аналоги

Скрыть / Показать Сортировать по дате
2013-02-06 15:26:07
Ирина Пономарева » Всем

Уважаемые коллеги, вопрос по допродажам.

В нашей компании нередко встречается такая ситуация:

Клиент заказал разработку нетипового сайта, на который изначально было подробно прописано техническое задание до мелочей, отрисованы макеты тоже заранее и утверждены.

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

- он может не захотеть за это платить, аргументировав тем, что мы сами должны были изначально подумать получше и сделать сразу наиболее удачным способом.

Получается, что с одной стороны мы хотим предложить доработку, но с другой - не хотим делать это бесплатно. Включать такие доработки в тарифы на поддержку сайтов нецелесообразно, так как распределяются они (доработки) неравномерно и по объему очень разные. Мелкие мы и так по поддержке делаем (поддержка платная).

Вопрос в том, как преподнести Клиенту доработку только что разработанного сайта так, чтоб он обрадовался?

2013-02-06 15:31:52
Ирина Пономарева » Всем

Добавлю, что специально опрос Клиентов не проводился, но кто-то нормально относится к доработкам, а кто-то отвечает именно так, как приведено выше.

Думаю, стоит разработать речевой модуль на такую продажу.

Возможно у кого-то из вас появятся идеи по аргументированию.

Заранее большое спасибо!

2013-02-07 09:11:03
Андрей Жуков » Ирина Пономарева

Добрый день!

А у Вас есть поддержка этих разработанных сайтов или их Клиент забирает, и сам потом поддерживает?

С Уважением,

2013-02-07 16:03:39
Андрей Курьян » Ирина Пономарева

Конечная цель: клиент должен сам заказать реализацию предложений по доработке. 

Как минимум, клиент должен узнать о существовании таких предложений. Еще лучше, если клиент узнает об этих предложения не в форме "если сделать, то будет лучше", а, например, в форме, "если не сделать, то будет плохо потому что...". 

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

2013-02-14 09:06:30
Ирина Пономарева » Андрей Жуков

Андрей, у нас есть поддержка разработанных сайтов. Есть 5 тарифов по объему поддержки. Но в тарифы доработки не входят, так как размер доработки может сильно отличаться и ее нужно каждый раз обсчитывать.

В тарифы входит поддержка хостинга, домена, почты, лечение вирусов, обновления сайта, модерация поступающих на сайт сообщений, пополнение интернет-магазинов и т.п. То есть работа, которая примерно равномерно поступает каждый месяц. Объем у всех разный - поэтому 5 тарифов от 500 до 20000 в мес.

2013-02-14 09:08:34
Ирина Пономарева » Андрей Курьян

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

Спасибо!

2013-03-03 16:29:51
Андрей Жуков » Ирина Пономарева

Добрый день!


Андрей, у нас есть поддержка разработанных сайтов...


А там у них есть "личные кабинет" или т.п. - я имею в виду, чтобы 1 сообщение можно было направить сразу всем?


С Уважением,

2013-03-03 17:53:04
Ирина Пономарева » Андрей Жуков

Андрей, центр поддержки на базе API Planfix сейчас как раз проектируется, по-моему идея отличная и то, что вы об этом написали еще раз подтверждает правильность задумки.

А что еще кроме общих уведомлений (скидки, акции, изменение тарифов, профилактические работы и т.п.) , баланса на "счете" по числу обновлений за месяц - что еще может быть там полезно людям?

Например, можно приучать их к интерфейсу поддержки уже на этапе разработки, например, создавать для каждого новостную ленту, где сообщать о ходе выполнения задач ("сегодня подготовили 5 макетов страницы Заказа товара - вам необходимо утвердить или внести корректировки"... потом: "сегодня вы утвердили макет2 и т.п.", "завтра ваш сайт будет готов".).


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


2013-03-04 11:06:33
Дмитрий Гончаренко » Ирина Пономарева
Но после разработки и запуска проекта через месяц-два мы сами замечаем некоторые моменты, которые можно было сделать по-другому, улучшить. Бывает, что у Клиента в процессе у самого меняется виденье проекта, бывает, что мы сами находим что-то новое также уже в процессе. Я думаю, сам факт таких находок вполне нормален, и это даже хорошо. Но вопрос в том, как преподнести это Клиенту, ведь есть минус

- он может не захотеть за это платить, аргументировав тем, что мы сами должны были изначально подумать получше и сделать сразу наиболее удачным способом.


Ирина, а почему плохо в этот момент менеджеру проекта, с которым скорее всего у клиента в процессе работы установились нормальные отношения, просто сказать: "Вы знаете, мы видим, что сайт можно улучшить таким-то и таким-то образом. Мы думаем, что это приведет к тому-то и тому-то. Как Вы к этому относитесь?"


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


Это решение, конечно, не является "сильным" - оно не решает противоречие "клиенту надо сказать о доработках, но клиенту нельзя/не хочется говорить о доработках". Но исходя из практики,  во многих случаях оно работает. Есть опыт работы по сайтам, коллеги схожим образом работают по кастомной настройке 1С.


С 1С, кстати, интересный случай, возможно он поможет взглянуть на ситуацию с другого ракурса. "Интересность" его в том, что заказчик кастомной настройки 1С очень четко видит, какие преимущества дадут ему доработки, зачастую он сам выходит с инициативой о доработках после опытной эксплуатации сданного проекта. За счет понимания выгод он готов платить за эти доработки.


Отсюда гипотеза: если сделать так, чтобы клиент понял выгодность доработок, он сам будет искать вас и просить их реализовать. Дело за "малым" - сделать так, чтобы клиент это понял :) К сожалению, сайты для многих это все еще rocket science, в отличие от бухгалтерии или систем управления, с которыми они плотно работают каждый день. Но может быть Вы или коллеги по triz-ri смогут что-то придумать в этом направлении.

2013-03-06 07:16:29
Ирина Пономарева » Дмитрий Гончаренко

Дмитрий, спасибо. Именно этого мы и хотим: показать, что мы заботимся о его проекте и хотим сделать лучше.

Адекватный клиент действительно нормально воспримет такие вещи.

Скандальный - да, будет требовать бесплатно, но мы в этом случае вправе и не предлагать. Буквально сегодня произошла похожая ситуация. Сайт делали 3 года назад, доработок за 3 года было буквально две. Устарел механизм анти-спама, но клиент согласился на платную переработку механизма сразу без вопросов, хоть он и находится на поддержке, клиент это понял, и его выгода очевидна - не будет спама (по 400 писем с сайта в день - это ужас).

С одной стороны нам стыдно, что мы это допустили и не предугадали заранее (над этим и нужно работать!), с другой - мы понимаем, что на тот момент их разработка была основана на новейшей для того времени технологии.

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

Думаю, вопрос дошел уже до уровня технологии, как именно регулярно напоминать Клиенту о возможных доработках, или звонить ему, или показывать через какой-то "личный кабинет", или делать рассылку всем. Мы как раз хотели взаимодействие с клиентом перевести в программу, чтоб они обновления (всякие новости, акции, баннеры, новые разделы и т.п.) сайта присылали не по почте, а через постановку задач в Планфиксе.

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

Есть ли смысл в этом? Клиенты не очень рады осваивать какой-то новый интерфейс, им привычна почта (мы их от устной постановки по телефону-то долго отучали).

Вопрос со "Службой клиентских задач" у нас подвешен уже давно, около года.


В идеале хорошо было бы вообще привить стереотип о том, что сайт нужно менять (полностью обновлять) каждые 3 (5) лет.

Т.к. устаревает и технология и дизайн, да и Киленту это позволит по-новому взглянуть на свой "виртуальный офис".


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

2013-03-06 13:05:51
Дмитрий Гончаренко » Ирина Пономарева


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

Это хорошее дело, такую практику надо продолжать и дальше - но это не решает ситуаций с усовершенствованиями, идеи которых возникли уже после сдачи проекта.


Думаю, вопрос дошел уже до уровня технологии, как именно регулярно напоминать Клиенту о возможных доработках, или звонить ему, или показывать через какой-то "личный кабинет", или делать рассылку всем. Мы как раз хотели взаимодействие с клиентом перевести в программу, чтоб они обновления (всякие новости, акции, баннеры, новые разделы и т.п.) сайта присылали не по почте, а через постановку задач в Планфиксе.

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

Есть ли смысл в этом? Клиенты не очень рады осваивать какой-то новый интерфейс, им привычна почта (мы их от устной постановки по телефону-то долго отучали).

Вопрос со "Службой клиентских задач" у нас подвешен уже давно, около года.

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

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

Другой вопрос, как построить технологию подбора предложений по модернизации для клиента?

Если поддерживаемых сайтов не так много, то информацию о них, условно говоря, можно держать и в голове. Но это не технологично: во-первых, вероятность что-то забыть увеличивается с ростом количества сайтов, а во-вторых "головы" могут менять место работы.

Как вариант, можно хранить информацию о каждом сайте в виде набора блоков функционала с коротким описанием уровня реализации и актуальности каждого из них. Например: "Блок Антиспам. Реализация на механизме Х, актуальность - 2009 год". Такой подход помог бы при необходимости получать произвольные выборки, отвечающие на вопросы, к примеру "Какова актуальность антиспам-блоков на сайтах клиентов?"

Один из вариантов технологии поддержания связи с клиентом и стимулирования его к модернизации сайта может быть таким:

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

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

- Этот сотрудник делает выборку (или достает "из головы") клиентов, сайты которых неплохо бы модернизировать в ключе, рассматриваемом в статье. Затем он готовит небольшое письмо примерно по такому сценарию: "Здравствуйте, <Имя представителя клиента>! На днях я прочитал интересную статью о том-то и том-то. Она навела меня на мысль, что неплохо бы модернизировать блок <название блока> на Вашем сайте. Решил послать Вам эту ссылку: <ссылка на статью>. Как думаете, имеет смысл нам с Вами проработать модернизацию этого блока?"

- Письмо с типовым (для конкретной статьи) текстом рассылается клиентам из выборки. Если кто-то из них заинтересуется - идет дальнейшее общение и проработка конкретного предложения модернизации его сайта.

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

В идеале хорошо было бы вообще привить стереотип о том, что сайт нужно менять (полностью обновлять) каждые 3 (5) лет.

Т.к. устаревает и технология и дизайн, да и Киленту это позволит по-новому взглянуть на свой "виртуальный офис".

"Правильный" стереотип это дело хорошее, но очень уж затратное. Гораздо проще и эффективнее использовать существующие стереотипы клиентов, чем прививать им новые.


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

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

2013-04-29 16:37:46
Ирина Пономарева » Дмитрий Гончаренко

Прошу прощения, что долго не отвечала :)

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


Да, так и сделаем, спасибо!

Как вариант, можно хранить информацию о каждом сайте в виде набора блоков функционала с коротким описанием уровня реализации и актуальности каждого из них. Например: "Блок Антиспам. Реализация на механизме Х, актуальность - 2009 год". Такой подход помог бы при необходимости получать произвольные выборки, отвечающие на вопросы, к примеру "Какова актуальность антиспам-блоков на сайтах клиентов?"

Тоже отличная идея, посмотрим как технически это реализовать
Таким образом, Вы используете авторитет автора статьи для "продажи" клиенту модернизации. Если статьи будут интересными и слать такие письма Вы будете не слишком часто, то клиенты будут реагировать на это положительно.

Согласна, это стоит также взять на заметку, можно делать как рассылку, так и блог у себя на сайте

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

 Согласна со всем, написанном вами, насчет универсального движка все таки мы думаем, но возможно стоит не делать его слишком универсальным,  а ограничиться отдельными областями применения, но при этом широкой географией, сейчас как раз проводим опрос по выявлению стереотипов на эту тему, как будут результаты (после праздников), если интересно - напишу здесь

Больше спасибо за советы!



Яндекс.Метрика