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

Хорошо, что из каждой такой неприятности есть приятный выход.

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

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

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

а) Разочарование от неудовлетворенной просьбы.
б) Домыслы — вы наверняка не делаете этого для него потому, что не хотите.
в) Раздражение от полученной «отписки».

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

Не тратить время на 1 из 1000 клиентов, у которого что-то не работает и вообще не ясно, что это, кажется разумным, но на самом деле это скорее наплевательство, нежели рационализм.

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

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

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

Добывать ее проще всего двумя путями (они зачастую применяются вместе):

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

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

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

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