Почему уходят клиенты: 5 кейсов от NexGenDesign

Когда мы становимся клиентами и платим деньги, то судей строже сложно найти: 5 минут ожидания заказа – негативный отзыв в Swarm, каждая проблема сразу постится на Facebook. Но часто, стоит нам вернуться на рабочие IT-шные места, мы перестаем вставать на место клиента, забываем выложить новый релиз или отправить обещанный файл к условленному сроку.

Кажущееся решение – провести опрос, идентифицировать и исправить проблемные точки. Если бы сделать было так же легко, как написать! За последние 3 года мы в NexGenDesign наблюдаем одну и ту же картину – пожелания клиентов не меняются, а проблемы клиентов с командами-подрядчиками остаются прежними.

Пожелания клиентов не меняются, а проблемы клиентов с командами-подрядчиками остаются прежними

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

1. Срыв сроков

За последние 3 года я не вспомню ни одну конференцию, на которой иностранные докладчики и клиенты не говорили о проблеме с выполнением сроков. Срыв сроков – первая и главная проблема. Мы легко обещаем сдать проект к оговоренному сроку. Потом приходит час Х, клиент ждет, но проект еще не сдан: мы впопыхах заканчиваем работу.

Мы вели проект, в котором срывались сроки сдачи первых двух этапов работ. Команда ни разу не предупредила, что не успевает, хотя вопросы о сроках и готовности неоднократно задавались. О срыве сроков узнавали в последний день. Давайте представим себя на месте клиента: «Ок, первый этап. Не успели, вылез лишний баг. Ну ребята же умные, у них менеджеры, они учтут ошибки на следующем этапе».

Второй этап проекта не сдан вовремя: «Ребята, вы понимаете, что означают сроки и зачем заранее закладываться на срыв проекта! Что мне говорить 500 клиентам, которые ждут обновлений через 2 дня!». По опыту работы, каждая команда разработчиков срывала хотя бы один срок сдачи. Иногда мы успевали предупредить клиента. К этой же проблеме относится пропуск запланированных звонков и встреч с клиентами.

Разберитесь, в чем причина срыва сроков сдачи

Посчитайте соотношение – сколько проектов за последние полгода сданы в срок к количеству срывов. Разберитесь, в чем причина срыва сроков сдачи. Разберитесь с организационными проблемами. Сдача проекта в срок – то, за что клиенты вам платят деньги.

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

2. Изменение бюджета после подписания контракта

Как рассуждает клиент после заключения контракта, с прописанной стоимостью работ (в час или за проект): «Фух, можно теперь заняться другими делами, тут проблем нет». Когда мы говорим, что не укладываемся в оговоренный бюджет, что стоимость выросла, клиент испытывает стресс. Представьте, что к вам подошел новый сотрудник, проработавший месяц, и попросил бы у вас повышения зарплаты, потому что: «Цены выросли, а я не так представлял себе работу». То же самое испытывает ваш клиент.

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

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

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

Пересмотр расценок для fixed price проектов возможен только в случае изменения объема работ

Пересмотр расценок для fixed price проектов возможен только в случае изменения объема работ или неожиданно возникших технических ограничений. Других адекватных оснований для пересмотра бюджета нет. Изменяя цену, вы рискуете контрактом.

Если вы уже пошли на уступки клиенту, то допустимо ограничить срок действия специального предложения. Как рассуждает клиент после заключения контракта, с прописанной стоимостью работ (в час или за проект): «Фух, можно теперь заняться другими делами, тут проблем нет». Не ставьте клиентам ультиматум и не заставляйте их отвечать за ваши собственные решения и ошибки.

Подумайте, что не учли кроме программирования, тестирования и дизайна. Оцените реалистично бюджет проекта. Сориентируйте клиента сразу. Это золотое правило, которое поможет вам быть предсказуемыми для клиента, а значит – надежными.

3. Состояние «готово», когда ничего не готово

Пару лет назад, во время встречи с клиентами в Киеве, я слушала истории работы с другими подрядчиками. Они рассказали о команде, для которой понятие «проект готов» означало готовность на 70%. После двух фидбеков она доходила до 90%, но ни разу не было проекта, готового на 100%.

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

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

4. Непонимание задачи

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

Случилось так потому, что разработчик решил, что «в общем» задача ему ясна и не стал уточнять детали, чтобы не показаться неопытным. В итоге потребовались дополнительные изменения в коде.

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

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

5. Upsell

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

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

Делайте upsell тогда, когда клиент находится на эмоциональном подъеме и доволен вашей работой

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

Послесловие

Общение с клиентом крайне важно, не пренебрегайте им! Мы сами формируем ожидания клиентов. Часто мы ждем неизвестного, гадаем, совпадет ли результат работы с ожиданиями клиента, вместо того, чтобы формировать эти ожидания. Общаться с клиентом нужно ПОСТОЯННО: когда проект идет по плану и наоборот. Информируйте клиента о новостях.

Не ждите, когда вас спросят. Начинайте диалог сами – общение не страшно, оно нормально для клиентов. Они ждут этого. Когда к нам приходит новый клиент, мы спрашиваем, работал ли он с разработчиками или командами в прошлом. Часто мы слышим знакомую «боль»: клиент упоминает пункты этой статьи – он испытал такие ситуации на своей шкуре.

И нам, и команде стоит усилий убедить клиента, что проекты выполняются и по-другому. Мы верим, что каждая команда разработчиков в состоянии исправить главные ошибки и стать лучше для клиентов. И тогда клиенты отнесутся проще к найму новых подрядчиков на проект – ведь положительный опыт скажет им, что и в этот раз проект пройдет ХО-РО-ШО!