Orium Studios

Еженедельный отчёт владельцу: что в нём должно быть

Шаблон снят не с презентации, а с двух сообщений работающей системы. Одно рассылается по расписанию, второе с мая 2026 запускают руками, и это тоже часть урока.

Автор ·Опубликовано

Короткий ответ

Сначала решается адресат, потом поля. В системе, с которой снят этот шаблон, по расписанию ходит ежедневная сводка, а денежный отчёт с 15 мая 2026 запускается руками. Порядок полей не меняется, строка с нулём не печатается вовсе, список ошибок обрезан пятью записями. Для бизнеса в США такая работа чаще идёт по ретейнеру от $300 в месяц, чем через сборку от $2 000.

SHT-02От чего зависит число

01

Сначала адресат, и только потом поля

Первое решение в отчётности не про содержание, а про то, кто именно получит текст, и принимать его надо до первой строки кода. Обе сводки, разобранные ниже, уходят через notifyFounder в lib/telegram.ts, а он шлёт ровно в один чат: единственный FOUNDER_CHAT_ID, собственный чат основателя студии в мессенджере. Это не чат владельца компании-клиента, и подменять одно другим нельзя, иначе описание системы обещает то, чего в ней нет. Рядом живёт задание другого рода: reminders пишет менеджерам и монтажникам о завтрашних работах, то есть выдаёт инструкцию на день, а не сводку. Слитые в одно, они дают текст без точного читателя.

02

Что из этого ходит по часам, а что руками

Прежде чем копировать поля, посмотри, что вообще запускается само. Под app/api/cron в той системе тринадцать директорий с заданиями, а на часах живут пять путей: четыре записаны в vercel.json и ещё один, va-daily, запускает workflow в GitHub Actions. Остальные восемь сняли с расписания 15 мая 2026 коммитом 1e0d7e6, и причина записана в docs/paused-crons-2026-05-15.md: вместе они доставляли шесть-восемь сообщений в будний день в один и тот же чат. Денежный отчёт из этих восьми первый, то есть сам он с той даты не уходит и запускается руками. Код не удалили: вернуть любое из них значит вставить строчку обратно.

03

Ежедневная сводка, поле за полем

Файл lib/followups/digest.ts собирает то сообщение, которое ходит по расписанию, и порядок в нём не меняется. Заголовок с датой. Сколько писем ушло и достигнут ли дневной потолок. Предупреждение о том, что потолок опустился сам, и только если он действительно опускался. Число настоящих ответов. Отписки, возвраты почтового сервера, автоответы об отсутствии, лиды, которых движок сам пометил мёртвыми. Затем строка про персонализацию первых писем: в файле она печатает долю, и здесь эта доля не приводится, потому что процентов на моих страницах нет. После счётчиков идут блоки: ответы, ждущие действия, здоровье очереди и сводка по темам писем. Ошибки последними.

04

Ноль не печатается, и это правило важнее любой формулировки

Каждая строка со счётчиком обёрнута в условие. Отписки появляются, только если отписки были. Возвраты, только если были возвраты. Предупреждение о потолке, только когда потолок сработал. Отчёт, который ежедневно печатает ноль напротив каждой подписи, приучает пробегать себя глазами, а тот, кто пробегает глазами, пробежит и в день, когда число не ноль. Раздел ошибок держит то же правило дважды: его нет совсем, когда ничего не сломалось, и он обрезан пятью записями с подсчётом остальных, когда сломалось. Длина сообщения тут сама несёт смысл: короткое значит тихий день, и прочитывается это раньше, чем первое слово в нём.

05

Денежный отчёт и два места, из которых он считает

Маршрут app/api/cron/weekly-revenue/route.ts печатает месячную повторяющуюся выручку, округлённую до целых долларов, число активных подписок с пробными внутри этого числа, а не рядом, сколько пришло за последние семь дней, список новых регистраций с датами и разбивку по тарифам, где самый большой вклад сверху. Запускают его с 15 мая 2026 вручную, и это не мешает скопировать два решения из него. Цену каждой подписки он читает у платёжного провайдера вживую, а не из таблицы идентификаторов, поэтому клиент на старом тарифе посчитан по тому, что платит он. И регистрации он берёт ещё и из базы: зарегистрировавшийся без подписки для провайдера невидим.

06

Что не класть в отчёт и когда его не заказывать

Не клади то, по чему нельзя действовать в день прочтения. Не клади число, набранное в одном месте и напечатанное в другом: как только факт существует дважды, одна из копий протухает, и протухшая попадает именно в то сообщение, по которому ты принимаешь решение. Не клади долю, посчитанную на маленьких числах, потому что доля прячет, насколько эти числа малы. И не заказывай отчётность, пока половина работы живёт в таблице: сводка честно отчитается по видимой половине и выдаст уверенность в неверной цифре. Если записи уже в одной системе, это обычно ретейнер, а не сборка: $300, $750 или $1 500 в месяц.

SHT-03Варианты рядом

Во что на самом деле обходится каждый путь.

ВариантЦенаСрокКомпромисс
Смотреть в систему самому каждое утро$0нетПока работ немного, это быстрее любого отчёта и не стоит ничего. Перестаёт работать не постепенно, а в первую же неделю, когда ты занят чем-то другим.
Написать одну недельную сводку рукой$015 минут один разПоказывает, какие пять строк тебе на самом деле нужны, и этот список почти никогда не совпадает со снимком экрана из презентации вендора. Делать так каждую неделю никто не будет.
Сводка по расписанию в мессенджерРетейнер от $300 в месяц, если записи уже в одной системеДниПриходит туда, где ты и так есть. Требует правил подавления: без них через две недели сообщение перестают открывать.
Дашборд внутри системыЧасть сборки от $2 000 или подписки от $99 в месяц30-45 дней для своей системыНезаменим, когда надо покопаться и сравнить. Плох как способ заметить: туда надо решить зайти, и решать это перестают примерно через две недели.

SHT-04Общие примечания

Вопросы, которые задают на самом деле.

N01Что должно быть в еженедельном отчёте владельцу?
Одно главное число, что пришло за неделю, что не сдвинулось с самым старым сверху, что система пыталась сделать и не смогла, и сравнение с прошлой неделей. Печатать в этом порядке каждую неделю: неизменный порядок и позволяет прочитать отчёт за десять секунд, а не разбирать его.
N02Почему хороший отчёт в тихую неделю короче?
Потому что строки в нём условные: счётчик с нулём не печатает строки вовсе. Из этого следует, что длина сообщения сама по себе сигнал, и понятен он раньше, чем прочитано первое слово. Отчёт одинаковой длины каждую неделю это бланк, а бланки перестают читать.
N03Можно ли верить числу в отчёте?
Только если оно пересчитано из записей в момент отправки. Денежное задание читает цену каждой подписки у платёжного провайдера вживую, а не из таблицы идентификаторов тарифов, поэтому клиент на старом тарифе посчитан по тому, что платит он. Число, набранное где-то ещё и перепечатанное сюда, однажды разойдётся с правдой молча.
N04Ошибки класть в отчёт или в лог?
В отчёт, и последними. В лог надо решить зайти, и решать это перестают недели через две. Внизу сообщения, которое ты и так открыл, ошибки видно, и они не вытесняют число, ради которого ты его открыл, а ограничение списка пятью не даёт одной плохой ночи похоронить всё остальное.
N05Кому должен приходить отчёт?
Одному названному получателю на сообщение, и решать это надо до первой строки кода. В системе выше обе сводки, и ежедневная, и запускаемая руками денежная, уходят в один чат основателя студии, а задание для менеджеров и монтажников отправляет им завтрашние работы, потому что это инструкция, а не сводка.
N06Отчёт приходит, а его никто не открывает. Что делать?
Снимать лишние с расписания, а не переписывать формулировки. В системе выше это пришлось сделать разом: восемь заданий из тринадцати ушли с расписания в один день, потому что вместе давали шесть-восемь сообщений в будний день в один чат. Код оставили на месте, чтобы возврат стоил одну строчку.

SHT-05Доказательство

Системы, из которых этот довод взялся.

Всё выше узнано на их сборке. На каждом листе названа компания, названо правило ремесла и назван файл в репозитории, который доказывает возможность. Ни выручки клиента, ни его покупателей там нет.