Содержание

    Как общаться с клиентом до, во время и после работы над проектом, чтобы не захлебнуться правочками? 12 советов

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

    Мы тоже часто оказывались в таких ситуациях. Специалисты тратили на проекты на 30% больше времени, чем закладывалось в сметы, окупаемость проектов падала — из-за «правочек» мы теряли деньги. Но мы вовремя выработали и внедрили несколько правил, которые и сегодня помогают сдавать CRM-игры, рассылки, лендинги и другие продукты в срок и с минимальными замечаниями от клиентов.

    В этой статье мы поделимся советами: как выстроить общение с заказчиком перед началом, в процессе и по завершении работы, чтобы правки не мешали.

    До

    Зафиксируйте условия работы с правками в договоре

    Все принципиальные моменты нужно обсуждать перед стартом проекта — что называется, на берегу. Это общее правило применимо и к работе с замечаниями и комментариями.

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

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

    Проговорите их лично

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

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

    Определите инструменты для общения и комментирования

    Вряд ли кому-то нравится, когда клиент пишет (и звонит!) везде. Заранее договоритесь с клиентом, где вы будете ждать сообщения и ответы друг от друга. Площадок для коммуникации сегодня более чем достаточно, так что подобрать удобную наверняка получится.

    Мы для общения с клиентами обычно используем почту и таск-менеджер Basecamp, а для срочных вопросов — мессенджеры. А вот непосредственно правками лучше заниматься сразу, например, в Google Docs (для текстов) или Figma (для дизайна). Там можно оставлять комментарии к конкретным абзацам, словам и визуальным элементам. Обеим сторонам легче отрабатывать короткие замечания по отдельности вместо длинного общего списка. А ещё это снижает риск запутаться.

    работа с правками в Фигме

    Вот так мы прямо в Figma обсуждали нашу настолку «ТЗ»

    Выясните, кто у клиента принимает решения

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

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

    Во время

    Дожидайтесь всех замечаний

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

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

    переписка с клиентом о правках

    Просите обосновывать правки

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

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

    Напоминайте о цели проекта

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

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

    Отговорите клиента от аудиосообщений

    К голосовым сообщениям можно относиться по-разному, но для работы с правками это точно ужасный формат. Замечания сложно соотнести с элементами проекта, передать специалисту и особенно — найти снова, если спустя время потребуется вернуться к нему.

    общение с клиентом о правках

    Уважаемые знатоки, какие варианты CTA предлагал клиент?

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

    • Вежливо напомнить о договоре, где указаны форматы замечаний.
    • Созвониться, если у клиента действительно нет возможности описать правки текстом.

    Фиксировать итоги созвонов текстом

    Результаты всех разговоров — личных и в Zoom, плановых и спонтанных — нужно записывать в официальных каналах. Причём клиент должен подтвердить ваш конспект. Так вы оба убеждаетесь, что поняли друга друга правильно и ничего не забыли. Иначе в будущем может возникнуть ситуация из разряда «мы же договаривались совсем о другом».

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

    Попросите не редактировать сообщения

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

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

    Не закрывайте комментарии

    Отработанные замечания в Google Docs, Figma и так далее лучше оставлять активными до тех пор, пока их автор не проверит исправления. Так клиенту будет проще отслеживать прогресс, а вам не придётся напоминать ему, что же он предлагал, когда смотрел работу неделю назад.

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

    После

    Представляйте работу лично

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

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

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

    И ещё раз

    Эти правила помогают нам предотвращать конфликтные ситуации, запускать проекты в срок и экономить силы, нервы и время сотрудников. Закрепим:

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

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

    Проверьте нашу работу с замечаниями на практике
    Давайте сделаем что-нибудь вместе!
    Имя
    Корпоративный email *
    Array
    (
        [0] => WP_Term Object
            (
                [term_id] => 1425
                [name] => Статьи
                [slug] => articles
                [term_group] => 0
                [term_taxonomy_id] => 1907
                [taxonomy] => category
                [description] => 
                [parent] => 0
                [count] => 660
                [filter] => raw
                [cat_ID] => 1425
                [category_count] => 660
                [category_description] => 
                [cat_name] => Статьи
                [category_nicename] => articles
                [category_parent] => 0
            )
    
    )
    
    Поделиться статьёй
    Подписаться на рассылку