Операционный директор решил, что диагностика нужна. Теперь ему предстоит пригласить собственника и объяснить расходы. Именно здесь покупка может остановиться, хотя на сайте всё работало.
Паспорт из предыдущей главы отвечает, что и когда покупают. Теперь восстановим решения участников от первого события до оплаты. Страницы, интеграции и поля формы подождут до главы 34.
Результат: карта покупательских решений на реальных случаях. Она войдёт в доказательства главы 33.
Начать с события
Путь начинается до сайта: запуск, потеря клиента, обязательный срок, конфликт, неудачная попытка. Человек называет проблему, оценивает последствия, вовлекает коллег, сравнивает способы, снижает риск, получает бюджет.
Описывай глаголами:
заметить → назвать → признать важность → объяснить коллегам → сравнить → проверить → согласовать риск → взять обязательство
Порядок может отличаться: участники возвращаются к прежним вопросам и пересматривают условия. Сохрани это в карте, если так происходило в реальном случае.
Единица карты: решение
Карточка перехода содержит участника, контекст, решение, неизвестность и личный риск, доказательство, обязательство, условие отказа и источник.
Операционный директор решает, вовлекать ли собственника. Риск: принести расплывчатую инициативу. Нужны последствия, применимость и границы диагностики. Переход подтверждает приглашение собственника.
Маршруты участников
Инициатор, пользователь, владелец бюджета, эксперт и человек, способный остановить проект, решают разные задачи. Ключевое решение может пройти на внутреннем совещании без подрядчика.
Отметь, кто кому передаёт смысл, что должно жить без устного сопровождения, где меняется владелец, кто блокирует и где решение совместное.
Отдельно опиши нужные каждой роли сведения. Материал, по которому инициатор распознаёт проблему, может не помочь финансам оценить риск.
Решение не равно точке контакта
Одно решение поддерживают разговор, письмо, документ или сайт. Одна страница участвует в нескольких решениях. Носитель пока не назначай.
Хорошо: «финансовый директор должен убедиться, что риск первого этапа ограничен». Рано: «нужна страница „Цены“». В первом случае ещё можно выбрать подходящее доказательство и способ его передачи. Во втором реализация уже выбрана, хотя её полезность не проверена.
Граница автоматизации, SLA, интеграции и приёмка появятся в главе 34. Сейчас только коммерческая логика.
Предполагаемая роль проекта
Выбери не больше трёх переходов, где цифровой механизм предположительно уберёт существенное препятствие. Для каждого запиши нынешний порядок, место остановки, ожидаемое поведение, человеческую работу и неизвестность до разработки.
Проект может помочь распознать ситуацию, подготовить внутренний разговор и назначить диагностику. Закрывать сложную продажу в одиночку ему необязательно. Часть решений требует личного разговора и участия сотрудников.
Проверить на историях
Прогони карту минимум через успешный, потерянный и остановленный случай. Пусть участники исправят порядок, возвраты и момент решения. Сверь слова с пересылкой документа, приглашением, данными и оплатой.
Пробелы данных переходят в очередь проверок главы 33.
Комплект карты
На выходе:
- схема решений до первого платного шага;
- карточки переходов;
- внутренние передачи между ролями;
- не больше трёх работ проекта;
- неизвестные по ущербу ошибки;
- исходные случаи проверки.
Проверь карту перед испытанием
Каждый приоритетный переход связан с паспортом, имеет наблюдаемое обязательство и подтверждён случаем или помечен гипотезой. Если команда обсуждает экран, но не может назвать решение человека, вернись к описанию покупательского пути.
В главе 33 предстоит проверить, помогают ли выбранные доказательства совершить нужные действия. До этого карту рано превращать в ТЗ.