Аналитика
12%
сессий с выбранной услугой завершались без результата. В 83% таких сессий пользователь уходил из приложения в течение минуты.
Techsbook · Direct Booking
Нулевой результат поиска стал восстановленным заказом
В Techsbook клиент выбирает специалиста для установки телематики, оплачивает и отслеживает заказ. Если подходящего специалиста не было, путь обрывался в звонке или переписке с поддержкой.
Я спроектировал два связанных решения: единые правила доступности для карты и списка и передачу заказа координатору без потери услуги, адреса и времени. Вместе с командой довёл сценарий до релиза.
31%
сессий с нулевой выдачей удалось связать с последующим оплаченным заказом
раньше такого продолжения внутри продукта не было
68%
увидевших причину продолжили сценарий
и отправили запрос координатору
4,2 ч
медианное время до первого ответа координатора
94% запросов получили ответ в течение рабочего дня
Метрики собраны за первые 8 недель после релиза, без контрольной группы. База для 31% - сессии, в которых мэтчинг не нашёл подходящего специалиста. Расчёт и ограничения - в разделе 07.
Исходный сбой
Причина была видна. Заказ всё равно обрывался.
Если рядом не было специалиста с нужной сертификацией, интерфейс объяснял ограничение, но отправлял пользователя в Messages или на телефон поддержки. Услуга, адрес и время не передавались дальше - помощь существовала вне сценария бронирования.
Состояние системы
Нет сертифицированного специалиста
Следующий шаг
Начать заново через поддержку
01Диагностика
Проблемой был не отказ, а тупик после него
Карта показывала специалиста рядом, но следующий шаг не позволял его выбрать. Для одной из услуг требовалась сертификация PRO360. Я проверил аналитику, обращения в поддержку и опыт клиентов, чтобы понять масштаб сбоя до проектирования.
Поддержка
47
обращений за месяц о том, что нет специалистов. Это была вторая по частоте тема в поддержке после вопросов об оплате.
Интервью
6
интервью с клиентами после нулевой выдачи. Никто не понял, как продолжить тот же заказ без повторного ввода его деталей.
«На карте было три человека рядом. Я подумал, что приложение глючит, закрыл и позвонил в сервис напрямую».
«Я бы подождал день-два, если бы мне сказали, что кто-то этим занимается. А так - просто пусто».
Реальный экранИсходная выдача
Предложенный дизайнNo-match выдача
С PM и разработчиками мы разобрали три независимых ограничения: сертификацию, радиус и занятость. Близость на карте не означала, что специалист подходит для заказа. Решение требовало двух частей: объяснить ограничение и сохранить путь к бронированию.
02Модель
Единые правила подбора для карты и списка
Присутствие специалиста в сети не означает пригодность для конкретного заказа. Я разложил мэтчинг на пять состояний и сделал их единым источником сигналов для карты, списка и recovery-flow.
- 01
Сертифицирован и свободен
Может принять работу сейчас.
- 02
Доступен позже
Подходит, но на другое время.
- 03
Занят
Квалификация есть, возможности нет.
- 04
Нет сертификации
Не может выполнить эту услугу.
- 05
Вне радиуса
Находится вне зоны обслуживания.
Карта использует те же состояния, что и список
Цвет и пиктограмма показывают не просто присутствие специалиста, а пригодность для конкретного заказа. Легенда сохраняет смысл без необходимости открывать каждый маркер.
03Решение
Сохранить ограничения и продолжить заказ
Самое простое решение - ослабить фильтры, чтобы список никогда не был пустым. Я сравнил пять вариантов по двум критериям: остаётся ли интерфейс честным и может ли пользователь продолжить тот же заказ.
| Вариант | Правдив | Заказ жив | Вывод |
|---|---|---|---|
| Ослабить фильтры | Нет | Да | Покажет специалиста без нужной сертификации как подходящего. Непустой список ≠ успешный мэтчинг. |
| Расширить радиус с согласия | Да | Частично | Работает, когда сертифицированный специалист существует. Выход за радиус меняет travel fee и требует его согласия - это решение координатора, а не автоматический переключатель. |
| Лист ожидания «сообщим» | Да | Нет | Заказ уходит в пассив. По интервью - клиент за это время звонит в сервис напрямую. |
| Кнопка «позвонить в поддержку» | Да | Нет | Контекст заказа теряется - услугу, адрес и время придётся диктовать заново. |
| Запрос координатору с сохранённым контекстом | Да | Да | Причина названа, заказ не пересобирается, у сервиса появляется владелец. Цена - нужна операционная часть. |
Что это стоило
Выбранный вариант - единственный, который нельзя запустить силами одной продуктовой команды. Он требует очередь, владельца и SLA на стороне операций. Это и стало главным риском проекта - см. раздел 06.
04Сценарий заказа
Передать заказ координатору без повторного ввода
Сначала клиент видит причину нулевой выдачи. Затем проверяет сохранённые детали, отправляет запрос и получает статус в приложении. Координатор помогает с подбором, но не отменяет требования к квалификации.
Пользователь видит, что именно ограничивает выбор
Предложенный дизайнНет нужной сертификации
Выезд за пределы радиуса
Нет свободного времени
Проверить детали заказа
Отслеживать ход запроса
Вернуться к бронированию
Весь recovery-flow в одном проходе
От оформления заказа и проверки eligibility до запроса координатору, назначения специалиста и возвращения в обычное бронирование. На этом flow проходил тест с пользователями - см. следующий раздел.
05Проверка
Что проверка изменила в сценарии заказа
Я провёл модерируемый тест прототипа с пятью клиентами, которые раньше сталкивались с пустым результатом. Две находки изменили дизайн, ещё одна - формулировку.
Находка 1
«Send request» читали как отправку жалобы
3 из 5 сомневались нажимать: думали, что это форма обратной связи, а не продолжение заказа.
Изменил: заголовок экрана и кнопку - теперь это «Продолжить заказ через координатора».
Находка 2
Причине отказа не хватало пространственного контекста
Текст «нет сертифицированных специалистов» не объяснял, где они есть. Люди спрашивали: «А в соседнем районе?»
Изменил: сохранил переход к полной карте, где ближайшие специалисты показаны через ту же модель состояний, что и в списке.
Находка 3
Конкретный срок воспринимался как гарантия
«Within 1 business day» все прочитали как точное обещание, хотя скорость ответа зависела от загрузки координаторов.
Изменил: убрал конкретный срок из экрана подтверждения. Скорость первого ответа осталась внутренним показателем после релиза.
06Сервис
У запроса есть владелец, контроль скорости и статус
Выбранный вариант требовал операционной части. Я собрал blueprint, вынес три открытых вопроса и договорился о владельце до релиза.
Пользователь видит, почему мэтчинг не сработал
Запрашивает помощь, продукт сохраняет услугу и адрес
Заказ уходит в очередь CRM, координатор назначает специалиста
Статус возвращается в приложение
Открытый вопрос
Кто владелец запроса?
Решено: координатор смены, запросы видны в общей очереди CRM.
Открытый вопрос
Как контролировать скорость ответа?
Решено: не обещать точный срок в интерфейсе и отдельно отслеживать время до первого ответа координатора.
Открытый вопрос
Что видит пользователь, пока ждёт?
Решено: статус запроса в разделе заказов и push при назначении специалиста.
07Результат
Восстановленные заказы и работа сервиса
Релиз вышел в апреле 2026 на iOS, Android и Web. Я считал не клики, а продолжение заказа: правило остановки мэтчинга связывалось с созданным запросом и последующей оплатой.
Метрики собраны за первые 8 недель без контрольной группы. Поэтому они показывают раннее направление, а не точный причинный эффект.
Ключевой результат
31%
сессий с нулевой выдачей удалось связать с последующим оплаченным заказом. До релиза отдельного recovery-flow внутри продукта не было.
Ранний сигнал
68%
увидевших причину доходят до отправки запроса. Основной отвал - на подтверждении адреса.
Guardrail
4,2 ч
медианное время до первого ответа координатора; 94% запросов получили ответ в течение рабочего дня.
Здоровье системы
71%
нулевых результатов - из-за сертификации, не радиуса. Это стало аргументом для расширения программы обучения PRO360.
08Рефлексия
Что я изменю в следующем проекте
Надо было идти к операциям в первую неделю, а не в четвёртую.
Согласование очереди и SLA заняло две недели из шести. Если бы я начал с blueprint, а не с экранов, релиз был бы раньше.
Отвал на подтверждении адреса - это мой недосмотр.
На тесте адрес был всегда правильный. В реальности треть пользователей ищет установку не по домашнему адресу, и экран выглядит как ошибка. Следующая итерация - предлагать адрес из последнего заказа.
Самый ценный результат - не flow, а данные о причинах.
Распределение по сертификации, радиусу и занятости оказалось полезнее для бизнеса, чем сам сценарий восстановления: оно показывает, где платформе нужно расширять предложение.