RRRRR - 54.205.89.199

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

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 год". Такой подход помог бы при необходимости получать произвольные выборки, отвечающие на вопросы, к примеру "Какова актуальность антиспам-блоков на сайтах клиентов?"

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

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

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

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

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

Уважаемые Коллеги!

Если Вам нравится наш Форум, Вы можете поддержать его, отправив любую сумму (тогда выберите опцию "Спасибо за Форум").

Вы также можете поддержать конкретное обсуждение и получить гарантированный ответ от наших специалистов (тогда выберите опцию "Прошу эксперта ответить в этой теме").
Задайте Ваш вопрос здесь.

Большое Спасибо!


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