A weekly ops report that checks its numbers first

Every Monday at 7am, numbers from finance, CRM, support and project tools arrive in Slack or email as a short summary of what moved and why, after being checked against last week and the source systems. Nobody spends Friday afternoon building the spreadsheet.

We reply to every inquiry within 1 working day.

Blueprint facts

Build time
3 to 6 weeks
Price band
$8,000 to $20,000
Steps
6
Components
6
Updated

In short

An automated weekly ops report pulls the same numbers every week from your finance, CRM, support and project tools, checks them for gaps and errors, calculates what changed, and writes a plain-language summary of the movements and their likely causes. It posts to Slack or email with links to the source data. Build: 3 to 6 weeks, $8,000 to $20,000.

Updated

How the parts connect

SourcesWorkflowModelOps leadFinanceQuickBooks or XeroCRMHubSpot or SalesforceHelpdeskZendesk or IntercomProjectsJira, Asana, Linear01Scheduled pullSunday night, n8n02Compute metricsSQL, not the model03Run the checksStop on a failed sourceAlert the ownerReport stops04Find the driversRecords behind a change05Write the summaryFrom the table only06Approve and postOps lead, then SlackSourcesWorkflowModelOps leadYour toolsFinance, CRM, helpdesk, projects01Scheduled pullSunday night, n8n02Compute metricsSQL, not the model03Run the checksStop on a failed sourceAlert the ownerReport stops04Find the driversRecords behind a change05Write the summaryFrom the table only06Approve and postOps lead, then Slack
Weekly ops report automationOn Sunday night a scheduled workflow pulls finance, CRM, helpdesk and project data, computes the metrics in SQL, runs checks that stop the report if a source fails, finds the drivers behind each change, has a model write the summary and posts it after the ops lead approves.
  • Model step
  • A person decides
  • Exception or feedback path

How it runs, step by step

6 steps, in the order the system runs them.

  1. Step 1

    Scheduled pull

    On Sunday night n8n or Make calls the APIs for QuickBooks Online or Xero, HubSpot or Salesforce, Zendesk or Intercom, and Jira, Asana or Linear. Raw results are stored as a dated snapshot.

  2. Step 2

    Compute the metrics

    SQL turns the raw data into the metrics in your catalog, such as cash collected, pipeline created, first response time and projects past due. The language model does no arithmetic.

  3. Step 3

    Run the checks

    Freshness, row counts, totals against the source system and week-over-week ranges are tested. Anything out of range is marked, and a failed source stops the report and alerts its owner.

  4. Step 4

    Find the drivers

    For each metric that moved past its threshold, queries pull the records behind the change: the largest deals, the ticket tags that grew, the overdue projects by owner.

  5. Step 5

    Write the summary

    A language model writes 150 to 300 words from the metric table and driver records only. Every statement must point to a number or a record, or it is not written.

  6. Step 6

    Approve and post

    For the first 4 weeks an ops lead approves the draft in Slack before it goes out. After that it posts at 7am Monday unless a check failed.

What the system is made of

The parts you own at handover, each one written up in the documentation and the runbook.

Metric catalog
One document defining each metric: source, formula, owner, normal range and the threshold that makes a change worth a sentence.
Source connectors
Read-only API pulls from each tool on a schedule, with retries and a record of the last successful sync.
Snapshot store
Postgres or BigQuery, or a Google Sheet for small teams, holding every weekly snapshot so each figure can be traced.
Check runner
SQL tests for freshness, completeness, reconciliation and range, with results stored next to the metrics.
Summary writer
A model call that receives the metric table and driver records and returns the summary with a reference for each claim.
Delivery
A Slack message or email with the summary, a compact table and links to the snapshot and source dashboards.

What it runs on and what it costs

Runs on

  • n8n or Make for scheduling and API pulls
  • QuickBooks Online, Xero or NetSuite
  • HubSpot, Salesforce or Pipedrive
  • Zendesk, Intercom or Freshdesk
  • Jira, Asana, Linear or ClickUp
  • Shopify for ecommerce teams
  • Postgres, BigQuery or Google Sheets
  • OpenAI or Anthropic API, Slack, Gmail or Outlook

Everything is set up on accounts in your name.

Build time and price

$8,000 to $20,000 per project

4 sources and one weekly report. Each extra source adds $1,500 to $4,000, depending on how clean its API is.

Build time
3 to 6 weeks
During the build
A demo of working software every week
Model and tool usage
Billed at cost, no markup
Changes after handover
$175 an hour, or a care plan
See prices for every service

What could go wrong and what stops it

The risks we design for from the first week, and how the build handles each one.

  • Wrong numbers in front of leadership

    Numbers come from SQL, never from the model. Reconciliation checks compare totals with each source system, and when a source fails the report either says so in its first line or does not go out.

  • A confident but wrong explanation

    The model may only explain a change with records it was given. When the data shows no clear driver, it writes that the cause was not found in the data and names the metric owner to ask.

  • A connector that fails without anyone noticing

    Each connector logs its last good sync. A dry run on Thursday afternoon alerts the source owner to anything stale, which leaves Friday to fix it before Monday's report.

  • Sensitive figures in the wrong channel

    The report posts to a private Slack channel or a fixed email list. API credentials are read-only, and payroll and individual compensation are excluded unless you ask for them.

  • Metric definitions drifting

    Each definition has an owner in the catalog. Changing a formula needs that owner's approval, and the next report notes the change so nobody compares unlike numbers.

How is this different from a BI dashboard?

A dashboard shows every number and waits for someone to look. This report picks the 5 to 10 numbers that moved past their threshold, says by how much, and points to the records behind the change. It arrives where leadership already reads, at the same time every week.

The two work well together. If you already run Looker Studio, Power BI or Metabase and people use it, keep it. The report links to the relevant dashboard view under each point, so a reader who wants more detail is one click away. If you have no dashboards, the snapshot store this build creates is a clean base for one later.

What the report adds is the sentence a COO would otherwise write by hand on Monday morning. An illustrative example of the output, with made-up figures:

New pipeline was $182,000, down from $240,000 the week before. Most of the gap is one deal: a $50,000 renewal moved to next quarter at the customer's request (HubSpot note, October 22). Excluding it, pipeline was flat. Support first response time rose from 2.1 to 3.4 hours; 60% of new tickets were tagged billing, following the invoice template change on October 20.

Every figure in that paragraph comes from a query, and every cause comes from a record the model was handed. That split is what keeps AI hallucination out of the numbers leadership reads.

What does a weekly ops report cost to build and run?

The build is a fixed price from $8,000 to $20,000. The low end covers 4 sources with standard APIs, one metric catalog of up to 25 metrics, one report to one channel, and the checks described above. Each extra source adds $1,500 to $4,000; the range depends on how clean its API is. A second version for another audience, such as a board summary, is priced as an addition.

Running costs are small and billed at cost with no markup:

ItemWhat to expect
Model usageOne report a week is cents per run at current API prices
OrchestrationAn n8n Cloud or Make plan, or a self-hosted n8n server
Snapshot storeA small Postgres database, BigQuery storage, or a Google Sheet at no extra cost
UpkeepSource tools change their APIs and you will add metrics

Upkeep is the line to budget for. An automation care plan from $1,500 a month covers monitoring, fixes and small changes, and usually covers several automations at once. To compare this against the hours it saves, use the method in how to measure AI automation ROI.

When should you not build this?

When fewer than 3 systems are involved, or when the company is small enough that the founder already knows the numbers. Under about 10 staff, the report tells people what they heard in the hallway.

It is also the wrong build in these cases:

  • The numbers are disputed at the source. If finance and sales disagree on what counts as revenue, automation spreads the disagreement faster. Agree the definitions first; the metric catalog is a useful forcing document even without the build.
  • Nobody needs the narrative. If leadership only wants the figures, a scheduled email with a table, built in n8n or Make with no language model, does the job for less. We will build that instead, because it is cheaper to run.
  • You already have a data team with a warehouse and dbt. Then the pulls, metrics and checks, including dbt's source freshness (opens in a new tab) checks, exist. Only the driver queries and summary writer are missing, which is a single-workflow AI automation build from $4,000.

The source tools also need usable APIs. Most finance, CRM, support and project tools have them, but some plans restrict API access, and older on-premise systems may need an export step. We check every source on the scoping call, before the fixed price. For the connector work itself, see workflow integrations and n8n vs Make vs Zapier.

Common questions about this build

The full FAQ covers pricing, ownership, data and timelines.

Which tools can the weekly ops report pull from?

Any tool with an API your plan allows you to use. The usual set is QuickBooks Online, Xero or NetSuite for finance, HubSpot, Salesforce or Pipedrive for sales, Zendesk, Intercom or Freshdesk for support, and Jira, Asana, Linear or ClickUp for projects. Spreadsheets in Google Sheets work too. We confirm access for each source before quoting a fixed price.

Can the AI get the numbers wrong?

The language model never calculates a number. Every figure comes from SQL queries over the snapshot and is checked against the source system before the summary is written. The model only describes figures it is handed and explains changes using records it is handed. If a check fails, the report says so in its first line or is held back.

How long until the first report goes out?

Usually in week 2 or 3 of the build, in shadow mode. The report goes only to the ops lead, who compares it with the manual version for 2 to 4 weeks. Once the numbers match and the summaries read right, it goes to the full list. The total build runs 3 to 6 weeks depending on the number of sources.

Do we need a data warehouse first?

No. For most companies with 10 to 500 staff, a small Postgres database or even a Google Sheet holds a year of weekly snapshots without trouble. If you already have BigQuery, Snowflake or another warehouse, we build on it. The snapshot store we create is structured so it can move into a warehouse later.

What does it need from our team each week?

After the first 4 weeks, very little. Metric owners get an alert when a check fails or a number moves outside its normal range, and they answer it. Someone owns the metric catalog and approves changes to definitions. Everything else runs on schedule, and the runbook lists who to call for each failure type.

Price your version of this system

Bring your tools and volumes to a 30-minute call. If a simpler build would do the job, we'll say so.

Request a 30-minute scoping call

Scope and price arrive in writing within 5 working days of the call.