Интервью после неудачного внедрения: как отделить ожидания клиента от фактического опыта

Когда полезен такой разбор

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

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

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

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

Как подготовить результат по записи

1. Найдите исходную задачу

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

2. Разделите ожидание и полученное обещание

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

3. Восстановите последний выполненный шаг

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

4. Соберите вопросы к проверке

   У каждой версии причины укажите, что её подтвердит или опровергнет: запись демонстрации, настройка, журнал операции, повторный тест. Сохраните несколько объяснений, если данных пока недостаточно для выбора.

Для возврата к исходнику используйте опорные таймкоды. Подписывайте файл и версию: одинаковое время в двух записях указывает на разные фрагменты.

Учебный пример: подключение источника заявок не завершено

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

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

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

Заготовка для вашей записи

Скопируйте заготовку и заполните её по конкретной записи. Не переносите догадки как подтверждённые факты.

Исходная задача клиента:
Ожидаемый первый результат:
Откуда ожидание:
Что было обещано / источник:
Фактически выполненные шаги:
Где остановились:
Последствие для работы:
Версии причины и проверка:
Таймкоды:

Что проверить перед использованием

• Ожидания и обещания разделены
• Назван последний фактически выполненный шаг
• Каждая причина имеет статус и основание
• Один эпизод не распространён на всех клиентов

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