What should a business report actually tell the owner?
Thirteen report jobs were built for one production CRM. Eight were switched off again, and that is the most useful thing on this page.
By Eugene Romanov·Published
The short answer
A useful owner report answers three questions on a schedule: what came in, what has not moved, and what broke. The harder question is how many survive. In one production CRM thirteen report jobs were built and eight came off the schedule on a single day in May, because between them they were putting six to eight messages a weekday into this studio's own founder chat.
SHT-02What drives the number
What came in, what has not moved, what broke
Those three questions are the structure, and the thirteen job endpoints under app/api/cron/ in the wallpaper contracting CRM this studio owns and runs divide along them. What came in: morning-briefing with the day's calendar and callbacks, va-daily on yesterday's calling, resend-stats on the last day of outbound email, weekly-revenue with the subscription position. What has not moved: followup-engine sending the day's steps and reporting what it sent, followup-stats on the shape of the pipeline, lead-rescue watching for a promised callback about to come due, reminders for tomorrow's scheduled work. What broke: smoke-test, against the live site and the database. Then housekeeping that keeps the first two honest: expire-trials, inbox-cleanup, competitor-monitor and an evening prompt to write the day down. Thirteen endpoints, which is the number a proposal would quote you. The next paragraph is the number that matters.
Eight of the thirteen were switched off, and the reason is written down
Five paths are on a schedule. Four sit in vercel.json, reminders, followup-engine twice a day, expire-trials and a weekly inbox-cleanup, and a GitHub Actions workflow adds va-daily. The other eight came out of the schedule on 2026-05-15, and docs/paused-crons-2026-05-15.md says why: every one of them delivered into the same chat, this studio's own founder DM, at roughly six to eight messages a weekday, which that note calls the spam. Weekly revenue, the morning briefing, the evening prompt, the pipeline and email stats, the callback watcher, the competitor check and the health check all went quiet. None of the code was deleted; re-enabling any one of them is a line pasted back. Worth being plain about who did it: the same author added those alert crons in April and took their schedules out in commit 1e0d7e6, whose message reads 'pause the 8 founder-bot Telegram crons'. The person who wrote the reports is the person who switched them off.
What survived, and who it actually goes to
Of the five still on a clock, two go to the founder chat through lib/telegram.ts: the follow-up digest and the daily calling report. One reaches other people entirely, since reminders messages a customer's managers and installers about tomorrow's jobs, which is an instruction somebody acts on rather than a summary somebody reads. And two say nothing at all: inbox-cleanup has no messaging in it, and the single founder summary at the end of expire-trials is commented out, so the job still expires trials and stays silent. That is the pattern in what survived: a job lives if it does work instead of describing it, or if it speaks to somebody who has to act on it that day. Count your own list that way before commissioning a reporting suite.
Report only what the system can recompute
Every figure in those jobs is derived from the records at send time. The weekly revenue job reads live subscription amounts from the payment provider rather than a hardcoded price table, which is why a customer on an older plan is counted correctly instead of being quietly mapped to the current one. That is the rule generalised: a report must never carry a number that is typed somewhere else. The moment a figure exists in two places, one of them goes stale, nobody finds out, and the stale one is what lands in the message an owner makes a decision on. There are no percentages in any of this for the same reason.
What a weekly owner report should contain
Five things, and they are much the same in any service business. New work that arrived, counted rather than described. Work that is sitting still, oldest first, because age is the field that tells you something is wrong. Money in a state that is not finished: sent and unpaid, promised and uninvoiced. Anything the system tried to do and failed at, which is the section nobody builds and everybody needs. And one comparison against the week before, so the report answers is this normal rather than only what happened. If a line does not change a decision, it is decoration, and it makes the four that matter harder to see.
When you should not build reporting yet
Do not build reporting on top of records nobody trusts. If the jobs are half in a spreadsheet and half in somebody's head, a weekly summary will faithfully report the half it can see and give you confidence in a number that is wrong, which is worse than the uncertainty you have now. Fix the recording first. Do not build it if you already look at every job yourself each morning and there are eleven of them, because the report is slower than looking. And do not pay for a reporting product before you have written one week's summary by hand: fifteen minutes with a pen tells you which five lines you actually want, and that list never matches the one on a vendor's screenshot.
SHT-04General notes
The questions people actually ask.
- N01What should a weekly business report include?
- New work that arrived, work that is sitting still with the oldest first, money that is sent and unpaid or promised and uninvoiced, anything the system tried and failed at, and one comparison against the previous week. Five lines. Anything that does not change a decision makes the ones that do harder to find.
- N02Should reports go to a dashboard or to my phone?
- Send them wherever you already are, which for most owners is a chat app rather than a dashboard. A dashboard is somewhere you have to decide to go, and the deciding stops after about two weeks. Keep the dashboard for the times you need to explore rather than to notice.
- N03How often should an automated report run?
- Daily for the things that go stale within a day, such as callbacks due and follow-ups sent, and weekly for money and trend. Then take one off the schedule every time you notice you have stopped opening it. In the system described here that pruning happened all at once: eight of thirteen jobs were unscheduled on a single day, and the code was left in place in case any of them earned its way back.
- N04Can AI write the summary?
- It can, and the plumbing underneath it matters more than the wording. The rules that suppress a quiet day, the counts recomputed from records instead of typed, and the health check that speaks only on failure do more for an owner than any phrasing of the paragraph does.
- N05Should my managers and crew get the same report I do?
- No, and in the system described here they do not get a report at all. The job that messages managers and installers sends tomorrow's scheduled work, the address and the customer, which is an instruction somebody acts on rather than a summary somebody reads. Owner reports and crew notifications have different jobs, and merging them produces one message that neither audience opens.
- N06Do I need a custom build to get automated reports?
- No. If your records already live in one system, reporting on top of them is usually retainer-sized work rather than a build, and the retainers are $300, $750 and $1,500 a month. A custom CRM from $2,000 over 30 to 45 days is the answer when the records themselves are the problem.
- N07What is the first report to build?
- The one that tells you what has not moved. Everything else is comfortable reading, and the list of work sitting still is the only report that reliably makes somebody do something on the day they read it.
SHT-05Evidence
The systems this argument comes from.
Everything above was learned building these. Each sheet names the business, what the trade's arithmetic actually is, and the file in the repository that proves the capability. No client revenue and no client's customers appear on any of them.