В большинстве случаев сервисы работают с потребителем, который хотя бы в первом приближении понимает, как сделать свой выбор.
На самом деле нет.
В большинстве случаев сервисы имеют дело с посетителем, который ДУМАЕТ, что способен сделать свой выбор, совершая его, опираясь на маркетинговые ориентиры и внутренние мифологемы. И в большинстве случаев это прокатывает.
Чуть сложнее эта история устроена с сервисами, которые имеют касательство с физическим миром, поскольку реальные предметы обычно предъявляют больше требований к компетенции потребителя. Не всегда радикально, но все же.
Каноническим примером преодоления такой некомпетенции можно считать Яндекс-гуру, один из самых инновационных сервисов Маркета своего времени, сейчас почти полностью исчезнувший из него. Идея с Гуру была очень проста — подобрать потребителю товар с нужными характеристиками на основании ответов на вопросы, заданных на языке потребителя, и преобразованных затем в запрос, который бы сформулировал профессионал.
В ситуации с автоматизацией создания юридических документов проблема некомпетентности пользователя становится критичной. Но тут надо оговориться:
Значимую часть аудитории Конструктора документов FreshDoc занимают профессионалы: юристы, главные бухгалтеры. У них все хорошо с компетентностью, для них система адекватна в режиме «как есть». НО! Есть другая аудитория, для которой наш проект во многом панацея, но которые порой затрудняются с ним работать.
Казалось бы, в теории, мы оптимальны для того чтобы дать возможность дилетанту сделать себе договор самостоятельно, без привлечения юриста, и сама процедура обычно не вызывает больших вопросов. Но при этом сам путь до необходимого шаблона договора может быть очень непростым. В лучшем случае вам нужен узкоспециализированный договор с названием, которое точно известно потребителю. Какой-нибудь договор займа. В этом случае он точно знает, что хочет, как это называется не только на бытовом, но и на юридическом языке.
Все становится хуже, когда потребитель понимает, что ему в принципе нужно легализовать через договор, но не понимает, как это сформулировать. Это та самая история, когда для того чтобы задать правильный вопрос, надо уже знать половину ответа. А он не знает. Ни половины, ни четверти.
Понятно, что в большинстве случаев эту проблему можно решать, задавая наводящие вопросы на бытовом языке. Если вы можете интегрировать диалоговый бот в воронку продажи, который позволит сузить запрос до одного документа — отлично, это неплохое решение. И Очень Модное. Но если мы вернемся к правде жизни, то увидим, что мы упираемся в проблему узкого входа. Сейчас покажу.
99% людей, приходящих с поисковых машин (а это самые вкусные потребители — с горячим спросом) ожидает после клика увидеть перед собой конкретный ответ на свой запрос, а не форму с дополнительными вопросами. Загонять на форму — удваивать отказ. Дальше хуже — поле ввода может означать что угодно, в том числе поиск. Человек думает, что хитрая оптимизация привела его на вторичную поисковую машину, что довольно распространенный способ поискового спама и отваливает. Значит надо объяснять. Надеюсь, не надо говорить, что люди в большинстве своем не читают тексты, то есть это тоже дорога в тупик.
Собственно потенциальных путей решения получается два: рывком поднять компетенцию потребителя за счет легкоусвояемого формата (почти как йогурт, только полезнее) или втянуть его в коммуникацию и начать задавать необходимые бытовые вопросы по ходу пьесы.
В целом, оба пути сравнительно понятны:
В первом случае нам помогает инфографика и бинарные сравнения типа «Не знаешь что выбрать, договор купли-продажи или договор поставки? Вот тебе сравнительная табличка, вникай».
Во втором случае придумываем пошаговый сценарий, в котором настройка начинается уже после того, как в работу с документом были проинвестированы какие-то силы или время.
В качестве бонуса к первой схеме мы получаем контент, работающий с косвенными вопросами типа «сравнение договоров», ко второй — можно получать очень прикольные интерфейсные решения, которые будут вас отличать от других визуально.
