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