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