Stop rebuilding weekly reports by hand

Who this is for

This is for owners and operators who still sit in a Monday pack, a client status email, or a pipeline snapshot that dies if one person is traveling. Agencies, service firms, and product-adjacent companies all hit the same pattern: four exports, one workbook, a narrative typed from memory. If that is already the leak you feel, the focused doorway is /manual-reporting. This playbook is the longer method: how to change the report without pretending a BI project is the first move.

It is not for teams whose problem is a regulated close, a board pack with external auditors, or a data warehouse no one has agreed to fund. Those need their own scope. Do not hide them inside a weekly-ops cleanup.

Symptoms

If several of these are true in the same month, this is a live operational leak — not a tooling preference.

• The same four exports are pasted into a workbook every week, and only one person knows which tabs matter.
• Leaders ask for the number in Slack because they do not trust, or do not open, the dashboard that already exists.
• A meeting starts with twenty minutes of reconstructing last week instead of deciding this week.
• Two reports disagree on revenue, pipeline, or delivery because each uses a different date field.
• When the usual assembler is out, the pack is late or skipped.
• A new tool was bought to “visualize” the same messy exports, and the workbook is still the source people quote.
• Exception notes — refunds, paused projects, one-off retainers — live in someone’s head and never make the page.

What done looks like

Done is a working operating change, not a purchased seat or a dashboard nobody opens.

• Each number on the weekly brief has a written definition: system, field, grain, owner, and exclusions.
• The brief arrives before the decision it supports, in the channel leaders already read.
• One person can be out and the brief still goes, including a visible “source late” note.
• Unread dashboards are not treated as the deliverable.
• Only one report has been automated. The rest of the pack is still honest about being manual.
• A later dashboard, if any, is scoped after the brief is trusted.

Decisions on time beat prettier charts

A weekly report exists to change what someone does this week: hire, pause spend, call a stuck account, accept a late delivery, or leave the plan alone. If you cannot name the decision and the person, you are producing theater. Start there. “The owner reads this before Tuesday standup and decides which accounts get a call” is a job. “Leadership wants visibility” is not.

Once the decision is named, the report has a deadline that is not aesthetic. If the standup is Tuesday at 10:00, a brief that arrives Tuesday at 9:50 is on time. A dashboard that was refreshed last Thursday is not. Push beats pull for this job. People who already ignore a tab will not suddenly become analysts because the charts got nicer.

Definitions first, automation second

Write the sentence for each number before you connect anything. “New qualified opportunities this week” needs a source, a stage name, a created-at field, and a rule for junk or duplicates. “Cash collected” needs the billing system, not the CRM’s optimism. “Work in progress” needs a delivery tool the team actually updates. If two leaders would give two sentences, you do not have a definition. You have an argument. Settle the argument on paper.

Put the definition next to the number on the brief for the first month. It feels pedantic. It is how trust is built. When a number looks wrong, you want to inspect the rule, not the assembler. This is also where an operational knowledge base starts to earn its place: the report definition is a trusted source with an owner, not a comment in a cell.

Do not skip this because a vendor showed a connector. Connectors copy confusion at higher speed. The ranking guide is useful here: low data readiness means the item is not DIY automation yet. It is definition work.

Ship a push brief, not another unread dashboard

A good weekly brief is short enough to read on a phone and specific enough to act on. Aim for: what moved, what is stuck, what needs a decision, and what is unknown because a source was late. Unknown is a first-class field. Hiding a missing export inside a pretty tile is how people stop trusting the whole page.

Pick one audience. Owner and coordinator can share a brief. Client success and finance usually cannot. If someone needs a different grain, that is a second report, which means it is not in the first automation. Resist the “one dashboard for everyone” instinct. That is how you get a wall of tiles and a side conversation in email that is the real report.

Delivery path matters. Email, Slack, or a standing doc all work if the people already live there. A new login does not. If you later want a live page, it can sit behind the same brief as a link. The brief remains the product until the page is trusted.

DIY one report before you talk about a stack

Choose the report that already has a clock and a reader. Rebuild its path on paper: sources, transforms, narrative, send. Automate the assembly you can do with current tools — a scheduled export, a locked sheet, a mail merge, a simple script — and keep the narrative human if the exceptions are still verbal. The win is that the assembler is no longer the single point of failure, not that a model wrote a witty executive summary.

Failure modes to expect: a source changes a field name; a filter silently drops a customer; timezone math doubles a day; someone “helps” by editing the output instead of the definition; the brief grows until it is the old workbook in a new skin. Write those down as checks. When they happen, you want a visible break, not a quiet wrong number.

Adjacent document work — the status PDF you also rebuild, the client recap that is really the same numbers in a nicer font — belongs with document workflows and call notes to proposals. Do not fold every artifact into the weekly brief. One job per artifact.

What a definition sheet actually contains

One row per number. Name the number in the language leaders already use. Then write the system, the object, the field, the time grain, the timezone, who may change the rule, and what is excluded. Exclusions are where trust dies: refunds, internal jobs, paused retainers, test records, the founder’s side project. If those stay verbal, the brief will look “wrong” every week and people will go back to the workbook.

Add a “disputed?” column. If finance and sales do not share a sentence for revenue, the row is not ready to automate. The DIY is the meeting that produces the sentence, not a connector. Put the agreed sentence on the brief for a month even if it makes the page uglier. Ugly and trusted beats pretty and argued.

Keep the sheet next to the send path. When a source vendor renames a field, you want the assembler — human or scheduled job — to fail loudly and point at the row. Silent defaults are how a filter drops a customer and nobody notices until a meeting.

Design the meeting around the brief

If the weekly meeting still opens with “where are we?”, the brief is not in use. Change the agenda: read the brief beforehand, start with the decision list, and only open raw systems when a number is contested. The report’s job is to shorten that meeting, not to decorate it.

Give unknowns a spoken slot. “Ads export late; spend is not in this brief” is a better sentence than a guessed spend tile. If unknowns are chronic, you have a source-owner problem. That belongs on the ranking list, not as a permanent footnote.

Do not add a second verbal report for people who skipped the brief. That trains the company to ignore the send. If someone needs a different grain, write a second definition later. Do not grow the first brief until it is the old workbook again.

Failure modes after the first send

The brief grows because every stakeholder adds a vanity metric. Park those asks on a list. Most will die. The ones that survive become a second report with its own audience.

Someone edits the output to “make it look right” instead of changing the definition. That is how two truths appear. Treat output edits as incidents unless they are a signed exception for a known one-off.

A model is asked to write the narrative from the numbers and starts explaining causation it cannot see. Keep narrative to what moved, what is stuck, and what needs a decision. Causes stay human until you have a source for them.

The team buys a dashboard because the brief worked. Then they stop sending the brief. Six weeks later nobody opens the dashboard. Keep the push until the pull is proven. A dashboard is a later build, and it has to earn the same trust test: a week with the usual assembler out.

DIY vs hire

DIY if you can name the decision, lock three to seven definitions, and own one send path. A competent operator can do this without a vendor. Use the tools you already have. The first month will be part manual on purpose so you can see where the path lies.

Hire or scope a later build when you need joins across systems that do not agree, row-level permissions, or a dashboard that several teams will treat as a system of record. That is implementation. It is not inside the $997 assessment. The assessment can tell you which report to do first and what to leave on the roadmap. If you want that ranking on paper, book the assessment.

Controls before automation

Recommendations that touch customers, money, contracts, private data, or systems of record need human review, limited permissions, a log, and a fallback. Do not automate a broken path because the tool is ready.

• Every number cites a system and a field, not “as of last pull.”
• Late or missing sources produce an explicit gap, never a zero that looks like a result.
• People edit definitions and sources, not the sent brief, unless they are adding a signed exception note.
• Revenue, cash, and customer counts need a reviewer the first time a new path goes out.
• Do not let a model invent a narrative over numbers it cannot see.
• Keep the old pack available as a fallback until the new brief survives a week with the usual assembler out.

Where this sits in the fourteen asks

Reporting is one of the fourteen asks mid-market companies make. Rank it against follow-up and knowledge before you buy another charting tool. If the inventory is still a pile of demos, start with the AI work ranking playbook. If the brief keeps dying because nobody knows which document is current, you have a knowledge problem, not a chart problem.