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