Клиенту не нравится результат. Что я уточняю до переделки
Как разобраться в недовольстве клиента, отличить ошибку от нового ожидания и согласовать правки. Вопросы для разговора, таблица замечаний и условный пример AI-помощника.
«Я ожидал другого». «Как-то не то». «Нужно всё переделать».
Такая обратная связь может относиться к чему угодно: неверному ответу помощника, неудобному сценарию, оформлению страницы или тому, как команда показала работу. По одной фразе нельзя понять, что именно нужно исправить.
Мой первый шаг — разобраться в несовпадении ожиданий. Я хочу понять, какой результат человек увидел, что собирался с ним делать и в какой момент понял, что это ему не подходит. После этого можно обсуждать переделку.
В предыдущей статье я разбирал дополнительные задачи. Здесь ситуация тоньше: клиент пока не просит новую функцию. Он говорит, что полученная работа его не устраивает.
1. Сначала я даю человеку объяснить, что не получилось
Начинать с защиты каждого решения — плохой способ услышать замечание. Но обещание «сейчас всё переделаем» тоже преждевременно: команда ещё не понимает, что должно измениться.
Я бы ответил так:
Понимаю, что результат вас не устраивает. Давайте возьмём конкретный пример: что вы хотели получить, что увидели и где возникло расхождение. После этого предложу, как его исправить.
Клиенту не обязательно сразу формулировать точное техническое задание. Он может показать неудобный экран, прочитать неудачную фразу или описать действие, которое не смог выполнить. Моя задача — помочь перевести это в рабочее описание.
Полезно также проверить, что мы смотрим на одну версию. Иногда обсуждается старый файл, промежуточный вариант или результат на других исходных данных. Это стоит выяснить спокойно, не превращая разговор в поиск виноватого.
Если человек говорит о серьёзной ошибке, я уточняю её отдельно от остальных пожеланий. Например, неверное обещание клиенту нельзя потерять в общем списке замечаний к стилю ответа.
2. Я прошу показать пример и описать ожидаемый результат
Фраза «помощник отвечает плохо» слишком широкая. Мне нужны исходное обращение, ответ помощника и объяснение, почему этот ответ не подходит. Для чувствительных данных достаточно обезличенного примера, сохраняющего смысл ситуации.
Я задаю несколько вопросов:
- В какой ситуации появился этот результат?
- Что человек хотел сделать с его помощью?
- Какой конкретно фрагмент мешает?
- Как выглядел бы приемлемый вариант и почему?
- Что в текущем результате уже подходит и должно сохраниться?
Последний вопрос помогает не выбросить вместе с неудачным решением то, что работает.
Условный пример. AI-помощник готовит черновики ответов на входящие заявки. Менеджер читает их перед отправкой. Собственник говорит: «Тексты сухие, клиент так не купит».
Я бы попросил разобрать один ответ. Возможно, там длинное приветствие, перечисление всех услуг и никакой связи с вопросом покупателя. Тогда замечание можно уточнить: ответ должен начинаться с сути запроса, использовать понятные слова и предлагать уместный следующий шаг.
Это уже основа для правки. А связь с продажами ещё предстоит проверять отдельно: одобрение текста само по себе не доказывает, что сделок станет больше.
В материале Nielsen Norman Group о разборе дизайна предлагается связывать замечания с целями работы и задачами пользователя. Я использую этот принцип шире: при обсуждении текста, интерфейса или автоматизации возвращаю разговор к тому, что человеку нужно сделать.
3. Я различаю ошибку, неясное ожидание и новую цель
После уточнения примера нужно понять причину расхождения. От неё зависит и решение, и разговор об условиях.
Ошибка относительно договорённостей. Мы согласовали, что помощник не обещает срок без подтверждённых данных, а в ответе такой срок появился. Я фиксирую несоответствие и предлагаю исправление в рамках принятого обязательства. Заодно проверяю, где ещё может возникнуть та же проблема.
Неясное ожидание. В описании было «дружелюбный ответ», но стороны представляли разный тон. Здесь полезнее сравнить примеры и уточнить правило, чем спорить о значении слова. Если я не помог достаточно ясно описать результат на старте, это тоже часть разбора.
Удобство, которое не было проверено. Формально все функции есть, но менеджеру приходится открывать несколько окон, чтобы выполнить простое действие. Я бы посмотрел сам сценарий. Выполнение списка функций ещё не отвечает на вопрос, удобно ли человеку работать.
Новая цель. Сначала ожидали черновик для менеджера, теперь хотят самостоятельную отправку сообщений и ведение диалога. Тогда нужно отдельно обсудить полномочия, проверки и состав работ. Порядок такого разговора я описал в статье о дополнительных задачах.
Эти ситуации могут встретиться одновременно. Я не хочу оценивать весь список одним словом «переделка» и автоматически относить каждое замечание к платным дополнениям. Сначала нужно разобраться по пунктам.
4. Я превращаю общие оценки в проверяемые замечания
Уточнение должно помочь увидеть проблему, а не заставить клиента говорить профессиональными терминами. Ниже — условные примеры такого перевода.
| Что говорит клиент | Что я уточняю | Что можно проверить после правки |
|---|---|---|
| «Слишком сухо» | Какая фраза звучит неуместно и какой тон нужен в этой ситуации? | Тон ответа соответствует согласованному образцу, смысл запроса сохранён |
| «Неудобно пользоваться» | На каком действии приходится останавливаться или искать подсказку? | Пользователь выполняет согласованный сценарий в изменённом интерфейсе |
| «Помощник врёт» | Какое утверждение неверно и какой источник его опровергает? | Неверное утверждение устранено, при нехватке данных помощник уточняет |
| «Выглядит непрофессионально» | Что именно создаёт такое впечатление: текст, структура, изображения? | Выбранный фрагмент соответствует согласованному образцу |
| «Я хотел совсем другое» | Какую задачу должен был решать результат и где она была описана? | Обе стороны одинаково описывают ожидаемый итог перед новой работой |
Правая колонка задаёт направление проверки. Для реального проекта её нужно уточнить на конкретных материалах. Например, «короче» не всегда означает «лучше»: можно убрать важное условие и получить лаконичный, но неверный ответ.
Субъективные предпочтения тоже имеют значение. Если речь о голосе автора или визуальном стиле его бренда, не обязательно искать числовую метрику для каждого решения. Полезнее согласовать несколько характерных примеров и объяснить, что именно в них подходит.
В разборе критериев приёмки Atlassian акцент сделан на ясных, проверяемых условиях результата. Для меня практический вывод такой: до правки стоит договориться, по чему мы будем судить, что замечание учтено.
5. Перед большой переделкой я предлагаю проверить небольшой фрагмент
Если причина недовольства пока не ясна, полная переделка может повторить ту же ошибку в другом оформлении.
В условном примере с помощником я бы сначала подготовил исправленный ответ на выбранное обращение. Рядом показал бы исходный вариант, новый и короткое пояснение: что изменено и какое замечание это закрывает.
Клиенту проще оценить конкретную разницу. Например: «Теперь текст звучит нормально, но следующий шаг всё ещё не подходит — покупатель просил расчёт, а мы зовём его на общую презентацию». Значит, нужно уточнить логику ответа, а не ещё раз менять прилагательные.
После согласования направления проверяю другие подходящие ситуации. Один удачный ответ не подтверждает качество помощника в целом. Изменение может улучшить тон, но убрать уточняющий вопрос или добавить неподтверждённое обещание. Поэтому прежние требования продолжают действовать.
Для AI-сценария полезно добавить обнаруженный случай в контрольную выборку и проверить обновление вместе с другими примерами. При этом не стоит подгонять проверку так, чтобы новая версия обязательно выглядела удачной.
Если ошибка уже влияет на рабочий процесс, вопрос временных ограничений решается сразу. Согласование красивого образца не должно задерживать устранение подтверждённого сбоя.
6. Я фиксирую, что меняем и кто принимает решение
После разговора команде нужен понятный список действий. Для каждого замечания я хочу видеть исходный пример, ожидаемое поведение, предлагаемую правку, ответственного и способ проверки.
Отдельно согласуем сроки. Если выяснилась новая задача, сначала оцениваем её влияние на объём и стоимость. Если речь об исправлении ошибки, это так и называем. Неясные пункты остаются открытыми, пока по ним нет решения.
Вот условный пример сообщения после разбора:
Зафиксировал замечания к черновикам ответов: длинное вступление, общие формулировки и неуместное предложение следующего шага.
Сначала покажем исправленный ответ на выбранном обращении. Начнём с сути запроса, уберём перечисление лишних услуг и уточним, какие данные нужны для расчёта. Подтверждённые факты и проверку менеджером сохраняем.
После согласования образца проверим другие обращения. До начала правки подтвердим дату показа. Отдельное пожелание об автоматической отправке сообщений обсудим как изменение сценария.
Если замечания дают несколько людей, я уточняю, кто соберёт итоговое решение со стороны клиента. Один участник может просить короткий ответ, другой — подробное объяснение. Команде нужен согласованный ориентир, а не задача угадать, чьё сообщение важнее.
7. AI помогает собрать обратную связь, но не решает за клиента
AI может сгруппировать замечания из переписки, найти повторы и подготовить черновик списка правок. Я бы сохранял рядом исходную формулировку и ссылку на её источник. Тогда видно, что сказал человек и как это было понято.
Предположения важно отмечать отдельно. Фразу «не нравится подача» модель не должна самостоятельно превращать в решение «переписать весь текст» или в подтверждённый запрос на новую функцию.
Перед передачей команде я проверяю список и согласую спорные пункты с клиентом. После исправления возвращаюсь к исходным примерам и показываю, что изменилось. Если замечание остаётся, нужно снова выяснить причину, а не просто закрыть задачу в системе.
Для меня хороший результат этого разговора — ясность. Клиент понимает, что его услышали и как будет выглядеть следующий вариант. Команда знает, что исправлять и как проверить работу. И переделка начинается с понятной задачи.