Работа с клиентами для новичков: как вести переговоры и не теряться в правках

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

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

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

Почему новички теряются в работе с клиентами

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

На практике обычно происходит так:

• Клиент описывает задачу нечётко, потому что сам пока не до конца понимает, какой результат ему нужен
• Ты интерпретируешь его слова по-своему и начинаешь работу, исходя из собственной логики
• Результат не совпадает с ожиданиями клиента, хотя формально ты вроде бы всё сделал
• Начинаются правки, причём часто хаотичные и даже противоречивые
• Обе стороны разочарованы: клиент думает, что его не услышали, а ты — что с задачей изначально было невозможно нормально работать

Это замкнутый круг, и он знаком почти каждому, кто начинает работать на фрилансе или берёт первые заказы в студийном формате. Хорошая новость в том, что решается он не «талантом общения», а структурой. Чем лучше ты организуешь переговоры, тем меньше в проекте лишних эмоций, бесконечных правок и потери времени.

Этап 1: первичный контакт и уточнение задачи

Не спеши с ответом

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

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

Что делать вместо этого:

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

Например, если клиент пишет: «Нужен дизайн лендинга для моего сервиса», нормальная рабочая реакция — не «Сделаю, сколько платите?», а серия уточнений:

• Какой именно сервис и в чём его ценность?
• Кто целевая аудитория?
• Лендинг нужен для продажи, регистрации или сбора заявок?
• Есть ли брендбук, фирменный стиль, существующий сайт?
• Сколько секций предполагается?
• Есть ли готовые тексты и материалы?
• Какой бюджет и какие сроки?

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

Задавай уточняющие вопросы правильно

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

Плохо:

Привет! У меня много вопросов. Какой сервис? Кто аудитория? Есть брендбук? Сколько секций? Какой бюджет? Когда нужно?

Хорошо:

Спасибо за запрос! Чтобы я понял задачу правильно, мне нужны уточнения. Вот что важно знать:

О вашем сервисе:

• Что конкретно вы продаёте или предлагаете?
• Кто ваша целевая аудитория? (возраст, профессия, проблема, которую вы решаете)

О лендинге:

• Это лендинг для продажи услуги или для сбора контактов?
• Сколько основных секций должно быть? (например: hero, преимущества, отзывы, CTA)
• Есть ли уже готовый текст или нужно писать с нуля?

О стиле:

• Есть ли у вас брендбук или примеры дизайна, который вам нравится?
• Какой стиль вы предпочитаете? (минималистичный, яркий, корпоративный и т.д.)

О сроках и бюджете:

• Когда нужен результат?
• Какой бюджет вы готовы выделить?

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

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

Слушай внимательнее, чем говоришь

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

Например, клиент пишет: «Хочу минималистичный дизайн, но чтобы там было много ярких элементов и побольше всего на первом экране». Это типичный конфликт ожиданий. Сам клиент может его не видеть, но если ты пропустишь это мимо, конфликт всплывёт уже на этапе правок.

Твоя задача — аккуратно подсветить противоречие и помочь клиенту уточнить приоритет:

Я заметил, что вы упомянули минималистичный стиль, но также хотите много элементов и ярких акцентов. Здесь может возникнуть конфликт. Давайте уточним: вам ближе чистый, сдержанный дизайн с несколькими сильными акцентами? Или более насыщенный, визуально активный вариант?

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

Если говорить совсем практично, сильный исполнитель отличается от новичка не только качеством макета, но и способностью распутывать неясность ещё до начала работы.

Этап 2: создание технического задания

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

Многие новички боятся ТЗ, потому что им кажется, что это что-то громоздкое, бюрократическое и «для больших студий». На деле ТЗ — это просто письменная фиксация того, о чём вы договорились. Оно нужно не для формальности, а чтобы обе стороны одинаково понимали, что именно будет сделано, в каком объёме и в каких рамках.

Что должно быть в ТЗ

1. Общее описание проекта

Кратко, в 2–3 предложениях, зафиксируй суть задачи. Это база, которая выравнивает ожидания обеих сторон.

Пример:

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

2. Целевая аудитория и задача

Опиши, для кого создаётся решение и какое действие должен совершить пользователь. Это особенно важно в дизайне: без понимания аудитории визуальные решения быстро превращаются в субъективный спор о вкусах.

Пример:

• Целевая аудитория: фрилансеры 25–45 лет, которые работают на себя или в малой команде
• Задача: убедить в преимуществах сервиса и получить регистрацию
• Основное возражение: «Я и так справляюсь без такого сервиса»

3. Структура и содержание

Перечисли все секции лендинга и содержание каждой. Чем меньше абстракции, тем меньше сюрпризов в процессе.

Пример:

1. Hero-секция: заголовок, подзаголовок, кнопка регистрации, изображение
2. Преимущества: 3–4 основных преимущества с иконками
3. Как это работает: пошаговый процесс (3–4 шага)
4. Отзывы: 3–4 отзыва с фото и именами
5. Призыв к действию: финальная секция с кнопкой регистрации

4. Стиль и визуальные ориентиры

Зафиксируй стиль, цвета, типографику и референсы. Это сильно снижает риск ситуации, когда клиент ожидал одно визуальное направление, а ты сделал совсем другое.

Пример:

• Стиль: современный, чистый, с акцентом на функциональность
• Цвета: основной цвет — синий (#0066FF), дополнительный — белый и серый
• Типография: sans-serif (Roboto или похожий шрифт)
• Примеры: [ссылка на Dribbble], [ссылка на другой сайт]

5. Технические требования

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

Пример:

• Адаптивность: мобильные, планшеты, десктоп
• Браузеры: Chrome, Firefox, Safari (последние версии)
• Формат доставки: Figma файл + экспортированные изображения

6. Сроки и количество правок

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

Пример:

• Срок выполнения: 5 рабочих дней
• Количество раундов правок: 2 раунда (по 5 правок в каждом)
• Дополнительные правки: 500 руб. за раунд

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

Как оформить ТЗ, чтобы клиент его согласовал

Когда ТЗ готово, отправь его клиенту и попроси не просто «посмотреть», а проверить по конкретным вопросам. Так ему будет проще дать осмысленную обратную связь.

Я составил техническое задание на основе нашего разговора. Пожалуйста, прочитай и скажи:

• Всё ли правильно я понял?
• Что нужно добавить или изменить?
• Есть ли противоречия или неясности?

Важно, чтобы мы согласовали ТЗ до того, как я начну работу. Так мы избежим недопониманий и правок.

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

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

Этап 3: как вести переговоры, чтобы не потеряться в правках

Устанавливай границы с самого начала

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

Что нужно сообщить клиенту:

• Как часто ты будешь отправлять обновления
• В каком формате клиент должен присылать правки
• Сколько времени уходит на обработку правок
• Когда заканчиваются правки, включённые в стоимость

Пример сообщения:

Отлично, ТЗ согласовано! Вот как мы будем работать:

Процесс:

• Я буду отправлять черновики каждые 2 дня
• Ты отправляешь правки через комментарии в Figma (так удобнее всем)
• Я беру 1–2 дня на доработку

Правки:

• В стоимость включены 2 раунда правок (по 5 правок в каждом)
• Правка — это небольшое изменение (цвет, размер текста, сдвиг элемента)
• Серьёзные переделки (например, новая компоновка) считаются дополнительно

Сроки:

• Первый черновик: [дата]
• Финальный вариант: [дата]

Если что-то непонятно, спросим сейчас, пока я ещё не начал.

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

В реальной удалённой работе это особенно важно. Если не задать рамку, клиент начинает писать в Telegram, почту, комментарии в Figma и голосовые сообщения одновременно. В итоге теряются решения, путаются версии, а ответственность размывается.

Различай правки и переделки

Это один из самых частых источников конфликтов. Клиент может искренне считать, что просит «пару небольших изменений», хотя по факту речь идёт о новой концепции или серьёзной перестройке макета.

Правка — это небольшое изменение:

• Изменить цвет кнопки
• Увеличить размер заголовка
• Сдвинуть элемент на 20 пиксель
• Изменить текст

Переделка — это серьёзное изменение:

• Переделать всю компоновку секции
• Добавить новую секцию, которой не было в ТЗ
• Изменить концепцию дизайна
• Переписать весь текст

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

Если видишь, что речь идёт о переделке, проговори это прямо:

Спасибо за правки! Я посмотрел твои комментарии. Вот что я вижу:

Правки (включены в стоимость):

• Увеличить размер заголовка на hero
• Изменить цвет кнопки на зелёный
• Добавить больше пространства между секциями

Переделка (дополнительно):

• Переделать компоновку секции «Преимущества» — это требует нового макета и изменения всей структуры. Это не входит в 2 включённых раунда правок.

Давайте уточним: ты хочешь переделать эту секцию? Если да, это будет [стоимость] дополнительно. Или может быть, мы найдём компромисс в рамках правок?

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

Собирай правки в один пакет

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

Почему это важно:

• Ты экономишь своё время и не распыляешь внимание
• Клиент получает более собранный и предсказуемый процесс
• Снижается риск пропустить часть замечаний

Удобная формулировка:

Спасибо за правки! Я собираю все твои комментарии и буду работать над ними в течение [времени]. Отправлю обновление [дата].

Если у тебя есть ещё правки, отправь их до [дата], и я включу их в этот же раунд.

Это простое правило хорошо работает и в малых проектах, и в долгих клиентских процессах. По сути, ты приучаешь клиента работать раундами, а не импульсивными сообщениями «давай ещё тут чуть-чуть подвинем».

Не спорь, а объясняй

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

Вместо спора объясняй последствия и предлагай альтернативу.

Плохо:

Нет, так не будет хорошо смотреться. Заголовок слишком большой.

Хорошо:

Я понимаю, что ты хочешь выделить заголовок. Но если его сделать такого размера, он займёт половину экрана на мобильнике, и текст под ним будет плохо читаться. Давайте найдём компромисс: увеличим размер на 20%, но не больше. Так заголовок будет выделяться, но текст останется читаемым.

Такой ответ показывает, что ты не защищаешь своё эго, а решаешь задачу. Для клиента это принципиально важно.

Если же клиент всё равно настаивает, сделай как он просит — но зафиксируй это письменно:

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

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

Этап 4: документирование и защита от бесконечных правок

Веди историю изменений

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

В Figma версии сохраняются автоматически, что очень удобно. Если работаешь в другом инструменте, именуй файлы последовательно: Проект_v1, Проект_v2, Проект_v3_правки_раунд1 и так далее.

Из практики: чем сложнее проект и чем больше в нём участников, тем важнее версионирование. Это касается и дизайна, и текстов, и no-code сборки, и материалов для разработки.

Отправляй промежуточные результаты

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

Пример:

Вот первый черновик hero-секции. Что думаешь? Нужны ли правки, прежде чем я буду делать остальное?

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

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

Фиксируй согласование в письменном виде

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

Спасибо! Я фиксирую, что ты согласен с:

• Компоновкой hero-секции
• Цветовой схемой
• Типографией

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

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

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

Этап 5: завершение проекта

Подготовь финальный пакет

Когда проект завершён и все согласованные правки внесены, не стоит просто отправлять один файл фразой «всё готово». Финальная передача результата — это тоже часть профессионального впечатления.

Подготовь полный пакет:

• Финальные файлы (Figma, PSD, Figma link — в зависимости от договорённости)
• Экспортированные изображения (PNG, JPG в нужных разрешениях)
• Гайд по использованию, если он нужен
• Исходники, если это было оговорено

Отправь всё с понятным сопроводительным письмом:

Готово! Вот финальный пакет:

• [Ссылка на Figma]
• [Скачать изображения]
• [Гайд по использованию]

Если что-то не так, дай знать. Я готов помочь.

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

Попроси обратную связь

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

Спасибо за проект! Мне было интересно с тобой работать. Если у тебя есть минута, расскажи: доволен ли ты результатом? Что прошло хорошо, а что можно было сделать лучше?

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

Практические инструменты для работы с клиентами

Вот несколько инструментов, которые помогают структурировать коммуникацию и не терять договорённости:

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

Типичные ошибки новичков (и как их избежать)

Ошибка 1: ты сразу начинаешь работать, не уточнив задачу

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

Как избежать: всегда проясняй задачу до старта. Задавай вопросы. Собирай вводные. Оформи ТЗ и согласуй его до начала работы.

Ошибка 2: ты не устанавливаешь границы с количеством правок

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

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

Ошибка 3: ты не различаешь правки и переделки

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

Как избежать: каждый список изменений сначала оценивай по объёму. Если это переделка, называй её переделкой и обсуждай отдельно.

Ошибка 4: ты спорил с клиентом вместо того, чтобы объяснить

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

Как избежать: не спорь в лоб. Объясняй последствия, говори языком задачи и предлагай рабочую альтернативу. Если клиент настаивает — выполняй запрос, но фиксируй договорённость письменно.

Ошибка 5: ты не документируешь согласования

Почему это плохо: позже клиент может сказать: «Мы это не утверждали» или «Я имел в виду не это», а у тебя не будет ни подтверждения, ни ясной истории проекта.

Как избежать: всё важное фиксируй письменно. ТЗ, структура, направление дизайна, сроки, лимит правок — всё это должно быть задокументировано.

Как говорить «нет» клиенту вежливо, но твёрдо

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

Как это делать:

1. Признай его просьбу. Покажи, что ты её услышал: «Я понимаю, что ты хочешь переделать компоновку».
2. Объясни, почему это невозможно или требует доплаты. Не просто отказывай, а связывай ответ с объёмом, временем и рамками проекта.
3. Предложи альтернативу. Это может быть дополнительная оплата, сдвиг сроков или компромиссный вариант в рамках текущего объёма.
4. Будь вежлив, но твёрд. Не нужно извиняться за собственные границы. Для профессионала это нормально.

Пример полного ответа:

Спасибо за правки! Я посмотрел твой комментарий про переделку компоновки секции. Я понимаю, что ты хочешь попробовать другой вариант.

Но это не входит в 2 включённых раунда правок, потому что это серьёзная переделка, которая требует нового макета и изменения всей структуры. Это займёт примерно 4–5 часов работы.

Вот что я предлагаю:

• Либо мы делаем эту переделку за дополнительные 2000 руб.
• Либо я предложу тебе 2–3 варианта компромисса в рамках текущей компоновки (например, изменим цвета, размеры, пространство между элементами).

Что ты выбираешь?

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

На длинной дистанции именно такие ответы и формируют твою репутацию специалиста, с которым удобно работать: он не «мягкий до бесконечности», но и не токсичный.

FAQ: ответы на частые вопросы

Вопрос: Как часто нужно отправлять обновления клиенту?

Ответ: Зависит от проекта. Если проект короткий (1–2 недели), отправляй обновления каждые 2–3 дня. Если проект длинный, можно реже. Главное — согласовать это заранее. Например: «Я буду отправлять обновления каждый понедельник и четверг». Для клиента важна не столько частота, сколько предсказуемость.

Вопрос: Что делать, если клиент не отвечает на мои вопросы?

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

Вопрос: Как поступить, если клиент просит что-то, что я не умею делать?

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

Вопрос: Что делать, если клиент хочет изменить всё в последний момент?

Ответ: Спокойно обозначь, что это переделка, а не обычная правка. Уточни объём изменений. Если запрос действительно критичный, обсуждай дополнительную оплату и/или перенос сроков. Если клиент не готов ни платить, ни двигать дедлайн, отправляй то, что уже было согласовано, и предлагай доработку как следующий этап проекта.

Вопрос: Как защитить себя от клиента, который постоянно просит правки?

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