← All case studies
Live internal system · Python, Google Sheets, Slack

Automated
KPI Reporting

A live small business gets an accurate morning KPI snapshot every weekday, with zero AI anywhere in the calculation path. A metric that isn't computable yet is reported as missing — never estimated, never guessed — because a wrong number reaching a real business decision is worse than no number at all.

Verified live — posting every weekday morning
CASE STUDY
THE PROBLEM

A wrong number is worse than no number.

The business needed one honest morning KPI snapshot — but a number that's wrong is worse than no number at all, and a metric that isn't computable yet needs to say so, not get filled in with a plausible-looking guess. The fix: a single deterministic pipeline, with no AI anywhere in the calculation path, that reports what it can't compute as missing instead of estimating it.
CASE STUDY
WHAT CHANGED

From "check the Sheet yourself" to a trustworthy daily number.

No single source of truth each morningOne deterministic pipeline — Sheet, then KPI calculation, then snapshot, then a Slack post — the same steps every time.
Risk of an AI-estimated number reaching a real decisionZero AI in the calculation path. Every figure is either genuinely computed or explicitly null.
Metrics that aren't tracked yetReported as missing, never guessed at and never silently dropped from the message.
Re-running the same day risked duplicate historyThe snapshot step is idempotent per calendar date — safe to re-run without corrupting the trend history.
CASE STUDY
THE STRUGGLE

The boring architecture decision was the right one.

Cloud-based scheduling was the first option on the table — it's the more "impressive" answer, no machine has to stay on. It didn't survive contact with reality: a cloud-scheduled job can't reach local secrets and files without restructuring the whole project onto a hosted git repo and reworking how credentials are handled, a much bigger rework than the scheduling problem justified. Local scheduling was the honest choice instead — which came with its own real friction, not a clean win.

Real incident

The locally scheduled script silently couldn't read its own files at first. The cause: macOS blocks background processes from touching anything under a user's Desktop folder unless the specific binary running the script is explicitly granted Full Disk Access — a protection most people only ever encounter through the GUI, not from a cron-style scheduled script. The fix was a one-time manual grant in System Settings, not a code change — the kind of environment-specific gotcha no amount of code review catches.

Picking the boring, locally-constrained option (a machine that has to stay powered on) over the impressive-sounding one (cloud scheduling) was the honest call once it was clear the impressive option couldn't actually reach the data without a rework the problem didn't justify. The same honesty applies to what's still a known gap: KPI history currently lives in a local, disposable-by-convention file as a deliberate short-term stopgap, with a standing reminder to migrate it to durable storage once enough history has accumulated to be worth protecting.
CASE STUDY
HOW IT'S BUILT

One script. No AI in the loop.

A single script pulls the source Sheet, computes every KPI it can from real, current data, appends a snapshot, and posts to the relevant Slack channels — the same sequence every weekday morning, no model call anywhere in that path. If the Sheet is unreachable, the pipeline surfaces a clear error rather than retrying silently or posting a stale number as if it were current.

Also honest about what it can't automate: the shared live dashboard link isn't refreshed by the cron job itself, because publishing it requires an active session — it updates on request ("refresh the dashboard"), not silently on a schedule. A smaller, deliberate gap rather than a hidden one.

Want a KPI pipeline you can actually trust?

Happy to talk through what your own source-of-truth reporting would look like.